Payment Gateway Customisation
PSD2, PCI DSS, and regional payment methods done properly across global markets.
· Reviewed by senior engineers
01 What it is
What this service is
Payment gateway customisation is the engineering work that takes a generic payment provider integration and makes it actually fit your business — the right payment methods surfacing in the right markets, Strong Customer Authentication done in a way that does not crater conversion, network tokenisation for subscriptions, dispute handling, payout reconciliation against your accounting system, and the operational tooling your finance team needs to investigate edge cases.
We work primarily with Stripe, Adyen, Braintree, and Worldpay for global card processing, alongside region-specific providers — Klarna across the EU and US, MercadoPago and dLocal across LATAM, Razorpay and PayU for India, GrabPay and Atome for South-East Asia, AliPay and WeChat Pay for cross-border China. The goal is one coherent payment layer regardless of which providers sit behind it, with intelligent routing, smart retries on soft declines, and fall-back logic that does not lose conversions.
It is not a feature you bolt on once and forget. Regulation, fraud patterns, and customer expectations move quickly, and a payments layer that is not actively maintained quietly becomes a tax on growth.
02 What it's for
What it's for
Payment work is for any business with material payment volume and global ambitions. A US subscription business with twenty percent of revenue at risk to involuntary churn from soft declines who needs network tokenisation and smart retries; a UK retailer expanding to Germany and France who needs Klarna, SEPA, and PSD2-compliant SCA done in a way that does not destroy mobile conversion; a Brazilian marketplace that has to accept PIX, boleto, and instalment-based credit alongside cards; an APAC SaaS that needs to support local cards plus AliPay, WeChat Pay, and GrabPay across six markets.
It is also for B2B businesses where invoicing, ACH, SEPA Direct Debit, BACS, and bank-transfer reconciliation matter as much as cards. We build the queue infrastructure, reconciliation tooling, and exception workflows your finance team uses every day.
PCI DSS scope is the other reason teams hire us for this. Done badly, payments integration drags your whole platform into PCI scope. Done properly — with tokenisation, hosted fields, and strict separation — you stay in SAQ A scope with a fraction of the audit burden.
03 How to use it
How to engage devinsta
We begin with a payments review — current providers, transaction volumes by region, decline rates by method, SCA exemption usage if you are in scope, dispute and chargeback rates, and the operational pain points your finance team raises. From there we produce a payments roadmap that sequences provider rationalisation, regional method additions, and reliability work.
Delivery is staged carefully because payments are a sensitive system. Every change ships behind a feature flag, with a percentage rollout that we increase as we watch decline rates, authorisation rates, and chargeback signals in production. We never flip a payments change to one hundred percent on a Friday afternoon.
We also document the operational side: how to investigate a stuck order, how to issue partial refunds across captures, how to reconcile a daily payout against orders, how to respond to a chargeback within network deadlines. The runbooks go to your finance and operations teams alongside the engineering work.
04 How to deploy
How we deploy it
Payment logic sits in a dedicated service in your application stack — never embedded in the storefront or admin code — running on Cloud Run, Fargate, or a Workers service depending on traffic profile. The service is the only thing that talks to payment provider APIs; everything else goes through it. This keeps PCI scope tight and makes provider changes a single-service refactor rather than a platform-wide one.
Webhook ingestion is async through SQS, EventBridge, or a similar queue, with signature verification, idempotency, and retries. We never assume a webhook is the source of truth; reconciliation jobs run against the provider API hourly to catch anything the webhook stream missed. Failed webhooks land in a dead-letter queue with a replay UI for the operations team.
For PSD2 markets we implement 3D Secure 2 with exemption logic — Transaction Risk Analysis, Low Value, Trusted Beneficiary — to keep frictionless authentication rates high. We integrate with the provider's network tokenisation (Stripe Issuing tokens, Adyen network tokens) so card-on-file customers do not churn when their physical card is reissued. Observability covers authorisation rate, decline reason codes, SCA challenge rate, and chargeback rate per provider and per market, with alerting on regression. Compliance documentation — PCI DSS SAQ A attestation, PSD2 SCA flow diagrams, GDPR data-flow maps — is part of the deliverable.
05 What we provide
What you get from us
- Payments review with provider rationalisation and regional roadmap
- Integrations with Stripe, Adyen, Braintree, Klarna, MercadoPago, Razorpay, and regional providers
- PSD2-compliant SCA with exemption logic for high frictionless authentication rates
- Network tokenisation, smart retries, and intelligent decline recovery for subscriptions
- Webhook ingestion with idempotency, dead-letter queues, and a replay console
- Reconciliation tooling against accounting (NetSuite, Xero, QuickBooks, Sage)
- PCI DSS SAQ A documentation and data-flow diagrams for auditors
- Operational runbooks for refunds, disputes, chargebacks, and exception handling
FAQ
Common questions
Will adding payment customisations put us in PCI scope?
Not if we design it properly. By using tokenised payment methods, hosted fields, and never touching raw card numbers, you stay in SAQ A scope — the lightest PCI tier. We design the architecture and documentation to make that posture defensible for your assessor.
Do we need separate integrations for each region's payment methods?
Sometimes. Stripe and Adyen cover a lot of markets through a single integration, including Klarna, SEPA, iDEAL, Bancontact, and some APAC methods. For PIX, OXXO, boleto, and certain APAC providers you often need a specialist gateway like dLocal or MercadoPago. We design a unified internal payment interface so your application sees one API regardless of the providers behind it.
How do you handle subscription churn from declined cards?
Network tokenisation keeps card-on-file working even when a customer's physical card is reissued. Smart retry logic re-tries declines on a schedule informed by decline reason codes — soft declines retry, hard declines do not. Dunning emails are triggered automatically. Properly implemented, this recovers between fifteen and thirty percent of would-be churn for most subscription brands.
Can you migrate us from one payment provider to another without downtime?
Yes. We run dual-provider routing — new traffic goes to the new provider, in-flight subscriptions and customers stay on the old until we migrate the vault. Network tokens or PCI-compliant data import handles the vault migration. The whole cutover usually runs over four to eight weeks with no customer-facing disruption.