Payment Gateway Integration: PCI DSS Without the Pain

Scope Is the First Architecture Decision

PCI DSS compliance cost is a function of one thing: how much of your system touches cardholder data. The single most valuable payments decision you'll make is ensuring the answer is "none of it".

Modern gateways make this achievable. Hosted fields and payment elements (Stripe Elements, Adyen Components, Checkout.com Frames) mean card numbers travel from the customer's browser directly to the gateway — your servers only ever see tokens. Done properly, you qualify for SAQ A, the lightest self-assessment tier, instead of the audit-heavy tiers that come with touching PANs. The difference is measured in weeks of engineering and tens of thousands of pounds, every year, forever.

• Never log request bodies on payment routes. The most common accidental scope expansion we find in audits is card data sitting in application logs.
• Tokenise at the edge, store only tokens and last-four. Everything downstream — refunds, repeat billing, reporting — works on tokens.
• Segment payment services. Even token-only payment code benefits from being a distinct service with its own credentials, so the audit boundary is a service, not your monolith.

Pick Rails by Use Case, Not Brand

The right provider mix depends on what you're collecting and from whom:

• Cards (Stripe, Adyen, Checkout.com): best conversion for one-off and consumer payments; expect 1.4-2.9% + fixed fees. Adyen wins at scale and multi-region; Stripe wins on developer velocity.
• Direct Debit (GoCardless, or direct BACS via a sponsor bank): the UK default for recurring B2B and subscriptions — fees measured in pence and basis points rather than percent, with failure handling and retry logic that materially beats cards for churn.
• Open banking / pay-by-bank: instant settlement, no chargebacks, fees far below cards. Increasingly the right answer for high-value invoices and top-ups; conversion still trails cards for casual consumer checkout.

Most platforms we build end up multi-rail: cards for acquisition, Direct Debit for recurring revenue, open banking for large invoices. Architect for that from day one with a provider-agnostic payments service, so adding a rail is configuration, not a rebuild.

Webhooks: The Part Everyone Gets Wrong

Payment state lives at the provider and arrives asynchronously. Treat webhooks as the source of truth and your integration becomes robust; treat the redirect back to your site as truth and you will ship phantom orders.

• Verify signatures, respond fast, process async via a queue.
• Make every handler idempotent — providers redeliver, and duplicate "payment_succeeded" events must not create duplicate fulfilments.
• Reconcile daily against provider reports. Every payout should tie to the ledger; unexplained differences are found within 24 hours, not at year-end.

A payments integration isn't finished when the happy path works. It's finished when a webhook arriving twice, out of order, three days late, changes nothing.

The Reconciliation Layer Finance Will Love You For

The gap between "payments work" and "finance trusts the system" is reconciliation. Build a small internal ledger: every order, every payment intent, every payout, every fee, every refund, with provider IDs joined to your records. From that one table you get automated payout matching, dispute tracking, revenue recognition exports, and month-end that takes an hour instead of a week. This is consistently the highest-ROI component of the entire build — and it pairs naturally with automated invoice processing on the payables side.

Delivery Shape

A production payments capability — checkout, tokenised repeat billing, webhook pipeline, refunds, reconciliation ledger and finance reporting — is typically a 4-8 week fixed-price build. Week 2 includes a threat model and PCI scope review in writing, so your compliance position is a design artefact, not an afterthought.