Payment Gateway App Development

A payment gateway is the software layer that sits between a merchant's checkout and the card networks, bank APIs, and payment scheme rails that ultimately move money. Building a payment gateway is not the same as integrating Stripe. It's the work of becoming Stripe: acquiring relationships, scheme certification, authorisation routing logic, 3DS2 challenge flows, and a reconciliation engine that can match authorisations to settlements across multiple acquirers and currencies.

Most FinTech companies and financial institutions don't need to build a full payment gateway from scratch. But the ones that do (PayFacs (Payment Facilitators) embedding payment acceptance into their platform, banks building proprietary acquiring infrastructure, and marketplaces that need to route payments across multiple merchant sub-accounts) are building one of the most technically and regulatorily complex categories of financial software.

Scrums.com provides dedicated engineering squads for payment gateway development. Our teams have built and certified payment interfaces against Vocalink (UK Faster Payments), EBA Clearing (SEPA), Visa, and Mastercard scheme specifications. Read about our work on a national payments compliance platform for context on what regulated payment infrastructure delivery looks like in practice.

Payment Gateway Architecture

The architecture of a payment gateway determines its performance, fault tolerance, and regulatory posture. The key architectural decisions your engineering team needs to get right up front:

Hosted vs. Embedded vs. Direct Integration

A hosted gateway redirects the customer to a payment page controlled by the gateway operator: simple to integrate, but you lose control over the checkout UX and hand off PCI scope to a third party. An embedded gateway (iFrame or JavaScript SDK) keeps the customer in your UX while the gateway handles card data in an isolated CDE. A direct integration takes the card data entirely into your own environment: highest integration flexibility, but full PCI-DSS SAQ D scope falls on you. Most platforms building for scale start embedded and migrate to direct only when they have the compliance infrastructure to justify it.

Authorisation and Routing Engine

The core of a gateway is the authorisation message (typically ISO 8583 or ISO 20022 format) sent to the acquiring bank, which routes it to the card network (Visa, Mastercard, Amex), which routes it to the issuing bank. Smart routing logic (routing by acquirer cost, acceptance rate, geography, card type) can materially improve authorisation rates. A 1% improvement in authorisation rate at scale is significant revenue. This routing logic is where gateway operators compete technically.

3DS2 and SCA

EMV 3-D Secure 2.x is the authentication protocol underpinning PSD2 SCA. Your gateway needs to initiate 3DS2 authentication flows, handle the challenge/frictionless decision from the ACS (Access Control Server), pass the authentication result in the authorisation message, and provide liability shift to the issuer where authentication succeeded. The data collection for 3DS2 risk-based authentication (device fingerprint, browser data, transaction history) needs to be built into the checkout flow carefully.

Tokenisation and PCI-DSS Scope

Network tokenisation (Visa Token Service, Mastercard Digital Enablement Service) replaces PANs with network tokens tied to a specific device and merchant, improving authorisation rates for recurring payments and reducing card data compromise risk. Gateway-level tokenisation isolates card data in a vault so the rest of your payment stack never touches PANs, minimising PCI-DSS scope. See our guide to PCI-DSS software delivery for the engineering decisions that determine your assessment scope.

Where Payment Gateway Projects Go Wrong

Payment gateway development fails most often in two places: underestimating scheme certification timelines and building reconciliation as an afterthought.

Visa and Mastercard scheme certification is a gated process with testing environments (VSDC, MTF), mandated test case suites, and certification windows scheduled months in advance. An engineering team that completes the development work and then discovers a 6-month certification queue has a significant problem. Certification planning needs to run in parallel with development, not after it.

Reconciliation (matching authorisation records to clearing files to settlement funds) is often treated as a reporting feature. In practice, it's a core control. A gateway that can't reconcile in real time doesn't know whether it's profitable, whether merchants have been paid correctly, or whether there's a systematic authorisation-to-settlement break that's draining funds. The reconciliation engine should be designed as a first-class component, not bolted on later.

Our legacy modernisation experience is directly relevant here: payment gateway teams inherited from acquisitions or built on legacy acquiring platforms face exactly this problem: good authorisation capability, broken reconciliation. We've also supported the FinTech engineering teams navigating these challenges.

Payment gateway platforms like these are built and delivered by dedicated engineering squads through our mobile app development service.

Payment Gateway Platform Types We Build

Different business models need fundamentally different gateway architectures. Scrums.com engineering teams have delivered across five platform categories:

E-Commerce Payment Gateway

Embedded checkout for online merchants, supporting card payments (Visa, Mastercard, Amex), digital wallets (Apple Pay, Google Pay), BNPL integrations, and bank transfer (Open Banking Pay). Hosted payment page, iFrame SDK, and direct API integration modes. 3DS2 SCA handling, network tokenisation for returning customers, and dynamic currency conversion for cross-border merchants.

Marketplace and Platform Payments

Payment routing across multiple merchant sub-accounts (PayFac model) with split payment distribution, escrow management, and payout scheduling. Regulatory compliance: PayFac registration with Visa/Mastercard, KYC/KYB for sub-merchant onboarding, and AML monitoring on marketplace transaction flows. Stripe Connect and Adyen for Platforms provide baseline infrastructure; custom gateways are needed when the platform's routing logic or regulatory requirements exceed what managed platforms support.

Card-Present and POS Gateway

Terminal management, EMV chip-and-PIN/contactless authorisation, and ISO 8583 message routing from POS hardware to acquiring hosts. Hardware abstraction layers for Verifone, Ingenico, and PAX terminals. Offline authorisation queuing for unreliable connectivity environments. TMS (Terminal Management System) for remote configuration and key injection. Relevant to our payments compliance work.

Recurring Billing and Subscription Gateway

Network tokenisation for stored credentials, MIT (Merchant-Initiated Transaction) authorisation flows under PSD2 SCA exemptions, retry logic with exponential backoff for declined transactions, and dunning management. Card updater integrations (Visa Account Updater, Mastercard Automatic Billing Updater) to reduce passive churn from expired cards. Revenue recognition reporting for subscription metrics (MRR, churn, failed payment recovery rate).

Cross-Border and Multi-Currency Gateway

FX conversion at point of authorisation (dynamic currency conversion) vs. settlement (static conversion). Local payment method support (iDEAL, Sofort, Boleto, UPI, Alipay) through payment method aggregators. Correspondent banking relationships for settlement in local currencies. Regulatory compliance varies significantly by market: payments licensing requirements in the EU (PSD2 PI licence), UK (FCA PSP authorisation), and emerging markets add materially to the delivery timeline. See our dedicated engineering team model for how we structure cross-border payment builds.

Technology Stack for Payment Gateway Development

Payment gateway development demands technology choices optimised for throughput, reliability, and security. The stacks our teams deploy:

Message Processing and Routing

Java (Spring Boot) and Kotlin for the authorisation routing and message processing core: the jPOS framework provides ISO 8583 message handling, and prowide-core handles ISO 20022 parsing. High-throughput authorisation processing benefits from non-blocking reactive frameworks (Project Reactor, Vert.x) where latency at the 99th percentile matters. Apache Kafka for authorisation event streaming and downstream clearing/settlement pipelines.

Card Data Vault and Tokenisation

HashiCorp Vault for encryption key management in the tokenisation vault. The PAN vault itself runs in an isolated network segment (CDE) with strict ingress/egress controls: typically on a dedicated AWS VPC or Azure subnet with no internet egress. Network tokenisation integrations via Visa Token Service (VTS) API and Mastercard MDES are Java/REST.

3DS2 and Authentication Services

EMV 3DS Server implementation (the component that initiates authentication requests to the DS/ACS) using certified 3DS SDKs. ThreatMetrix or Sift for device intelligence signals fed into the 3DS2 risk-based authentication data payload. FIDO2/WebAuthn for SCA on banking-embedded gateways where the issuer controls the authentication experience.

Infrastructure

AWS or Azure in multi-AZ active-active configuration with sub-100ms authorisation response time targets. Route53 or Azure Traffic Manager for geographic load balancing. Real-time observability stack: Datadog or Grafana for transaction latency, authorisation rate, and decline rate dashboards. Automated alerts for authorisation rate drops: a 5% decline rate increase at 3am is often your first signal of a scheme connectivity issue, not a business intelligence report the next morning. Explore the FinTech platform reliability work our teams have delivered.

Compliance and Certification Considerations

PCI-DSS

Any system that stores, processes, or transmits cardholder data falls within PCI-DSS scope. For a gateway operator, this means SAQ D or a full QSA assessment, network segmentation between the CDE and the rest of your infrastructure, and annual penetration testing of the CDE perimeter. The scope reduction strategies that matter most: network tokenisation (so your application layer never touches PANs), iFrame or hosted field isolation (so your checkout page never handles raw card data), and point-to-point encryption (P2PE) for card-present environments. Full detail in our PCI-DSS delivery guide.

Scheme Rules and Operating Regulations

Visa and Mastercard operating regulations are extensive documents governing everything from chargeback timeframes to surcharging rules to 3DS2 implementation requirements. Non-compliance results in fines, scheme audits, or loss of acquiring relationship. Your engineering team needs access to scheme technical specifications and needs to track scheme rule updates (published quarterly) as a live compliance obligation, not a one-time certification event.

PSD2 and Payments Licensing

Operating a payment gateway in the EU or UK requires authorisation as a Payment Institution (PI) under PSD2/PSRs 2017, or operating as an agent of an authorised PI. The technical requirements for PI authorisation include a documented security policy, operational resilience plans, and strong customer authentication implementation. These are engineering deliverables that need to be designed into the system architecture, not documented after the fact. Connect with our FinTech engineering team for guidance on structuring your build for regulatory authorisation.

Frequently Asked Questions

How long does payment gateway app development take?

A custom payment gateway (authorisation routing, 3DS2, tokenisation, basic reconciliation) takes 12 to 18 months for a first production version. Scheme certification timelines (Visa, Mastercard) add 3 to 6 months and need to run in parallel with development. Scrums.com dedicated teams mobilise within 21 days, which is critical for the early architecture and scheme certification planning phases.

Do we need to build our own gateway or can we use Stripe/Adyen?

Most businesses should use Stripe, Adyen, or Checkout.com rather than building their own gateway. Custom gateway development makes sense when: you're operating as a PayFac registering sub-merchants at scale, you need authorisation routing control across multiple acquirers for acceptance rate optimisation, your transaction volume makes the per-transaction fees on managed gateways uneconomic, or you're a bank building proprietary acquiring infrastructure. We'll tell you which category you're in before we start the build.

What is PCI-DSS and do we need it?

PCI-DSS (Payment Card Industry Data Security Standard) is a set of security controls that apply to any organisation that stores, processes, or transmits cardholder data. Any payment gateway handles cardholder data, so PCI-DSS compliance is mandatory, not optional. The specific assessment level (SAQ A, SAQ D, or full QSA assessment) depends on your integration architecture and transaction volume. Getting this wrong exposes you to scheme fines and potential loss of card acceptance privileges.

How do you handle multi-acquirer routing?

Multi-acquirer routing routes each transaction to the acquirer most likely to result in an authorisation at the lowest cost. Routing logic considers card type, issuer country, transaction currency, acquirer acceptance rates by card BIN, and acquirer pricing tiers. The routing engine needs real-time feedback loops (updating routing weights based on live authorisation data from each acquirer), not static configuration tables that go stale.

What's the difference between a payment gateway and a payment processor?

A payment gateway handles the authorisation message: routing the transaction from the merchant to the acquirer to the card network and back, in real time. A payment processor handles clearing and settlement: the batch processes that actually move funds between banks after the authorisation has occurred. Many modern platforms combine both functions, but they are architecturally distinct and have different latency, reliability, and compliance requirements.