Written by: Awang, Web3 Lawyer

Digital payments have become mainstream, but settlement is not yet.

This is the assessment of Dan Mottice, a former Visa executive and founder of Beam. Visa transactions are authorized at any merchant globally, but the settlement behind the scenes still runs on SWIFT—aggregating bulk transactions, transferring funds via cross-border wire transfers, going through local regulations, holidays, and multiple intermediary banks, and then the merchant waits to receive payment. This isn't just a Visa problem; it's a structural deficiency across the entire industry. And PSP (Personal Support Service) is where this deficiency is most concentrated.

This article focuses on payment service providers (PSPs), which have evolved from simple payment collection tools into a core infrastructure layer governing fund flows, settlements, and accounting. They were originally designed for a simpler era—a single-track 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 tracks. Today, a payment may involve: consumer applications, payment service providers (PSPs), anti-fraud/identity verification service providers, custodian banks, one or more payment tracks, and the company's internal accounting system.

Businesses must simultaneously support bank cards, ACH, wire transfers, RTP, FedNow, and increasingly, stablecoin-based settlements. Each track has different settlement times, failure modes, data formats, and operational requirements.

This article is a compilation of Modern Treasury's guide, which will explore how PSPs have evolved, how their underlying architecture needs to adapt to modern payment systems, and what strategies teams building payment products should adopt when choosing their next PSP.

Core judgment

01 | Digital payments have entered the mainstream, but settlement hasn't. 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 mechanism remains unresolved.

02 | PSP executes payments, but doesn't explain the flow of funds. Stripe tells you what happened at that point, but it can't tell you the true state of the money now. The execution layer and the recording layer are two different things.

03 | Each payment track is an independent operating system, not a variant of the same model. ACH can be revoked, RTP cannot; card networks can be disputed, stablecoins are finalized on-chain. PSP's abstraction layer masks these differences, but only until a problem arises.

04 | Real-time payments eliminate buffers, requiring control to be moved upstream. Traditional PSP risk control, approval, and reconciliation logic all assume that "there is time to remedy errors." RTP and FedNow eliminate this assumption. Decisions must be made before funds move, not afterward.

05 | Stablecoins are a settlement track, not a new payment method. They don't solve the payment interface problem, but rather the delay between "accounting completion" and "actual arrival" of funds. The most practical implementation path is a sandwich structure: fiat currency in, on-chain circulation, fiat currency out, and users at both ends don't need to understand stablecoins.

06 | Funds in transit can generate returns, which is almost non-existent in traditional systems. In cross-border payments, funds are tied up for 24 to 72 hours before settlement is completed, generating no returns and tying up working capital. Stablecoins are the first to allow "funds in transit" to generate value.

07 | The biggest failure in payment operations is the inability to answer a simple question: Where did this money go? Reconciliation, anomaly handling, liquidity management—these problems don't arise when a payment is initiated, but rather afterward. Without a unified coordination layer, each service provider can only tell you its own part of the story.

08 | The real strategic risk isn't whether you use stablecoins or not. It's that your competitors are using stablecoins to restructure their settlement costs and capital efficiency, while you're still waiting for the perfect entry point.

I. The Historical Evolution of the PSP

Over the past two decades, the role of the PSP has undergone a fundamental change.

In the early days of e-commerce, PSPs primarily functioned as payment gateways. Their role was simple and clear: to connect merchants to card networks and acquiring banks, enabling transaction authorization and settlement.

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

In the 2010s, Marketplace, SaaS platforms, and fintech products began to embed payments directly into their offerings. Platforms needed to handle user onboarding, splitting payments among multiple parties, and managing fund transfers. PSPs expanded accordingly, introducing merchant onboarding, payment infrastructure, and fraud prevention tools.

However, despite the ever-expanding capabilities of PSP, its underlying architecture remains rooted in a model designed for linear payment processes—primarily optimized for transaction processing rather than for coordinating complex, multi-step fund movements across service providers and tracks.

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

This shift transformed the PSP's role from "connector" to "coordinator," but its architecture did not evolve at the same pace.

The result is that the PSP is still responsible for transferring funds, but it operates within a more complex environment encompassing the entire transaction payment lifecycle.

II. Modern PSP Payment Technology Stack

To understand the limitations of PSP, one must first understand the broader payment environment in which it exists.

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 work together to support the movement, settlement, and accounting of funds.

Application layer: payment-initiated e-commerce platforms, marketplaces, fintech apps, and SaaS products with embedded payments.

The PSP layer is responsible for executing payment instructions, such as routing transactions to the card network, initiating bank transfers, and connecting to the payment track. In most cases, these underlying complexities are abstracted behind the PSP's interface, allowing users to interact with a single system rather than directly dealing with the multiple service providers involved.

Compliance layer: Modern payment processes also rely on identity verification service providers, fraud detection tools, and compliance infrastructure, which determine whether a payment should be allowed to proceed.

At the banking level: Custodian banks hold funds, provide regulated accounts, and support access to payment networks such as ACH, wire transfer, RTP, and FedNow.

Internal reconciliation layer: A system used by enterprises to track balances, indicate transaction status, and maintain consistent records of financial activities.

Each of these layers plays a role in the movement of funds, 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

The traditional PSP had a fundamental design flaw: it only cared about sending money out, regardless of what happened afterward.

The problem is that "after it's sent out" is precisely the most complicated part of the payment process.

PSP's API interface logic is synchronous—you send a command, and it returns a result. However, the actual flow of funds is asynchronous: settlement is completed afterward, failures only surface with delay, and refunds and reversals can be reversed at any time. This mismatch creates a persistent information black hole.

The specific manifestation of a black hole is the fragmentation of its state:

No single point in time can tell you the true state of this money at any given moment.

Taking seller withdrawals on a marketplace platform as an example, the entire process is a long chain: verifying eligibility → risk control and compliance → confirming funds → issuing instructions → executing the transaction → receiving confirmation → post-transaction settlement → updating the ledger. PSP only covers a few of the intermediate steps; the earlier decision-making and subsequent reconciliation are not within its scope of responsibility. If a payment fails or is returned, no single system can provide a complete answer.

This is the significance of the internal reconciliation layer: it doesn't replace the PSP in executing payments, but rather establishes a unified observation layer above the entire chain—continuously translating asynchronous events from different service providers, with different timings, and in different formats into a single, reliable state within the enterprise. No matter how many intermediaries the money passes through, there's always one place that can answer the most fundamental question: Where is this money now?

III. Payment Limitations of Traditional PSPs

The traditional PSP's abstraction layer is built around bank card payments—authorization, capture, and settlement—with a predictable lifecycle. While exceptions exist (such as disputes and chargebacks), the overall structure is predictable and well-understood. This model shapes how PSPs are designed.

With the emergence of new payment methods, PSP will expand its support to more tracks, but these tracks will behave differently from bank cards and will not conform to the same assumptions:

• ACH transfers: introduce delays and the possibility of being canceled even days after payment is initiated.
• Wire transfer: Settlement is faster, but it usually requires manual processing and is more expensive.
• Real-time payment networks such as RTP and FedNow enable instant movement of funds, but transactions are usually irreversible once completed.
• Stablecoin transfers operate on completely different infrastructures and have different security mechanisms and operational considerations.

Take, for example, a payment made by a US company to a Philippine supplier:

• If you use ACH, the funds will arrive in T+2, but Philippine banks do not accept ACH directly. It will be transferred to a local channel in between, so the actual arrival time may be T+4. During this period, the order may be canceled at any time due to mismatched account information.
• Sending a wire transfer is faster, but you need to submit it before the 3 PM wire cutoff. If it falls on a holiday, it will be delayed. SWIFT fees range from $25 to $45, and the receiving bank may also deduct an intermediary bank fee, so the final amount received may not match the amount sent.
• Using a stablecoin sandwich method, USDC is issued from a US account, confirmed on-chain in a few seconds, and then converted into pesos and deposited into a local account by the Philippine partner. The whole process takes less than an hour and costs less than 1% of the transfer amount.

Three different payment methods, the same amount of money, but settlement times differed by 96 hours, costs by tens of dollars, and traceability was completely different. This wasn't a difference in product experience; it was a difference between three operating systems. PSP's abstraction layer couldn't hide these differences; it could only push them upwards to the developers and operations team to digest.

These are not variations of the same payment model, but fundamentally different operating models.

The traditional approach of a PSP is to expose different APIs and state definitions for each track—there's no real uniformity; it just pushes the differences upwards to the developers. Engineering teams start writing specific logic for each track, operations teams start manually handling different failure modes, and finance teams start reconciling similar transactions that have gone through completely different paths.

This is abstraction leakage: the complexity of the track, which should have been shielded, begins to seep into the application layer.

As more tracks are added, the payment environment becomes a series of loosely connected integrations rather than a unified abstraction. On slower tracks, latency provides a time window for detecting problems. On real-time tracks, this window disappears—payments are settled within seconds, errors cannot be easily reversed, and decisions must be made before, not after, the funds move.

IV. Real-time payments force PSPs to move control forward.

The shift to real-time payment networks is not just about speeding up the flow of funds—it fundamentally changes the design requirements of payment infrastructure.

In the era of ACH and wire transfers, time was a buffer.

ACH transactions can take several days to settle, bank card transactions can be disputed after authorization, and wire transfers often involve manual review steps. While these delays result in inefficiencies, they also provide opportunities to detect errors, intervene in suspicious activities, and complete reconciliation before settlement finalization.

The traditional PSP model is built around this buffer.

However, real-time payment networks such as RTP and FedNow have completely shattered this assumption. Funds flow directly between accounts within seconds, and once a payment is completed, it is usually irreversible.

• Fraud detection must be completed earlier.
• Compliance screening must be conducted in real time.
• Financial decisions must be made precisely at the instant the payment is released.
• The opportunity to correct mistakes afterward no longer exists.

Platforms offering instant payments cannot rely on workflows designed for delayed settlements. Internal enterprise systems managing payment funds across multiple accounts cannot determine liquidity at the moment of execution. Customer support teams cannot guarantee reversibility when the underlying mechanisms simply do not allow it.

The result is a shift in responsibility: the PSP must evolve to support internal systems that determine when payments should be made. In other words, control must be moved forward.

Payment infrastructure must be designed so that approval, funding logic, risk checks, and status verification are completed before, not after, the flow of funds. This requires a more coordinated view of balances, transaction status, and cross-servicer conditions than traditional PSP architectures can provide.

The real-time trajectory is not the final state, but merely an inflection point. The introduction of stablecoins will escalate the issue further.

V. Stablecoins: A New Track, Not a New Payment Method

The most common misconception about stablecoins is that they are seen as a new payment product. They are not. They represent a new settlement track that addresses the delay between the "completion of the transaction" and the "actual receipt" of funds.

Unlike credit cards, ACH, and wire transfers, stablecoin transactions run on a blockchain network:

• Settlement is ongoing, not processed in batches.
• Near-instantaneous final confirmation is possible (depending on the network).
• It operates 24/7 and is not subject to bank closing times or holidays.
• Not dependent on specific domestic payment systems
• The primitives for tracking balance, ownership, and transaction history are completely different.

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 all occur outside the original design. A company may need to coordinate banking tracks, real-time networks, and on-chain settlements simultaneously, each with different assumptions about finality, timing, and control—these differences cannot be unified through a single API, making it increasingly difficult to maintain PSP's position as a single abstraction layer.

Just as real-time payment systems challenge assumptions about timing and revocability, stablecoins challenge assumptions about where and how payments occur.

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

The stablecoin sandwich is currently the most practical implementation path: fiat currency in → on-chain circulation → fiat currency out.

Customers and suppliers at both ends of the transaction don't need to understand stablecoins; stablecoins are merely an intermediary channel—specifically designed to address the slow, expensive, and unstable aspects of traditional cross-border settlements. The most valuable applications are concentrated in "hard-to-reach" scenarios, namely cross-border scenarios where traditional methods are slow, expensive, or simply unattainable.

Enterprises should not and will not go all-in on stablecoins. The realistic approach is to choose one or two specific use cases for partial replacement, build awareness, and then expand.

Stablecoins also bring an additional dimension: in-transit earnings, which is almost non-existent in traditional systems. In traditional payment processes, funds are tied up for 24 to 72 hours from issuance to receipt, yielding no earnings and tying up working capital. On-chain stablecoins can generate earnings during circulation—this is not a minor optimization of payment costs, but a complete restructuring of the logic of capital efficiency.

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

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

The responsibility for moving funds, which used to be tied to a single PSP, has now become a series of responsibilities distributed across multiple layers of the technology stack.

The job of PSP is no longer just to move funds, but to interpret the flow of funds.

This shift reflects a deeper change: execution alone is no longer sufficient. PSPs must now support an enterprise's internal systems, enabling them to represent, record, and reconcile how funds flow across different environments.

① Product-level platform: Embedding payment into software

Vertical software platforms such as Shopify, Square, Toast, Mindbody, ServiceTitan, and Housecall Pro have directly embedded payments into their products.

In these scenarios, payments are integrated into the application experience rather than being processed as a separate payment system. These platforms typically 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-track fund movement

At the heart of the technology stack are the payment service providers responsible for executing payments. These include traditional PSPs such as Stripe, Adyen, Checkout.com, Worldpay, PayPal, Nuvei, and dLocal, whose role is to connect businesses to the payment track and facilitate the movement of funds.

They remain key components of the payment technology stack, but primarily operate at the execution layer—initiating payments, reporting status, and exposing APIs—but do not provide 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 in its own segment. Stripe is just one node in the chain; the transaction may also involve four or five other links, such as PSP, banks, tracks, and internal ledgers, but it only sees a part, not the whole picture.

③ Orchestration and Routing Layer: Connects to service providers

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

④ Risk control and compliance layer: Decides whether funds should be moved.

A group of independent service providers are 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 assess users and transactions before execution. In a real-time environment, these decisions must be made before funds move, thus moving critical control logic outside the PSP (Personal Service Provider).

⑤ Banking infrastructure layer: Holds funds and supports access

Custodian banks such as Cross River Bank, Lead Bank, Column, and Sutton Bank provide regulated accounts and access to payment networks. They hold client funds, manage liquidity, and act as gateways to payment systems such as ACH, wire transfers, RTP, and FedNow. This layer is crucial for accessing the financial system but operates independently of application logic and PSP APIs.

⑥ Card Issuance Layer: Expanding Payment Functions

Card issuance platforms such as Marqeta, Lithic, and Rain enable businesses to issue debit and credit cards as part of their product offerings, supporting use cases such as fee management, corporate cards, and market spending. While these platforms connect banks and card networks, they operate as a separate layer within the technology stack, introducing additional workflows, control mechanisms, and states that require coordination with other parts of the payment technology stack.

⑦ Payment Track Layer: Underlying Execution Network

Payment tracks are networks that move funds between financial institutions. Traditional tracks include ACH, wire transfers, and card networks, while newer networks such as RTP and FedNow support real-time settlement. Each track makes different assumptions about timing, finality, and revocability, creating inconsistencies that PSPs must expose or circumvent (rather than completely abstract) from.

⑧ Stablecoin Network Layer: Extending Beyond Bank 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, with different settlement models and security mechanisms, enable the transfer of digital dollars across a global infrastructure. They extend the reach of payment systems beyond the bank-based track, introducing an additional layer of complexity that must be integrated into existing workflows.

9. Banking as a Service Layer: Connecting applications and banks

Bank-as-a-Service (BaaS) platforms such as Unit, Galileo, and Treasury Prime provide the infrastructure connecting fintech applications with regulated banks. They enable businesses to offer accounts, cards, and payment capabilities without having to be a bank. This layer simplifies access to banking infrastructure but adds another intermediary between applications, PSPs, and the underlying money flow.

⑩ The missing layer: A unified PSP covering the entire lifecycle of fund flows

Looking at the nine layers above, the pattern is consistent: each service provider is responsible for a specific function, and none of them can independently provide a complete view of the flow of funds—including understanding, control, and reconciliation of it.

Execution is handled by one service provider, risk decisions by another, funds are held in custody by a bank, and the payment process may extend across card networks, real-time tracks, and on-chain systems. Each system exposes different data, timelines, and state definitions.

In a fragmented environment, this problem doesn't manifest itself at the initiation stage—it emerges afterward: when disagreements arise within the system, funds are delayed or returned, and the team needs answers. This is precisely where payment systems begin to break down.

VII. Where did the payment operation crash?

At 2:55 PM on Friday, the finance team submitted a $50,000 wire transfer to a supplier. At 3:00 PM, the bank wired off. The system showed "submitted," but no confirmation email arrived.

At 4 PM, the supplier messaged to inquire about the payment status. The finance department checked the PSP backend, which showed "Processing." Checking the bank account showed "Pending Settlement." Two systems, the same amount of money, two different statuses; neither could tell you where the money was at.

It was 5 PM on Friday, and the bank's customer service had closed for the day. The supplier was waiting for payment to arrange weekend shipping. The finance team didn't know what to tell the supplier, or whether the money would automatically arrive on Monday morning, or if it had been returned and needed to be re-initiated.

This isn't an extreme case; it's a scenario that payment operations teams experience every week. It won't appear in the PSP's product manual, but it will appear in the work logs of every cross-border payment team.

The most challenging issues with payments are often not in the initiation phase, but afterward—when the team needs to explain exactly what happened.

The market map in the previous chapter revealed the breadth of the payment ecosystem. A seemingly simple payment often flows through multiple service providers in the technology stack before settlement occurs. Each party may have different representations of the same fund movement, with different timings, different states, documents arriving at different schedules, and anomalies 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 a payment as completed while another shows it's still processing, the company needs a model to resolve discrepancies. If a cancellation arrives after the internal balance has been updated, the ledger needs to be revoked or adjusted accordingly.

Exception handling: Faults without a clearly defined attribution

A withdrawal might fail due to an invalid target account, the use of the wrong funding account, a compliance review suspending the transaction, or missing the deadline. These failures are not the same and do not occur at the same time. However, users still expect consistent answers, and the internal team still needs to process the process.

Liquidity and Funding: Money in the Wrong Place

Businesses operating across multiple service providers and accounts must ensure that the right funds are in the right accounts at the right time. Even with ample overall balances, payment execution can still fail if funds remain in the wrong accounts—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, requiring companies to reliably record who did what, when, and why. This is not only a compliance requirement but also the foundation for tracing transaction history in case of problems.

These issues are both operational and architectural.

The biggest failures in payment operations often occur when the team cannot answer a simple question: Where did this money go?

What's missing isn't another service provider that performs payments, routes transactions, or holds funds within the existing model, but an evolved PSP capable of coordinating all these functions, tracking status across service providers, managing cash flow workflows, and maintaining reliable financial records over time.

8. The Next Evolution of the PSP

The challenge lies not in accessing payment infrastructure, but in maintaining a consistent and reliable understanding of how funds flow within it.

The current ecosystem is structured as follows: 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 and 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 that every payment, from initiation to final settlement, can be understood, recorded, and trusted.

This layer must be able to:

• Execute payments across banks, traditional railroads and stablecoin networks
• Maintain a consistent record system through internal ledgers.
• Workflow for managing approvals, funds, and exception handling
• Reconcile external activities with internal financial status.
• As it scales, it features built-in compliance, account infrastructure, and continuously growing track connectivity.

Conclusion: Where to begin?

Modern payment infrastructure is no longer defined by a single processor or a single track. It is an environment comprised of multiple service providers, each responsible for different aspects of fund flow, approval, settlement, and accounting.

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

Payment service providers have gone beyond transaction processing, payment tracks are increasing, real-time systems have removed the safety net of delayed settlement, and new forms of infrastructure such as stablecoins have further extended the entire system.

For teams building financial products or embedding payments into software, the entry point is more important than strategic discussions.

Don't start by debating whether to fully embrace stablecoins. Instead, identify a specific pain point: a cross-border settlement process is too slow, a supplier payment process involves too much manual intervention, and idle funds are stuck in transit without generating returns. Choose a use case, open an account, and conduct an actual payment. Pilot it internally first, focusing on treasury management rather than directly altering customer-side processes. This allows you to control risk while building awareness.

From a compliance perspective, KYC, AML, and sanctions screening rules remain fully applicable; stablecoins represent only a change in the underlying mechanism. The regulatory framework, established after the GENIUS Act, is much clearer than it was two years ago and should not be a reason to hinder pilot programs.

The real strategic risk isn't whether you use stablecoins or not, but that your competitors are using stablecoins to restructure their settlement costs and capital efficiency, while you're still waiting for the perfect entry point.

Without a unified coordination layer, complexity increases with scale. With it, businesses can manage cash flow with clarity, control, and confidence.

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