Two seconds that hold a business together
A customer taps a card. A light turns green. A receipt prints. From the shopper’s side, two seconds. From the system’s side, a relay race across a dozen components run by different teams and sometimes different companies, any of which can stumble.
I have spent many years around retail checkout and payments, and most of what I know came from watching those two seconds go wrong. The shopper remembers only one thing: whether they were charged correctly, once. The business remembers a different list: whether it was paid, whether the stock moved, whether the books balance, and whether the tax was right.
This essay walks through what happens between the scan and the settlement, where it tends to break, and how to design so that a break is a small, recoverable event rather than a loss of trust.
The journey of one sale
Scan and basket
The sale begins with a scan, a tap on a screen, or an item placed on a smart surface. The till identifies the item, looks up its details, and adds it to a basket. Already, several things must be right: the item code resolves to one product, the unit is known, and the basket can be changed and recalculated safely.
Pricing and promotions
Next, the system works out what the basket costs. This means base prices, store or region differences, member prices, multi-buy promotions, coupons and tax. Promotion logic is where subtle errors live. The order in which discounts apply, whether a coupon stacks, how a discount is shared across items for tax and for returns: each choice changes the final number and the later refund.
Tender and authorization
The customer pays. For cash, the till records the amount and the change. For a card or wallet, the till asks a payment terminal, which talks to a payment provider, which talks to the card network and the issuing bank. The reply comes back as approved, declined or something in between. This is the step with the most outside parties and the least control.
Receipt and record
If the payment is approved, the till finalises the transaction, prints or sends the receipt, and writes the record. That record feeds many things: stock, sales reporting, loyalty points, tax and the financial ledger.
Capture, settlement and reconciliation
Behind the scenes, an approval is a promise, not money. The approved amount is later captured, grouped into a batch, and settled to the business’s bank account, usually after a delay and net of fees. The business then reconciles what its tills recorded against what the provider and the bank report. Differences are investigated.
Every step in that chain has a different owner and a different clock. The till thinks in seconds. The provider thinks in batches. The bank thinks in days.
A parable of the river crossing
A parable, in the spirit of the teaching stories I like. It is a story I tell, not a record of history.
A trader had to carry goods across a river each day, using a ferry run by one boatman, then a cart run by another on the far side. Sometimes the boat reached the middle and the mist closed in, and the trader on the bank could not tell whether the boat had turned back or was still crossing. Early on, the impatient merchants sent a second boat and ended up paying twice for the same goods. Others assumed the boat was lost and ordered new stock, and then the first boat arrived. The trader who prospered did something dull. He gave every crossing a numbered token. If the mist came down, he did not guess. He asked the boatman on either bank, by token number, “what happened to crossing forty-two?” The answer was always one of a few things, and he knew what to do for each.
That token is what engineers call an idempotency key, or a transaction reference. It is the most useful humble idea in payments, and it is the reason a good checkout can say “I don’t know yet” without losing its head.
Where it breaks
Timeouts and the unknown outcome
The worst moment in checkout is the timeout. The terminal sent the request and heard nothing. Did the payment go through? The customer’s bank may have approved it. The terminal may simply not have received the answer.
If the system treats a timeout as a decline, the shopper may be charged without a sale. If it treats a timeout as approval, the shop may give goods away. The honest answer is neither. It is “unknown”, and unknown is a state that needs its own handling: the till must not finish the sale, must not invite a blind retry, and must ask the provider about the outcome using the transaction reference.
Duplicates and retries
Networks fail and software retries. A retry that creates a second charge is among the most damaging failures a retailer can cause, because it is visible on the customer’s statement and it arrives with a complaint.
Protection comes from design. Each payment attempt carries a unique reference. The provider recognises a repeated reference and returns the original result instead of charging again. The till keeps the reference until the outcome is known. When someone does decide to try again, such as a customer using a different card, that is a new reference and a new decision.
Partial failure
Many failures are halfway ones. The payment was approved but the receipt did not print. The sale was recorded but stock was not updated. The loyalty points were awarded for a sale that was later voided. In each case, one part of the system believes the sale happened and another does not.
The fix is to think of a sale as a small state machine with clear states: started, priced, awaiting payment, paid, completed, failed, reversed. Each transition is recorded. If something stops midway, a recovery process can look at the state and decide whether to complete or reverse. Without explicit states, recovery depends on someone noticing and guessing.
Refunds, voids and reversals
Money going back is harder than money going in. A void before payment is simple. A refund after settlement must match the original sale, the original tender, the promotions applied and the tax charged. A refund to a different method than the original raises fraud and compliance questions. A reversal of an authorization that was never captured needs to release the hold on the customer’s funds, and customers notice when it does not.
Design refunds as a first-class flow, not an afterthought. Tie them to the original transaction reference, enforce rules about tender and limits, and record the reason.
Designing for the unknown
A few design habits make the plumbing forgiving.
Give everything a reference. Every sale, every payment attempt, every refund. Pass it through every system so that anyone can trace one customer’s two seconds across many components.
Make state explicit. Record the stage of each transaction, and let recovery processes act on states rather than on guesses.
Treat unknown as a real outcome. Build a screen and a procedure for it. Tell the cashier what to do, tell the customer what is happening, and have the system resolve it as soon as the provider can confirm.
Prefer to ask over assuming. Where possible, query the provider for the status of a transaction before retrying or cancelling.
Separate the customer’s experience from the system’s certainty. A shopper can walk away happy while the back-end completes confirmation, as long as the system will definitely close the loop.
Keep an audit trail that a person can read. When a customer disputes a charge, the shop should be able to see the whole story in one place.
Test failure on purpose. Simulate timeouts, drops and duplicates in a test environment, and in carefully planned live exercises. The first time you see a failure should not be a busy Saturday.
The money trail: from till to bank
Reconciliation is where checkout meets finance. A typical flow looks like this: the tills report their tenders for the day; the payment provider reports its approved and captured transactions; the bank reports the settlement, net of fees; and finance compares the three.
Differences usually fall into familiar groups:
- Timing: a sale near midnight lands on different days in different systems.
- Fees and adjustments: the settlement is net of charges that the till never saw.
- Chargebacks and disputes: money taken back after the fact.
- Missing or duplicate records: a transaction present on one side only.
- Currency and rounding: small differences that add up.
Good practice is to match at the transaction level using the shared reference, not by comparing daily totals. Totals hide offsetting errors. Transaction-level matching tells you exactly which sale is missing, and often why.
It also helps to agree on cut-off times and on who owns each type of difference. Without owners, differences pile up in a suspense account until someone has to write them off.
Self-checkout and new channels
Self-checkout, mobile checkout, click-and-collect and unattended formats move the same plumbing to new places and remove the cashier who used to absorb the odd failures. A customer facing an “unknown” at a self-checkout needs clear wording and a fast path to a person. A mobile basket that persists across devices needs the same state discipline as a till. Click-and-collect adds a gap between payment and handover in which stock, price and substitutions may change.
The principle is the same: the fewer humans in the loop at the moment of failure, the more the system must make failure clear, safe and recoverable by itself.
What to watch on a dashboard
A short set of signals will tell you most of what you need.
- Approval rate by tender, store and time of day. A sudden drop often means a connectivity or provider problem, not a sudden change in customers.
- Time to authorise. Slow payments cause abandoned baskets and long queues.
- Unknown or timed-out rate, and how long each stays unknown.
- Duplicate attempts caught by the reference check.
- Voids and refunds by reason and by store.
- Reconciliation breaks by type and age.
- Offline transactions held and replayed.
Look at trends rather than single spikes, and always ask for the cause to be named: network, terminal, provider, configuration or process.
A starting playbook
- Draw the journey. For one store format, map every system between scan and bank, with an owner and a clock for each.
- Find your references. Check that every sale and every payment attempt carries a unique reference that travels end to end.
- Define the sale states. Write down the states and the transitions, and check that recovery acts on them.
- Design the unknown. Write the procedure for a timeout, for the cashier and for the customer, and test it.
- Check duplicate protection. Confirm with your provider how repeated references are handled.
- Review refunds. Walk through a refund after settlement, to the original tender, with a promotion applied, and see what happens.
- Match at transaction level. Set up reconciliation by reference and agree on owners for each difference type.
- Rehearse failure. Run a controlled test of a network drop and a provider timeout, and learn from it.
- Review monthly. Look at the dashboard signals and pick one cause to remove.
Closing thought
Good checkout feels like nothing. The shopper taps, the light turns green, and they walk away. That quiet is the product of a lot of careful, unglamorous plumbing: references, states, retries done safely, and a habit of saying “I don’t know yet” instead of guessing.
If you run checkout, payments or retail operations, and want a second pair of eyes on how your own journey handles failure, I am happy to talk it through. The first conversation is a free 20-minute call: https://topmate.io/raja_jeevan_kumar_maduri