PCI-Compliant WooCommerce Checkout with a PCI Proxy & 3DS2

One of my clients needed an API-based payment gateway for his WooCommerce store. API-based gateways give you full control over the checkout, but they normally come with a heavy price: if card numbers pass through your server, your whole infrastructure falls into PCI DSS scope.

For a small business, that's a nightmare. It means the long SAQ D self-assessment, secure card storage, network segmentation, regular security testing and the cost of keeping all of it up to date. It was simply too expensive and time-consuming for him.

So I built a solution using PCI Vault, a PCI proxy service. He could use an API-based gateway without his servers ever touching raw cardholder data.

The core idea: card data never reaches the merchant's server

Staying out of PCI scope is simple in principle and harder in practice: the card number must never pass through, or even near, the merchant's own infrastructure. Not in a form post, not in a log file, not in the database.

Here's the flow at a glance:

Shopper's browser ──card details──▶ PCI Vault (secure proxy)
        │                               │
        │                        token (no card data)
        ▼                               ▼
WooCommerce + wc-pci-vault plugin ──token──▶ Trust Payments (3DS2 + authorisation)
        ▲                                         │
        └──────────── signed webhooks ◀───────────┘

How the pieces talk to each other

1. Browser → PCI Vault

At checkout, the card fields are served directly by PCI Vault, not by WooCommerce. The shopper's card number, expiry date and CVV go straight from their browser to PCI Vault over a secure connection. My WordPress server never sees them.

2. PCI Vault → WooCommerce

PCI Vault returns a one-time reference token instead of the real card data. That token is what my custom plugin, wc-pci-vault, stores against the WooCommerce order. It's a harmless string with no PCI scope attached to it.

3. WooCommerce → Trust Payments, with 3D Secure 2

Using the token, the plugin asks the payment gateway, Trust Payments, to run the transaction through 3DS2 authentication:

1. a lookup step that checks whether the card is enrolled for 3D Secure,
2. authentication, either frictionless or with a challenge for the shopper (for example, approving the payment in their banking app),
3. the authorisation request itself.

All of this happens server-to-server and through redirects, referencing the token, never the card.

4. Gateway → WordPress, via webhooks

When the bank responds, Trust Payments and PCI Vault call back into the site through signed webhooks. The plugin then updates the WooCommerce order: paid, failed, or needs further action.

What this means for PCI compliance

Because the merchant's systems never store, process or transmit cardholder data, the store's PCI DSS scope shrinks dramatically. Instead of the full SAQ D, with its hundreds of requirements, a merchant in this setup typically qualifies for a much shorter self-assessment, often SAQ A, when the card fields are fully hosted by the PCI provider.

It doesn't make PCI disappear completely: the merchant still confirms compliance each year, and the site itself must stay secure. But it turns PCI from a costly infrastructure project into a short annual form. Always confirm the exact questionnaire with your acquirer or a QSA, because it depends on how the payment fields are embedded.

Why this matters for a small business

• Full control over the checkout flow and the customer experience, with no redirect to a generic payment page.
• No card data to protect on your own servers, so there's nothing for attackers to steal from your database.
• No costly PCI infrastructure: no segmented card-data network and no secure card storage to maintain.
• Strong Customer Authentication built in through 3DS2, which reduces fraud and chargebacks.

Things to get right if you build this

• Verify every webhook signature before changing an order, and reject anything that doesn't match.
• Make webhook handling idempotent. Gateways retry, so the same notification can arrive more than once.
• Never log raw request bodies on payment endpoints. Even with a proxy, keep logs free of anything sensitive.
• Test every 3DS2 path with the gateway's test cards: frictionless, challenge passed, challenge failed and abandoned.
• Keep WordPress itself secure. A compromised site could change the checkout page, so updates, strong admin security and monitoring still matter.

Final thoughts

A PCI proxy gives small businesses what used to be reserved for companies with big compliance budgets: an API-based, fully custom checkout with 3D Secure, without ever handling a card number.

Need a payment gateway integrated with WooCommerce, a PCI-proxy setup or 3DS2 support? I build secure payment integrations, including Stripe, Authorize.Net, Trust Payments and PCI-proxy setups. Tell me about your project and I'll reply within a few hours.