A Single Payment Is No Longer a Single Transaction

A Single Payment Is Not a Single Transaction

Most teams still think about a payment as a single event. You initiate it, and it either succeeds or fails.

That model does not hold up in real payment operations.

A payment is not one event. It is a sequence of state transitions across multiple systems: eligibility checks, compliance screening, funding verification, routing, execution, settlement, and reconciliation. Each step is owned by a different system. Each system has its own statuses. Those statuses do not always line up in real time.

So when your PSP says a payment is completed, your bank says it is pending, and your ledger shows a different amount, you are not looking at a bug. You are looking at a coordination problem.

The mental model most teams still use

When my co-founders and I were at Kiavi, we managed thousands of payments every day: funding loans, collecting monthly payments, and moving money to investors. Even at that scale, it was obvious that the simple model of “payment = one event” did not match how payments actually worked.

These days, I often see teams that still operate as if it does.

A payment gets created through an API call. The API returns a status. That status gets stored in the database. The PSP is expected to handle everything else.

That works in a demo. It can work for a business moving a small number of payments on one rail - and even then, only in the happy path. It stops working once a payment has to move through multiple systems before it reaches the recipient.

Our State of Payment Operations 2025 research found that 98% of companies still handle some payment operations work manually. One reason is that their internal systems are based on a model that does not reflect how payments actually move.

What actually happens

A payment moves through a series of discrete state transitions on its way from initiation to final settlement.

A typical sequence looks like this:

InitiationYour application creates a payment object. At this point, the payment exists only in your system. Status: created.

Eligibility and validationYour system checks available funds, validates the recipient account, and confirms the payment is within approved limits. Status: validated.

Compliance screeningA compliance provider runs sanctions checks, fraud checks, and any required regulatory screening. Depending on the payment, this can take milliseconds or hours. Status: screened, held, or flagged.

RoutingYour system chooses the rail and provider. ACH for a standard domestic transfer. Wire for same-day settlement. RTP for instant delivery. That choice changes timing, cost, confirmation behavior, and failure modes.

Submission to the PSPThe payment instruction is sent to your PSP. The PSP acknowledges receipt. In the PSP, the payment may now be submitted. In your application, it may still be processing.

Execution by the bank partnerThe PSP passes the instruction to a bank or banking partner. The bank places it in its own processing queue. Bank status might be pending. PSP status may still be submitted or processing.

SettlementThe receiving institution confirms funds have arrived. Depending on the rail, that can happen in seconds, hours, or days. The bank may treat the payment as settled before the PSP updates its status.

Ledger reconciliationYour internal ledger reflects the completed movement of funds. Balances are updated. The transaction is marked final. That only happens after your reconciliation process matches bank activity back to the original payment.

That is eight distinct states across at least four systems for what most teams still call a single payment.

At any point in that sequence, a delay, hold, return, or mismatch can change the outcome.

A marketplace payout makes this visible

Marketplace payouts make this complexity obvious.

Imagine a marketplace that collects money from a buyer and then needs to split funds among the seller, the platform, and tax obligations.

Step 1: The customer paysThe customer submits payment by card or bank transfer. The gateway confirms the charge succeeded. That usually means the charge was authorized and captured. It does not mean the marketplace has the cash in its bank account.

Step 2: The funds settle to the marketplaceDepending on the payment method, settlement may take one to three business days. During that period, the marketplace sees a successful charge but has not actually received the funds. The gateway’s ledger and the bank balance do not line up.

Step 3: The platform calculates the splitThe marketplace calculates fees, take rate, taxes, and the amount owed to the seller. That creates another record in another system.

Step 4: The payout is screenedBefore money is sent to the seller, the payout goes through sanctions and fraud screening. The compliance system now has its own record and its own status.

Step 5: The payout is initiatedThe marketplace submits an ACH credit through its PSP. The PSP accepts the instruction. The payment is now in flight, but the seller still has not received funds.

Step 6: The ACH is processed by the banking systemThe originating bank submits the ACH file to the network. The receiving bank picks it up on the next processing window.

Step 7: The seller receives fundsThe seller’s account is credited. The marketplace may not get confirmation immediately. In the meantime, the PSP might already show the payout as completed.

Step 8: Everything gets reconciledThe marketplace still needs to confirm that the original customer payment, the downstream settlement, the split calculation, the compliance decision, and the seller payout all match.

That is not one transaction. It is a chain of related state transitions across multiple systems, each with its own timing and status model.

Where this turns into operational risk

The issue is not that these systems exist, but you have to be aware of them. The issue is that they may at times disagree, and most teams do not have a reliable way to resolve those disagreements.

Double payoutsA charge looks settled. A prior payout attempt has an unclear outcome. The marketplace initiates another payout. The seller gets paid twice. Recovery is manual.

Stuck fundsCompliance holds a payout for review. The PSP never receives it. The application still shows the payment as in progress. The seller sees nothing. Support has to check multiple systems to figure out where it stopped.

Incorrect balancesYour ledger shows one balance. Your bank shows another. Your PSP shows a third. Reconciliation catches some issues later, but not before finance starts building its own spreadsheet because it no longer trusts the source systems.

Regulatory exposureA regulator asks where a payment is right now. That should be easy to answer. For many teams, it still requires pulling data from several systems and reconstructing the payment path by hand.

It gets worse as you add rails and providers

Every new rail adds a different timing model, different failure conditions, and different confirmation behavior.

ACH has return windows that can extend for weeks. Wires settle quickly but lack a native return flow. RTP is immediate but constrained by network and limit considerations. FedNow introduces another timing and coverage model that teams need to account for.

Every new PSP adds another API, another status taxonomy, and another webhook format. One provider’s completed may mean another provider’s processed or settled. Teams end up building their own translation layer, and that layer gets harder to maintain with every additional provider.

Every new bank partner adds different reporting, different settlement timing, and different operational edge cases. Some banks support APIs and near-real-time updates. Others still rely on batch files and end-of-day reporting.

This complexity compounds quickly. Three rails, two PSPs, and two bank partners do not create a small number of integrations. They create a growing set of state combinations, any of which can produce a discrepancy your team has to detect and explain.

The real requirement

The answer is not better status mapping. It is not more dashboards. It is not asking operations teams to reconcile faster.

The real requirement is infrastructure that can coordinate the full lifecycle of a payment.

That means one system that can track a payment from initiation through execution, settlement, and reconciliation. One system that can absorb status updates from PSPs, banks, compliance tools, and internal ledgers. One system that can tell you, with confidence, what happened, what changed, what is still pending, and where intervention is needed.

Once you see a payment for what it actually is, a sequence of state transitions across multiple systems, the architectural requirement becomes obvious.

It is not infrastructure built to process a payment. It is infrastructure built to coordinate the full lifecycle of a payment and keep your business running well.

We put together A Practical Guide to PSPs in 2026 to break down how payments are changing and what to look for in a modern PSP.

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