Payment gateway integration

Connecting to a payment gateway is not the hard part. The provider's sandbox will take your first authorisation inside a day, and that is usually the moment a team calls the integration done. Everything that decides whether it survives production comes after: the capture that succeeds while the webhook never arrives, the customer who taps twice, the refund that lands against a settlement which has already closed.

We treat a payment gateway integration as finished when the money reconciles - when the transactions in your database, the provider's settlement file and your ledger agree at month end, and a break in any of the three is visible to you before finance finds it.

That is a wider scope than a working checkout, and it is the scope we quote. It means idempotency on every write path, signed webhooks with replay handling, a reconciliation job with a defined break process, and enough observability that support can answer "where is my money" without opening a database console.

The failures that reach a board meeting are rarely exotic. In our experience they cluster in a short list, and each one has a known answer that has to be designed in rather than patched on.

• Webhooks that arrive twice, out of order, or not at all. Without idempotency keys and a reconciliation sweep, a retried webhook double-credits a customer and a lost one silently strands a payment.
• Optimistic status handling. Treating an authorisation as revenue is how a platform books money it never captures. The state machine has to model authorised, captured, settled and refunded as separate facts.
• Refunds and chargebacks bolted on late. They touch the ledger, the settlement file and the customer record at once, so retrofitting them is far more expensive than designing them in.
• Reconciliation left to finance and a spreadsheet. It works until volume grows, then it becomes the reason nobody trusts the numbers.

None of this is provider-specific. It is the difference between an integration that passes a demo and one that runs at GBP 10M+ in daily transactions.

Most platforms start with a single provider and a single method, and the integration is written straight into the checkout. The second method - a wallet, a local scheme, an A2A rail - is where the cost appears, because the first integration made assumptions the second one breaks.

We put an internal payment interface between your product and the providers from the start: one contract your application speaks, adapters behind it per provider and per method. Adding a wallet becomes an adapter and a configuration change instead of a second checkout.

That interface is also what makes a provider swap survivable later, and it is the foundation the payment orchestration layer sits on if you eventually run more than one acquirer.

The cheapest way to pass a PCI DSS assessment is to have nothing in scope. Wherever the architecture allows, we keep card data out of your systems entirely: the PAN is captured by the provider's hosted fields or SDK and your platform only ever holds a token.

Where a token vault genuinely is needed - typically to keep card-on-file portable across providers - we design it as a narrow, isolated service with its own access control and audit trail, rather than letting card data spread through the platform.

Your security team is right to treat a new payment provider as part of the attack surface. We document what the integration sends, what it stores, which keys exist and who can rotate them, so the review is a conversation about evidence rather than assurances.

Price follows scope, and in a gateway integration the scope drivers are concrete: how many providers and methods are in scope, whether refunds and chargebacks are included, whether settlement reconciliation is in scope, and whether the flow touches a terminal as well as a browser.

We will tell you which shape fits on the first call. A single provider with cards, refunds and reconciliation is a well-understood piece of work; the same integration plus a wallet, an A2A rail and a POS SDK is a different engagement and we will say so rather than discovering it in month two.

The reference points are real: an Android payment SDK for payabl. reached production in one month, and a credit PWA for $lana (Monetech) went live with two KYC providers and full reporting in five months. Your numbers depend on your scope, which is what discovery exists to pin down.