How a card payment gets approved
There is a window, running until whenever my terminal closes its batch for the day, in which a card charge can be made never to have happened. Cancel inside it and the line vanishes from the customer’s banking app leaving nothing behind. Miss it, and the only way to return that money is to send new money in the opposite direction, which takes the better part of a week.
Same amount, same customer, same mistake. Two entirely different mechanisms, and which one I get depends on the time of day.
I run mobile proxy lines on carrier SIMs in Singapore and a rack of Android phones that people rent by the hour. Both of those take cards, so a decent slice of my week goes on explaining why somebody’s money is in a state with no everyday name. I have never worked at a bank or inside a card network. What follows is the merchant end of the system plus the rules the networks publish.
Four parties who cannot see each other’s books
A tap involves four organisations. The terminal standing in the shop. The acquirer, which is the shop’s bank. The card network, which routes messages. The issuer, which is the customer’s bank.
Only the last of those can answer the question being asked. My acquirer has no route to a cardholder’s balance and there is no interface through which it could ask. The network holds no accounts and never touches the funds. The terminal holds a signature and a total.
The structural fact under all of this is that the shop’s bank never sees your balance and your bank never sees the shop’s records. Every party holds one fragment and is prevented by design from holding the others. An authorisation is what you get when a question has to be answered by four institutions that are forbidden from merging their books.
That constraint is the reason the whole thing is a relay of messages instead of a lookup.
What the chip proves
The chip in a card is a small computer with a key sealed inside it, and that key has never left the card. When the terminal wakes it, the terminal supplies the amount, the currency, the date and a fresh random number. The chip signs all of that and returns a block of ciphertext.
That block proves one narrow thing: this specific card was physically present for this specific amount at this specific moment. Copy the digits off the front and you cannot generate it, because the key is not printed on the front. Knowing an account number and holding the account are different things, and the chip exists to enforce the difference.
The terminal then does nothing interesting with it. It packages the signature, the amount and its own merchant identity into a message and pushes it upward. A terminal can approve alone in a narrow set of cases, small values, transit gates, aircraft with no connectivity, and those are losses the issuer agreed to absorb in advance. Everything else travels.
The acquirer that receives it knows a great deal about me and nothing at all about the person paying. It knows my dispute history and my category code, four digits describing what kind of business I am, which drives more of my treatment than I expected. It cannot see a balance either, so it formats the question and passes it on.
The only party that can answer
The issuer holds the two things the question needs: the balance and the history.
It checks the chip signature against its own key material first, which is cheap and binary. Then it scores the request, using the same family of machinery that decides whether the person opening a banking app is really the account holder. A model, a few milliseconds, a pile of individually weak signals collapsed into one number.
What goes in: the amount relative to normal spending on that card, the merchant category, the location and whether the card has ever transacted there, how many attempts have hit the card in the past hour, and whether the chip was read at all or the terminal dropped back to the magnetic stripe, which is a much weaker proof and is scored as one.
None of that is a rule. They are inputs, and a probability comes out the other end.
Why the cheap purchase abroad fails and the expensive one at home does not
Two thousand dollars at a furniture shop near your flat clears without comment. Forty dollars at a petrol station in a country you landed in that morning gets refused. This looks broken and is the model working exactly as designed.
Size barely matters. Distance from your established pattern is the thing being measured. The furniture shop sits inside everything the issuer already knows about you, at an amount that is unusual but easy to explain. The petrol station is a merchant category with a long recorded history of being used to check whether a stolen card still authorises, in a place with no history for you at all, on a day the card began behaving in new ways.
The issuer is not making an accusation. It produced a number and the number crossed a threshold that somebody set in a meeting months earlier.
Twenty five characters of text, and the disputes they cause
Your bank does not receive an itemised basket. It receives an amount, a category code, and a short string of text that the merchant chose, capped around twenty five characters.
That string does real damage. A customer who cannot recognise the name on their statement disputes the charge in good faith, believing it to be fraud, and I then have to prove a legitimate sale happened. It is one of the most common dispute categories in online commerce and it is a labelling problem from end to end.
Authorised, captured, settled
Here is the reframe that explains most of the confusing behaviour: when the green tick appears, no money has moved. None has left the payer’s account and none has arrived in mine.
What happened is that the issuer made a commitment. It set the amount aside, reduced the available balance by it, and undertook to pay if the shop later claims it. An approval is a promise with a short shelf life, and my till is now holding a claim it has not yet presented.
Unclaimed holds expire on their own, usually within a few days, and the line disappears from the app as though nothing occurred. That is the mechanism behind the classic double line: one real order, plus an authorisation from an earlier attempt that timed out before anyone saw an answer. Fuel pumps and hotels make it stranger, since they must authorise a figure before the true one is known, so a statement can carry an amount that was never a price.
Money moves at batch time. My terminal submits the day’s claims, the acquirer collects, the network runs a settlement cycle, funds travel on a schedule that only counts banking days, and an amount eventually lands in my account with fees already deducted. It never matches any receipt, because it is a day of takings minus interchange, minus the network’s cut, minus my acquirer’s margin, sometimes minus a refund attached to an order from the previous week.
Two seconds for the decision. Two to three days for the money.
Void and refund are different animals
Before the batch closes, I can void an authorisation. Nothing moved, so nothing has to move back, and neither side is left with a record worth arguing about.
After it closes, that option is gone. The original transaction has already begun travelling through settlement and it will complete that journey regardless of what I want. So a refund becomes a brand new transaction pointing the other way, and it has to cover identical ground: same batch, same settlement cycle, same banking days.
Which is the honest answer to why a charge takes two seconds and a return takes five days. The two seconds bought a decision. The five days are value physically moving between institutions, twice, in opposite directions. Customers rarely believe this, and from where they are standing I do not blame them.
Why the decline reason stays useless
The reply that comes back down the wire is tiny. An approval code, or a decline with a reason drawn from a short fixed list, and the one I see most often amounts to “ask your bank” with nothing else attached.
Merchants hate this and campaign to have it opened up. I think they are wrong, and this is the part I will argue about. A detailed decline reason is an oracle. Somebody grading a list of stolen numbers, one small approval at a time, would learn precisely which field on each record was wrong and what to correct. The vagueness is deliberate, and it is the price of refusing to hand a testing operation a free debugging tool. I have paid that price in support tickets for years and would not trade it.
What I had wrong
For a long time I reported revenue from approvals, because approvals arrive instantly and settlement does not. The numbers never matched my bank statement and I spent a couple of months privately convinced my processor was skimming.
It was nothing of the sort. The gaps were authorisations that never got captured, refunds settling in a different cycle from the payments they reversed, and currency conversion applied at a rate fixed on the settlement date instead of the order date. Everything keys off settlement now, and the approval dashboard sits beside it as a separate number that is permitted to disagree. The disagreement is correct behaviour, which took an embarrassingly long time to accept.
What I still cannot see is the inside of the scoring model. No merchant can. I get an outcome and a three digit code, and everything I believe about the reasoning is inference from a large pile of outcomes.
The architecture is a trade. The decision is fast because a person is standing at a counter with a queue behind them, and that pressure is social rather than technical. The money is slow because moving value between institutions requires all of them to agree on what happened, and agreement is expensive. Almost every confusing thing about cards falls into the space between those two speeds.
More on the machinery running underneath the ordinary internet at The Hidden Internet.
Get new guides and videos first — join the Telegram channel.