Payments ThatReconcileBy Construction.
A provider is a dependency, not the system. What a payment is, what it may still become, and whether the money has moved are facts the platform holds itself — so a provider can fail, answer late or answer ambiguously without the record becoming a guess.
Next Step / Technical Discovery
- Money state is owned here
- Interchangeable by design
- Double-entry, not a log
- An outage changes the route
Where this system fits
A payment platform is the layer a company owns between its checkout, the regulated providers that move money, its financial records, and the people who answer for both.
- The contracts to each provider and each internal consumer.
- The trail from a settlement line back to the payment behind it.
- The environment it runs in, and its behaviour while a dependency is unavailable.
- An auditor reads the same record an operator does.
- Every movement of value needs a recorded inverse.
- Unavailability is an operating mode, not an incident.
Where payment systems come apart
- 01
Revenue stops when a provider does
One route means one availability. Nothing is wrong with the code; the money stops arriving, and recovery runs on somebody else's schedule.
- 02
Three systems, three answers
The product says paid, the provider says pending, the accounts say missing. Support answers from whichever screen was open.
- 03
The response that never came
A request that timed out may already have taken the money. Trying again risks charging twice; not trying risks the sale.
- 04
Money moves after the order closes
Refunds, adjustments and disputes arrive days later, against a record the product considers finished. A system with nowhere to put them uses a spreadsheet.
Actors and boundaries
Payer
Presents an instrument, consents to an amount.
Nothing inward. A provider-issued reference, never the instrument.
Merchant or platform
Decides what is charged for, and when.
The platform takes an intent, returns a state. The commercial decision stays here.
Payment platform
Holds the payment's identity, state, route and history.
All of it: transitions, repeat boundary, event record, ledger instruction.
Provider or acquirer
Processes, and answers whether money moved.
The provider owns its processing behaviour; the platform owns which was asked.
Scheme or banking rail
Carries value between institutions under its own rules.
Nothing inward. The platform models its outcomes, including late ones.
Finance operations
Closes periods, answers auditors, judges differences.
The platform supplies instruction and evidence. Judgement stays with finance.
How money state moves
Four states forward, two answering one afterwards. Nothing is reversed in place.
- 01
The intent exists before the money does
An amount, a payer, a reason — under an identity the platform issues before a provider is asked.
- 02
The funds are held, not taken
A provider reserves the amount. Reservations expire, and reading this as payment shows up at settlement.
- 03
The claim on the money is made
The reservation becomes an amount owed, whole or partial. The first state the ledger may recognise.
- 04
The money has actually moved
Funds arrive net of fees, in a batch matching no single payment. Matching it back is the point.
- 05
Value returns by the route it came
The capture stays true. A refund is a second movement, with its own identity and entry.
- 06
The payer disputes after the fact
An issuer reverses settled funds on a timetable the merchant does not set. The authorisation stands; what is owed does not.
How many providers, and how close
Three models. None of them is the default; the conditions below decide.
- Lowest. One contract, one console.
- Routing rules, per-provider behaviour, one shared state.
- Highest. Rail obligations arrive with the control.
- The outage is yours; recovery is waiting.
- A route changes on a rule written in advance.
- Failure moves nearer the rail, where fewer people help.
- The provider decides. Often adequate.
- The platform decides, against cost, coverage and health.
- Total, and only worth having if it is used.
- The provider's format, accepted as given.
- Several formats normalised into one owned ledger.
- Settlement matching owned end to end.
- One market, predictable demand, no appetite to run payments.
- Several providers, geographies or failure paths to hold together.
- Proximity to a rail produces value the business can name.
What it has to reach
Payment providers
PSPs, acquirers and banking rails: the only parties permitted to move money. The platform sends an instruction and keeps what came back, including answers arriving hours later about a payment considered done.
Financial systems
The general ledger, ERP and treasury do not read payment tables. This boundary produces entries and settlement evidence in the shape those systems use.
Product and risk
Checkout decides what is paid for, screening and fraud whether it proceeds, support asks afterwards what happened. Three views of one payment.
When it fails
Five conditions, and no answer that claims certainty it does not have.
- The provider stops answering mid-request
No response. The payment is held in a state named unknown, not failed.
A query against the provider's own record settles it; until then nothing is resent.
- The same payment is submitted twice
The second request carries the first one's identity, seen before sending.
The original outcome is returned. A repeat never becomes a second charge.
- Only part of the order is captured
Captured and authorised differ, and the difference is recorded, not rounded.
The remainder is captured separately or left to expire; the ledger carries both.
- The settlement file disagrees with the platform
Exceptions by kind: unmatched, one-sided, or right identity, wrong amount.
Each becomes named work carrying both references, and the period stays open.
- A dispute arrives against a closed order
The provider notifies weeks later, about a payment the product finished with.
A compensating movement is appended and the window tracked; the original is not edited.
What you own afterwards
- Differences between platform, provider and ledger are named by the system, not by somebody comparing exports at month end.
- A provider that stops answering changes the route and the exception list. It does not change what the record says happened.
- Support, finance, risk and audit answer from one history: what was asked, what came back, and what the books did.
- Adding or replacing a provider is an adapter and a routing rule. The product's model of a payment does not move.
Related pages
Ledger and Reconciliation
The system that appends financial events as balanced entries, matches them against the records other parties keep, and turns each difference into a break with an owner.
API & Systems Integration
The boundary between systems that change independently, fail differently and sometimes disagree — engineered as a contract rather than a connection.
Cloud Infrastructure
The operating environment beneath critical software: deployment, isolation, observability and recovery, engineered so failure stays bounded and the service returns to a known state.
Bring a payment path that rests on one provider, a reconciliation nobody can close, or three systems that disagree about what a customer paid.