PCI Proxy
Your checkout, your design, but card data never touches your server.
The card fields load in an isolated iframe from the certified environment. To the customer it looks like part of your page; for you it means you neither store nor process card data.
The difference is practical: without PCI Proxy a custom checkout pulls you into PCI DSS scope with the audit and cost that follows. With it you stay in the lightest form of compliance.
What you get
Outside PCI scope
Data never passes through your infrastructure.
Full design control
Style the fields to belong to your site.
Tokenisation
You receive a token instead of a card number.
No redirect
The customer never leaves your page.
Ready components
A JS library with validation and localisation.
Same reporting
Transactions land in the same panel.
How it works
Embed
Add the JS library and style the fields.
Entry
The customer types their card into an isolated container.
Token
You receive a token and create the payment with it.
Result
Confirmation arrives over a webhook, as usual.
The problem it solves
You want your own checkout: your colours, your fields, your flow, with no redirect to somebody else's page. The problem is that the moment a card number passes through your server, even for a millisecond, even without being stored, you fall into PCI DSS scope with the heaviest questionnaire and a requirement for an external audit.
PCI Proxy solves exactly that. The card field on your page is in fact a small iframe served from a certified environment. Visually it is indistinguishable from your own fields, because you style it. Technically the data travels from the customer's browser straight to the certified environment and never touches your infrastructure.
You receive a token. With it you do everything else: charge, refund, charge again on a subscription. The full number is not in your database, not in your logs and not in your backups.
What you gain besides peace of mind
PCI scope drops from SAQ D, which is hundreds of questions and an external audit, to SAQ A, which is around twenty questions you fill in yourself. The difference in money and time is substantial and it repeats every year.
A data breach stops being an existential risk. If someone gets into your server, there are no card numbers there. That changes both the conversation with your insurer and the conversation with your customers.
Switching provider becomes possible. When cards are tokenised in an independent environment, you are not locked in with one processor holding your data hostage.
What it looks like in practice
You add a script to the payment page and replace the number, expiry and CVC fields with ours. You style them through a settings object: font, size, colour, border, error behaviour. The customer sees no difference.
On form submit you get a token in the response and pass it to the API along with the amount. If you run subscriptions, the same token serves later charges. If you redesign the site, the fields are restyled without touching anything in the payment flow.
When you do not need PCI Proxy
There are cases where this is needless complexity, and it is more honest to name them.
If hosted checkout is good enough, meaning you do not mind the customer being redirected to a page on our domain, your PCI scope is already minimal and Proxy adds nothing. The redirect costs a little conversion, but if that difference is not material to your business, the simpler option is the better one.
If you sell only through a plugin on an off-the-shelf platform and have no front end of your own, Proxy is equally pointless. The plugin already uses a similar mechanism under the hood.
If you have no developer and will not have one, do not start with something that needs attention every time the design changes. Hosted checkout works without that care.
PCI Proxy earns its place when control of the payment flow makes money: your own application, a non-standard checkout, sales over the phone, or when you insist on not being locked to a single processor.
SAQ A against SAQ D, briefly
What changes when card data never passes through your server.
| SAQ A | SAQ D | |
|---|---|---|
| When it applies | Card data never touches your system | You process or store card data |
| Number of questions | Around twenty | Over three hundred |
| External audit | Not required | Required above certain volumes |
| Vulnerability scanning | Not required | Quarterly, by an approved vendor |
| Who completes it | You, in about an hour | Usually an external consultant |
Exact scope depends on the integration and on transaction volume. When in doubt, ask before you build.
What remains your responsibility
PCI Proxy takes away the heaviest part, but not all of it. Here is what stays with you and what moves to us.
- HTTPS across the whole site, not just the payment page
- Software kept current and known vulnerabilities closed
- Control over who has access to your admin
- Never storing CVC anywhere, for any reason
- Never sending card details by email or chat
- One SAQ A questionnaire a year
Questions about this
Will the card field look foreign?
Not if you style it. You control font, size, colour, spacing, border and error state. The whole point of the approach is that the customer never suspects the field comes from elsewhere.
What if I change processor?
Tokens are independent of any one processor. That is one of the main reasons to use this kind of solution: you are not hostage to whoever holds the card data.
Does it work with Apple Pay and Google Pay?
Yes. The wallets are added as separate buttons in the same flow and return a token the same way.
How complex is the integration?
For a standard checkout it is a few hours: a script, three replaced fields and one backend call. For a non-standard flow we set aside a day with your developer.
Can I use it for payments over the phone?
Yes, there is a mode where the agent enters the details into an isolated environment, or the customer keys them in by phone tones, so the agent never hears or sees the number.
What is the difference from hosted checkout, briefly?
With hosted checkout the customer leaves your site and returns after paying. With PCI Proxy they stay with you and only the card fields come from outside. Both reduce PCI scope to SAQ A; the difference is control over the flow.
What happens if the script fails to load for a customer?
The fields do not appear and the form cannot be submitted with incomplete data. We recommend a fallback redirect to hosted checkout, so a script blocked by a browser extension does not mean a lost order.
Ready to start accepting payments?
Send us an enquiry and you will get a concrete quote with calculated fees for your business, usually within one business day.