Payment gateway integration

Scope sets it: the number of providers and methods, whether refunds, chargebacks and settlement reconciliation are included, and whether a terminal is involved. As a reference point from our own work, 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. Discovery exists to turn your scope into a dated plan before you commit.

Yes, and it is usually the right call. We work with the acquirer, PSP or gateway you already operate and build inside your existing architecture. If the provider is genuinely the constraint - on cost, on approval rates or on a market it cannot reach - we will say so, and an orchestration layer is often the answer rather than a rip-and-replace.

By keeping card data out of your systems wherever the architecture allows: the PAN is captured by the provider's hosted fields or SDK, and your platform holds only a token. That keeps your PCI DSS scope as small as possible. Where a token vault is genuinely required, we isolate it as a narrow service with its own access control and audit trail, and document exactly what is stored and who can reach it.

More than a one-time code. Under the SCA-RTS, Commission Delegated Regulation (EU) 2018/389, the authentication code must be single-use and resistant to forgery under Article 4, the amount and payee must be dynamically linked to it under Article 5 so a changed payee invalidates the code, and the elements must be independent under Article 9 so one compromised device does not defeat both factors. The exemptions are where conversion is won or lost - transaction risk analysis under Article 18, recurring transactions under Article 14 - and applying them correctly is design work, not a provider setting.

Two that many teams have not caught up with. PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1 have been mandatory since 31 March 2025 and apply to the page a cardholder actually sees: every script loaded on it must be authorised, justified and inventoried, and there must be a mechanism that detects and alerts on unauthorised changes to the HTTP headers and page content reaching the browser. In practice that constrains tag managers and third-party scripts on checkout - a conversation worth having with marketing before the assessment rather than during it.

Through a boundary, not through the checkout. We put an internal payment interface in front of the provider so the legacy system deals with one stable contract - authorise, capture, refund, chargeback - while the adapter absorbs the provider's model. The hard part is rarely the outbound call; it is the return path, because an old system often has nowhere to receive an asynchronous webhook. That usually needs a small service to hold payment state and reconcile, which is also what makes a second provider cheap to add later.

Your engineers should own it afterwards; the question is who does it the first time. A payment integration is a small amount of code around a large amount of knowledge - decline taxonomies, idempotency, settlement timing, what a provider actually does when it is degraded - and that knowledge is expensive to acquire on a first attempt with live money. We build inside your repository and your continuous integration with your team on the work, so the knowledge transfers with the code rather than leaving when we do.

Ask them to describe a failure. A capture that succeeds while the webhook is lost, a customer who submits twice, a refund against a settlement that has already closed - a team that has run payments in production answers those immediately and with a mechanism, not a principle. Then ask what they keep out of your systems, because the right answer is card data, captured by the provider's hosted fields or SDK so your PCI DSS scope stays small. And ask who holds the tokens, because that is where lock-in actually lives.

Instant became the baseline. Under Regulation (EU) 2024/886, payment service providers in the euro area have had to be able to send instant euro credit transfers since 9 October 2025, priced no higher than an ordinary transfer, and to offer verification of payee - a check of the beneficiary name against the IBAN - from the same date. Providers outside the euro area follow by 9 July 2027. For a platform this is not only a bank problem: the name-mismatch response has to be handled in your interface, or customers abandon a payment they were about to complete.