The customer taps, the terminal flashes approved, and they walk out with the goods. In their mind, they paid. In your bank account, nothing has happened yet. Between that green checkmark and money you can actually spend sits a pipeline of batches, cut-off windows, funding delays, and reconciliation, and every one of those stages is a place where a euro can go missing quietly.
Authorization is a promise; capture is the ask
An authorization is the card network agreeing to hold funds. A capture is you actually claiming them. Collapsing the two into one step is fine for a coffee, but the gap between them is where real commerce lives. A hotel authorizes at check-in and captures at checkout. A marketplace authorizes on order and captures on ship. Authorizations expire, often within seven days, so a capture that never fires is revenue you were promised and then silently forfeited. Track both states explicitly, or you will ship goods against holds that quietly lapsed.
Money moves in batches, not in moments
Captures do not settle one by one. Your processor accumulates them and submits a batch at a daily cut-off, and where that cut-off falls decides which calendar day a sale belongs to. The batch is funded a day or two later, minus interchange, scheme fees, and the processor's cut, and then a payout lands in your account as a single lump. That lump almost never equals the sum of the sales the customer sees, because refunds, chargebacks, and fees are all netted into it. If your books expect a tidy one-to-one, the mismatch starts on day one.
The ledger, reconciliation, and the exceptions queue
This is why the processor dashboard cannot be your source of truth. The source of truth is your own double-entry ledger, where every state transition, authorized, captured, refunded, settled, charged back, is an immutable entry. Money is never created or destroyed, only moved between accounts you control. The ledger is what lets you answer, at any second, exactly how much you are owed and how much has actually arrived.
Reconciliation is where that claim gets tested. You match the ledger against the processor's settlement report and against the raw bank statement, a three-way match, not two. Most lines agree and clear automatically. The ones that do not, a payout short by a fee you did not model, a refund that never funded, a duplicate, drop into an exceptions queue. That queue is the real product of a settlement system. It is usually a fraction of a percent of volume, and it is where every genuine discrepancy surfaces before it becomes a loss.
Treat the ledger as the truth and the bank as a claim to be verified. Money is not real until reconciliation says the two agree.— Protocore · Payments engineering
We ran this pipeline live for 80,000 festival attendees and cleared 2.4M euro in three days, tap-to-confirm in 120ms, with zero settlement disputes at the end of it. Zero disputes is not luck; it is a ledger that matched the bank to the cent, an exceptions queue that stayed nearly empty, and cut-off windows we understood before the gates opened. Authorization is the easy half. Getting the money into the account, provably, is the half that earns the trust.
Have a system to build?
Tell us the problem. We'll come back with an architecture and a plan.
Start a project