Stablecoins are a settlement rail, not a new payment method.

Written by: Awang

Digital payments have entered the mainstream, but settlement has not.

This is the judgment of Dan Mottice, former Visa executive and founder of Beam. Visa transactions are authorized globally at any merchant, but the underlying settlement still operates via SWIFT—aggregating bulk transactions, transferring funds through cross-border wires, undergoing local regulations, holidays, multiple intermediary banks, and then the merchant waits to receive the payment. This is not a problem of Visa; it is a structural shortcoming of the entire industry, and PSPs are where this shortfall is most concentrated.

This article focuses on payment service providers (PSPs), which have evolved from mere collection tools to the core infrastructure layer governing the flow of funds, settlement, and accounting. They were initially designed for a simpler era—a single rail system, linear transaction processes, and highly bundled infrastructure.

In the modern payment environment, a „payment‟ is no longer a single transaction but a series of state transitions across multiple participants and payment rails. Today, a payment may involve: C-end applications, PSPs, anti-fraud/identity verification service providers, custodian banks, one or more payment rails, and internal accounting systems within enterprises.

Businesses must support credit cards, ACH, wire transfers, RTP, FedNow, and an increasing number of settlements based on stablecoins simultaneously. Each rail has different settlement times, failure modes, data formats, and operational requirements.

This article compiles a guide from Modern Treasury and explores how PSPs have evolved, how their underlying architecture needs to adapt to modern payment systems, and the strategies teams building payment products should adopt when choosing their next PSP.

Key Judgments

01｜Digital payments have entered the mainstream, but settlement has not. Visa allows you to authorize transactions at any merchant worldwide, but the underlying settlement still runs on SWIFT. The interface is solved, but the underlying issue is not.

02｜PSPs execute payments but do not explain the flow of funds. Stripe tells you what happened during its segment, but it cannot tell you what the actual status of that money is now. The execution layer and the record layer are two different things.

03｜Each payment rail is a set of independent operating systems, not variants of the same model. ACH can be reversed, RTP cannot; card networks can dispute, stablecoins are on-chain final confirmations. The abstraction layer of PSPs obscures these differences, but only until something goes wrong.

04｜Real-time payments eliminate the buffer; control must be shifted forward. The risk control, approval, and reconciliation logic of traditional PSPs assume „there is still time to remedy if something goes wrong.‟ RTP and FedNow make this assumption invalid. Decisions must be made before funds move, not afterward.

05｜Stablecoins are a settlement rail, not a new payment method. They do not solve the issue of the payment interface but rather the delay from „accounting completed‟ to „actual funds received.‟ The most practical implementation pathway is a sandwich structure: fiat in, on-chain transfer, fiat out; users at both ends do not need to understand stablecoins.

06｜Funds in transit can generate returns, which is almost nonexistent in traditional systems. In cross-border payments, funds may be dormant for 24 to 72 hours before settlement, without generating any returns and using up working capital. Stablecoins allow „liquid funds‟ to generate value for the first time.

07｜The biggest failure of payment operations is the inability to answer a simple question: where did this money go? Reconciliation, exception handling, liquidity management—these issues do not appear at the time of payment initiation; they emerge afterward. Without a unified coordination layer, each provider can only tell you its own segment of the story.

08｜The real strategic risk is not whether you use stablecoins. Rather, it is that competitors are using stablecoins to reconstruct their settlement costs and capital efficiency, while you are still waiting for a perfect entry moment.

1. The Historical Evolution of PSPs

Over the past two decades, the role of PSPs has fundamentally changed.

In the early e-commerce era, PSPs primarily operated as payment gateways. Their responsibilities were straightforward: connecting merchants to card networks and acquiring banks for transaction authorization and settlement.

These PSP systems were designed for a very specific world. Payments were mainly card-based, flowing through a single merchant account, following a linear lifecycle from authorization to settlement. PSPs were optimized to process transactions efficiently within this model.

In the 2010s, marketplaces, SaaS platforms, and fintech products began embedding payments directly into their offerings. Platforms needed to onboard users, split payments between multiple parties, and manage payouts. PSPs consequently expanded, introducing merchant onboarding, payout infrastructure, and fraud prevention tools.

However, despite the expanding capabilities of PSPs, their underlying architecture remains rooted in models designed for linear payment processes—primarily optimized for transaction processing rather than coordinating complex multi-step fund movements across service providers and rails.

By the early 2020s, enterprises began operating across multiple rails, regions, and scenarios. Traditional PSPs continued to bundle numerous components, allowing businesses to interact with a single platform. But as payment processes became more complex, a payment flow could span multiple steps: identity verification, risk assessment, funding decisions, rail execution, internal tracking.

This transition transformed the role of PSPs from „connectors‟ to „coordinators,‟ yet their architecture did not evolve at the same pace.

The result is that PSPs still facilitate fund transfers but operate within a more complex complete transaction payment lifecycle environment.

2. Modern PSP Payment Technology Stack

To understand the limitations of PSPs, it is essential to comprehensively understand the broader payment environment they operate in.

2.1 PSP Technology Stack

The modern payment environment is not a single platform or service provider but a layered infrastructure of components that collectively supports the movement, settlement, and accounting of funds.

Application Layer: E-commerce platforms, marketplaces, fintech apps, and SaaS products embedding payments.

PSP Layer: Responsible for executing payment instructions, such as routing transactions to card networks, initiating bank transfers, and accessing payment rails. In most cases, this underlying complexity is abstracted behind the PSP interface, allowing users to interact with a single system rather than directly facing multiple service providers involved behind the scenes.

Compliance Layer: Modern payment processes also depend on identity verification service providers, fraud detection tools, and compliance infrastructures that determine whether payments should be allowed to proceed.

Bank Layer: Custodian banks hold funds, provide regulated accounts, and support access to payment networks such as ACH, wire transfers, RTP, and FedNow.

Internal Reconciliation Layer: Systems enterprises use to track balances, indicate transaction statuses, and maintain consistent records of financial activities.

Each of the above layers plays a role in fund movement, but none can provide a complete picture of what actually happens after payment initiation. This is precisely why the internal reconciliation layer becomes indispensable.

2.2 Synchronous and Asynchronous

Traditional PSPs have a fundamental design flaw: they only manage sending out money, with no regard for what happens afterward.

The problem is that „after sending out‟ is precisely the most complicated part of payment.

The logic of the PSP's API interface is synchronous—you send a command, it returns a result. But real fund movements are asynchronous: settlements are completed afterward, failures surface with delays, and refunds and reversals can pop back at any moment. This mismatch creates a persistent information black hole.

The specific manifestation of the black hole is fragmented states:

No single node can tell you what the actual status of this money is at this moment.

For instance, when a marketplace's seller withdraws funds, the entire process is a long chain: verification → risk compliance → confirmation of funds → issuing instruction → rail execution → returning confirmation → post-settlement → updating ledgers. PSP only covers several middle steps; the initial decisions and subsequent reconciliations fall outside its responsibilities. If this payout fails or is reversed, no system can provide a complete answer.

This is the purpose of the internal reconciliation layer: it does not replace the PSP in executing payments, but establishes a unified observation layer above the entire chain—translating asynchronous events from different service providers, at different times, and in different formats into a single reliable state that the enterprise can trust. No matter how many intermediaries the money flows through, there is always a place that can answer that most fundamental question: where is the money now.

3. Limitations of Traditional PSPs in Payments

The abstraction layer of traditional PSPs is built around card payments—authorization, capture, and settlement, with a predictable lifecycle. While there are exceptions (such as disputes and chargebacks), the overall structure is predictable and well understood. This model has shaped the design approach of PSPs.

With the emergence of new payment methods, PSPs have broadened their support to encompass more rails, but the behavior of these rails differs from that of card payments and does not conform to the same assumptions:

• ACH transfers: introduce delays and the potential for chargebacks within days after payment initiation.
• Wire transfers: settle faster but often require manual processes and are costlier.
• Real-time payment networks like RTP and FedNow: enable instant fund movement, but transactions are typically irreversible once completed.
• Stablecoin transfers: operate on entirely different infrastructures, carrying different assurance mechanisms and operational considerations.

For example, taking a U.S. company's payment to a supplier in the Philippines:

• Using ACH, it arrives in T+2, but Filipino banks do not directly accept ACH, requiring one more local rail routing; actual arrival may be T+4, and there is always a risk of chargeback due to mismatched account information.
• Using a wire transfer, it's faster, but it has to be submitted before the afternoon 3 PM wire cut-off, with holidays causing delays, and SWIFT fees ranging from $25 to $45, with the recipient's bank possibly charging an intermediary fee, leading to discrepancies in the final arrival amount compared to the sent amount.
• Using a stablecoin sandwich, USDC is sent from a U.S. account, confirmed on-chain in seconds, and the Filipino partner receives it and converts it to pesos in their local account, all within an hour and costing less than 1% of the transfer amount.

The three pathways represent the same amount of money but differ by 96 hours in settlement time, cost by several dozen dollars, and traceability is entirely different. This is not a difference in product experience; it is a divergence between three operational systems. The abstraction layer of PSPs cannot mask these differences but can only push the discrepancies upward for developers and operations teams to digest.

These are not variations of the same payment model; they are fundamentally different operating models.

The traditional PSP's response has been to expose different APIs and state definitions for each rail—without genuinely unifying the differences but merely pushing them up to developers. Engineering teams began writing special logic for each rail, operations teams started manually handling different failure modes, and finance teams began reconciling seemingly similar transactions that followed entirely different pathways.

This is abstraction leakage: the complexity of rails that should have been shielded now begins to seep into the application layer.

As more rails are added, the payment environment transforms into a series of loosely connected integrations rather than a unified abstraction layer. On slower rails, delays provide time windows to detect issues. On real-time rails, this window disappears—payments settle within seconds; errors cannot be easily reversed, and decisions must be made before fund movement, not afterward.

4. Real-time Payments Force PSPs to Shift Control Forward

The shift to real-time payment networks not only accelerates the speed of fund movement but fundamentally alters the design requirements for payment infrastructure.

During the ACH and wire transfer era, time was a buffer.

ACH might require days for settlement, card transactions can initiate disputes after authorization, and wires often involve manual review steps. Though these delays cause efficiency losses, they also provide opportunities to detect errors, intervene in suspicious activities, and reconcile before final settlement.

Traditional PSP models are built around this buffer.

However, real-time payment networks like RTP and FedNow utterly dismantle this assumption. Funds move directly between accounts within seconds; once a payment is completed, it is typically irreversible.

• Fraud detection must be completed much earlier
• Compliance screening must be conducted in real-time
• Funding decisions must be accurately completed at the moment the payment is released
• Opportunities for post-error correction no longer exist

Platforms providing instantaneous payouts cannot rely on workflows designed for delayed settlement. Internal systems managing payment funds across multiple accounts cannot ascertain liquidity at the moment of execution. Customer service teams cannot promise reversibility when the underlying rails simply do not allow it.

The consequence is a shift in responsibility: PSPs must evolve to support those internal systems making decisions about when payments should execute. In other words, control must shift forward.

The payment infrastructure must be designed so that approval, funding logic, risk checks, and status validations occur before movement of funds, not afterward. This requires a more coordinated view of balances, transaction statuses, and cross-provider conditions than traditional PSP architectures can offer.

Real-time rails are not the end state; they are merely a turning point. Once stablecoins come in, the issues will further elevate.

5. Stablecoins: A New Rail, Not a New Payment Method

The most common misunderstanding about stablecoins is treating them as a type of new payment product. They are not. They are a new settlement rail, addressing the delay between „accounting completed‟ and „actual funds received.‟

Unlike cards, ACH, or wire transfers, stablecoin transactions operate on blockchain networks:

• Settlement occurs continuously, rather than through batch processing
• Near-instant final confirmation is possible (depending on the network)
• Available 24×7, unaffected by bank cutoff times and holidays
• Independent from specific domestic payment systems
• Tracking of balances, ownership, and transaction history uses entirely different primitives

Traditional PSP architectures are built around the integration of banks and payment networks, while stablecoins introduce networks that do not rely on these intermediaries. Origin, settlement, and accounting occur outside the original design. A business may need to coordinate bank rails, real-time networks, and on-chain settlement simultaneously, each with different assumptions regarding finality, timing, and control—these differences cannot be unified through a single API, making it increasingly difficult for PSPs to maintain their position as a single abstraction layer.

Just as real-time payment systems challenge assumptions about timing and reversibility, stablecoins challenge assumptions about the location and representation of payments.

In the process, they introduce a new layer of complexity.

The stablecoin sandwich represents the most practical implementation pathway: fiat in → on-chain transfer → fiat out.

Customers and suppliers on both ends do not need to understand stablecoins; stablecoins merely serve as an intermediary channel—specifically designed to solve the slow, expensive, and unstable pathways of traditional cross-border settlements. The most valuable applications are concentrated in „challenging corridors,‟ namely cross-border scenarios where traditional methods are slow, expensive, or completely inaccessible.

Businesses will not, and should not, go all-in on stablecoins. The realistic approach is to select one or two specific use cases for localized replacement and then expand after building familiarity.

Stablecoins also bring an additional dimension: returns on funds in transit, which are almost nonexistent in traditional systems. In traditional payment processes, funds may be dormant for 24 to 72 hours from issuance to receipt, yielding no returns and tying up working capital. On-chain stablecoins can yield returns while in transit—this is not a minor optimization of payment costs; it is a reconstruction of the entire logic of capital efficiency.

6. Current Ecosystem: Ten Layers of Division and the Missing Layer

As payment infrastructure spans more rails, more service providers, and more types of infrastructure, defining the role of PSPs becomes increasingly difficult.

Responsibilities for fund transfer roles previously bundled within a single PSP have now become a series of responsibilities distributed across various levels of the technology stack.

PSPs' work is no longer just about moving funds but interpreting the flow of funds.

This transformation reflects deeper changes: execution alone is no longer sufficient. PSPs now must support enterprise internal systems, enabling them to represent, account for, and reconcile how funds flow across different environments.

① Product Layer Platform: Embedding Payments into Software

Vertical software platforms like Shopify, Square, Toast, Mindbody, ServiceTitan, Housecall Pro embed payments directly into their products.

In these scenarios, payments are integrated into the application experience, rather than being processed as an independent payment system. These platforms frequently rely on underlying PSPs, banking partners, and infrastructure service providers, adding another layer of abstraction between the application and the flow of funds.

② Execution Layer: Cross-rail Fund Movement

At the core of the technology stack are service providers responsible for executing payments, including traditional PSPs like Stripe, Adyen, Checkout.com, Worldpay, PayPal, Nuvei, dLocal. Their role is to connect enterprises to payment rails and facilitate fund movements.

They remain a critical part of the payment technology stack but primarily operate at the execution layer—initiating payments, reporting statuses, exposing APIs, yet not providing a complete model of how funds flow across service providers and internal systems.

If you ask Stripe „where is this money now?‟ it can only tell you what happened during its segment. Stripe is just one node; that transaction may involve four or five steps of PSPs, banks, rails, and internal ledgers, but it always sees only a part, not the whole.

③ Orchestration and Routing Layer: Connecting Execution Service Providers

As businesses adopt multiple PSPs and payment methods, orchestration platforms have arisen to manage routing across service providers. Companies like Primer, Gr4vy, Spreedly, Paydock, CellPoint Digital allow businesses to route transactions based on geography, cost, or performance. These systems enhance the flexibility of the execution layer but do not provide a unified model of behavior post-payment initiation.

④ Risk and Compliance Layer: Determining Whether Funds Should Move

A number of independent service providers are responsible for assessing whether a payment should proceed. Vendors like Persona, Sardine, Alloy, Unit21, Sift, Sumsub conduct identity verification, fraud detection, and compliance evaluations before execution. In a real-time environment, these decisions must be made before fund movements, thus shifting critical control logic outside of PSPs.

⑤ Banking Infrastructure Layer: Holding Funds and Supporting Access

Custodian banks like Cross River Bank, Lead Bank, Column, Sutton Bank provide regulated accounts and access to payment networks. They hold customer funds, manage liquidity, and act as a gateway to access rails like ACH, wire transfers, RTP, and FedNow. This layer is critical for accessing financial systems, yet operates independently from application logic and PSP APIs.

⑥ Card Issuer Layer: Extending Payment Functionality

Card issuing platforms such as Marqeta, Lithic, Rain enable businesses to issue debit and credit cards as part of their products, supporting expenses management, corporate cards, and marketplace consumption. The issuing platform connects banks and card networks but operates as an independent layer within the technology stack, introducing additional workflows, control mechanisms, and states that need to be coordinated with other parts of the payment technology stack.

⑦ Payment Rail Layer: Underlying Execution Network

Payment rails are the networks that move funds between financial institutions. Traditional rails include ACH, wire transfers, and card networks, while new networks like RTP and FedNow support real-time settlements. Each rail has different assumptions regarding timing, finality, and reversibility, creating inconsistencies that PSPs must expose or navigate around (rather than fully abstract).

⑧ Stablecoin Network Layer: Extending Beyond Bank Infrastructure

Stablecoin networks like Ethereum, Solana, Polygon, Base introduce a new form of payment infrastructure operating independently of traditional banking systems. These networks enable the transfer of digital dollars across global infrastructures with different settlement models and assurance mechanisms. They extend the reach of payment systems beyond bank-based rails, introducing an additional complexity layer that existing workflows must integrate with.

⑨ Banking as a Service Layer: Connecting Applications to Banks

Banking-as-a-service (BaaS) platforms like Unit, Galileo, Treasury Prime provide the infrastructure to connect fintech applications with regulated banks. They enable businesses to offer accounts, cards, and payment capabilities without becoming banks. This layer simplifies access to banking infrastructure but adds another intermediary between applications, PSPs, and the underlying flow of funds.

⑩ The Missing Layer: A Unified PSP Covering the Complete Lifecycle of Fund Movement

Looking across the nine layers, a consistent pattern emerges: each provider is responsible for a specific function, and none can independently provide a complete view of fund movement—including its understanding, control, and reconciliation.

Execution is handled by one service provider, risk decisions by another, funds are held in banks, and payment flows may span card networks, real-time rails, and on-chain systems. Each system exposes different data, timelines, and state definitions.

In a fragmented environment, this issue does not surface at the initiation phase—it emerges afterward: when systems diverge, funds are delayed or returned, and teams need answers. This is where payment systems begin to break down.

7. Where Payment Operations Crash

At 2:55 PM on Friday, the finance team submitted a $50,000 vendor wire transfer. The bank wire cut-off is at 3:00 PM. The system shows „submitted,‟ but the confirmation email has not arrived.

By 4:00 PM, the vendor messages to ask about the status of the funds. The finance team checks the PSP backend, which shows „processing.‟ They check the bank account, which shows „pending settlement.‟ Two systems, the same amount of money, two different states, and none can tell you which node the money is at.

By 5:00 PM on Friday, the bank customer service closes. The vendor is waiting for the funds to arrange weekend freight. The finance team does not know what to tell the vendor, nor do they know if the funds will automatically arrive on Monday morning, or if they have already been returned and need to be re-initiated.

This is not an extreme case; it is a scenario the payment operations team experiences weekly. It will not appear in the PSP's product manual, but it will be in the work records of every cross-border payment team.

The trickiest issues in payments often do not surface at the initiation phase; they emerge afterward—when the team needs to explain what exactly happened.

The market map from the previous chapter reveals the breadth of the payment ecosystem. A seemingly singular payment often flows through multiple service providers within the tech stack before settlement occurs. Each party may represent the same fund movement differently, with differing timings, statuses, and documents arriving on different schedules, and exceptions reported through different channels.

This is precisely where payment operations become difficult.

Reconciliation: Multiple Versions of the Same Event

The finance team needs to match internal ledgers with bank statements, settlement reports, and processor data. If one service provider shows the payment has completed while another states it is still processing, the business needs a model to resolve the discrepancy. If a chargeback arrives after the internal balance has been updated, the books need to be revoked or adjusted accordingly.

Exception Handling: Faults with No Clear Attribution

A payout may fail for issues such as an invalid target account, using the wrong fund account, compliance review suspending the transaction, or missing the rail cutoff. These faults are not the same and do not occur simultaneously. Yet users still expect consistent answers, and internal teams still need to process workflows.

Liquidity and Funds: Money in the Wrong Place

Enterprises operating across multiple service providers and accounts must ensure that the correct funds appear in the correct accounts at the right times. Even if the overall balance is sufficient, if funds remain in the wrong account, payment execution may still fail—creating a gap between product logic and operational reality.

Auditability and Control: Retrospective Reconstruction of Events

Approvals, suspensions, releases, and reconciliation operations occur across teams and systems; enterprises need reliable records of who did what and when, and why. This is not only a compliance requirement but also the basis for tracing transaction history when things go wrong.

These issues are both operational and architectural.

The biggest failure in payment operations often occurs when teams cannot answer a simple question: where did this money go?

The missing element is not another service provider executing payments, routing transactions, or holding funds within the existing model, but rather an evolving PSP that can coordinate all these functions, track statuses across service providers, manage fund movement workflows, and maintain reliable financial records over time.

8. The Next Evolution of PSPs

The challenge is not accessing payment infrastructure, but whether one can maintain a consistent, reliable understanding of how funds move within it.

The current division of labor: PSPs execute payments, banks hold funds, compliance systems assess risks, and orchestration tools route transactions. However, no single service provider is responsible for providing a complete, consistent view of the flow of funds across the entire lifecycle of payments.

The next evolution of PSPs is towards delivering consistent visibility across the entire technology stack—ensuring that every payment from initiation to final settlement is understandable, accounted for, and trusted.

This layer must be able to:

• Execute payments across banks, traditional rails, and stablecoin networks
• Maintain a consistent record system through internal ledgers
• Manage workflows for approvals, funding, and exception handling
• Reconcile external activities with internal financial states
• Scale with built-in compliance, account infrastructure, and an ever-growing network of rails

Conclusion: Where to Start

Modern payment infrastructure is no longer defined by a single processor or a single rail. It is an environment composed of multiple service providers, each responsible for different aspects of fund movement, approvals, settlement, and accounting.

Throughout this guide, we have seen the evolution of this environment:

Payment service providers have transcended the transactional processing scope, payment rails continue to multiply, real-time systems have removed the safety net of delayed settlement, and forms of infrastructure such as stablecoins have further extended the whole system.

For teams building financial products or embedding payments into software, an entry path is more important than a strategic discussion.

Do not start with „should we fully embrace stablecoins?‟ Instead, identify a specific pain point: a cross-border pathway is too slow, a vendor payment process has too many manual operations, or a portion of idle funds is not yielding any returns along the way. Choose one use case, open an account, and make a real payment. Start with an internal pilot, focusing on treasury scenarios rather than directly overhauling client-side processes. This can help manage risk while building understanding.

From a compliance perspective, rules such as KYC, AML, and sanctions screening still fully apply; stablecoins are merely a change in underlying rails. The regulatory framework is clearer today than it was two years ago following the GENIUS Act; this should not serve as an obstacle to piloting.

The real strategic risk is not whether you use stablecoins but that competitors are using stablecoins to reconfigure their settlement costs and capital efficiency while you are still waiting for a perfect entry moment.

Lacking a unified coordination layer, complexity compounds with scale. Equipped with it, businesses can operate the flow of funds with clarity, control, and confidence.

Some content sourced from: Modern Treasury — A Practical Guide to PSPs in 2026