Article by Awang, Web3 Little Lawyer
Digital payments have gone mainstream, but settlement has not.
This is the assessment of Dan Mottice, former Visa executive and founder of Beam. While Visa transactions are authorized at any merchant worldwide, the underlying settlement still runs on SWIFT—aggregating batch transactions, transferring funds via cross-border wire transfers, and enduring local regulations, holidays, and multiple intermediary banks before merchants receive payment. This is not Visa’s issue; it is a structural debt across the entire industry. And PSPs are where this debt is most concentrated.
This article focuses on payment service providers (PSPs), which have evolved from simple payment collection tools into the core infrastructure layer governing fund flows, settlement, and accounting. They were originally designed for a simpler era—single-track systems, linear transaction flows, and highly bundled infrastructure.
In today’s payment environment, a single "payment" is no longer a standalone transaction, but rather a series of state changes across multiple participants and payment rails. Today, a payment may involve: consumer applications, PSPs, fraud prevention and identity verification providers, custodial banks, one or more payment rails, and internal accounting systems within enterprises.
Enterprises must support debit cards, ACH, wire transfers, RTP, FedNow, and an increasing number of stablecoin-based settlement methods. Each channel has distinct settlement times, failure modes, data formats, and operational requirements.
This article compiles Modern Treasury’s guide, exploring how PSPs have evolved, how their underlying architecture must adapt to modern payment systems, and what strategies teams building payment products should adopt when selecting their next PSP.
Core judgment
01 | Digital payments have gone mainstream, but settlement has not. Visa enables you to authorize payments at any merchant worldwide, yet the underlying settlement still runs on SWIFT. The interface is solved, but the foundation isn't.
02 | PSP processes the payment but does not explain the fund flow. Stripe tells you what happened on its end, but cannot tell you the actual current status of the funds. The execution layer and the recording layer are two different things.
03 | Each payment rail is a standalone operating system, not a variant of the same model. ACH can be reversed; RTP cannot. Card networks allow disputes; stablecoins are settled on-chain with finality. PSPs' abstraction layers mask these differences—until something goes wrong.
04 | Real-time payments eliminate the buffer—risk control must shift upstream. Traditional PSP risk management, approval, and reconciliation logic all assume “there’s still time to fix mistakes if something goes wrong.” RTP and FedNow render this assumption invalid. Decisions must be made before funds move, not after.
05 | Stablecoins are a settlement rail, not a new payment method. They address the delay between "accounting completion" and "actual fund receipt," not issues with the payment interface. The most practical implementation is a sandwich structure: fiat in, on-chain transfer, fiat out—end users don’t need to understand stablecoins.
06 | Funds in transit can generate returns, something that almost doesn’t exist in traditional systems. In cross-border payments, funds are tied up for 24 to 72 hours before settlement is complete, yielding no return and tying up working capital. Stablecoins have, for the first time, enabled funds in transit to generate value.
07 | The biggest failure in payment operations is being unable to answer one simple question: Where did the money go? Reconciliation, anomaly handling, and liquidity management—these issues don’t arise at the time of payment initiation; they emerge afterward. Without a unified coordination layer, each service provider can only tell you its own piece of the story.
08 | The real strategic risk isn't whether you use stablecoins. It's that your competitors are using stablecoins to redesign their settlement costs and capital efficiency, while you're still waiting for the perfect entry opportunity.
I. Historical Evolution of PSP
Over the past two decades, the role of PSPs has undergone a fundamental transformation.
In the early days of e-commerce, PSPs primarily operated as payment gateways. Their role was straightforward: connecting merchants to card networks and acquiring banks to enable transaction authorization and settlement.
These PSP systems were designed for a very specific world where payments are card-based, flow through a single merchant account, and follow a linear lifecycle from authorization to settlement. PSPs are 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 handle user onboarding, split payments among multiple parties, and manage payouts. PSPs expanded accordingly, 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 flows—primarily optimized for transaction processing rather than coordinating complex, multi-step fund movements across service providers and channels.
By the early 2020s, businesses began operating across multiple channels, regions, and scenarios. Traditional PSPs continued to bundle numerous components, requiring businesses to interact with a single platform. However, as payment processes became more complex, a single payment flow might span multiple steps: identity verification, risk assessment, funding decisions, channel execution, and internal tracking.
This shift has transformed the role of PSPs from connectors to coordinators, but their architecture has not evolved at the same pace.
The result is that PSPs still handle fund transfers, but operate within a more complex, full transaction payment lifecycle.
II. Modern PSP Payment Technology Stack
To understand the limitations of PSPs, one must first understand the broader payment environment in which they operate.
2.1 PSP Technology Stack
The modern payment environment is not a single platform or service provider, but a layered set of infrastructure components that collectively enable the movement, settlement, and accounting of funds.
Application Layer: E-commerce platforms initiating payments, marketplaces, fintech apps, and SaaS products with embedded payments.
PSP Layer: Responsible for executing payment instructions, such as routing transactions to card networks, initiating bank transfers, and connecting to payment rails. In most cases, these underlying complexities are abstracted behind the PSP’s interface, allowing users to interact with a single system rather than directly managing the multiple service providers involved.
Compliance Layer: Modern payment processes also rely on identity verification providers, fraud detection tools, and compliance infrastructure, which determine whether a payment should be allowed to proceed.
Banking Layer: Custodial banks hold funds, provide regulated accounts, and support access to payment networks such as ACH, wire transfers, RTP, and FedNow.
Internal reconciliation layer: A system used by enterprises 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 provides a complete picture of what actually happens after a payment is initiated. This is precisely why the internal reconciliation layer becomes indispensable.
2.2 Synchronous and Asynchronous
Traditional PSPs have a fundamental design flaw: they only handle sending out funds, not what happens after the funds are sent.
The problem is that "after sending" is precisely the most complex part of payment.
The PSP's API interface is synchronous—you send a command, and it returns a result. But actual fund flows are asynchronous: settlements occur afterward, failures emerge with delay, and refunds or reversals can be initiated at any time. This mismatch creates a persistent information gap.
The specific manifestation of a black hole is state fragmentation:
No single node can tell you the true status of this money at this moment.
Taking a seller’s withdrawal on a marketplace platform as an example, the entire process is a long chain: eligibility verification → risk control and compliance → fund confirmation → instruction issuance → payment execution → return confirmation → post-settlement → ledger update. The PSP only covers several middle steps; the initial decision-making and subsequent reconciliation fall outside its scope. If this payment fails or is refunded, no single system can provide a complete answer.
This is the purpose of the internal reconciliation layer: it does not replace PSPs in executing payments, but instead establishes a unified observation layer above the entire chain—continuously translating asynchronous events from different service providers, at different times, and in different formats into a single, trusted internal state for the enterprise. No matter how many intermediate steps the funds pass through, there is always a single source that can answer the most fundamental question: Where exactly is this money right now?
III. Payment Limitations of Traditional PSPs
The abstraction layer of traditional PSPs is built around card payments—authorization, capture, and settlement—with a predictable lifecycle. Although exceptions exist (such as disputes and chargebacks), the overall structure is predictable and well understood. This model has shaped how PSPs are designed.
With the emergence of new payment methods, PSPs have expanded their support to additional channels, but these channels behave differently from bank cards and do not adhere to the same assumptions:
- ACH transfers: Introduced delays, and the possibility of chargebacks occurring several days after payment initiation.
- Wire transfer: Faster settlement, but typically involves manual processes and higher costs.
- Real-time payment networks such as RTP and FedNow: enable instant movement of funds, but transactions are typically irreversible once completed.
- Stablecoin transfers: Operate on entirely different infrastructure with distinct security mechanisms and operational considerations.
For example, a U.S. company making a payment to a Philippine supplier:
- Via ACH, funds settle in T+2, but Philippine banks do not directly accept ACH; the payment must first be routed through a local clearing system, so actual settlement may take T+4. During this period, the transaction may be reversed at any time due to mismatched account information.
- Use wire transfer for faster processing, but submit before the 3 PM wire cutoff—delays may occur on holidays. SWIFT fees range from $25 to $45, and the recipient bank may also deduct an intermediary bank fee, resulting in a different final received amount than the amount sent.
- Use a stablecoin sandwich: USDC is sent from a U.S. account and confirmed on-chain in seconds. After receipt, our Philippine partner converts it to pesos and deposits it into a local account—all completed in under an hour, with costs under 1% of the transfer amount.
Three paths, the same funds, with settlement times differing by 96 hours, costs varying by tens of dollars, and completely different traceability. This isn’t a difference in product experience—it’s a difference between three separate operating systems. The PSP’s abstraction layer cannot hide these discrepancies; it can only push the differences upward for developers and operations teams to manage.
These are not variations of the same payment model, but fundamentally different operational models.
Traditional PSPs address this by exposing different APIs and state definitions for each channel—rather than truly unifying the differences, they simply push those differences up to developers. Engineering teams began writing custom logic for each channel, operations teams started manually handling different failure modes, and finance teams began reconciling similar transactions that followed entirely different paths.
This is an abstraction leak: the underlying complexity of the track begins to seep into the application layer.
As more lanes are added, the payment environment becomes a series of loosely connected integrations rather than a unified abstraction layer. On slower lanes, delays provide a window of time to detect issues. On real-time lanes, this window disappears—payments settle within seconds, errors cannot be easily reversed, and decisions must be made before funds move, not after.
IV. Real-time payments force PSPs to shift control forward.
The shift to real-time payment networks has not only accelerated the speed of fund movement—it has fundamentally changed the design requirements of payment infrastructure.
In the era of ACH and wire transfers, time is a buffer.
ACH transactions may take several days to settle, card transactions can be disputed after authorization, and wire transfers often involve manual review steps. While these delays reduce efficiency, they also provide opportunities to detect errors, intervene in suspicious activity, and reconcile accounts before settlement is finalized.
The traditional PSP model is built around this buffer.
However, real-time payment networks such as RTP and FedNow have completely overturned this assumption: funds flow directly between accounts within seconds, and payments are typically irreversible once completed.
- Fraud detection must be completed earlier.
- Compliance screening must be conducted in real time.
- Funding decisions must be accurately completed at the moment of payment release.
- Opportunities for post-event correction no longer exist.
Platforms offering instant payouts cannot rely on workflows designed for delayed settlement. Internal systems that manage payment funds across multiple accounts cannot determine liquidity instantly. Customer service teams cannot guarantee reversibility when the underlying infrastructure does not allow it.
The result is a shift in responsibility: PSPs must evolve to support internal systems that determine when payments should be executed. In other words, control must move upstream.
The payment infrastructure must be designed so that approval, funds logic, risk checks, and status verification are completed before funds move, not after. This requires a more coordinated view of balances, transaction states, and cross-service provider conditions than traditional PSP architectures can provide.
The real-time trajectory is not an endpoint, but merely a turning point. Once stablecoins enter, the issue will be elevated to a higher dimension.
Five: Stablecoins: A New轨道, Not a New Payment Method
The most common misconception about stablecoins is viewing them as a new payment product. They are not. They are a new settlement pathway that addresses the delay between "accounting completion" and "actual receipt" of funds.
Unlike cards, ACH, or wire transfers, stablecoin transactions operate on blockchain networks:
- Settlement is ongoing, not batched.
- Near-instant final confirmation (subject to network conditions)
- Operates 24/7,不受银行截止时间和节假日限制
- Not dependent on specific domestic payment systems
- The primitives for tracking balances, ownership, and transaction history are completely different.
Traditional PSP architectures are built around integration with banks and payment networks, while stablecoins introduce networks that do not rely on these intermediaries. Origin, settlement, and accounting all occur outside the original design. A business may need to coordinate bank rails, real-time networks, and on-chain settlement simultaneously—each type operates under different assumptions regarding finality, timing, and control; these differences cannot be unified through a single API, making the PSP’s role as a single abstraction layer increasingly unsustainable.
Just as real-time payment systems challenge assumptions about timing and reversibility, stablecoins challenge assumptions about where payments occur and how they are represented.
During this process, they introduced a new layer of complexity.
Stablecoin sandwich is the most practical current implementation path: fiat in → on-chain circulation → fiat out.
Neither the customers nor suppliers on either side of the transaction need to understand stablecoins—stablecoins simply serve as an intermediary channel designed specifically to address the slow, costly, and unreliable aspects of traditional cross-border settlement. The most valuable applications are concentrated in "difficult channels"—cross-border scenarios where traditional methods are slow, expensive, or simply inaccessible.
Enterprises should not and will not go all-in on stablecoins; the practical approach is to select one or two specific use cases for partial replacement, build understanding, and then expand gradually.
Stablecoins also introduce an additional dimension: yield on funds in transit, which is nearly nonexistent in traditional systems. In conventional payment processes, funds sit idle for 24 to 72 hours between initiation and settlement, generating no return and tying up working capital. On-chain stablecoins, however, can generate yield while in transit—not merely a marginal improvement in payment costs, but a fundamental restructuring of capital efficiency logic.
Six: Current Ecosystem: Ten Layers of Specialization and the Missing Layer
As payment infrastructure spans more channels, more service providers, and more types of infrastructure, defining the role of PSPs has become increasingly difficult.
The responsibility for fund movement, previously bundled within a single PSP, has now become a series of responsibilities distributed across multiple layers of the technology stack.
The role of PSPs is no longer just moving funds, but explaining the flow of funds.
This shift reflects a deeper change: execution alone is no longer sufficient. PSPs must now support enterprises' internal systems to enable them to represent, account for, and reconcile how funds flow across different environments.
① Product Layer Platform: Embed Payments into Software
Vertical software platforms such as Shopify, Square, Toast, Mindbody, ServiceTitan, and Housecall Pro integrate payments directly into their products.
In these scenarios, payments are integrated into the app experience rather than handled as standalone payment systems. These platforms typically rely on underlying PSPs, banking partners, and infrastructure providers, adding another layer of abstraction between the app and the movement of funds.
② Execution Layer: Cross-Chain Fund Transfer
The core of the tech stack consists of payment service providers that handle transaction execution, including traditional PSPs such as Stripe, Adyen, Checkout.com, Worldpay, PayPal, Nuvei, and dLocal, whose role is to connect businesses to payment networks and facilitate fund movement.
They remain key components of the payment technology stack, but operate primarily at the execution layer—initiating payments, reporting status, and exposing APIs—without providing a complete model of how funds flow across service providers and internal systems.
When you ask Stripe, “Where is this money right now?”, it can only tell you what happened in its own segment. Stripe is just one node in this transaction, which may also involve PSPs, banks, clearing networks, internal ledgers, and several other steps—but it only ever sees a partial view, not the full picture.
③ Orchestration and Routing Layer: Connect to Execution Service Providers
As businesses adopt multiple PSPs and payment methods, orchestration platforms have emerged to manage routing across service providers. Companies such as Primer, Gr4vy, Spreedly, Paydock, and CellPoint Digital enable businesses to direct transactions based on geography, cost, or performance. These systems enhance flexibility at the execution layer but do not provide a unified model for behavior after payment initiation.
④ Risk Management and Compliance Layer: Determines whether funds should be moved
A group of independent service providers is responsible for determining whether a payment should be allowed to proceed. Identity verification, fraud detection, and compliance systems from vendors such as Persona, Sardine, Alloy, Unit21, Sift, and Sumsub evaluate users and transactions prior to execution. In a real-time environment, these decisions must be completed before funds are moved, so critical control logic is moved outside the PSP.
⑤ Banking Infrastructure Layer: Holds funds and enables connectivity
托管银行 such as 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 gateways to channels like ACH, wire transfers, RTP, and FedNow. This layer is essential for accessing the financial system but operates independently of application logic and PSP APIs.
⑥ Card Issuance Layer: Expand Payment Functionality
Card issuing platforms such as Marqeta, Lithic, and Rain enable businesses to issue debit and credit cards as part of their offerings, supporting use cases like expense management, corporate cards, and marketplace spending. These platforms connect to banks and card networks but operate as an independent layer within the technology stack, introducing additional workflows, control mechanisms, and states that require coordination with other components of the payment technology stack.
⑦ Payment Rail Layer: Underlying Execution Network
Payment rails are networks that move funds between financial institutions. Traditional rails include ACH, wire transfers, and card networks, while newer networks such as RTP and FedNow enable real-time settlement. Each rail makes different assumptions regarding timing, finality, and reversibility, creating inconsistencies that PSPs must expose or navigate—rather than fully abstract away.
⑧ Stablecoin Network Layer: Extending Beyond Banking Infrastructure
Stablecoin networks such as Ethereum, Solana, Polygon, and Base have introduced a new form of payment infrastructure operating outside the traditional banking system. These networks enable the transfer of digital dollars across global infrastructure using different settlement models and security mechanisms. They extend the scope of payment systems beyond bank-based channels, adding an additional layer of complexity that must be integrated into existing workflows.
⑨ Banking-as-a-Service Layer: Connecting Applications to Banks
Banking-as-a-Service (BaaS) platforms such as Unit, Galileo, and Treasury Prime provide the infrastructure to connect fintech applications with regulated banks. They enable businesses to offer account, card, and payment capabilities without needing to become a bank themselves. This layer simplifies access to banking infrastructure but introduces another intermediary between the application, PSP, and the underlying funds flow.
⑩ The Missing Layer: A Unified PSP Covering the Full Lifecycle of Fund Flows
Looking across the nine layers above, the pattern is consistent: each service provider is responsible for specific functions, and none can independently provide a complete view of fund flows—including their understanding, control, and reconciliation.
Execution is handled by one service provider, risk decisions by another, and funds are held in a bank; the payment flow 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 doesn’t surface during the initiation phase—it emerges afterward: when the system diverges, funds are delayed or refunded, and the team needs answers. This is precisely where payment systems begin to break down.
Seven: Where Payment Operations Break Down
At 2:55 PM on Friday, the finance team submitted a $50,000 wire transfer to a vendor. At 3:00 PM, the bank’s wire cut-off time occurred. The system showed “Submitted,” but the confirmation email did not arrive.
At 4 p.m., the supplier messaged to inquire about the payment status. The finance team checked the PSP backend, which showed "Processing." They then checked the bank account, which showed "Pending Settlement." Two systems, the same payment, two different statuses—neither could tell them exactly where the funds currently stood.
At 5 p.m. on Friday, bank customer service closes. The supplier is waiting for payment arrangements to be made for weekend shipping. The finance team doesn’t know what to tell the supplier—whether the funds will automatically arrive on Monday morning or have been returned and need to be resent.
This is not an extreme case—it’s a scenario the payments operations team encounters every week. It won’t appear in a PSP’s product manual, but it will show up in the work logs of every cross-border payments team.
The most challenging issues in payments often aren’t at the initiation stage, but afterward—when the team needs to explain exactly what happened.
The market map from the previous chapter revealed the breadth of the payments ecosystem. A seemingly simple payment often passes through multiple service providers within the technology stack before settlement occurs. Each party may have a different representation of the same fund movement, with varying timelines, statuses, documents arriving on different schedules, and exceptions reported through different channels.
This is exactly where payment operations become challenging.
Reconciliation: Multiple versions of the same event
The finance team must reconcile internal ledgers with bank statements, settlement reports, and processor data. If one service provider shows a payment as completed while another indicates it is still pending, the company needs a model to resolve these discrepancies. If a chargeback arrives after the internal balance has already been updated, the ledger must be reversed or adjusted accordingly.
Error handling: Failures with no clear ownership
A withdrawal may fail due to an invalid destination account, use of an incorrect funding account, a hold for compliance review, or missing the cutoff time. These failures are distinct and do not occur simultaneously, yet users still expect a consistent response, and internal teams must still manage the process.
Liquidity and Funds: Money is in the wrong place
Enterprises operating across multiple service providers and accounts must ensure that the correct funds are in the right account at the right time. Even if overall balances are 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: Reconstructing What Happened
Approval, suspension, release, and reconciliation operations occur across teams and systems, and enterprises require reliable records of who did what, when, and why. This is not only a compliance requirement but also the foundation for tracing transaction histories when issues arise.
These issues are both operational and architectural.
The biggest failures in payment operations often occur when a team cannot answer a simple question: Where did the money go?
What is missing is not another service provider that performs payments, routes transactions, or holds funds within existing models, but an evolved PSP capable of coordinating all these functions, tracking status across service providers, managing fund flow workflows, and maintaining reliable financial records over time.
Eight: The Next Evolution of PSP
The challenge is not in connecting to payment infrastructure, but in maintaining a consistent and reliable understanding of how funds flow within it.
Current ecosystem分工: PSPs handle payments, banks hold funds, compliance systems assess risk, and orchestration tools route transactions. However, no single service provider is responsible for delivering a complete, consistent view of fund flows across the entire payment lifecycle.
The next evolution of PSP is to provide consistent visibility across the entire technology stack—ensuring every payment, from initiation to final settlement, is understandable, traceable, and trustworthy.
This layer must be able to:
- Execute payments across banks, traditional networks, and stablecoin networks
- Maintain a consistent record system through an internal ledger.
- Manage workflows for approvals, funds, and exception handling
- Reconcile external activities with internal financial status
- As it scales, it integrates compliance, account infrastructure, and seamless connectivity for sustained growth.
Conclusion: Where to begin
Modern payment infrastructure is no longer defined by a single processor or single pathway. It is an environment composed of multiple service providers, each responsible for different stages of fund movement, authorization, settlement, and accounting.
Throughout this guide, we have seen the evolution of this environment:
Payment service providers have moved beyond transaction processing, with an increasing number of payment rails. Real-time systems have eliminated the safety net of delayed settlement, and new infrastructure forms such as stablecoins have further extended the entire system.
For teams building financial products or embedding payments into software, the go-to-market path is more important than strategic discussions.
Don’t start with “whether to fully embrace stablecoins”; instead, identify a specific pain point: a cross-border settlement channel that’s too slow, excessive manual steps in a supplier payment process, or idle funds earning no return while in transit. Choose one use case, open an account, and make one actual payment. Begin with an internal pilot, starting with treasury management scenarios rather than immediately overhauling customer-facing processes. This approach helps control risk while building understanding.
On the compliance side, rules such as KYC, AML, and sanctions screening still fully apply; stablecoins merely represent a change in the underlying infrastructure. The regulatory framework has become significantly clearer since the GENIUS Act, and should not serve as a reason to hinder pilot programs.
The real strategic risk isn't whether you use stablecoins—it's that your competitors are using stablecoins to redesign their settlement costs and capital efficiency, while you're still waiting for the perfect moment to enter.
Without a unified coordination layer, complexity increases cumulatively with scale. With it, businesses can operate cash flows with clarity, control, and confidence.
部分内容来源：Modern Treasury — 2026年PSP实用指南