A Transaction, Narrated

27.0 What this chapter gives you#

1. You will be able to narrate a contactless card authorisation from card presentation to receipt, naming every hop and what each party does in it.
2. You will be able to say where the 1.8 seconds actually goes, and why the printer is a larger component than the network, the acquirer, the scheme and the issuer put together.
3. You will be able to explain why the beep at 320 milliseconds is not an approval, and why nothing has left the shop when it sounds.
4. You will be able to say why the issuer’s response cryptogram in tag 91 is discarded on a contactless tap and delivered to the card on a contact chip transaction, and what that costs in security and in time.
5. You will be able to expand a primary bitmap such as 723C648108E08201 by hand and list the twenty elements it declares.
6. You will be able to name which fields the acquirer adds, which it rewrites and which it passes through unchanged, and why the ones it passes through are the ones every downstream reconciliation depends on.
7. You will be able to describe how an issuer validates a cryptogram — master key, card key, session key, recomputation — and state the three things a match proves that nothing else in the message can.
8. You will be able to explain why an approval reduces an available balance and touches no ledger anywhere, and why no money has moved at 1,800 milliseconds.
9. You will be able to say what a terminal must do when no response arrives, and why retrying with a fresh trace number is the wrong answer.
10. You will be able to reason about the tail rather than the median — mobile data, cold DNS, PIN entry, stand-in processing — because that is where merchant contracts and scheme rules are written.

Everything in this volume so far has been apparatus. The four-party model gave you the cast. ISO 8583 gave you the envelope. The bitmap gave you the index. The fields gave you the contents. None of it has yet moved.

This chapter moves it. One purchase, one card, one terminal, one acquirer, one scheme, one issuer, and a stopwatch running from the moment the card enters the reader’s field to the moment the receipt is torn off. Every message is written out. Every field is named and populated. Every hop is timed, and at the end the timings are added up and compared against the number everyone quotes and nobody audits, which is that a card payment takes about two seconds.

The purchase is the same one used in the previous two chapters, so that nothing has to be relearned: a book costing £42.50, bought at a small bookshop in London on Tuesday 17 March 2026, at eight minutes past half past two in the afternoon, paid for by tapping a contactless Visa debit card on a countertop terminal. The card number, 4111111111111881, is from the test range every payments engineer recognises, and it is used here deliberately so that no real account appears in print.

Two warnings. The millisecond figures are a representative budget for a well-built United Kingdom deployment on a fixed broadband line, not a measurement of a particular system; the shape of the budget is the point, and the shape is stable even when the numbers move. And several values in the message are marked illustrative, because inventing an issuer’s proprietary bytes and presenting them as fact is exactly what this book refuses to do.

The plain version#

Imagine a shopkeeper who cannot accept your promise to pay, only your bank’s.

You want a book. The shopkeeper wants £42.50. He does not know you, and he cannot look inside your bank account. So before he will let you leave with the book, he wants a sentence from your bank that says: we have seen this, we have put £42.50 aside, and we will pay the shop. Getting that one sentence, from a bank that might be four hundred miles away, is the entire event.

The trouble is that the shopkeeper cannot telephone your bank. There are thousands of banks and millions of shops, and nobody could keep that many phone numbers. So the question travels along a fixed chain of four parties, each of whom only ever talks to the party next to them.

The card is the first. It is not a piece of plastic with a number on it; it is a tiny computer that can perform a calculation nobody else can perform, because it holds a secret only it and your bank know.

The till — properly, the card terminal — is the second. It knows the price, the date, the shop, and how the card was presented. It cannot decide anything.

The shop’s bank, the acquirer, is the third. It has an account for the shopkeeper, a direct line into the card networks, and a filing cabinet in which this transaction will live for years.

The card company in the middle, Visa in this case, is the fourth. It is a switchboard. Its job is to look at the front of the card number, work out which bank issued it, and pass the question on.

And your bank, the issuer, is the fifth and the only one that can say yes.

The question goes card, till, shop’s bank, card company, your bank. The answer comes back your bank, card company, shop’s bank, till. Nine steps in all, and it is over before you have finished putting your card away.

Where the time actually goes#

Here is the same purchase with a stopwatch on it. Start the clock the instant the card comes within range of the reader.

Read that table twice, because it says something nobody expects.

The part everyone imagines is slow — the message flying across the country to your bank and back — is the smallest number in it. All four outward journeys and all four return journeys, added together, come to about a tenth of a second. The computers at the other end are not slow either; your bank’s whole decision takes a quarter of a second.

The two big numbers are the ones nobody thinks about. Nearly a fifth of the time is the card and the till talking to each other over a few centimetres of air before anything leaves the shop at all. And almost half of it is the printer.

That is worth saying plainly. In a modern card payment, the single slowest component is a strip of paper being pushed past a hot line of dots.

Three things that are not what they look like#

The beep is not the approval. The terminal beeps and shows a green light at about 0.32 seconds, when the card has finished its part and can be taken away. At that moment nothing has left the shop. No bank has seen anything. The beep means “I have got what I need from your card”, and people read it as “you have paid”, which is why customers walk off and why terminals then have to display a decline to somebody’s back.

Your bank is not looking up your balance and subtracting. It does two quite different things. It checks that the card is genuine, by redoing the calculation the chip performed and seeing whether it gets the same answer. And it checks the money is available, by looking at your balance and at everything else it has already promised out of it today. Then it earmarks £42.50.

No money has moved. At the end of all 1.8 seconds, the shopkeeper has a promise and you have a hold on your account. The £42.50 has not left your bank and it has not arrived at the shopkeeper’s. That happens later, in a batch, overnight, and it is the subject of a later chapter. All this chapter’s machinery exists to produce one six-character code and a two-character yes.

Where the plain version stops being true#

There is no such thing as “the message”. The plain version speaks of a question travelling along a chain, as though one document were being carried from hand to hand. Nothing of the sort happens. The terminal produces a message in one format; the acquirer parses it, discards some of it, adds fields the terminal never sent, rewrites fields the terminal did send, and produces a different message in a different format; the scheme does the same again on the way to the issuer. In the United Kingdom this is unusually visible, because the terminal-to-acquirer link has historically not used ISO 8583 at all. It uses Standard 70, the Card Acceptor to Acquirer Interface Standards maintained on the industry’s behalf by UK Payments Administration and its predecessors, whose Book 2 covers real-time systems and whose Book 3 covers post-event systems. A British terminal typically speaks Standard 70 to its acquirer, and the acquirer speaks ISO 8583 to the scheme. Two formats, two vocabularies, one purchase. When you debug across that boundary you are comparing two different documents, and the correct question is never “what did the message say” but “which message, at which hop”.

The card is gone before the answer exists. In the plain version the chain is symmetrical: the question goes up and the answer comes back down the same path. For a contact chip transaction that is nearly true, because the card stays in the slot and receives the issuer’s reply. For a contactless tap it is false in a way that matters. The card finishes its work at around 320 milliseconds and is back in your pocket by 500. The issuer’s reply, which contains a cryptogram the card could in principle have verified, arrives at the terminal at around 900 milliseconds with nothing to deliver it to. The terminal discards it. This is not a defect; contactless was designed this way on purpose, trading one protection for the speed that makes tapping tolerable at a ticket barrier. But it means the security model of a tap and the security model of an inserted chip are genuinely different, and the difference is invisible to everyone in the shop.

These are not constants; they are distributions with a long tail. Every number in the plain version’s table is roughly a median. The engineering discipline of payments is not about medians. An acquirer’s contract with a merchant, and a scheme’s rules for an issuer, are written about the far end of the distribution: how often does this exceed one second, exceed three, time out altogether. The interesting behaviour is all in that tail, and it is where the protocol’s timeouts live. Mastercard’s published documentation for one of its processing products states that the issuer must respond within four seconds before that processor stands in on the issuer’s behalf, and that the processor in turn has a maximum of seven seconds to respond to Mastercard before Mastercard stands in. Those numbers exist because the tail exists. A system built to the median will meet them comfortably in testing and breach them on the first Saturday before Christmas.

Nothing in the narrative is the transaction. The receipt feels like the end. It is the end of the authorisation and the beginning of everything else. The clearing record has yet to be created, the interchange has yet to be assessed, the funds have yet to settle, the hold has yet to be released or converted, and the transaction remains disputable for months. What has been narrated here is the fastest and most reliable part of the life of a payment, and it is the part on which the industry’s public reputation rests, which is precisely why the slow and expensive parts that follow are so poorly understood.

The technical version#

The setting#

A countertop terminal in a bookshop in London. It is EMV Level 1 and Level 2 approved, contact and contactless, PCI PTS approved, with a thermal printer and a wired Ethernet connection to a business broadband line. It is configured for a single United Kingdom acquirer.

The card is a consumer Visa debit card, issued in the United Kingdom, dual interface, supporting Visa’s contactless application. Its application identifier is A0000000031010.

The date is Tuesday 17 March 2026, day 076 of the year. British Summer Time does not begin until Sunday 29 March 2026, so on this date the United Kingdom is on Greenwich Mean Time and local time equals Coordinated Universal Time exactly. This is a convenience that disappears twelve days later, and the disappearance breaks a great many reconciliation jobs each spring.

The card is presented at 14:32:04.800 local. That instant is T+0 for everything that follows.

The transaction is £42.50. The relevant United Kingdom contactless limits, as of writing in 2026, are a single-transaction ceiling of £100, in force from 15 October 2021 until 18 March 2026, after which the Financial Conduct Authority permitted firms to remove the mandatory cap; and a cumulative threshold of £300, or five consecutive contactless transactions, since the last application of strong customer authentication, the cumulative figure having been raised from £130 by the FCA in policy statement PS21/2. On 17 March 2026 the £100 ceiling still applies, and £42.50 is inside both, so no cardholder verification will be requested.

Phase one, T+0 to T+320 ms: the card in the field#

The reader has been polling continuously. The card’s antenna couples to the reader’s field at 13.56 MHz under ISO/IEC 14443, draws its power from that field, and answers.

Three details of that sequence do real work.

The terminal does not ask for the payment application by name. It selects the proximity payment system environment, 2PAY.SYS.DDF01, reads back the list of applications the card supports, and picks one by its own configured priority. This is why a card carrying two applications can behave differently at two terminals that are otherwise identical.

The GET PROCESSING OPTIONS command is where the transaction is actually committed. The card publishes a processing options data object list, the PDOL, naming the values it wants from the terminal. For Visa’s contactless kernel this list includes the terminal transaction qualifiers in tag 9F66, the authorised amount in 9F02, the other amount in 9F03, the transaction currency in 5F2A, the terminal country in 9F1A, the unpredictable number in 9F37 and the transaction type in 9C. The terminal concatenates those values in the order the card asked for them and sends them. The card signs over them. That is the whole basis of the cryptogram’s meaning: it attests to these values, in this order, at this moment.

And in Visa’s contactless EMV mode the cryptogram comes back in the response to GET PROCESSING OPTIONS. There is no separate GENERATE AC exchange, and therefore no second exchange in which the issuer’s reply could be handed to the card. This is the single design decision that makes contactless fast and that makes the issuer’s response cryptogram undeliverable.

At 320 milliseconds the terminal beeps and the customer takes the card away. The terminal now holds an authorisation request cryptogram, tag 9F26, eight bytes, computed by the chip using a key derived from a master key held by the issuer, together with the transaction counter in 9F36 that makes this cryptogram different from every other one this card has produced.

Phase two, T+320 to T+400 ms: the terminal builds the request#

The terminal now performs terminal action analysis. It examines the terminal verification results in tag 95, five bytes of flags, and the cryptogram information data in tag 9F27, one byte, whose value indicates an authorisation request cryptogram. It applies its floor limit, which for a United Kingdom contactless acceptance point is effectively zero, and concludes what it already knew: this transaction must go online.

It stamps the local transaction time and date. Its clock reads 14:32:05.120, so data element 12 becomes 143205 and element 13 becomes 0317. It assigns its own system trace audit number, 000982, from a counter persisted to non-volatile storage. It composes the message, applies whatever point-to-point encryption its acquirer requires, and hands it to the network stack.

At 375 milliseconds the request goes out over an already-established TLS session. A terminal that keeps a persistent, authenticated connection to its acquirer pays the handshake cost once, at sign-on. A terminal that opens a fresh connection per transaction pays it every time: a TLS 1.3 handshake costs one round trip before application data can flow, TLS 1.2 costs two, and both cost certificate validation on a processor that is not fast.

The one-way transit to the acquirer’s front end, over business fibre to a London data centre, takes about 25 milliseconds including the shop’s own router. Arrival at 400 milliseconds.

The message as it leaves the terminal#

Presented here in ISO 8583 terms for comparability with what follows, although a British terminal would more usually present it in Standard 70 form.

MTI 0100, authorisation request: version 0 for the 1987 edition, class 1 for authorisation, function 0 for request, origin 0 for acquirer.

Primary bitmap 723C448000E08200, declaring sixteen elements present.

Data element 43 deserves a note. Its forty characters are subdivided into name, town and country, but the subdivision is scheme-defined and the schemes do not agree on the boundaries; the value above is padded on the convention of twenty-five characters of name, thirteen of town and two of country code.

Two coincidences in the message are not coincidences. Data element 49 carries 826 for sterling and data element 19, which the acquirer will add shortly, carries 826 for the United Kingdom. ISO 4217’s numeric currency codes were assigned to match ISO 3166-1’s numeric country codes wherever a country has its own currency, so the sterling code and the British country code are the same three digits by construction. Systems that validate one against the other by equality will work perfectly in Britain and fail in the eurozone.

Data element 55, in full#

The acquirer interface used here encodes data element 55 as a three-character ASCII total length followed by binary tag-length-value data, a convention documented in Worldpay’s Lync ISO 8583 message specification and typical of the industry. The tag-length-value structure is BER-TLV as defined for EMV, not the composite-dataset structure that ISO 8583:2023 defines for its own fields; the 2023 standard explicitly exempts the integrated-circuit-card element and defers to ISO/IEC 7816-6.

Twenty-four objects, 160 bytes:

Note tag 57. On a chip transaction the track 2 equivalent data lives inside data element 55, and the acquirer interface used here specifies that where tag 57 is present it is the source of track data. That is why the message carries no data element 35: duplicating it would create two sources of truth for the same account number.

Note also 9F02, 5F2A and 9F1A. The amount, the currency and the country each appear twice in this message: once in the ISO 8583 elements 4, 49 and 19, and once inside the cryptogram’s input. Only the second copy is protected. If those two copies disagree, the issuer knows that something between the chip and itself altered the transaction, and it will decline. This is the only integrity guarantee in the entire message that does not depend on trusting the sender.

The same acquirer specification states that data element 55 is required on 0100, 0200, 0220 and 0400 messages and on stand-in messages, and must not be sent to the network for manual or fallback transactions. That last clause is the certification failure named in the previous chapter, in its formal wording.

Total message length as it leaves the terminal, in the ASCII-and-hexadecimal representation used here: 484 characters, of which 323 are data element 55.

Phase three, T+400 to T+470 ms: the acquirer#

The acquirer’s front end does more in seventy milliseconds than any other party in the chain.

It terminates the TLS session and parses the message, defensively: length prefixes are the standard attack surface of this protocol and a hostile or broken length is the first thing a front end must survive. It performs duplicate detection against the terminal’s trace number and terminal identifier over a short window, because the commonest cause of a double charge is not fraud but a terminal that retried.

It decrypts. If the account data arrived under a point-to-point encryption scheme, the ciphertext goes to a hardware security module — a tamper-responsive device holding keys that cannot be read out of it in the clear — and comes back as a primary account number inside the acquirer’s secure zone. That round trip is a few milliseconds and it is the moment at which the acquirer’s PCI DSS scope is defined. Had this been a PIN transaction, the same module would also have translated the PIN block from the key shared with the terminal into the key shared with the scheme, without the PIN ever existing in plaintext outside a tamper boundary.

It applies its own risk rules: velocity by terminal, by card, by merchant, and amount thresholds. A small proportion of traffic dies here and never reaches a scheme.

Then it writes its fields.

• Data element 7 is restamped with the acquirer’s own transmission time.
• Data element 11 is replaced. The terminal’s 000982 is meaningful only within that terminal; the acquirer substitutes 004417 from a counter unique within the acquirer for the processing day.
• Data element 19 is set to 826, the acquiring institution’s country.
• Data element 32, the acquiring institution identification code, is populated with the acquirer’s scheme-assigned identifier. This is 060000 in the worked example and is illustrative.
• Data element 37 is created: 607614430041, decomposing as year digit 6, day 076, hour 14 and a sequence. This value will now outlive everything else in the message.
• Data element 15, the settlement date, may be set here, determining which business day this transaction belongs to regardless of what the clocks say.
• Data element 64, an eight-byte message authentication code, is computed over the assembled message under a key shared with the scheme.

At 455 milliseconds the acquirer’s routing logic reads the leading digits of the account number, identifies a Visa product, and hands the message to its scheme endpoint. Twenty digits of routing decision, made on a table that is refreshed daily and that every acquirer in the world maintains separately.

Fifteen milliseconds of transit. Arrival at the scheme, 470 milliseconds.

The message as it leaves the acquirer#

MTI 0100. Primary bitmap 723C648108E08201.

That hexadecimal string is worth expanding by hand, because it is the whole argument of the bitmap chapter reduced to eight bytes.

Twenty elements declared in sixty-four bits. Bit 1 is zero, so there is no secondary bitmap and nothing above element 64 is present.

The message now runs to 523 characters. Compared with what the terminal sent, four elements have been added (19, 32, 37, 64) and two have been rewritten (7, 11). Sixteen have been passed through unchanged, and it is on those sixteen that every downstream reconciliation depends.

Phase four, T+470 to T+525 ms: the scheme routes it#

The scheme is a switch, and its work is narrow, fast and unglamorous.

It validates the message authentication code in data element 64 against the key it shares with this acquirer. It reads the issuer identification number from the leading digits of data element 2 — under ISO/IEC 7812-1 as revised in 2017 these are eight digits, though six-digit ranges remain in wide use and both must be supported — and looks up the destination in a routing table.

If the account number in data element 2 is a network token rather than a funding account number, the scheme’s token vault resolves it here, and the payment account reference, a value that stays constant across every token issued against the same underlying account, travels alongside so that the merchant and the issuer can still tell that two different tokens are the same customer. In the acquirer interface used above this reference occupies data element 56.

The scheme scores the transaction against its own risk models, starts a response timer, and records enough to build a clearing record later and to answer on the issuer’s behalf if the issuer does not reply. Then it sends. VisaNet, by Visa’s own published figures, is engineered to handle more than 65,000 transaction messages per second; this is one of them, and it occupies the switch for perhaps thirty-five milliseconds.

Twenty milliseconds of transit to the issuer’s processor. Arrival at 525 milliseconds.

Phase five, T+525 to T+775 ms: the issuer decides#

This is the largest single block of computation in the transaction, and it is a quarter of a second.

The cryptogram validation is the part worth understanding in detail, because it is the only step in the whole chain that proves anything.

The issuer holds a master key for the card portfolio inside a hardware security module. From that master key, together with the account number and the application PAN sequence number in tag 5F34, the module derives the unique key belonging to this individual card. From that card key, together with the application transaction counter in tag 9F36, it derives a session key that is used for this transaction and no other. It then recomputes the cryptogram over the data the card signed — 9F02, 9F03, 5F2A, 9F1A, 95, 9A, 9C, 9F37, 82, 9F36 and 9F10 — and compares its answer with the eight bytes in 9F26.

If those eight bytes match, the issuer knows three things it cannot know any other way: that a genuine chip carrying its key was present; that the chip saw this amount and this currency; and that this is not a replay, because the counter has advanced. If they do not match, everything else in the message is unsupported assertion.

The balance check is not a subtraction from a single number. The issuer holds a ledger balance, which is what has actually posted, and computes an available balance by subtracting authorisations already granted and not yet cleared. The £42.50 becomes another such deduction: an entry in a shadow-balance table with an expiry, not a movement in the ledger.

The fraud model is where the variance lives. A real-time scoring service consulting device, merchant, geography and behavioural features is the likeliest reason an issuer’s median response time is 250 milliseconds rather than 90, and its failure mode is a timeout rather than an error.

The decision is yes. The issuer generates the authorisation identification response, six alphanumeric characters, A4T29B, and sets the response code to 00. It generates an authorisation response cryptogram in the security module and packages it, with a response code the card would understand, into tag 91 inside data element 55.

The response#

MTI 0110, authorisation response: same version, same class, function 1 for request response, origin 0 because it retains the acquirer origin of the request.

Primary bitmap 723860010EC08201.

Eighteen elements, 186 characters. Of those eighteen, exactly two are new:

Data element 55 in the response contains a single object: tag 91, issuer authentication data, eight or ten bytes depending on which response cryptogram method the card profile uses. Everything else is echo.

Data element 4 is echoed at 000000004250. Had the issuer approved a lesser sum, this field would have come back smaller, and the terminal would have been required to notice, tell the operator, and collect the difference or reverse the whole transaction. A terminal that reads only data element 39 and ignores data element 4 will approve a partial authorisation as though it were full and leave the merchant short.

Phase six, T+775 to T+895 ms: back down the chain#

The acquirer’s forty milliseconds are not idle. It writes an authorisation record keyed on data element 37 that will have to be matched against a clearing record arriving days later, it reserves the merchant’s exposure, and it translates its terminal-facing response vocabulary — a mapping that is lossy in both directions for every value except approval.

Phase seven, T+895 to T+1,800 ms: the terminal finishes#

The terminal parses the response, confirms it matches the request it is waiting on, and updates its state machine to approved. At 935 milliseconds the screen reads APPROVED and the operator can start bagging the book.

It also discards tag 91. The card left the field six hundred milliseconds ago, and there is no second exchange in a contactless transaction to deliver the issuer’s cryptogram to. Had this been a contact chip transaction the terminal would now issue a second GENERATE AC command carrying that data, and the card would verify the issuer’s cryptogram and return either a transaction certificate or an application authentication cryptogram — retaining the right to decline a transaction the issuer has just approved. That exchange costs a further two to four hundred milliseconds and requires the card to still be in the slot, which is the entire reason chip-and-PIN feels slower than tapping.

Then it prints. A thermal printer laying down a merchant copy of roughly 120 millimetres at a realistic line speed takes about 660 milliseconds, and cutting, clearing and prompting for the customer copy takes another 200. Receipt out at 1,800 milliseconds.

The printed record carries data element 38 as the authorisation code, elements 12 and 13 as the date and time, element 41 as the terminal identifier, a masked form of element 2, and the entry mode derived from element 22. It does not carry element 37, which is the one number the acquirer will ask the merchant for when something goes wrong. That omission is a small, permanent, industry-wide own goal.

Where the two seconds actually goes#

Three conclusions follow, and all three are unwelcome to somebody.

The network is not the problem. Six one-way hops across two commercial boundaries, including a leg into a global switch, come to 120 milliseconds. That is under seven per cent, and it is the component with the least headroom, because most of it is the speed of light in glass.

The issuer is not the problem either, though it is the largest computational block. A quarter of a second to validate a cryptogram in a hardware security module, read an account, score it against a fraud model and commit a hold is not slow; it is the cost of doing the work honestly.

The problem, if there is one, is physical. The card conversation and the printer together are two thirds of the elapsed time, and neither is a computer being slow. One is a passive device drawing its power from a radio field. The other is paper. This is why the most effective latency work in retail payments over the past decade has been suppressing the customer receipt and printing the merchant copy asynchronously, which removes up to 865 milliseconds from the queue without touching a line of protocol code.

The tail#

Everything above is a median. Here is the same transaction going wrong in the ordinary ways, and what each costs.

The last row is the one that changes the shape of the outcome rather than the duration. Mastercard’s published documentation for one of its processing products puts the issuer response window at four seconds, and the processor’s own window at seven seconds, after which Mastercard authorises on the issuer’s behalf. When that happens, the approval the merchant receives was granted by the scheme against limits the issuer configured in advance, the issuer learns about it afterwards by advice message, and the liability position is different from a normal approval in ways set out in the scheme’s rules rather than in any technical specification.

Note also the cardholder verification row. The moment a human is asked to do something, every millisecond above becomes rounding error, and no amount of protocol optimisation touches it.

When the answer never comes#

The narration above has a response arriving. Consider the case where it does not: the acquirer’s reply is lost between 870 and 895 milliseconds, after the issuer has already placed a hold.

The terminal times out. It does not know whether the transaction was approved, declined, or never seen. What it must not do is simply retry with a fresh trace number, because the issuer would then see two unrelated requests and place two holds.

The correct behaviour is one of two things. Either it retransmits the identical message with the MTI’s origin digit changed from 0 to 1, producing 0101, with the same trace number and retrieval reference number, so the issuer recognises a repeat of something it may already have answered. Or it sends a reversal, MTI 0400, quoting the original message’s identifying values inside data element 90 — the original MTI, trace number, transmission date and time, and acquiring and forwarding institution identification codes — so the issuer can find the hold and release it.

Reversals are the least glamorous and most consequential messages in the protocol. A terminal that fails to send them leaves customers with money held against purchases that never happened, for as long as the issuer’s hold expiry allows. Every complaint that begins “the payment failed but the money has gone” is a missing 0400.

What has and has not happened#

At 1,800 milliseconds the customer has a book, the operator has a receipt, and the following is true.

The issuer has reduced the cardholder’s available balance by £42.50 and has not touched the ledger balance. The acquirer holds an authorisation record keyed on 607614430041 with an approval code of A4T29B. The scheme holds a routing and timing record. The terminal holds a batch entry awaiting the day’s close.

No money has moved. No entry has been posted to any account at the Bank of England. The merchant will not be paid until the transaction is submitted for clearing, matched, assessed for interchange — at, as of writing, a United Kingdom domestic cap of 0.2 per cent for consumer debit where merchant, acquirer and issuer are all in the United Kingdom, which on £42.50 is 8.5 pence — and settled between the parties’ banks. On this transaction the merchant service charge, the scheme fees and the acquirer’s margin will all be assessed against a payment that took 1.8 seconds to authorise and will take days to complete.

The next chapter deals with the identifiers left behind — the trace number, the retrieval reference number, the acquirer reference number and the authorisation code — because those four values are the only handles anybody has on this transaction for the rest of its life, they have four different owners and four different lifetimes, and asking the wrong party for the wrong one is how a simple query becomes a three-week correspondence.

27.98 Common wrong ideas#

Wrong: one message travels along the chain from the till to the issuer. Right: each hop parses, discards, rewrites and re-emits, and in Britain the terminal typically speaks Standard 70 to its acquirer while the acquirer speaks ISO 8583 to the scheme, so the correct question is never “what did the message say” but “which message, at which hop”.

Wrong: the network is the slow part of a card payment. Right: all six one-way hops come to about 120 milliseconds, under seven per cent of the elapsed time, while the printer is 865 milliseconds and nearly half.

Wrong: the beep means the payment is approved. Right: at 320 milliseconds the card has merely finished its part and nothing has left the shop, which is why customers walk away before a decline can be displayed.

Wrong: a tap and an inserted chip have the same security model. Right: in Visa’s contactless mode the cryptogram arrives in the response to GET PROCESSING OPTIONS, there is no second GENERATE AC exchange, and the issuer’s reply reaches a terminal with nothing left to deliver it to.

Wrong: the till’s trace number identifies the transaction all the way through. Right: the acquirer replaces DE11 with a value unique within itself and creates DE37, which is the number that outlives everything else in the message.

Wrong: DE39 00 is the whole answer, so the terminal can print APPROVED. Right: the response can echo a smaller DE4 for a partial approval, and a terminal that reads only DE39 will treat it as a full authorisation and leave the merchant short.

Wrong: the amount, currency and country the issuer checks are elements 4, 49 and 19. Right: only the copies inside DE55 — tags 9F02, 5F2A and 9F1A — are covered by the cryptogram, and a disagreement between the two copies is exactly what an altered transaction looks like.

Wrong: the approval means money has moved. Right: the issuer has written an entry with an expiry into a shadow-balance table and has not touched the ledger balance, and nothing posts until clearing and settlement days later.

Wrong: when the response times out the terminal should send the transaction again. Right: it must either retransmit the identical message as a 0101 with the same trace and retrieval reference numbers, or send a 0400 reversal quoting the original values in DE90, because a fresh trace number produces two holds.

Wrong: the median timings are the engineering target. Right: contracts and scheme rules are written about the tail, where Mastercard’s published four-second issuer window and seven-second processor window live, and a system built to the median will meet them in testing and breach them on the first Saturday before Christmas.

27.99 Chapter summary in 20 lines#

1. One purchase — a £42.50 book tapped on a countertop terminal in London on 17 March 2026 — takes 1,800 milliseconds from card presentation to receipt.
2. The card is a computer holding a key only it and the issuer know, the terminal knows the context and can decide nothing, the acquirer owns the merchant relationship, the scheme is a switchboard, and only the issuer can say yes.
3. The first 320 milliseconds are the card and the reader talking over a few centimetres of air: anticollision, selection of the proximity payment system environment, application selection, and GET PROCESSING OPTIONS.
4. The card publishes a processing options data object list naming the values it wants, the terminal supplies them in that order, and the cryptogram in tag 9F26 attests to exactly those values at that moment.
5. In Visa’s contactless mode the cryptogram comes back in the GET PROCESSING OPTIONS response, so there is no second exchange and no way to deliver the issuer’s reply to the card.
6. The terminal performs terminal action analysis, stamps its local time and date, assigns its own trace number, and sends the request at 375 milliseconds over an already-established TLS session.
7. Its message declares sixteen elements and runs to 484 characters, of which 323 are data element 55.
8. The acquirer’s seventy milliseconds are the busiest in the chain: parse defensively, detect duplicates, decrypt in a hardware security module, apply risk rules, then write its own fields.
9. It adds elements 19, 32, 37 and 64, rewrites 7 and 11, and passes sixteen elements through unchanged, and it is on those sixteen that every downstream reconciliation depends.
10. The scheme validates the message authentication code, reads the issuer identification number from the leading digits of the account number, resolves a token if there is one, scores the transaction, starts a response timer and forwards it.
11. The issuer’s quarter of a second is the largest computational block: parse, validate the cryptogram, read the account and its holds, score for fraud, decide, place the hold and build the 0110.
12. Cryptogram validation derives a card key from a portfolio master key and a session key from the transaction counter, recomputes the cryptogram and compares it, proving that a genuine chip was present, that it saw this amount and currency, and that this is not a replay.
13. The balance check subtracts authorisations already granted from a ledger balance, and the £42.50 becomes another such deduction with an expiry rather than a movement in any ledger.
14. The response carries exactly two new fields, the authorisation code A4T29B in element 38 and the response code 00 in element 39, plus tag 91 inside element 55 that a contactless terminal will discard.
15. Adding the components up: the card and terminal 320 milliseconds, all network transit 120, the acquirer 95, the scheme 55, the issuer 250, terminal software 95, and the printer 865.
16. The two slowest components are not computers being slow but a passive device drawing power from a radio field and a strip of paper, which is why suppressing the customer receipt is the most effective latency work of the past decade.
17. The tail is where the engineering is: mobile data, per-transaction TLS handshakes, cold DNS, the contact chip’s second GENERATE AC, and above all a human being asked to enter a PIN.
18. When the issuer does not answer within its window the scheme stands in, and the approval the merchant receives was granted against limits the issuer configured in advance, with a liability position set by scheme rules rather than by any technical specification.
19. When no response reaches the terminal the correct behaviour is a 0101 repeat carrying the same identifiers or a 0400 reversal quoting the original data elements in DE90, and every complaint that begins “the payment failed but the money has gone” is a missing 0400.
20. At 1,800 milliseconds the customer has a book and the merchant has a promise, but no money has moved, no entry has been posted at the Bank of England, and the transaction remains disputable for months.

Chapter sources: ISO 8583:1987 data element and MTI tables as consolidated in the Wikipedia ISO 8583 article; Worldpay Lync ISO 8583 Message Specification, data element 55, for the DE55 subelement encoding scheme, the tag and length table including 9B, 9F66 and 9F6C, the treatment of tag 57 as the source of track data, and the message types requiring DE55; Visa Developer Request and Response Codes for point of service condition codes 00, 08 and 51; UK Payments Administration Standard 70, Books 2 and 3, as catalogued at iso8583.info; Mastercard Processing Debit API documentation for the four-second issuer and seven-second processor windows and stand-in processing; Visa’s published figure of more than 65,000 transaction messages per second; FCA policy statement PS21/2 for the £300 cumulative contactless threshold, and reporting of the £100 limit in force from 15 October 2021 to 18 March 2026; Payment Systems Regulator on the UK Interchange Fee Regulation caps; ISO 18245 code 5942; EMVCo contactless entry point documentation and the arXiv systematisation “SoK: Security of EMV Contactless Payment Systems” for the PPSE, application selection and GET PROCESSING OPTIONS flows; ISO/IEC 14443, 7812-1, 7816-6, ISO 3166-1 and ISO 4217. All bitmap expansions, message lengths, timing totals and percentages were computed from the field sets stated in the text.