PSP’s Payment Gateway architecture explained

A payment gateway for a PSP has two workloads that must never be confused.

The real-time path authenticates and authorizes a payment while the customer waits. The back-office path turns completed transactions into clearing records, fees, merchant balances, settlements and reports. Both use the same transaction identifiers, but they have different requirements for latency, consistency and availability.

This distinction matters when a PSP is launching a gateway, replacing a legacy platform or bringing outsourced payment infrastructure in-house. A platform can appear complete at checkout while still depending on manual reconciliation, fragmented merchant data and settlement calculations maintained in spreadsheets. Conversely, a feature-rich back office creates little value if the authorization path cannot handle duplicates, processor timeouts or an acquirer outage safely.

Payment Gateway or Acquiring Platform? Define the Scope First

The term payment gateway is used too broadly.

At its narrowest, a gateway securely accepts payment data from a merchant, sends an authorization request to an acquirer or processor and returns the result. A PSP operating a merchant acquiring business normally needs considerably more:

• merchant onboarding and configuration;
• hosted checkout, APIs, SDKs and plugins;
• tokenization and stored-credential support;
• fraud controls and 3D Secure orchestration;
• routing across acquirers and alternative payment methods;
• capture, void, refund and reversal processing;
• fee calculation, reconciliation and merchant settlement;
• reporting, user access, audit logs and operational tooling.

That broader stack is better described as a payment gateway plus an acquiring back office. If multiple acquirers, PSPs or payment methods are managed through common routing and reporting, it also includes a payment orchestration layer.

The distinction is not semantic. It determines which system owns the payment state, which party submits clearing, who calculates the merchant balance and which entity is responsible for moving funds.

Four Layers of a PSP Payment Gateway

The diagram below presents the gateway as four functional layers. It is a product and capability map, not a literal sequence in which every transaction passes through every box. For example, the merchant portal does not sit in the synchronous authorization path, while the token vault and monitoring services support several layers at once.

Layer 1: Channel and integration

This is how merchants and their customers enter the platform. It includes REST and SOAP APIs, hosted payment pages, mobile SDKs, CMS plugins and customized checkout experiences.

Its job is to normalize different integration methods into one internal payment model. Whether a payment begins in a merchant's mobile app or on a hosted page, downstream services should receive the same core data structure, identifiers and lifecycle commands.

The channel layer should remain thin. It can own presentation, field validation and secure data collection, but routing policy, retry decisions and financial logic belong on the server. Otherwise, every SDK or plugin becomes a separate version of the payment engine.

Layer 2: Experience, risk and partner services

This layer brings together the services that shape the payment experience and connect the gateway to the wider payment ecosystem:

• risk rules and external fraud-prevention interfaces;
• the 3D Secure authentication interface;
• merchant portal and operational visibility;
• acquirer and alternative payment method connectors.

These components do not all have the same latency profile. Risk checks, 3DS and the selected provider connector participate in the real-time payment flow. Merchant reporting and portal functions should operate separately so that a slow query or dashboard issue cannot delay checkout.

Acquirer and APM connectors should also isolate provider-specific formats and behaviours from the core engine. The transaction manager should not need to understand the proprietary API of every acquirer.

Layer 3: Core payment engine

The core engine controls the payment lifecycle. Its transaction manager records valid state changes across payment creation, authentication, authorization, capture, void, reversal and refund. The routing component selects an eligible provider, while failover and cascading apply controlled fallback logic when a route is unavailable or a defined result permits another attempt.

The same layer can manage subscriptions and stored-credential schedules, provided it preserves the distinction between customer-initiated and merchant-initiated transactions. FX and dynamic currency conversion services can calculate and present eligible currency options, but their rates, markups, disclosures and authorization data must remain traceable throughout the transaction.

The transaction manager is the source of truth for payment state. It is not the acquiring ledger: an authorization or capture changes the status of a payment, while the financial effect on the PSP and merchant is posted later in the back office.

Layer 4: Operations and shared services

Monitoring, user management, administrative tooling, analytics and tokenization support the entire gateway.

The token vault is shown here as a shared service because multiple channels and payment-engine components need controlled access to it. Its position in the diagram does not mean security is confined to Layer 4. Encryption, key management, access controls, audit logging, secrets management and PCI DSS controls cut across the complete stack.

The same principle applies to reliability. Event processing, webhooks, configuration management, high availability and disaster recovery are platform-wide capabilities rather than isolated features.

Where the acquiring back office fits

The four-layer gateway determines what happened to a payment and maintains its operational lifecycle. A connected acquiring back office determines what that payment means financially for the PSP and merchant.

It receives transaction, capture, clearing and dispute events from the gateway and other processing systems. It then performs reconciliation, calculates fees and reserves, posts merchant accounting entries, prepares settlements and generates payout instructions.

Keeping this boundary clear prevents online authorization from becoming dependent on finance workloads. A slow reconciliation job must not affect checkout. A portal release must not interrupt processing. A failed webhook must not alter the committed state of a payment.

The Real-Time Payment Path

1. Payment creation

The merchant creates a payment or payment intent using the gateway API, hosted payment page, mobile SDK or an approved platform integration.

The request should include a merchant-generated idempotency key. If the same request is sent again because the customer refreshed the page or the merchant did not receive a response, the gateway should return the existing payment rather than create another one.

At this point, the gateway validates the amount, currency, merchant configuration and permitted payment methods. It creates a stable internal payment identifier that will be used across authentication, authorization, capture, reconciliation and reporting.

2. Credential collection and tokenization

Card data may be collected through hosted fields, a hosted payment page, a mobile SDK or a merchant server operating within the appropriate PCI DSS scope.

Where possible, the card number is replaced with a gateway token before it reaches the merchant's systems. The token can then be used for one-click checkout, recurring payments and subsequent merchant-initiated transactions without repeatedly exposing the primary account number.

The platform must keep a clear distinction between:

• a gateway token, which represents a stored card inside the PSP's environment; and
• a network token, issued through a card network token service and restricted to a defined token requestor or usage domain.

Network tokens can improve credential security and continuity when the issuer, token service and acquiring route support the required lifecycle updates. They do not remove the need for a gateway vault, credential-on-file controls or correct recurring-payment indicators.

3. Risk assessment and 3D Secure

Authentication and authorization are separate decisions.

3D Secure allows the issuer to assess whether the person initiating an e-commerce payment is the legitimate cardholder. The PSP's 3DS Server initiates and manages the authentication flow, the card scheme's Directory Server routes the messages, and the issuer's Access Control Server decides whether the transaction can proceed frictionlessly or requires a challenge. In an app-based flow, an EMV 3DS SDK collects device information and presents the challenge within the merchant's application.

The gateway should determine when authentication is required based on regulation, merchant policy, card and transaction characteristics, and the capabilities of the selected route. It must then preserve the authentication result and submit the correct 3DS data in the subsequent authorization request.

A frictionless authentication can complete within the normal checkout flow. A challenge is customer-interactive and may take considerably longer, so its session state must survive restarts, deployments and failover between data centres.

Supporting EMV 3DS helps a PSP implement Strong Customer Authentication and request eligible exemptions. It does not, by itself, make the PSP's complete payment operation PSD2-compliant. Regulatory responsibility remains with the relevant regulated entities.

4. Route selection

Before optimizing a route, the gateway must determine which routes are eligible. A route may be excluded because the acquirer does not support the merchant's MCC, currency, country, card brand, transaction type or required authentication data.

Among the eligible routes, the engine can consider:

• issuer country and card BIN range;
• card brand, product and funding type;
• transaction currency and amount;
• merchant, MID and vertical;
• local versus cross-border acquiring;
• acquirer availability and current latency;
• expected processing cost, including relevant scheme, interchange and FX effects;
• historical authorization performance for comparable traffic.

Raw approval rate is not enough. A route receiving mainly domestic debit traffic cannot be compared directly with one receiving cross-border commercial cards. Performance should be measured on comparable transaction segments and over a statistically meaningful period.

Routing should also respect commercial and operational constraints. The cheapest route may not be the best route if it has weak issuer coverage, limited refund capability or poor operational support.

5. Authorization

The gateway or acquiring processor formats the authorization request and sends it through the selected acquirer or processing connection. The card network routes it to the issuer, which approves or declines the transaction or allows the network to respond under applicable stand-in rules.

The authorization response does not mean that money has reached the merchant. An approval normally creates an authorization hold against the cardholder's available balance. The transaction must still be captured, cleared and settled.

The gateway should durably record the response before reporting a definitive result to the merchant. Customer-facing confirmation may be synchronous, while webhooks, analytics and other downstream events are delivered asynchronously.

What Happens After Authorization

Capture, void and reversal

Depending on the merchant model, capture may occur immediately or later. Airlines, hotels, car rental businesses and marketplaces often separate authorization from capture because the final amount or fulfilment status is not known at checkout.

A void cancels an authorization before capture. A reversal releases an authorization when the transaction will not be completed or when the original outcome needs to be corrected. These operations must refer to the original authorization and preserve the complete transaction history.

Partial and multiple captures, incremental authorizations and partial refunds introduce additional state transitions. They should be explicit in the transaction model rather than represented by manually editing the original payment record.

Clearing

Clearing converts captured transactions into the financial records used by the card schemes and acquiring participants. Depending on the operating model, the gateway, acquiring processor or sponsor acquirer prepares and submits the clearing data.

The PSP must retain enough information to connect every clearing record to the original payment, authorization, authentication result, capture and merchant. Missing or inconsistent references are a major source of manual reconciliation work.

Network settlement and merchant payout

Card-network settlement and merchant payout are separate processes.

The issuer and acquirer settle their network positions through the card scheme's settlement arrangements. The acquiring back office then calculates what is owed to each merchant after fees, refunds, chargebacks, reserves, FX adjustments and other contractual deductions.

The back office may generate a payout instruction, but the actual transfer is executed by a bank, sponsor acquirer, licensed payment institution or treasury system. A software gateway should not be described as holding or moving merchant funds unless the operating entity is licensed and structured to do so.

Reconciliation

Reconciliation compares records from systems that observed different parts of the transaction lifecycle. Depending on the PSP's role, these can include:

• gateway transaction events;
• processor or acquirer authorization and clearing files;
• card-scheme reports available to the acquirer;
• bank statements and payout confirmations;
• chargeback and dispute records.

The process should identify authorization records without capture, clearing records without a matching transaction, duplicate presentments, missing refunds, incorrect fees and payout differences.

Reconciliation is most reliable when financial postings are immutable. Corrections should be recorded through linked reversing or adjustment entries rather than by overwriting the original record. This preserves an audit trail from the merchant statement back to the underlying payment events.

Duplicates, Timeouts and Safe Retry Logic

The hardest gateway failures are not clean declines. They are uncertain outcomes.

Duplicate merchant requests

A merchant may repeat a request after a network interruption. The gateway should use the same idempotency key and return the result of the original operation. Protection should exist at the API, database and downstream-connector boundaries.

The idempotency control must be deterministic. It should define how long a key remains valid, which request parameters must match, and what response is returned while the original request is still being processed.

Processor timeouts

A timeout does not mean that the issuer declined the transaction. The request may have been approved downstream while the response was lost.

The gateway should mark the result as unknown, use a status enquiry where the connector supports it and initiate a reversal when required. Sending another authorization immediately can create two approved holds or two captured payments.

Failover versus cascading

Failover handles an unavailable or degraded endpoint. Health monitoring, circuit breakers and secondary connections can move new traffic away from the affected route.

Cascading attempts another eligible route after a defined result. It must be controlled by the response code, scheme rules, acquirer agreement, authentication data and duplicate risk.

A hard decline should normally terminate the attempt. Some soft declines require the customer to authenticate, update card details or contact the issuer. Others may permit a later retry rather than an immediate switch to another acquirer. For recurring payments, retry timing and frequency should follow the applicable card-scheme rules and the merchant's customer communication policy.

The objective is not to maximize the number of attempts. It is to recover transactions that have a legitimate chance of succeeding without creating duplicate charges, excessive network fees or compliance problems.

The Acquiring Back Office

The gateway determines what happened to the payment. The acquiring back office determines what that event means financially for the PSP and merchant.

Merchant pricing and fee calculation

The tariff engine may need to support blended MDR, Interchange++, fixed fees, volume tiers, card-brand pricing, cross-border markups, refunds, chargebacks and partner commissions. Rules can differ by merchant, MID, country, currency, card product and transaction type.

The engine should calculate each component transparently enough for finance teams to explain a merchant invoice and trace it back to individual transactions.

Ledger and merchant balances

This is where balanced financial postings belong.

The ledger records amounts payable to merchants, PSP revenue, reserves, refunds, chargebacks, fees and settlement movements. Each posting should balance in the smallest currency unit and remain linked to its source transaction or adjustment.

The ledger should not be confused with the gateway's transaction state machine. The state machine records that a payment was captured or refunded. The ledger records the financial effect of that event on the PSP and merchant.

Reserves and settlement schedules

Rolling reserves, deferred settlement and payout holds are commercial risk controls. Their calculation must follow the merchant agreement and remain visible to operations and finance teams.

Settlement schedules may support T+0, T+1 or longer cycles, but the available options depend on the sponsor acquirer, funding model, banking cut-off times, currencies, merchant risk and regulatory requirements. They are not simply a gateway configuration choice.

Disputes and chargebacks

A complete acquiring platform should connect disputes to the original payment, authentication result, clearing record, merchant balance and supporting evidence. Chargebacks affect both operational workflow and financial settlement, so they cannot be treated as a reporting-only feature.

What a white-label platform actually takes off your plate

Every component above is a real build-or-buy question. For most PSPs, the honest answer ends up being: buy the parts that are expensive to get wrong, build the parts that differentiate you.

Finon's white-label gateway is built around this same four-layer shape, and it's worth being specific about which parts it actually absorbs:

The channel layer, out of the box. REST/SOAP APIs, a hosted payment page, iOS/Android SDKs, CMS plugins, and a checkout that can be fully rebranded: your logo, your colors, your domain, nothing that looks borrowed.

Routing and cascading, configured rather than coded. Dynamic routing across acquirers, automatic cascading on decline, optimization by approval rate, cost, geography, BIN, and payment method. The logic described above, without needing a team to build a routing engine from a blank page.

A vault that's already been hardened. Token generation, network token support through VTS and MDES, lifecycle management, recurring-payment handling: the one component where a first attempt in-house is the riskiest place to learn from mistakes.

3D Secure as its own certified layer. Finon's 3DS Server and SDK carry EMVCo certification and are certified by Visa, Mastercard, Amex, JCB, and UnionPay. SCA and PSD2 compliant. PA-DSS (PCI-SSF) ready. The rules engine handles 3DS v2 frictionless flow, exemptions, and risk-based authentication. The SDK runs standalone or wrapped inside a PSP's own app, and the server itself is backend-agnostic through a RESTful API, deployable on Linux, Windows, or Solaris, whatever your stack already runs on.

An integrated Back Office that can also stand alone. FinOn Back Office connects directly with the gateway to automate merchant pricing, reconciliation, reserves and settlement operations. Its tariff engine supports blended, tiered, Interchange++ and volume-based pricing, while the reconciliation engine matches gateway data against processor, acquiring and clearing records. The module also manages rolling reserves, multi-currency settlement cycles and sub-merchant payout instructions. It can be deployed as part of the complete FinOn platform or integrated separately with an existing gateway or processing environment.

A merchant portal instead of a shared spreadsheet. Real-time dashboards, settlement visibility, custom reports, invoice generation, role-based access for finance versus support versus ops.

What's left for a PSP to actually differentiate on: pricing, merchant risk appetite, which verticals to specialize in, and the relationship itself. None of that depends on whether an authorization message got formatted correctly at 3am.

The real question for a CTO and CPO evaluating this

The commercial objective is to retain control without spending years rebuilding infrastructure that does not differentiate the PSP.

Building a gateway core isn't mainly a coding problem. It's a certification and operational-scars problem. EMVCo certification, PCI-DSS scope, PA-DSS readiness, and the thousand small edge cases that only show up after processing real volume across real merchants: none of that gets replicated by a strong engineering team in year one. Often not by year three, either.

Before picking any platform, white-label or otherwise, push on these specifically:

• What's the actual approval-rate track record on routing and cascading? Not the feature list. The numbers.
• What's the vault's certification status, and who's actually audited it?
• Which schemes is the 3DS server certified against, and does that match your merchant base?
• Is settlement native to the platform, or a separate vendor integration wearing the same login page?
• What does uptime look like specifically on the authorization path? That's the layer where five minutes of downtime is a headline, not a footnote.

A payment gateway looks simple from the checkout button. Underneath, it's multiple systems with genuinely different rules stacked on top of each other, each one built by people who got the edge cases wrong a few times before they got them right. Worth treating the choice of who built yours as its own decision, not a line item on a bigger roadmap.

The architectural decision behind the Checkout

A PSP does not need to build every component to control its payment business. It does need a clear boundary between the four-layer gateway, the acquiring back office and its regulated responsibilities.

That boundary determines whether the platform can scale safely, whether finance teams can trust merchant settlement and whether a PSP can change acquirers, pricing or routing strategy without rebuilding the merchant experience.

Talk to the FinOn team about the architecture behind FinOn's white-label payment gateway, 3D Secure and acquiring back-office software.