Payment stack layers explained

(This piece covers payment stack architecture. If you're looking for Paystack, the African PSP, that's a different product.)

A merchant doing €1B+ in gross merchandise value (GMV) doesn't need another explanation of what a payment gateway is. They already have several. The problems that land on a Head of Payments' desk tend to be messier: approval rates suddenly drop 2 points in one market, and nobody can confidently explain why. Was it a processor relationship, a 3DS configuration, an aging routing rule, or something at the acquiring layer? Without a clear way to separate the stack into parts, diagnosing the problem turns into guesswork.

Most payment stack explainers miss this entirely because they're written for merchants setting up Stripe for the first time. They explain components individually but rarely connect them to the outcomes payments teams are judged on: authorization rates, conversion, cost, resilience, and operational control.

So instead of another surface-level overview, this article breaks the payment stack into three practical layers, maps each one to the business outcome it directly influences, and makes the modular-versus-unified architecture more tangible.

What is a payment stack?

A payment stack is the full set of technology and banking infrastructure that a merchant uses to accept, process, and settle payments. From the checkout experience all the way through to funds landing in the merchant's account.

In practice, that usually means a payment gateway, one or more processors or acquirers, fraud and authentication tools, and the orchestration layer tying everything together.

The term "stack" matters because, at scale, payments stop being a single-provider setup. We regularly see European marketplaces running 3–5 acquirers in parallel to improve regional approval rates, rather than relying on one provider to handle everything. Even swapping the processor behind the same gateway can change approval rates on identical card types.

That's also why simple component lists rarely tell you much. You can name every provider in the stack and still miss what's driving performance. What really determines cost, approval rates, and fraud exposure is the flow: how a transaction moves through each layer and where decisions get made at each handoff.

The three layers of a modern payment stack

Every payment stack has three separate layers, each solving a different problem, with different vendors, data, and KPIs involved. Many teams routinely blur those lines and end up solving the wrong issue entirely, buying a new gateway to fix settlement delays, or rebuilding routing logic when the real problem is PSP token lock-in at capture. Until you separate the layers clearly, it's almost impossible to identify what's broken.

Front-end: Where the customer meets the stack

The front-end is every payment surface the customer touches before a transaction leaves their device: the checkout, the payment form, the authentication flow.

That usually means one of three setups:

• Hosted checkouts where the customer is redirected to a PSP-owned page
• Drop-in widgets, embedded payment UI that the merchant controls
• Or in-app SDKs for native mobile payments

The choice has real downstream consequences for conversion, customization, and how much customer data you can collect at the point of interaction.

The front-end decision with the biggest revenue impact is usually local payment method coverage. If you're missing iDEAL in the Netherlands, PIX in Brazil, UPI in India, Przelewy24 in Poland, or wallets like Klarna and Google Pay, customers often abandon checkout long before routing or authorization even becomes relevant. In Baymard's survey of US online shoppers, 10% cited "not enough payment methods" as a reason they'd abandoned a purchase in the past three months. A large share of that is recoverable simply by aligning payment methods to the market.

Tokenization at capture is another important decision made at this layer. If card details are stored inside a PSP's proprietary vault, you usually inherit two long-term problems: weaker negotiating leverage with that provider, and painful customer re-entry flows if they ever migrate processors. At Payrails, we tackle this with our provider-agnostic Token Vault, so tokens captured at the front-end stay portable across processors instead of being trapped inside a single PSP ecosystem.

Importantly, this layer also determines what the rest of the stack can see. Device fingerprints, browser metadata, and 3DS seed data collected here are passed downstream into fraud scoring and authentication workflows. If the front-end doesn't capture the right signals, the orchestration layer has less to work with later.

The orchestration layer: Routing, retries, and risk

Orchestration sits between capture and authorization, deciding where every transaction goes, how it's protected, and what data travels with it.

The layer handles four distinct jobs:

• Routing: Which processor, which acquirer, which fallback path if the primary declines.
• Fraud and risk scoring: Real-time transaction scoring against configurable rules and ML models.
• 3DS orchestration: Deciding when to trigger authentication, which method to use, and how to pass the result downstream.
• Transaction enrichment: Attaching network tokens, card-verification outputs, and BIN data to the authorization request before it leaves the stack.

Routing is one part of orchestration. The broader layer also covers retries, authentication, enrichment, analytics, and reconciliation.

Before 2020, most enterprise merchants built this layer themselves. That changed quickly once local payment methods exploded globally and 3DS2 added far more orchestration complexity. Now, maintaining custom orchestration is increasingly expensive, which has shifted the economics heavily toward buying instead of building.

There's a meaningful distinction between routing orchestration - which focuses narrowly on routing - and a broader financial operating system model which connects analytics, reconciliation, and disputes on shared data. Payrails operates at that wider layer, combining these elements in a single modular platform rather than functioning as a standalone orchestration tool.

Back-end: Authorization, clearing, and settlement

The back-end layer is where money moves. Processors send authorization requests through the card networks, issuing banks approve or decline them, and acquirers settle funds into the merchant's account over the following 1–2 business days.

Four different players operate here:

• Processor: Routes the authorization request to the relevant card network on behalf of the merchant.
• Card network (Visa, Mastercard, Amex): Sets the rules, carries the message between the processor and the issuer, and charges scheme fees.
• Issuing bank: Approves or declines based on the cardholder's account status and fraud signals.
• Acquirer: Holds the merchant account relationship and settles funds after clearing.

Settlement timing varies by scheme and rail. Standard card rails typically settle within 1–2 business days, while systems like FedNow and SEPA Instant operate close to real time. Amex OptBlue follows its own settlement cycle entirely. The structure matters too – direct merchant accounts provide more control, while PayFac models usually prioritize faster onboarding.

Ironically, this is also the layer merchants tend to see the least clearly, which is why reconciliation problems almost always originate here rather than in front-end UX or orchestration routing. Settlement files arrive from different acquirers in different formats, on different schedules, with completely different fee structures. Once you're operating across multiple processors, the gap between what was authorized and what settled becomes difficult to reconcile manually.

Payrails' Reconciliation capability resolves this by standardizing settlement data across connected processors and acquirers, making discrepancies visible at the transaction level instead of letting them accumulate until they're uncovered by month-end finance reviews.

How each layer maps to a business outcome

That scenario we opened with at the start of this article, where approval rates drop by 2 points, and nobody can explain why, isn't an edge case. Usually, it happens when the layer causing the problem isn't the layer being held accountable for the outcome. The reality is every payment issue traces back to a specific part of the stack, and the fix almost always lives there too.

Conversion is almost always a front-end problem

As we touched on earlier, roughly 10% of shoppers in Baymard's survey cited a missing payment method as a reason they'd abandoned a checkout. In our experience, the three culprits that show up repeatedly are:

• Poor local payment method coverage.
• Slow mobile checkout performance.
• Clunky 3DS flows.

Customers rarely complain when their preferred payment method is missing. They just leave. The same thing happens with badly implemented authentication flows. You won't find those users in fraud reports or support tickets. Instead, they disappear into your conversion data.

Decline and chargeback exposure live in orchestration

Approval rates are largely an orchestration outcome. Routing logic decides which processor gets the first shot at a transaction. Retry rules decide whether a soft decline turns into recovered revenue or a lost sale. Even network token adoption matters here. Replacing raw card details with scheme-issued tokens tends to improve authorization rates because issuers simply trust tokenized transactions more.

Fraud rules create the same balancing act. Push them too hard, and legitimate customers get blocked. Too soft, and fraudulent transactions slip through. Either way, the KPI that takes the hit is usually approval rate.

Chargebacks span layers, too. Authentication signals captured at the front-end and fraud rules applied at orchestration both shape dispute risk, but chargebacks are paid at the back-end. This is why keeping chargebacks below 1% usually comes down to understanding how disputes evolve across the full payment lifecycle.

Cost and settlement speed are back-end outcomes

Effective cost is the blended percentage paid across all transactions, shaped by acquirer setup, interchange structure, and scheme fees. Once you start unpacking where those fees originate (issuer banks, card networks, cross-border assessments, routing decisions, etc.), it becomes clear that cost is fundamentally a back-end outcome, rather than just a pricing negotiation with a single PSP.

Settlement speed works the same way. Once merchants start running multiple acquirers, they can optimize simultaneously for both cost and settlement speed. This is precisely where orchestration across the orchestration and back-end layers starts delivering value far beyond approval-rate gains alone.

Modular vs unified: The architectural choice

Once the three layers are clear and mapped to the outcomes they own, the vendor question reframes itself. It stops being "which provider is best" and becomes "do I want to own the integration complexity, or trade that control for simplicity?" Both answers are legitimate for different merchant profiles.

Why some merchants opt for a unified payment stack

A single-provider stack runs everything through one vendor end-to-end, Stripe or Adyen, for example. This allows you to keep to a single contract and data model, while also eliminating the integration overhead between layers.

The limitations are equally straightforward. A single-provider stack is all-or-nothing by design, and replacing one component means replacing everything, which is precisely why pricing leverage erodes over time. A vendor who owns your entire stack knows the switching cost better than you do. Local acquiring coverage can be thin in specific markets, and a single point of failure across all three layers carries more operational risk than most merchants account for when they sign.

Single-provider stacks typically fit merchants under roughly €500M GMV operating in a single market or single currency. But treat that figure as a rough proxy rather than a hard rule. If you're at €400M running 8 payment methods across 15 markets, you may already need a different architecture. Complexity and multi-market footprint are the real triggers.

When a modular stack wins

A modular stack deploys specialized vendors at each layer: local acquiring specialists per market, a dedicated fraud tool, a separate tokenization layer, and routing logic that isn't tied to any single processor relationship. The advantages of this compound at scale. You can swap any single vendor without breaking the stack, negotiate from a position of genuine optionality, and optimize each layer independently.

The integration overhead is the tradeoff; data can fragment across vendors, and reconciliation across multiple acquirers and settlement formats becomes a time sink. Modular can work, but only if you have an effective orchestration layer to manage the complexity.

The orchestration layer is how modular stacks stay maintainable

Modular stacks need an orchestration layer that abstracts multi-vendor integration into a single API surface, a single data model, and a single reconciliation pipeline. Without it, modular stacks accumulate integration debt faster than they generate routing leverage, leaving the benefits of best-of-breed selection consumed by the overhead of maintaining them.  

Payrails is the modular financial operating system combining Payment Orchestration, Unified Analytics, Reconciliation, Chargebacks, and Token Vault into one connected universe. Dispute data, token portability, and authorization outcomes share the same data model, which means the feedback loops that improve routing, reduce chargebacks, and protect token portability across processors are native rather than manually assembled.

Map your payment stack, then fix it

The biggest payment problems usually aren't hidden inside one PSP or one failed integration. They come from not having a clear picture of how the whole stack fits together: which layer owns which outcome, where dependencies sit, and where performance is quietly leaking across the system.

That's why the most effective payment teams stop looking at orchestration as a routing feature alone. They treat it as infrastructure for improving approval rates, reducing costs, recovering failed payments, simplifying reconciliation, and creating far better visibility across the entire operation.

‍Preply took this approach with Payrails, running a modular stack powered by Payrails Orchestration, Token Vault, and Unified Analytics. The result was a 30% payment cost reduction and a 25% decrease in failure rate. The gains came from understanding the stack layer-by-layer and optimizing each part against the KPI it controls.

Most merchants already know who their payment vendors are. The harder question is whether the stack itself is designed clearly enough to expose where performance, reliability, and margin are being lost.

‍Book a demo with Payrails to see how modularity can enhance your payment setup.