A payment gateway sits between a merchant's application and the payment network: it encrypts and tokenises cardholder data, routes authorisation requests to the appropriate card network or payment processor, and manages the settlement and reconciliation cycle. For most FinTech companies and merchants, using an existing gateway (Stripe, Adyen, Braintree, or a regional equivalent) is the correct decision. For a specific set of companies, building a custom gateway is defensible. Understanding the boundary between these two situations requires clarity about what a gateway actually does and what the real costs of building one are. For the full picture on what this means within US FinTech compliance architecture, see our post on FinTech app development in the US.
What a Payment Gateway Does
A payment gateway handles four functions in the payment authorisation flow:
Encryption and tokenisation. Cardholder data (PAN, expiry, CVV) is encrypted at capture and replaced with a token before it touches the merchant's application. This is the primary mechanism for reducing PCI DSS scope. If the merchant's systems never see raw cardholder data, most PCI requirements do not apply to them.
Authorisation routing. The gateway routes the authorisation request to the appropriate card network (Visa, Mastercard, Amex, or local networks) and returns the authorisation response to the merchant. For multi-rail gateways, routing logic can direct transactions to the lowest-cost or highest-success-rate processor based on real-time data.
Settlement and reconciliation. After authorisation, the gateway manages the settlement process: submitting captured transactions to the processor for settlement, reconciling settlement files against authorised transactions, and handling exceptions. This is the most complex part of the gateway operationally, because settlement failures and partial settlements require investigation and manual resolution.
Dispute management. Chargebacks and retrieval requests from card networks must be processed within defined timelines (typically 30 days for response). A gateway that handles dispute management receives these requests, routes them to the merchant, collects evidence, and submits responses to the card network. Failure to respond within the timeline results in automatic loss.
Build vs Buy: The Decision Framework
The case for building a custom payment gateway is narrower than it appears. The three situations where custom gateway development is defensible:
High transaction volume with differentiated routing logic. At sufficient volume (typically $500M+ annual processing), interchange fees and processor margins represent a cost that custom routing can reduce. Companies that have negotiated direct interchange rates with card networks can route transactions to maximise approval rates while minimising cost in ways that third-party gateways do not support. This is a marginal cost optimisation that only makes sense at scale.
Unique payment rail requirements. Companies building payment infrastructure for markets with local payment rails (mobile money in Africa, UPI in India, PIX in Brazil) may find that existing gateways do not support the rails they need to reach their target market. Custom gateway development is justified when the payment method itself is not available through existing providers. FinTech software development organisations with experience across multiple payment rails can advise whether existing aggregators cover your target rails before committing to a custom build.
Data ownership requirements. Some companies have regulatory or strategic reasons to retain full ownership of their payment data, including raw transaction records, without routing data through a third-party processor. This is more common in regulated industries (banking, insurance) than in merchant payments.
The case against building is straightforward: Stripe, Adyen, and their competitors have spent years and significant engineering investment on the problems a gateway must solve. PCI DSS compliance, chargeback processing, fraud detection, and 24/7 operational support are each significant engineering undertakings. For companies that do not have one of the three justifications above, third-party gateways deliver more capability at lower total cost than custom development.
Integration Architecture Requirements
Whether building a custom gateway or integrating with a third-party provider, the application layer that interacts with the gateway has specific requirements:
Idempotency. Payment API calls must be idempotent: a transaction submitted twice (due to network retry, client timeout, or application restart) must not result in a duplicate charge. Idempotency keys should be generated by the client, passed on every submission, and stored server-side to detect and reject duplicates. This is a basic requirement that is surprisingly often missing in initial FinTech implementations.
Audit and reconciliation. Every payment event (authorisation, capture, void, refund, dispute) must be logged with sufficient detail to support reconciliation against bank settlement files and customer statements. Reconciliation runs should be automated, with discrepancies surfaced for manual review. A payment system with manual reconciliation at scale is an operational liability.
Failure handling. Payment failures are not binary. A declined transaction is different from a gateway timeout, which is different from a network error on the route to the gateway. Each failure mode requires different handling: declines should be returned to the user immediately with a clear reason code; gateway timeouts require reconciliation against the gateway's records before retrying; network errors can be retried with exponential backoff. The failure handling logic is where most of the edge cases in payment development live.
PCI DSS scope management. The integration design should minimise PCI scope from the start. Using client-side tokenisation (where cardholder data is encrypted before it reaches the merchant's servers) means the merchant's application layer never handles raw PAN data, which removes the majority of PCI DSS requirements. This is a decision that must be made at the integration design stage, not added later. For the broader compliance architecture this sits within, see our guide to FinTech app development in the US.
Frequently Asked Questions
How much does it cost to build a custom payment gateway?
A production-grade custom payment gateway requires significant investment: PCI DSS Level 1 certification (the highest level, required for gateways processing above 6 million Visa transactions per year), 24/7 operational support, fraud detection infrastructure, and chargeback management processes. Initial build cost is typically in the range of $1M to $5M for a basic implementation, with ongoing operational costs that include PCI audit fees, bank sponsorship fees, and engineering headcount. Companies evaluating custom gateway development should compare this total cost against the margin savings achievable from custom routing at their projected transaction volume.
What is the difference between a payment gateway and a payment processor?
A payment gateway handles the communication between the merchant application and the payment network: it encrypts data, routes requests, and returns responses. A payment processor handles the actual movement of funds: it settles transactions with card networks, manages the relationship with issuing banks, and deposits merchant funds. In practice, many companies (Stripe, Adyen, Square) act as both gateway and processor, which simplifies integration but creates a single point of dependency. Companies processing high volumes sometimes split these roles, using a gateway of their choice while negotiating directly with processors for settlement.
What is dynamic routing in payment gateways?
Dynamic routing is the practice of selecting the optimal processor or card network path for each transaction in real time, based on factors including authorisation success rates, interchange cost, processing fees, and network availability. At high transaction volumes, routing optimisation can meaningfully improve approval rates and reduce per-transaction cost. Third-party gateways offer some routing optimisation, but companies with direct processor relationships can implement more granular routing logic by controlling the routing layer themselves.
