PCI Payment Platforms That Keep Card Data Out of Your Systems
A PCI payment platform that keeps card data out of your website, systems and staff hands, using the gateway's hosted fields and payment pages. Payment scripts are controlled and monitored, finance gets daily reconciliation, and your PCI DSS scope stays as small as it can be.
The acquirer’s annual PCI DSS reminder arrives, and nobody can say which questionnaire covers the website, the contact centre and the reception terminal. Thornacre builds the PCI payment platform that settles the question. Card data goes straight to the gateway in every channel, and finance stops reconciling by hand.
| Question | Answer |
|---|---|
| Who it is for | CTOs and IT Directors, Heads of Data, CISOs, Compliance Leads and DPOs, and COOs in any regulated organisation that takes card payments |
| The problem it solves | Card data of unknown PCI DSS scope across web, phone and in-person payments, uncontrolled payment-page scripts and manual reconciliation |
| What we deliver | Hosted payment fields, phone keypad masking, point-to-point encryption, tokenised repeat payments, script control, reconciliation and CRM integration |
| How we work | Scope reduction by design per channel, following the SAQ criteria in the PCI SSC document library and the GDS Service Manual phases |
| Regulations and standards | PCI DSS v4.0.1 and its SAQs, Payment Services Regulations 2017 strong customer authentication, UK GDPR, OWASP Top Ten |
What problem does a PCI payment platform solve?
A PCI payment platform takes card data out of your websites, phone lines and systems, so you stop carrying payment risk you cannot see. It also ends the manual work between a payment and the ledger.
The threat is rising. UK Finance reported that remote purchase card fraud cases, where criminals use stolen card details to buy online, rose 13% to 3.2 million in 2025. The UK government’s Cyber Security Breaches Survey 2025 found that 43% of businesses had a breach or attack in the past 12 months.
Each persona sees a different part of the problem:
- CTO or IT Director: signs the annual questionnaire without knowing what runs on the payment page.
- CISO: analytics tags and plugins load beside the card form, and agents hear card numbers read aloud.
- Compliance Lead or DPO: cannot evidence the SAQ type claimed, or prove call recordings hold no card numbers.
- Head of Data: payment records in the gateway portal never match the CRM.
- COO: finance rekeys transactions and refunds, and customers abandon at a clunky checkout.
The root cause is how payment channels grew: a card form added to the CMS, agents typing card numbers, terminals bought site by site. Nobody owns the whole picture: IT owns the website, operations owns the contact centre, finance owns reconciliation.
PCI DSS scope is a design decision you make channel by channel, not a form you fill in at year end.
How does Thornacre deliver a PCI payment platform?
Thornacre delivers a PCI payment platform in six steps, whatever your gateway, CMS or telephony.
- Map the payment channels. List every way you take cards (online, phone, in person, repeat billing) and where payment data must land. Outcome: a scope everyone signs off.
- Check gateway contracts. If a contract is in place, keep the existing gateway and integrate it. If not, compare Stripe, Opayo, Worldpay and Shopify against your channels. Outcome: no needless contract change.
- Take card data out of each channel. Online, hosted payment fields are card inputs the gateway serves inside your checkout page. By phone, keypad masking (DTMF masking) hides the caller’s keypad tones from the agent and the recording. In person, a validated point-to-point encryption (P2PE) solution encrypts the card in the terminal. For repeat payments, you store the gateway’s token, never the card number. Strong customer authentication runs through 3D Secure 2.
- Automate after payment. Send receipts, deliver daily reconciliation to finance and sync transactions to your CRM.
- Protect and monitor. Keep an inventory of every script on payment pages, authorise each one and watch for unexpected changes, as PCI DSS requirements 6.4.3 and 11.6.1 describe. Add a Web Application Firewall (WAF) and audit logs, following the OWASP Top Ten.
- Hand over. Finance gets daily reconciliation, and IT keeps the shortest annual SAQ each channel allows, with evidence.
The diagram shows the six steps and the gateway contract fork.
What do you get from a Thornacre PCI payment platform?
A Thornacre PCI payment platform gives each team something it keeps, including a smaller compliance scope for IT and security.
| Team | What you get |
|---|---|
| Customers | Cards and wallets online, keypad entry by phone, terminals in person, stored-card repeat payments, instant receipts |
| Finance and operations | Order dashboard, daily reconciliation across channels, CSV export, instalments with retry logic |
| Data | Payment status synced to the CRM, with one matching record per transaction |
| IT, security and compliance | The smallest SAQ per channel, a script inventory, recordings free of card data, audit logs and questionnaire evidence |
Thornacre is gateway-agnostic and connects payments to CRMs and finance platforms through our CRM and ERP integration work.
Which regulations does a PCI payment platform help you meet?
A PCI payment platform helps you meet PCI DSS, strong customer authentication under the Payment Services Regulations 2017, and UK GDPR, in any sector. The PCI Security Standards Council describes PCI DSS as “a set of baseline technical and operational requirements designed to protect payment account data”. A Self-Assessment Questionnaire (SAQ) is the form a merchant uses to validate compliance; SAQ A is the shortest.
| Cross-sector standard | What it requires | How the service addresses it |
|---|---|---|
| PCI DSS v4.0.1 | Protection of cardholder data by every entity that stores, processes or transmits it | Card data kept out of your systems, so each channel uses its shortest SAQ |
| SAQ A eligibility update (January 2025) | Merchants must “confirm their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s)” | Controlled scripts on payment pages, WAF and monitoring |
| Payment Services Regulations 2017, regulation 100 | Strong customer authentication, applied since 14 September 2019 | 3D Secure 2 built into the checkout |
| UK GDPR Article 32 | Security appropriate to the risk for customer personal data | Encryption, access control and audit logs |
The January 2025 change removed requirements 6.4.3 and 11.6.1 from SAQ A. The Council was clear that “they do not remove or diminish the underlying requirements within PCI DSS”.
Sector rules sit on top of PCI DSS. One example per sector:
| Sector | Regulation or framework | What it requires | How the service addresses it |
|---|---|---|---|
| Banking and payments | FCA operational resilience rules | Important business services mapped, with impact tolerances | Channels and gateway dependencies mapped in step 1 |
| Insurance | FCA Consumer Duty | Good outcomes for retail customers, without unreasonable barriers | Payment in every channel without needless hurdles |
| Private healthcare | UK GDPR Article 9 | Extra protection for health data, which payment records for a treatment can reveal | Only payment references pass to the gateway and finance system |
| Legal and professional services | SRA Accounts Rules | Client money kept separate, with accurate records and regular reconciliation | Each payment routed to the right account and reconciled daily |
| Public sector | Public Sector Bodies Accessibility Regulations 2018 | Accessible websites and an accessibility statement | Online checkout tested to WCAG 2.2 AA, as our accessibility service describes |
Which payment method keeps PCI DSS scope smallest per channel?
Keep card data with a validated third party in every channel. The PCI SSC’s eligibility criteria then decide each channel’s shortest questionnaire.
| Channel and method | Who handles card data | SAQ when every eligibility condition is met |
|---|---|---|
| Online: hosted fields or payment page | Gateway | SAQ A |
| Online: your page’s card form posting to the gateway | Gateway, but your page can affect it | SAQ A-EP |
| Phone: keypad masking by a compliant provider | Provider | SAQ A, if every account data function is outsourced |
| Phone: agent keys cards into a virtual terminal | Gateway, via one isolated device | SAQ C-VT |
| In person: terminals in a PCI-listed P2PE solution | P2PE solution | SAQ P2PE |
| Any channel through your own servers | Your servers | SAQ D |
For repeat payments, storing tokens instead of card numbers keeps scope where the card was first captured. Gateways such as Stripe are PCI DSS Level 1 service providers, and that status covers the gateway, not your channels.
If agents hear card numbers, move to keypad masking. If a supplier proposes posting card data through your server, ask why.
When is a custom PCI payment platform not the right choice?
A custom PCI payment platform is the wrong choice when a gateway’s standard products meet your needs.
- Simple, occasional payments. A gateway’s standard payment page or terminal is simpler, trading branding and integration for speed.
- Organisations that must store card data. Storing card numbers yourself means full PCI DSS validation, often with a Qualified Security Assessor. We design to avoid that, not to support it.
- Telephony you cannot change. Keypad masking routes calls through the masking provider; if your platform cannot, change the telephony first.
The usual objection is “our gateway is PCI compliant, so we are too.” Your payment page, its scripts, agent desktops and recordings are still yours. The PCI SSC warns that technologies used to reduce scope need to be “carefully evaluated” for their effect on security and scope.
Waiting adds risk: every new payment-page script and recorded call widens the attack surface. Our cyber security service covers the wider platform.
Frequently Asked Questions
Which payment journeys can the platform handle?
The platform handles online bookings with deposits and instalments, subscriptions and renewals, contact centre payments, payments at a desk or counter, and invoices. Each journey reuses its channel’s scope-reducing method, so adding one does not widen your PCI DSS scope.
Will hosted payment fields keep us in SAQ A?
Hosted payment fields send card data straight to the gateway, as SAQ A eligibility requires. Since January 2025, you must also confirm your site is not susceptible to script attacks that could affect the payment page. We control and monitor payment-page scripts, so you can confirm it with evidence.
How do we keep card numbers out of call recordings?
Keypad masking keeps card numbers out of call recordings. The caller types card details on their keypad, the tones are masked before the agent hears them, and the provider passes the card to the gateway. PCI DSS forbids keeping the card security code after authorisation, and the PCI SSC notes that recorded calls may store card data unnecessarily.
How does the payment platform connect to our finance system and CRM?
The payment platform sends daily reconciliation reports in a format your finance system accepts, with CSV export for audit. Transactions also sync to your CRM or line-of-business system, updating payment status. Finance stops rekeying payments, and every transaction has a matching record.
How do we start?
Start with a payment channel assessment: every way you take cards, your gateway contracts and where payment data goes. You come away with the SAQ type each channel implies today and the changes needed to shrink it. Bring your last PCI DSS questionnaire.
If your PCI DSS questionnaire is due or finance still reconciles by hand, book a payment channel assessment to find the smallest scope for each channel. Email hello@thornacre.com or see our work for regulated organisations.
This page is general guidance only; consult your acquirer, Qualified Security Assessor or compliance team for your specific PCI DSS requirements.