The PSP You Integrated Five Years Ago

It’s Time for a New PSP Model

Payment service providers were designed for a simpler world.

That world no longer exists.

For a long time, the model worked. You integrated once, got access to payment rails, and trusted the PSP to tell you what happened. Payments were relatively uniform. Timelines were predictable. If a PSP said a payment was complete, that was usually enough to run the business.

That assumption is now wrong.

The core problem

PSPs no longer provide a reliable view of payment state.

A payment can show as complete even though the money has not settled. A transfer can be delayed with no clear explanation. A “pending” status can mean fundamentally different things depending on the rail. Support cannot answer the customer. Finance cannot reconcile PSP data to the bank. Engineering ends up building logic just to interpret what the PSP is saying.

As payment complexity increases, the cost of not knowing what is actually happening increases with it.

This is not a UX problem. It is not a documentation problem.

It is a systems problem.

What changed

Payments did not just get incrementally more complex. The underlying assumptions changed.

Money now moves across fundamentally different systems:

• ACH with multi-day settlement and returns
• Wires with cutoff windows and manual processing
• Real-time rails with immediate finality
• Stablecoins with always-on movement

These systems have different timelines, different failure modes, and different definitions of “complete.”

Most PSPs were built to abstract this complexity away. That worked when the differences did not matter operationally.

Now they do.

When a PSP flattens these differences into a small set of statuses, those statuses no longer map to reality. “Complete” might mean instruction submitted. “Pending” might mean waiting on a bank. Or compliance. Or funds availability.

Status is no longer a reliable proxy for money movement.

That is the breakdown.

Why this is hard to fix

Most PSPs are built as orchestration layers on top of bank infrastructure.

They initiate payments, normalize APIs, and surface simplified states. But the underlying system of record still lives elsewhere—at the bank, across multiple rails, with inconsistent data models and timelines.

As payments get more complex, that abstraction leaks.

You can add more statuses. You can improve documentation. You can build better dashboards.

But if your system does not actually track the full lifecycle of money movement, you cannot reliably answer simple questions:

• Has this money settled?
• Where is it right now?
• What needs action?

That is not something you can patch at the edges.

What businesses need now

The job of a PSP is no longer just to move money.

It is to explain money movement.

Teams need:

• Accurate, real-time balances tied to a system of record
• Clear lifecycle states that reflect what is actually happening
• Continuous reconciliation between instructions and bank outcomes
• A shared source of truth across support, finance, and engineering

Without that, operational costs scale with payment complexity. Every new rail, edge case, or failure mode adds more manual work and more risk.

Our approach

We took a different path.

Before building a PSP, we built the underlying system of record: ledgers, reconciliation systems, and infrastructure that can account for every dollar and track it through its full lifecycle.

We can always answer a simple question: how much money is here, and who owns it?

That foundation changes what the PSP can do.

We built Payments as a full-stack PSP on top of that system.

Customers get custodial FBO accounts with sub-accounts for their users. Every account has a real-time ledger with a balance and transaction history. Payments move across ACH, wires, RTP, and other rails—but they are all tracked within a single, consistent system of record.

The difference is not in the rails we support. It is in how the system behaves.

You can see where money is.You can see what has settled and what has not.You can see what is pending, why, and what needs attention.

Support, finance, and engineering are all working from the same underlying truth—not interpreting a simplified status layer.

The shift

The original PSP model assumed that execution and visibility were the same thing.

They are not anymore.

As payments become more complex, visibility becomes its own problem—and the infrastructure has to solve for it directly.

A PSP that cannot explain money movement is no longer sufficient.

Learn more

If you are building on payment infrastructure today, this shift matters.

We wrote A Practical Guide to PSPs in 2026 to break down how the model is changing, where it breaks, and what to look for in a modern PSP.

Read the guide to learn more: www.moderntreasury.com/ebooks/a-practical-guide-to-psp