What the Terminal Actually Sends

22.0 What this chapter gives you#

1. You will be able to take any piece of a payment message and say which of the four writers — the card, the terminal, the acquirer or the issuer — put it there.
2. You will be able to explain why the terminal almost never sends the message the banks actually read, and what the acquirer’s host builds from scratch on its behalf.
3. You will be able to read a field 55 tag by tag and recover the transaction from it, including the single bit that explains why it went online at all.
4. You will be able to do the byte arithmetic on field 55 and predict which tags a 255-byte or 255-character ceiling will amputate, and which of those losses are fatal.
5. You will be able to explain why a disagreement between DE 4 and tag 9F02 presents as a cryptographic failure when it is really a mapping bug in somebody’s message translator.
6. You will be able to say what DE 22 claims about a transaction, and why claiming a chip read while sending no field 55 is the commonest certification failure in the industry.
7. You will be able to state what the terminal must and must not do when tag 91 is present in the response, and what it must do when it is absent.
8. You will be able to explain why a reversal has to replay the exact bytes that were sent rather than regenerate them from a database.
9. You will be able to distinguish the authorisation from the completion advice and from the clearing record, and say which of the three actually claims the money.
10. You will be able to explain why the twelve-character reference the acquirer stamps on a message today is the identifier a dispute will be argued from next summer.

At 09:45:12 on Monday 17 August 2026, in a coffee shop in Leeds, somebody buys a flat white for £4.20 and puts a card in a slot. Eleven chapters of this volume have been about what happens inside that moment: the plastic, the number, the chip, the eight bytes of mathematics it produces, the reader limits, the keypad, the encryption in the head of the terminal. This chapter is about the sentence at the end of it. The terminal has finished thinking. Something now has to leave the shop.

What leaves is about three hundred and fifty bytes. Less than a photograph of the receipt. Less than this paragraph, encoded as text. Inside those bytes are two things of quite different natures: a set of facts asserted by the machine on the counter, and a short, sealed block written by the chip, which the machine cannot read, cannot alter and does not understand. The whole of the rest of this book is the story of where those bytes go. This chapter is the story of how they are assembled, and of who wrote each one.

It is also the last chapter of Volume II, so it has a second job. Everything up to here has been about one end of the wire. From the next chapter the subject changes: four parties, a message format, a network, a settlement cycle, a dispute process. The join between the two is a single data element with a two-digit number, and getting the join wrong is the most common way for an otherwise correct chip implementation to fail certification.

The plain version#

Imagine a hospital referral. Your GP writes a letter to a consultant: your name, your age, the date, what she observed, what she thinks. Stapled to that letter is a sealed envelope from the laboratory containing a test result. The GP cannot open it. She does not need to. Her job is to describe the room she was standing in; the laboratory’s job is to say something the consultant can verify independently. The consultant reads both, and the value of the letter depends heavily on the fact that the envelope was sealed before it left the laboratory.

The terminal is the GP. The chip is the laboratory. The letter is the transaction: how much, when, where, which machine, how the card was read, whether anybody typed a PIN. The sealed envelope is eight bytes of cryptogram plus the exact facts the chip signed over when it made them. The bank at the other end reads the letter, opens the envelope, recomputes the mathematics with its own copy of the key, and sees whether the answer matches.

There is one more character: the courier. The card machine does not know how to reach your bank and has never heard of it. It knows exactly one address, the company the shop signed a contract with, which the trade calls the acquirer. The acquirer takes the letter, puts it in a standard envelope of a format the whole industry agrees on, writes its own reference number on the outside, adds its own return address, works out from the first few digits of the card number which bank the letter is for, and sends it.

So there are three writers, and one of the most useful habits you can build is asking, of any piece of a payment message, which of the three wrote it.

A worked example#

Take the flat white. The basket is £4.20. The shop is in the United Kingdom, so the currency is sterling. The card is a chip card, inserted rather than tapped. The amount is small, so no PIN is asked for. The terminal decides, for reasons Chapter 16 set out, that it will not approve this one on its own authority, and asks the chip for the kind of cryptogram that means “ask the bank”.

The chip produces its sealed block. In this transaction it is one hundred and thirty-four bytes long, and it contains twenty-one separate items. Eight of them the chip wrote. Thirteen the terminal wrote and then handed to the chip to be signed over, so that nobody in the middle can change them without the mathematics breaking. Among the thirteen are the amount, £4.20; the currency, sterling; the country, the United Kingdom; the date; the four random bytes the terminal generated to make this transaction unlike any other; and the terminal’s own account of what the customer did or did not have to do to prove who they were.

Around that block, the terminal writes the letter. The parts that matter to a human read roughly as follows.

Then the acquirer adds its own three lines: a reference number that will follow this transaction for the next eighteen months, its own institution number so the reply knows where to come back to, and a timestamp in universal time so that two computers in different countries can agree on the order of events.

The reply arrives in under a second and is much shorter. It contains a two-character verdict, a six-character approval code that the receipt will print, and, if the bank has bothered, a second sealed envelope addressed to the chip. That second envelope is the interesting one. It lets the chip check that the approval really came from its own bank and not from someone in the middle of the wire with a convincing manner. The terminal cannot read that envelope either. It simply passes it to the chip, and the chip says yes or no.

Count the writers once more. The chip wrote eight items and sealed twenty-one. The terminal wrote thirteen of the sealed ones and about a dozen unsealed ones. The acquirer wrote the outside of the envelope. The bank wrote three lines back. Nobody wrote the whole message, and no single party in the chain could have.

Where the plain version stops being true#

The terminal does not send the message the banks read#

The letter analogy quietly implies that the GP’s letter is the document the consultant receives. It is not. In almost every real estate, the terminal speaks a protocol of its own to the acquirer — sometimes a national standard, sometimes a vendor’s own format, increasingly a web API carrying JSON — and the acquirer’s host builds the industry-standard message from scratch. The terminal frequently has no idea that data elements have numbers. It sends fields with names like amount and emvData, and something in a data centre translates.

This matters more than it sounds. It means that when a specification says “the terminal sends field 55”, what it actually means is that the terminal sends a blob of chip data through whatever pipe it has, and the acquirer puts that blob into field 55 without touching it. It means the person debugging a chip problem may be looking at three different representations of the same bytes. And it means that the two halves of the industry have different vocabularies for the same object: Visa’s documentation calls it Field 55, Mastercard’s calls it DE 55, and both are talking about the same one hundred and thirty-four bytes.

There is a stronger version of the correction. Where point-to-point encryption is in use, as in the previous chapter, the card number is not in the terminal’s message at all. What the terminal sends is a ciphertext and a key serial number. The card number appears for the first time inside a hardware security module in the acquirer’s data centre, and is written into the message there. The field that everybody thinks of as the most important one in a payment message is, in those estates, authored by the acquirer.

Field 55 is not “the chip data”#

It is a selection from the chip data, made by the acquirer, and about half of it was written by the terminal rather than the card.

The card gives the terminal far more than travels. Public key certificates, the issuer’s public key remainder, the card’s own list of acceptable ways of verifying a cardholder, its offline counters and limits, its PIN try counter, its transaction log, the templates telling the terminal how to format commands: none of that leaves the shop. What leaves is a list of tags that the acquirer’s specification names, and if a tag is not on the list it does not travel however interesting it is.

The other half of the correction is the part that surprises people who have only read about EMV. Of the twenty-one objects in our one hundred and thirty-four bytes, thirteen were written by the terminal: the amount, the currency, the country, the date, the transaction type, the random number, the terminal’s type and capabilities, its serial number, its account of cardholder verification. They are in the chip’s sealed block not because the chip knows them but because the chip was asked to sign over them. That is the entire mechanism by which an issuer can detect that the amount was altered after the card agreed to it.

The same fact appears twice, and only one copy is protected#

The amount is in the message twice: once in the ordinary amount field, and once inside the sealed block. So is the currency. So is the date, in two different formats. So is the way the card was read. So is the card’s sequence number. This is not redundancy for safety; it is two systems that were designed twenty years apart and glued together.

The consequence is a rule worth memorising. Only the copy inside the sealed block is protected by the cryptogram. If the two copies disagree, the issuer’s cryptogram check will validate against the inner copy and fail against the outer one, and the failure will look like a cryptographic problem when it is really a mapping bug in somebody’s message translator. A great deal of expensive debugging in this industry is somebody discovering that their host was populating the outer amount from the basket total and the inner one from the pre-authorisation amount.

One message is not a transaction#

The plain version tells the story as request and answer, which is how it looks from the counter. It is not how the money moves. The authorisation is a question about whether funds exist and whether the issuer consents. It moves no money and, in most schemes, is not even the record that will be settled. A second message follows, telling the acquirer that the sale actually completed and carrying the chip’s final cryptogram; a third, in a batch overnight, is the one that claims the money. If the answer to the first message never arrives, a fourth kind of message has to be sent to unwind it, and that message must repeat enough of the first to name it unambiguously.

Approval is not payment. Chapter 30 is about the difference, and Chapter 49 is about what happens when somebody disputes the whole thing eleven months later and the only surviving evidence is the twelve-character reference the acquirer stamped on this message today.

The technical version#

The three hops, and the protocol on each#

The path from the counter to the issuer has at least three links, and each has a different standard.

The first, where the terminal is not a standalone device, is between the electronic cash register and the point of interaction. This is the link nobody certifies as a payment interface, and it carries the basket total in one direction and the receipt data in the other. In Europe it is increasingly the nexo Retailer Protocol, an ISO 20022 message set defining the exchanges between a Sale System and a POI System.

The second link is terminal to acquirer. In the United Kingdom this was standardised by APACS: Standard 60, Message Interchange between Card Acceptor and Acquirer, dated 2000, and its successor Standard 70, issued from 2007 in numbered books, in which Books 2 and 3 carry the message formats while the remaining books apply whichever message standard the terminal uses. Elsewhere in Europe the modern answer is the nexo Acquirer Protocol, described by nexo as a standard that “replaces ISO 8583 and its national derivatives”, built from the ISO 20022 Acceptor-to-Acquirer Card Transactions catalogue. Its authorisation pair is caaa.001.001.15, AcceptorAuthorisationRequestV15, and caaa.002, AcceptorAuthorisationResponse; its completion advice is caaa.003. Many acquirers offer none of this and publish their own format, which in a modern gateway means a JSON document with an emvData string in it.

The third link is acquirer to scheme, and this is where ISO 8583 lives. The fourth, scheme to issuer, is ISO 8583 again in the scheme’s own dialect, or increasingly the ISO 20022 Acquirer-to-Issuer set, whose authorisation initiation is cain.001.001.05.

ISO 8583, in exactly enough detail to hand over#

Three facts will carry you to the next chapter.

A message begins with a four-digit message type indicator. 0100 is an authorisation request, 0110 its response, 0200 a financial request that both authorises and claims, 0210 its response, 0400 a reversal.

After it comes a bitmap, sixty-four bits, one per possible data element. A bit set to one means that element is present later in the message, in numerical order. This is why the format is compact and why it is unreadable without a specification.

Then come the data elements themselves, identified only by their position in the bitmap. They are numbered, not named, and the numbering is the industry’s shared vocabulary: everybody in acquiring knows what DE 4 is without looking. Volume III takes this apart properly.

For now, one number matters: 55. It is the element that carries chip data. Later editions of the standard formalise it as the integrated-circuit-card-related data element, with a three-digit length prefix and a theoretical maximum of 999 bytes; every scheme caps it far lower, and 255 bytes is the common ceiling. Crucially, the standard is explicit that its own rules for structured elements do not apply inside DE 55: the linking of sub-elements there follows ISO/IEC 7816-6. In plain terms, field 55 is a bag of EMV tag-length-value objects, parsed by EMV’s rules, sitting inside a message parsed by ISO 8583’s rules. It is a format inside a format, and every practitioner error in this area comes from forgetting which set of rules applies to which bytes.

What the kernel hands the terminal#

Before anything is assembled, the chip’s part of the transaction ends and a boundary is crossed inside the terminal itself.

In the contact world the boundary is the second GENERATE AC, or, for an online transaction, the first: the card returns the cryptogram, the counter, the cryptogram information data and its issuer application data, in one of the two response templates of EMV Book 3. In the contactless world the boundary is explicit and named. The kernel completes and hands the terminal an outcome carrying a Data Record and Discretionary Data; EMV Contactless Book A’s Annex A lists which data elements populate each. The Data Record is the set the terminal is expected to forward to the acquirer. The Discretionary Data is for the terminal’s own logs and receipts and is not meant to travel.

Either way, what the terminal now holds is a pool of tags — some from the card, some of its own — and a list, supplied by the acquirer, of which ones to send.

Field 55, tag by tag, for one flat white#

Here is the actual field for the £4.20 transaction. The values follow the worked cryptogram of Chapter 15 and the terminal risk management of Chapter 16, so the arithmetic joins up with what those chapters computed.

Read down the values and the transaction is legible. 9F27 of 80 says the card produced an authorisation request cryptogram rather than an approval or a decline, because the top two bits of that byte carry the cryptogram type. 95 has one bit set, byte 4 bit 8, “transaction exceeds floor limit”, and that single bit is the reason this transaction is online at all. 9F34 of 1F 00 02 says the terminal applied the rule “no cardholder verification required”, under the condition “always”, and considers it successful — a statement, as Chapter 17 laboured, not a proof. 9F10 of 06 00 0C 03A00000 tells the issuer’s host which master key to load and which cryptogram version to run, and carries the card’s own four-byte account of the transaction, which the schemes append to the terminal’s data before recomputing the MAC. 82 has byte 1 bit 3 set, so the card is willing to be told, cryptographically, that the reply really came from its issuer. And 9F41 of 0071 is the terminal’s own transaction counter: the one hundred and thirteenth sale on that machine since it was last reset.

Encoded, the whole field is:

9F2608733084432BA24DAE 9F270180 9F100706000C03A00000
9F37049A1BC3D4 9F3602003D 95050000008000 9A03260817 9C0100
9F0206000000000420 9F0306000000000000 5F2A020826 82021D00
9F1A020826 9F3303E0F8C8 9F34031F0002 9F350122
9F1E083132333435363738 8407A0000000031010 9F0902008C
9F41020071 5F340101

One hundred and thirty-four bytes. Add the tags and lengths and there is no slack in it: 9F26 costs eleven bytes to carry eight, because a two-byte tag and a one-byte length ride with every object.

The byte budget, and what truncation does#

That is the arithmetic nobody does until it bites. Twenty-one objects, one hundred and thirty-four bytes, against a scheme ceiling of 255. Comfortable. Now add the tags that a contactless transaction wants — the terminal transaction qualifiers, the card transaction qualifiers, the form factor indicator — and the tags a tokenised transaction wants, and the issuer script results after a script has run, and a kernel’s proprietary data objects, and the budget tightens quickly.

Two encodings make it tighter still. If the interface between the terminal and the acquirer is character-based and carries the field as hexadecimal text, one hundred and thirty-four bytes become two hundred and sixty-eight characters. Any component in that chain with a 255-character limit will silently cut the field in the middle of a tag. And a field 55 truncated at the end loses its trailing objects first, which in the list above means 5F34, 9F41 and 9F09 — the least interesting three. Reorder the same list, as BER-TLV entitles you to, and truncation eats 9F10 instead, at which point the issuer cannot select a key, cannot derive a session key, cannot verify the cryptogram, and declines with a code that says nothing about why.

Which tags an acquirer requires is published, and reading that list is the first task of any integration. One large processor’s public specification for encrypted device integration, for instance, marks as mandatory 4F, 5F2A, 5F34, 82, 84, 95, 9A, 9C, 9F02, 9F03, 9F09, 9F10, 9F1A, 9F26, 9F27, 9F33, 9F34, 9F35, 9F36 and 9F37, with 9F1E, 9F41, 50, 9F5B and 9F6E optional, and in the response 8A, 91, 71 and 72. That shape — the card’s cryptogram set, the terminal’s signed context, the identity of the application — is common to every scheme, and the differences between acquirers are at the edges.

Read those lists sceptically. The same document describes tag 9F6E as the application transaction counter, which it is not, and tag 9F1A as a two-letter alphabetic country code, which it is not either: 9F1A is three numeric digits in two bytes, 0826 for the United Kingdom. Vendor documentation copies vendor documentation. The primary sources are EMV Book 3’s Annex A for what a tag is, and your acquirer’s own message specification for whether they want it.

What the terminal adds outside field 55#

The rest of the terminal’s contribution is the ordinary transaction, and its home in a scheme’s authorisation request looks like this.

Several rows deserve a note.

DE 22 is three digits in the 1987-format messages: two for how the account number was captured and one for the terminal’s PIN entry capability. 05 is contact chip, 07 contactless chip, 91 the legacy contactless stripe mode, 80 a fallback to magnetic stripe after the chip failed. Ours is 051: chip read, PIN pad present. This field is where the commercial consequences live. Claim 05 and send no field 55 and you have failed a scheme certification test in the most common way there is. Claim 07 after performing a stripe read and the issuer looks for a cryptogram that is not there. And the third digit must be true: a terminal that claims PIN capability and never sends a PIN block invites an issuer to distrust everything else it says.

DE 23 is three digits carrying what the chip holds in one byte, right-justified and zero-filled. 5F34 of 01 becomes 001. This is the field most often left out, and the failure it causes is specific: an issuer with two cards live on one account cannot tell which one it is being asked about, so it cannot select the right master key.

DE 35 carries the track 2 equivalent data the chip returned in tag 57 — not a stripe read, but the same layout, including a service code whose first digit of 2 or 6 announces that this is a chip card. The separator the chip encodes as hexadecimal D appears as = on character-based interfaces, and a translator that fails to swap it produces a field the issuer rejects for format.

DE 12 and DE 13 are local. DE 7, which the acquirer writes, is universal time. Our transaction at 09:45:12 British Summer Time is 094512 in DE 12 and 0817084512 in DE 7. Neither DE 12 nor DE 13 carries a year, which is a real problem exactly once a year.

DE 41 and DE 42 are not the terminal’s opinion. They are identifiers assigned by the acquirer and loaded into the terminal at installation, which is why a terminal moved between shops without reconfiguration produces transactions that reconcile to the wrong merchant and are extremely tedious to unpick.

The PIN, when there is one#

Our flat white needed no cardholder verification. Had it been a £47.50 purchase requiring online PIN, one more field would have appeared and it would not have come from the chip at all.

The PIN, captured on the approved keypad, is formatted into an ISO 9564-1 PIN block and encrypted under a key shared with the acquirer. In the 1987-format messages it occupies DE 52, defined as sixty-four bits — exactly one Triple DES block, which is why formats 0 to 3 are eight bytes long. It travels under a different key from the card data, with the key management information alongside it in DE 53, whose layout differs in every scheme’s dialect. At each hop between the terminal and the issuer’s own hardware security module the block is translated: decrypted and re-encrypted under the next zone’s key, inside a secure cryptographic device, never in the clear on any bus. That regime is the PCI PIN Security Requirements, and it is older and stricter than anything governing the card number.

One seam is worth flagging now because it is a live migration problem. ISO 9564-1’s format 4 block, introduced for AES, is sixteen bytes. A sixty-four-bit field cannot hold it. Carrying AES PIN blocks therefore requires arrangements outside the original definition of DE 52, and they are specified by each scheme rather than by ISO 8583. If you are planning an AES migration, that is a question for your acquirer’s message specification and not for the standard.

Note also what the PIN is not. If the cardholder verification was offline PIN, nothing about the PIN appears in the authorisation message at all. The only trace is 9F34 saying it happened, and the card’s own account inside 9F10 saying whether it agrees.

What the acquirer adds#

The acquirer’s host receives the terminal’s message and builds the scheme message. Its additions fall into four groups.

Identity and routing. The acquiring institution identification code in DE 32, and a forwarding institution code in DE 33 where an intermediary is in the path. The acquirer also does the routing itself: the leading digits of the account number are looked up in a table to decide which scheme, and therefore which network connection, this message belongs to.

Timekeeping and identifiers. DE 7, transmission date and time, in universal time, rewritten at every hop by whoever is sending. DE 37, the retrieval reference number, twelve alphanumeric characters, assigned by the acquirer and echoed unchanged by everybody downstream. Its internal construction is not fixed by the standard; a common convention is year, day of year, hour and sequence, which is how 622908004871 was built for this transaction: year 6, day 229 — 17 August 2026 — hour 08 universal time, sequence 004871. That string is the identifier with the longest life in the entire message. It will still be the key in a chargeback file next summer.

Merchant description. DE 18, the merchant category code — 5812, eating places and restaurants, from ISO 18245 — and DE 43, forty characters of name and location, conventionally twenty-three of trading name, thirteen of town, two of region and two of country. Both are the acquirer’s records rather than the terminal’s, and the second is what appears on the cardholder’s statement, which makes it the single most effective fraud-prevention field in the message and the one most likely to be wrong.

Cryptography and scheme dialect. The account data, if it arrived encrypted, is decrypted in a hardware security module and written into DE 2 and DE 35. The PIN block, if present, is translated. A message authentication code over the whole message may be computed and placed in DE 64. And the scheme’s own private data elements are populated: Mastercard’s DE 61 point-of-service data, DE 48 additional data, DE 63 network data, and their equivalents elsewhere. Those are the fields where scheme dialects diverge most, and a field number learned on one network must never be carried across to another.

Two things the acquirer does that are not fields at all. It applies its own duplicate detection and velocity rules before the message leaves, which is why an acquirer can decline a transaction the issuer never saw. And it keeps a record of what it sent, because if the response does not arrive it is the acquirer, not the terminal, that must reverse.

The assembled message#

Put it together and the 0100 for our flat white is a four-digit message type indicator, an eight-byte bitmap with seventeen bits set, and the elements in numerical order. In character encoding with a binary field 55, it is a little over three hundred and fifty bytes. Rendering field 55 as hexadecimal text pushes it near five hundred. Packing the numerics as binary-coded decimal brings it well under three hundred.

American Express’s Global Credit Authorization Guide, written to the 1993 edition of the standard, states the chip requirement plainly: ICC system related data in data field 55 must be present, alongside track 1 in data field 45 and/or track 2 in data field 35, and a point of service data code in data field 22. Visa’s Transaction Acceptance Device Guide puts the division of labour equally plainly from the other side: the acquirer formats the authorisation message with the chip data in Field 55. Both sentences say the same thing. The terminal produces chip data; somebody else builds the message; the two must agree about what the transaction was.

The response, and what the terminal does with it#

The 0110 comes back with three things that matter and one that matters to the chip.

DE 39, the response code, two alphanumeric characters in the 1987 edition and three in the 1993 edition: 00 approved. DE 38, the authorisation identification response, six characters, which the receipt prints and the clearing record carries. And DE 55 again, now populated by the issuer rather than the terminal.

In the response, field 55 carries up to three objects.

For our transaction, under ARPC Method 1 and with the two ASCII characters 0 and 0 as the authorisation response code, Chapter 15 computed the issuer’s cryptogram as 735C24FD87F1BF0E. The issuer authentication data is that cryptogram followed by the response code, so the object on the wire is 91 0A 735C24FD87F1BF0E3030: ten bytes of value, twelve on the wire.

What the terminal does next is not optional and is where implementations diverge from the specification most often. If 91 is present, the terminal delivers it to the card, either through EXTERNAL AUTHENTICATE or inside the second GENERATE AC, and sets the issuer-authentication bit in the transaction status information. If 91 is absent, the terminal must not attempt issuer authentication, must leave that status bit at zero, must leave the corresponding failure bit in the terminal verification results clear, and must proceed on the response code alone. A downgraded authorisation is not a failed one.

Then the terminal asks the card once more, using the second data object list, for a completion cryptogram, and passes it the two-byte authorisation response code in tag 8A — which it must pass through exactly as received and must never invent when it came from a response message. The card runs its own second round of risk management and answers with a transaction certificate if it is content or a decline cryptogram if it is not. A card that declines after an approved authorisation has almost always either failed to verify the issuer’s cryptogram or verified it and found the approval bit clear.

Where scripts were sent, the terminal delivers them, records what happened in tag 9F5B, the issuer script results, and sets the script-processing bit in the transaction status information. Kernel 3 is relaxed about how much of 9F5B travels: acquirer documentation quoting it notes that it is acceptable to transmit only byte 1, though preferable to send all five.

For our transaction the transaction status information ends as B8 00: offline data authentication performed, card risk management performed, issuer authentication performed, terminal risk management performed, no scripts. That two-byte object, and the final cryptogram, belong to the next message rather than this one.

The second and third messages#

The authorisation is finished and nothing has been paid.

What follows depends on the scheme and the acquirer. In a dual-message model the terminal or its host sends a completion advice — caaa.003 in the nexo set, a scheme-specific advice or an entry in the overnight batch elsewhere — carrying the transaction certificate in the same tag 9F26, the cryptogram information data now showing a transaction certificate rather than a request, the transaction status information, and the script results. That message is what tells the acquirer the sale actually happened. The clearing record built from it is what claims the money, and it is the record a dispute will be argued from.

In a single-message model the 0200 did both jobs at once, and the chip data requirements are the same.

And if the response never arrived, the acquirer must reverse. A reversal names its victim by repeating the original message type indicator, system trace audit number, transmission date and time and institution codes, and acquirer specifications commonly require that the original field 55 be repeated in the reversal too. This is the practical reason for a rule that sounds pedantic: keep the exact bytes you sent, not a re-derivation of them. A reversal built by regenerating field 55 from a database will differ from the original in some small way and will fail to match.

A short field guide to failures#

DE 22 says chip and field 55 is absent. The commonest certification failure in the industry. The message claims a chip was used and contains no evidence of one.

Field 55 truncated. Trailing tags vanish. If 9F10 was among them the issuer cannot select a key and declines uninformatively. Check the length before suspecting the cryptogram.

Hexadecimal where binary was expected, or the reverse. Every length doubles or halves and parsing fails at the first tag. This is the single most common integration fault on a new acquirer interface.

Flat parser meets a constructed tag. 71 and 72 contain further tag-length-value objects. A parser that treats them as opaque will deliver an issuer script the card cannot read.

Amount mismatch between DE 4 and 9F02. The cryptogram validates against 9F02. If the two disagree the issuer sees evidence of tampering, which is exactly what the design intends, and the tampering is your own message translator.

Card sequence number omitted. Two cards on one account; the issuer loads the wrong master key; cryptogram verification fails for a card that is entirely genuine.

Response code altered before the second GENERATE AC. A host that normalises 00 into something friendlier for its own logs, and passes the friendly version to the card, breaks issuer authentication and gets a decline cryptogram after an approval.

Reversal rebuilt rather than replayed. The original and the reversal differ in one byte and never match. This is how transactions become stuck: authorised, never completed, never reversed, and visible to the cardholder as a held balance for a week.

What you now know, and what Volume III answers#

Volume II has been a single argument, and it is worth stating in one place before the subject changes.

A card is a physical object carrying an account number whose structure is public and whose last digit is arithmetic. The number alone is a bearer credential and always has been, which is why the printed codes, the stripe codes and the chip codes are four different things with four different threat models. The chip is a computer running a specified application, and its value is not that it stores a secret but that it computes one: eight bytes that depend on a key never transmitted, a counter that only rises, and the exact terms of this transaction. Whether it goes online is decided by bit arithmetic between the terminal’s observations and the issuer’s declared policies, both held as five-byte lists. Whether the cardholder was verified is a claim the terminal writes down, not a fact the network can check. Contactless is the same machinery with different limits and a different kernel. A phone holds not your card number but a separate credential minted for that device. The terminal is a certified object whose configuration is auditable after the fact, and in a well-built estate it can encrypt the account number so thoroughly that the shop itself never sees it. And all of it converges on the message this chapter assembled: three hundred and fifty-odd bytes, one hundred and thirty-four of them a sealed statement the shop cannot read.

Volume III begins the moment that message leaves the acquirer’s building, and answers the questions this chapter has deliberately left open.

The terminal’s job ends with a message. The rest of this book is about what a message is worth.

22.98 Common wrong ideas#

Wrong: the terminal builds the message the banks read. Right: in almost every real estate the terminal speaks a protocol of its own — a national standard, a vendor format, increasingly a web API carrying JSON — and the acquirer’s host builds the industry-standard message from scratch.

Wrong: field 55 is the chip data. Right: it is a selection from the chip data, named by the acquirer’s specification, and about half of it was written by the terminal rather than the card.

Wrong: the card number is always the card’s contribution to the message. Right: where point-to-point encryption is in use the terminal sends ciphertext and a key serial number, and DE 2 is authored inside a hardware security module in the acquirer’s data centre.

Wrong: the amount appearing twice is harmless redundancy. Right: only the copy inside the sealed block is protected by the cryptogram, so if the two disagree the issuer sees evidence of tampering, and the tampering is your own message translator.

Wrong: an approval means the money is on its way. Right: the authorisation moves nothing and in most schemes is not even the record that will be settled; a completion advice follows, and a clearing record is what claims the money.

Wrong: a missing tag 91 means issuer authentication failed. Right: if 91 is absent the terminal must not attempt issuer authentication, must leave the status and failure bits clear, and must proceed on the response code alone, because a downgraded authorisation is not a failed one.

Wrong: the card sequence number is an optional nicety. Right: it is the field most often left out, and without it an issuer with two cards live on one account cannot select the right master key, so cryptogram verification fails for a card that is entirely genuine.

Wrong: a host may tidy the authorisation response code before handing it to the card. Right: tag 8A must be passed through exactly as received and never invented, because a host that normalises 00 into something friendlier breaks issuer authentication and gets a decline cryptogram after an approval.

Wrong: tags may be reordered freely inside field 55 because BER-TLV permits it. Right: it does permit it, and the order decides what truncation eats first; lose 9F10 and the issuer cannot select a key, cannot derive a session key, and declines uninformatively.

Wrong: vendor tag documentation is a primary source. Right: vendor documentation copies vendor documentation, and published specifications in circulation describe 9F6E as the application transaction counter and 9F1A as a two-letter alphabetic country code, neither of which is true.

22.99 Chapter summary in 20 lines#

1. About three hundred and fifty bytes leave the shop, and they contain two things of quite different natures: facts asserted by the machine on the counter, and a sealed block written by the chip.
2. Three parties write the outbound message — the chip, the terminal and the acquirer — and a fourth, the issuer, writes the reply.
3. For a £4.20 flat white the chip’s sealed block is one hundred and thirty-four bytes holding twenty-one objects, eight of them written by the card.
4. Thirteen of those objects were written by the terminal and merely signed over by the chip, which is the entire mechanism by which an issuer detects that an amount was altered after the card agreed to it.
5. The terminal usually knows nothing about numbered data elements; it sends named fields down whatever pipe it has, and something in a data centre translates.
6. Field 55 is a bag of EMV tag-length-value objects parsed by EMV’s rules, sitting inside a message parsed by ISO 8583’s rules, and most practitioner errors here come from applying the wrong rulebook to the wrong bytes.
7. Reading the tags down the list makes the transaction legible: 9F27 of 80 says the card asked the bank, and one bit of 95 says the amount exceeded the floor limit, which is the only reason this sale went online.
8. Several facts appear twice, inside and outside the sealed block, because two systems designed twenty years apart were glued together, and only the inner copy is cryptographically protected.
9. The byte budget is real: one hundred and thirty-four bytes against a 255-byte ceiling is comfortable until contactless, tokenisation and script results are added, and hexadecimal encoding doubles everything at a stroke.
10. Truncation removes the trailing objects first, so the order in which tags are written decides whether the loss is trivial or fatal.
11. Outside field 55 the terminal contributes the ordinary transaction fields, while the terminal and merchant identifiers were assigned by the acquirer at installation and at contract.
12. DE 22 declares how the card was read and whether a PIN pad is present, and every digit of it must be true, because claiming a chip read with no field 55 is the commonest certification failure there is.
13. Where an online PIN exists it travels in DE 52 under a different key from the card data, translated inside a secure cryptographic device at every hop under the PCI PIN Security Requirements.
14. Offline PIN leaves no trace in the authorisation at all beyond the terminal’s claim in 9F34 and the card’s own account of it inside 9F10.
15. The acquirer adds identity and routing, universal time, the retrieval reference number, the merchant category code and statement descriptor, and the scheme’s own private data elements.
16. That twelve-character retrieval reference number has the longest life of anything in the message and will still be the key in a chargeback file next summer.
17. The response carries a two-character verdict, a six-character approval code, and optionally a second sealed object addressed to the chip that the terminal cannot read and simply passes on.
18. If tag 91 is present the terminal must deliver it to the card and set the issuer-authentication bit; if it is absent it must do neither and rely on the response code.
19. The authorisation then ends with nothing paid: a completion advice carries the final cryptogram, a clearing record claims the money, and a reversal — replayed byte for byte, never rebuilt — unwinds a request whose answer never came.
20. Volume II closes here because everything before it concerned one end of the wire, and everything after it concerns what a message is worth once it leaves the acquirer’s building.

Sources: EMV Integrated Circuit Card Specifications for Payment Systems, Books 2, 3 and 4, in particular Book 2 sections 8.1 and 8.2 for cryptogram and ARPC generation, Book 3 Annex A for the data element dictionary and Annex C for the terminal verification results and cardholder verification coding, and Book 4 section 12 for online processing and issuer authentication; EMV Contactless Specifications for Payment Systems, Book A Annex A for the Data Record and Discretionary Data, and Book C-3 for Kernel 3’s issuer script results requirement; EMV Payment Tokenisation Specification – Technical Framework for token carriage; ISO 8583 and its 1987, 1993, 2003 and 2023 editions for data element definitions and for the statement that DE 55 sub-element linking follows ISO/IEC 7816-6; ISO/IEC 7816-4 and 7816-6; ISO/IEC 7813 for track 2 and the service code; ISO 4217 and ISO 18245; ISO 9564-1:2017 for PIN block formats; ISO 20022 message catalogue, Acceptor to Acquirer Card Transactions (caaa.001.001.15 and its siblings) and Acquirer to Issuer Card Transactions (cain.001.001.05), with nexo standards’ own descriptions of the nexo Acquirer and Retailer Protocols; APACS Standard 60:2000, Message Interchange between Card Acceptor and Acquirer, and Standard 70 Books 1 to 7 (2007); Visa Transaction Acceptance Device Guide v3.3; American Express Global Credit Authorization Guide (ISO 8583:1993); Mastercard Transaction Processing Rules; Worldpay ISO 8583 Reference Guide v2.51 and 610 Interface Reference Guide v2.56 for a published acquirer dialect; Fiserv encrypted device integration documentation for a published mandatory and optional tag list, cited also as an example of vendor documentation misdescribing tags 9F6E and 9F1A; PCI PIN Security Requirements v3.1 and PCI PTS POI v7.0 for PIN capture and translation. Tag names, formats and lengths cross-checked against EFTlab’s EMV and NFC tag list, neapay’s tag reference and emvlab.org.