The 10-Provider Payment Stack

What is the Modern Payment Stack?

The payment infrastructure market has split apart. Ten years ago, you could pick a PSP (Stripe or Adyen) and build on top of it. Today, moving money at scale requires orchestrating across at least ten different provider categories. Each serves a purpose. Each solves a specific problem. Together, they create a system that no single provider was designed to coordinate.

Understanding the full scope of that fragmentation is the first step toward fixing it.

What are the 10 layers of the modern payment stack?

Here is what the payment stack actually looks like for a company moving money at scale in 2026.

1. Product-layer platforms. Vertical software companies like Shopify, Square, Toast, and ServiceTitan embed payments directly into their products. Payments are part of the application experience, not a separate system. These platforms rely on underlying PSPs, banking partners, and infrastructure providers, adding another layer of abstraction between the application and the actual movement of funds.

2. Execution PSPs. At the core are providers responsible for executing payments: Stripe, Adyen, Checkout.com, Worldpay, PayPal, Nuvei, dLocal. Their role is to connect businesses to payment rails and facilitate the movement of funds. They initiate payments, report statuses, and expose APIs. They operate primarily within the execution layer. They do not, on their own, provide a complete model of how money moves across providers and internal systems.

3. Orchestration and routing. As businesses adopt multiple PSPs and payment methods, orchestration platforms like Primer, Gr4vy, Spreedly, Paydock, and CellPoint Digital manage routing across providers. They direct transactions based on geography, cost, or performance. These systems improve flexibility at the execution layer, but they do not provide a unified model for how payments behave after initiation.

4. Risk and compliance. Identity verification, fraud detection, and compliance screening run through providers like Persona, Sardine, Alloy, Unit21, Sift, and Sumsub. They evaluate users and transactions before execution. In a real-time payment environment, these decisions must happen before funds move, which shifts critical control logic outside the PSP itself.

5. Banking infrastructure. Sponsor banks like Cross River Bank, Lead Bank, Column, and Sutton Bank provide regulated accounts and access to payment networks. They hold customer funds, manage liquidity, and serve as the gateway to rails like ACH, wires, RTP, and FedNow. Essential for accessing the financial system, but operating independently from application logic and PSP APIs.

6. Card issuing. Platforms like Marqeta, Lithic, and Rain enable businesses to issue debit and credit cards as part of their offerings. They introduce additional workflows, controls, and state that must be coordinated alongside other parts of the payment stack.

7. Payment rails. The networks that actually move funds between financial institutions: ACH, wires, card networks, RTP, and FedNow. Each operates with different assumptions around timing, finality, and reversibility, creating inconsistencies that PSPs must expose or work around rather than fully abstract.

8. Stablecoin networks. Blockchain-based networks like Ethereum, Solana, Polygon, and Base introduce payment infrastructure that operates outside traditional banking systems entirely. Different settlement models, different finality guarantees, different operational considerations.

9. Banking-as-a-service. BaaS platforms like Unit, Galileo, and Treasury Prime connect fintech applications to regulated banks. They simplify access to banking infrastructure, but add another intermediary between applications, PSPs, and the underlying movement of funds.

10. The internal reconciliation layer. Businesses need a system to track balances, represent transaction state, and maintain a consistent record of financial activity over time. This layer exists because legacy PSP architectures were not built to maintain a complete, system-wide view of today's payment flows.

Why did the payment stack fragment?

This fragmentation didn't happen by accident. It happened because legacy PSPs couldn't evolve fast enough.

The original PSP model was designed for card payments: linear transaction flows, single-rail execution, synchronous settlement. When the world moved to multi-rail (cards + ACH + wires + RTP + FedNow + stablecoins), multi-geography, and asynchronous processing, the demands outgrew what any single execution-layer provider could handle.

So the market specialized. Orchestration broke off from execution. Risk and compliance became dedicated functions. Banking infrastructure remained its own layer. Stablecoin networks emerged as an alternative to traditional networks.

Each of these providers are good at their specialization. The problem is that none of them, individually, provides a complete view of money movement: how to understand it, control it, and reconcile it.

What does payment stack fragmentation cost?

For teams operating payment infrastructure across these providers, the cost is concrete.

Integration burden. Each provider has its own API, its own data model, its own status definitions. A payment marked "completed" by your PSP may still be reversible on the underlying rail. A bank may report settlement after your internal systems have already updated balances. Returns, reversals, and adjustments arrive asynchronously from different sources.

Reconciliation complexity. Finance teams need to match internal ledgers against bank activity, settlement reports, processor data, and ledger balances. When multiple providers represent the same movement of money differently, with different timing, different statuses, and different file formats, reconciliation becomes a manual investigation.

Exception handling without clear ownership. A payout fails. Was it the destination account? The wrong funding account? A compliance hold? A rail-specific cutoff? Those failures come from different providers at different times. The customer still expects a coherent answer, and the operations team still needs a process for responding.

Auditability gaps. As approvals, holds, releases, and reconciliation actions happen across multiple teams and systems, businesses need a reliable record of who did what, when, and why. With 10 providers, that audit trail is fragmented across 10 systems.

How do PSPs need to evolve?

Across all ten provider categories, one pattern is clear: each provider handles a specific function, but no single system handles the full lifecycle.

Execution lives in one provider. Risk decisions in another. Funds sit in a bank. Payment flows extend across card networks, real-time rails, and blockchain-based systems. Each exposes different data, timelines, and definitions of state.

What's missing is not another provider within the existing model. What's missing is a PSP that coordinates all of these functions, tracks state across providers, manages workflows for money movement, and maintains a reliable financial record over time.

Modern Treasury provides this layer. Through a unified API, Modern Treasury enables businesses to execute payments across traditional bank rails and stablecoin networks; maintain a consistent system of record through an internal ledger; manage workflows for approvals, funding, and exception handling; and reconcile external activity against internal business intent.

The payment stack doesn't need another point solution. It needs an integrated PSP that brings together multi-rail payments, programmable accounts, real-time reporting, and built-in compliance.

Frequently asked questions

What is a payment service provider (PSP)? A payment service provider is a company that connects businesses to payment rails and facilitates the movement of funds. Traditional PSPs like Stripe, Adyen, and Checkout.com initiate payments, report statuses, and expose APIs. In modern payment environments, PSPs operate as one layer within a broader stack of 10+ provider categories.

What is payment stack fragmentation? Payment stack fragmentation is what happens when the infrastructure for moving money is spread across multiple specialized providers, each with their own data model and API, requiring a lot of abstraction internally to create a unified layer coordinating the full payment lifecycle.

Why can't a single PSP handle the full payment lifecycle? Legacy PSPs were built for card-based, single-rail transaction flows. Modern payments span multiple rails (ACH, wires, RTP, FedNow, stablecoins), providers, and state transitions. The scope of what needs to be coordinated, from pre-execution compliance checks to post-settlement reconciliation, exceeds what execution-layer PSPs were designed to do.

What is a unified system of record for payments? A unified system of record is an internal ledger that tracks balances, represents transaction state, and maintains a consistent record of financial activity across all providers and rails. It solves the "state fragmentation" problem where the same payment appears in different states across different systems.

Read the full architectural evolution of PSPs in our Practical Guide to PSPs in 2026 here: www.moderntreasury.com/ebooks/a-practical-guide-to-psp