Online and Offline

16.0 What this chapter gives you#

1. You will be able to answer the question the previous chapter skipped — whether anybody actually phones the bank — and say what happens on the occasions when nobody can.
2. You will be able to explain why small purchases keep working during an outage while large ones stop, and why the cut-off is a number sitting in one particular till rather than a national figure.
3. You will be able to perform the three comparisons of Terminal Action Analysis by hand, in order, as a bitwise OR of two policies followed by a bitwise AND with the terminal’s own observations.
4. You will be able to decode a five-byte Terminal Verification Results bit by bit, and say why its fifth byte cannot be decoded without knowing which kernel produced it.
5. You will be able to state the asymmetric defaults for absent action codes — all ones for the issuer’s online and default lists, all zeros for every terminal action code — and explain why they point in opposite directions.
6. You will be able to explain why setting a terminal floor limit to zero does not straightforwardly mean “always go online”.
7. You will be able to distinguish an offline approval from a store-and-forward deferral, and say why calling both “offline” is how merchants end up carrying risk they did not know they had.
8. You will be able to sort a network failure into its three shapes — the request never sent, sent with no answer, and an answer arriving too late — and say which of them makes a reversal mandatory whatever the local decision was.
9. You will be able to read a Terminal Type byte and explain why a supermarket till, a fuel pump, an aircraft seatback and a transit gate behave differently, including why the pump must commit before it knows the amount.
10. You will be able to run the four diagnostics that recover most of this ground when an estate is sending everything online, approving too much offline, failing cryptograms during outages, or producing duplicate debits afterwards.

Chapter 15 ended with the card producing eight bytes and the issuer producing eight bytes back. That description skipped a question, and the question is the one that decides whether your card works in a tunnel, on an aeroplane, at three in the morning when your bank’s authorisation host is being patched, and at a petrol pump that has no idea how much fuel you are about to take.

The question is: does anybody phone the bank?

Most people assume the answer is always yes. It is not. A meaningful fraction of card transactions in the world are approved without any message ever reaching the issuer, and much of the decision is made locally even when a message does travel. The chip in your card is a small computer running its own risk policy, and the terminal is running a different risk policy, written by a different organisation, with different money at stake. Both are expressed in the same format: a five-byte bitmap. Both are consulted on every transaction. Neither can see the other’s reasoning.

This chapter is about those two policies, the bitmap they share, and what happens when the line to the bank is not there.

The plain version#

Imagine a new employee on a supermarket till in Leeds. On her first day she is handed a laminated card from head office saying, in effect: here are the situations in which you must ring us before taking the money, here are the situations in which you must refuse outright, and here is what to do if the phone is dead.

That is the shop’s policy. Now imagine that every customer also hands over a second laminated card, printed by their own bank, saying the same three things in the same three categories but with the bank’s own opinions on them. The employee now has two policies to satisfy at once, and she does not get to choose between them.

She also has a tick sheet of forty boxes, each a specific observation: the card would not prove it was genuine. The card has expired. The customer could not enter a PIN because the keypad is broken. The amount is above the limit the shop may approve on its own. She fills it in as she goes, and most boxes stay empty on most transactions.

At the end she lays the tick sheet next to the two policy cards and asks three questions in order.

First: do any of the ticked boxes appear on either “refuse outright” list? If yes, she refuses, and no phone call happens.

Second, if not: do any of the ticked boxes appear on either “ring us” list? If yes, she rings.

Third, if she cannot ring — the line is dead, the shop has no line, the call timed out: do any of the ticked boxes appear on either “if the phone is dead” list? If yes, she refuses. If no, she approves it herself.

That is the whole mechanism. Two policies, one tick sheet, three questions.

A real transaction, with real numbers#

A customer buys £42.50 of groceries. The till’s limit for approving things on its own — head office calls it the floor limit — is £30.00.

The employee starts ticking. The amount is over £30, so the box marked transaction exceeds floor limit gets a tick. The card also tells her it has been used sixty-one times in its life and last spoke to its own bank on use number fifty-five. That is six uses ago, and the card’s instructions say it prefers to check in after five, so a second box is ticked: the card has gone too long without ringing home. Everything else is fine, and thirty-eight of the forty boxes stay empty.

Question one: does either “refuse outright” list mention either of those? Neither does. She does not refuse.

Question two: does either “ring us” list mention them? The bank’s card says yes to the floor limit. It happens not to mention the six-uses box at all — that bank does not consider it urgent — but one match is enough. She rings, the bank approves, and the transaction goes through in about half a second.

The same transaction with the phone line cut#

Now run it again with the shop’s broadband down. Questions one and two go the same way: no outright refusal, and the answer to “should I ring?” is still yes. But she cannot ring, so she falls through to question three and reads the third list.

The bank’s third list does mention the floor limit, so the transaction is declined. Not because the customer has no money, not because the card is stolen, but because that customer’s bank decided in advance that a £42.50 offline purchase it cannot see is a risk it does not want to take.

Had the basket been £8.40, no box would have been ticked, no phone call would have been needed, and the sale would have gone through with the line still dead. That is the most useful thing to understand about card payments during an outage: small purchases keep working and large ones stop, and the cut-off is not a national figure but a number sitting in that specific till for that specific scheme.

Two risk managers, and a spot check#

One twist surprises people, and since it was the subject of the previous chapter it needs only a sentence here. The employee does not actually approve anything. She proposes. The card gets the final word, and it may be more cautious than she was but never less: she can say “I’d approve this offline” and the chip can answer “no, ring them”, but she can never say “ring them” and have the chip answer “don’t bother”. There are two risk managers in the conversation, not one.

One last wrinkle explains something you may have noticed: occasionally a £2 coffee takes longer and clearly goes online for no visible reason. That is deliberate. A terminal may pick transactions at random and send them online even when nothing is wrong, because if small transactions never went online a thief would learn to keep every purchase under the floor limit and would never once be checked. The chance is weighted, so a purchase near the floor limit is far more likely to be selected than a tiny one.

If you take one thing to dinner, take this. Your card and the shop’s till each carry a written policy about when the bank must be consulted, both policies are consulted every time, the strictest wins, and there is a third policy that only comes out when the line is down.

Where the plain version stops being true#

The tick-sheet story gets you to the right answer for a supermarket till on an ordinary day. It hides four things, and each of them is where real implementations go wrong.

The two policies are merged, not consulted separately, and the merge only ever adds#

The employee reads two lists and matches against either. That is nearly right, but the actual operation is a bitwise OR of the two policies followed by a bitwise AND with the tick sheet. Because the two are ORed before the comparison, neither party can ever remove a condition the other has set: an issuer cannot tell a terminal to stop going online for something the acquirer insists on, and an acquirer cannot relax a condition the issuer has demanded. Every configuration change either adds strictness or does nothing. There is no negotiation, no priority, no override.

That catches out people diagnosing live estates. When a terminal goes online it cannot tell you why: it has a five-byte mask, a five-byte tick sheet and a non-zero AND result, and it records neither which bit caused it nor which policy contributed that bit. To find out, you fetch the sheet and both policies out of the transaction record and do the arithmetic yourself.

An absent policy is also not a neutral policy. It is a defined value, and the value differs depending on which list is missing. An issuer that ships a card with no “ring us” list has not made it permissive; it has made it maximally strict, because the fallback for the missing online list is all ones. An acquirer that leaves the terminal’s lists unconfigured has done the opposite, because the fallback for a missing terminal action code is all zeros. The two defaults point in opposite directions, and that asymmetry causes a great many surprises in the field.

The terminal never approves, and the tick sheet is not a report#

Calling the tick sheet a record of what went wrong is misleading twice over. First, not every ticked box is a problem. “Online PIN entered” is one of the forty boxes and is set on perfectly successful transactions; so is “transaction selected randomly for online processing”. The sheet records observations, some neutral and some adverse, and it is the two policies — not the sheet — that decide which matter.

Second, the tick sheet is not a report at all. It is an input: its five bytes are handed to the chip inside the command that asks for a cryptogram, and they form part of the data the cryptogram is computed over. Two things follow. A terminal that sets a bit after sending the sheet has produced a transaction whose cryptogram covers a different sheet from the one in the authorisation message, and the issuer’s verification will fail with no diagnostic. And the issuer is verifying the terminal’s claims about its own behaviour: nothing prevents a compromised terminal from ticking boxes untruthfully, and the cryptogram merely proves the card saw the same lies the issuer did.

“Floor limit” is at least four different limits owned by four different parties#

The plain version has one number, £30, sitting in the till. Real transactions are governed by several limits at once, and confusing them is the most common error in this whole area.

There is the terminal floor limit, loaded by the acquirer, specific to a particular scheme’s application on that terminal, doing exactly what the story says. There are contactless reader limits, separate values with separate names governing whether a tap is allowed at all, whether it must go online, and whether it must carry a cardholder verification. There are the card’s own offline limits, set by the issuer, which count transactions and in some schemes cumulative amounts rather than looking at a single purchase. And there are the scheme and regulatory limits — the figure a cardholder thinks of as “the contactless limit” — enforced somewhere else entirely.

The card’s limits are the ones that usually bite, and they are worded more precisely than most people realise. The chip carries two consecutive-offline limits, and they are not “soft” and “hard” versions of the same thing. One states the issuer’s preference for a terminal that has online capability; the other for a terminal that has not. Reading them as a graduated pair will make your velocity behaviour wrong at exactly the unattended terminals where it matters.

Setting the terminal floor limit to zero, incidentally, does not straightforwardly mean “always go online”. It means the floor-limit observation is recorded every time; whether that produces an online request still depends on whether either policy lists it under “ring us”. With a hand-configured pair that both leave the bit clear it does not, and you have a terminal with a zero floor limit approving everything offline.

Offline approval and store-and-forward are different things, and “the network went down” is at least three things#

The plain version treats “cannot ring” as a single event with a single response. It is not.

Offline approval is a decision: nobody is going to ask the issuer, the card has sealed an approval in a cryptogram, and the money will be claimed later through clearing. Store-and-forward is a deferral: the terminal holds a cryptogram that says “please ask the bank”, cannot ask now, and intends to ask later. The customer has already left with the goods, and if the answer comes back “no” three hours later there is no customer to hand it to. The two put the loss in different places under different rules, and calling both “offline” is how merchants end up carrying risk they did not know they had.

The failure itself also has at least three shapes with three different correct responses. The request may never have left the terminal, in which case nothing has happened anywhere and the terminal falls through to its third policy. It may have left with no answer coming back, in which case the issuer may well have approved and debited a shadow balance, and the terminal is obliged to send a reversal regardless of what it decides locally, precisely because it does not know. Or an answer may arrive after the terminal has given up, leaving an approval in the issuer’s records for a transaction the terminal has declined and the card has refused to certify. Treating those three as one case is the classic way to produce duplicate debits during an outage, and it is a failure of the acquirer’s software, not of EMV.

The technical version#

Two decisions, in this order#

EMV places the online/offline determination in two processes with two owners, both running on every contact transaction that reaches the cryptogram stage. Terminal Action Analysis is EMV Integrated Circuit Card Specifications for Payment Systems, Book 3 (Application Specification), section 10.7: the terminal’s decision, producing a request for one of three cryptogram types via the reference control parameter of the GENERATE APPLICATION CRYPTOGRAM command. Card Action Analysis is Book 3 section 10.8, the card’s decision; the chip may return the requested type or a more restrictive one, never a less restrictive one, and reports what it did in the Cryptogram Information Data, tag 9F27. Book 4, Table 3, sets out what the terminal must do with each answer. Everything else in this chapter feeds those two decisions.

Terminal Verification Results#

The tick sheet is the Terminal Verification Results, tag 95, five bytes, binary, generated by the terminal and defined in Book 3, Annex C5. Bits run b8 (most significant) to b1 within each byte; reserved-for-future-use bits are coded as zero and neither party checks them.

Byte 5 is where contact and contactless diverge. In EMV Contactless Specifications for Payment Systems, Book C-2 (Kernel 2), byte 5 additionally carries the relay resistance outcomes: bits for “relay resistance threshold exceeded” and “relay resistance time limits exceeded”, and a two-bit field in b2 and b1 encoding whether the relay resistance protocol was not supported, not performed or performed. A decoder handling both interfaces cannot decode byte 5 without knowing which kernel produced it. Note too that byte 1 b2, “SDA selected”, is an observation rather than a failure: it exists so an issuer can express a policy about static data authentication being used where dynamic authentication was available.

Action codes: three lists, two owners, five bytes each#

Every one of the six action codes has exactly the same five-byte layout as the Terminal Verification Results, bit for bit.

The Issuer Action Codes live on the card and are read during the READ RECORD stage: 9F0D for Default, 9F0E for Denial, 9F0F for Online. Book 3 is precise about scope. Denial specifies the issuer’s conditions that cause denial without attempt to go online; Online, the conditions that cause a transaction to be transmitted online; Default, the conditions that cause rejection if it might have been approved online but the terminal is unable to process the transaction online.

The Terminal Action Codes are acquirer-configured and terminal-resident. On the contact interface they have no EMV tag because they never cross the card interface; Book 4, Table 7 lists all three as application-dependent terminal data elements, required if non-zero values are used. Contactless kernels carry them as configuration objects — Kernel 2 holds Terminal Action Code – Denial in tag DF8121.

The defaults when a code is absent must be memorised, because they are asymmetric.

Book C-5 (Kernel 5) states the three issuer defaults explicitly for cards that do not carry the codes, matching Book 3, and Book 4 confirms that in the absence of a Terminal Action Code the default is all bits set to 0. Book 4 attaches a strong recommendation to that default: the bits for “offline data authentication was not performed”, “SDA failed”, “DDA failed” and “CDA failed” should be set to 1 in both Terminal Action Code – Default and Terminal Action Code – Online. Those are byte 1 b8, b7, b4 and b3, so the minimum implied is CC 00 00 00 00. An acquirer shipping all-zero terminal action codes has followed the letter of the specification and ignored its advice.

The three comparisons#

Book 3 section 10.7 defines the decision as three bitwise tests in a fixed order. In each, the two five-byte action codes are ORed and the result ANDed with the Terminal Verification Results; a non-zero result means the condition applies.

Denial first: if any bit is set in TVR AND (TAC-Denial OR IAC-Denial), the terminal declines offline and requests an AAC, and no online message is attempted. Online second, and only if the terminal has online capability: if any bit is set in TVR AND (TAC-Online OR IAC-Online) the terminal requests an ARQC, otherwise a TC. Default third, used when the terminal is offline-only so the online test never ran, or is online-capable but unable to go online: if any bit is set in TVR AND (TAC-Default OR IAC-Default) the terminal requests an AAC, otherwise a TC.

Book 4 section 6.3.6 confirms the bookkeeping. On an offline approval the terminal sets the Authorisation Response Code to “Offline approved”; on an offline decline, to “Offline declined”; and when it transmits online it sets no value at all, leaving the field for the response message.

A complete worked example#

Take a supermarket till in Leeds on 17 August 2026. Terminal Type 9F35 is 22, attended, merchant-controlled, offline with online capability. The floor limit is £30.00, so 9F1B is 00 00 0B B8; the basket is £42.50, so Amount, Authorised, 9F02, is 00 00 00 00 42 50; Transaction Currency Code 5F2A and Terminal Country Code 9F1A are both 0826; Transaction Date 9A is 26 08 17 and Transaction Type 9C is 00. The card reports an Application Transaction Counter, 9F36, of 00 3D — sixty-one — a Last Online ATC Register, 9F13, of 00 37, and a Lower Consecutive Offline Limit, 9F14, of 05.

Terminal risk management runs. £42.50 exceeds £30.00, so TVR byte 4 b8 is set. The counter is six ahead of the last online register, which exceeds five, so byte 4 b7 is set. Data authentication succeeded, the application is in date, the PIN verified offline. The resulting TVR is:

95 05 00 00 00 C0 00

The card presents these issuer action codes:

9F0E 05 00 10 18 00 00      IAC - Denial
9F0F 05 FC 68 BC 98 00      IAC - Online
9F0D 05 FC 40 AC 80 00      IAC - Default

The acquirer has loaded CC 00 00 00 00 as both Terminal Action Code – Online and Terminal Action Code – Default, and all zeros as Terminal Action Code – Denial.

Denial test: (00 00 00 00 00) OR (00 10 18 00 00) is 00 10 18 00 00, ANDed with the TVR gives all zeros. No denial.

Online test: (CC 00 00 00 00) OR (FC 68 BC 98 00) is FC 68 BC 98 00, ANDed with 00 00 00 C0 00 gives 00 00 00 80 00 — non-zero, from the floor-limit bit alone. Note what did not contribute: byte 4 of this issuer’s online code is 98, that is b8, b5 and b4, and does not include b7. This issuer does not regard the lower consecutive offline limit as a reason to go online. The terminal requests an ARQC.

Now suppose the line is dead, and the terminal falls through to the default test: (CC 00 00 00 00) OR (FC 40 AC 80 00) is FC 40 AC 80 00, ANDed with 00 00 00 C0 00 gives 00 00 00 80 00. The terminal requests an AAC and sets the Authorisation Response Code to Z3. Same basket, same card, same till, different answer, and the only thing that changed is which of the three lists was consulted.

Terminal risk management: what sets those bits#

None of this runs unless the card asks for it. Application Interchange Profile, tag 82, byte 1 b4 is “terminal risk management is to be performed”. A terminal must also perform it whenever its own floor limit checking demands, but the AIP bit is the card’s request.

Floor limit checking. Terminal Floor Limit, tag 9F1B, is four bytes binary, terminal-sourced, held per application identifier — one physical terminal can carry different floor limits for different schemes. Book 4, Table 7 makes it required on an offline terminal or an offline terminal with online capability. The terminal may keep a log of recent transactions keyed on Application PAN and Application PAN Sequence Number so a customer cannot defeat the limit by splitting a purchase; where a log is kept, the current amount is summed with the logged amounts before comparison.

Random transaction selection. Required on offline terminals with online capability, using three acquirer-configured values: Target Percentage to be Used for Random Selection, Threshold Value for Biased Random Selection, and Maximum Target Percentage to be Used for Biased Random Selection. Below the threshold the selection probability is the target percentage; between the threshold and the floor limit it is interpolated linearly:

interpolation      = (amount - threshold) / (floor limit - threshold)
transaction target = ((max target - target) x interpolation) + target

The terminal generates a random number in the range 1 to 99 and selects the transaction for online processing if that number is less than or equal to the transaction target percent, setting TVR byte 4 b5. With a threshold of £10.00, a target of 10 per cent, a maximum target of 40 per cent and a floor limit of £30.00, a £22.50 purchase interpolates at 0.625 and yields a target of 28 per cent. That is why a purchase at £29.99 is very nearly always selected.

Velocity checking. The card supplies Lower Consecutive Offline Limit, tag 9F14, and Upper Consecutive Offline Limit, tag 9F23, one byte each. These are not soft and hard versions of one control. Book 3 is explicit: the lower limit is the issuer’s preference for the maximum number of consecutive offline transactions in a terminal with online capability, the upper limit the same preference in a terminal without online capability. If either is absent from the card, velocity checking is skipped entirely. The terminal retrieves Application Transaction Counter 9F36 and Last Online ATC Register 9F13 with GET DATA — class 80, instruction CA, tag in P1-P2 — and the difference between them is the number of transactions since the card last went online. Exceeding the lower limit sets TVR byte 4 b7; exceeding the upper limit sets byte 4 b6 as well.

Exception file. If the Application PAN matches an entry in the terminal’s exception file, TVR byte 1 b5 is set. Exception files are largely historical in online-capable estates and largely useless in offline-only ones, because they cannot be updated.

The terminal also maintains Transaction Status Information, tag 9B, two bytes, recording which processes ran rather than what they found: byte 1 b8 offline data authentication performed, b7 cardholder verification performed, b6 card risk management performed, b5 issuer authentication performed, b4 terminal risk management performed, b3 script processing performed, byte 2 reserved. The TSI says a step happened; the TVR says what it observed. A terminal reporting “issuer authentication failed” in the TVR while leaving “issuer authentication was performed” clear in the TSI has a bug.

Card Verification Results#

The card runs its own risk management and keeps its own tick sheet: the Card Verification Results. It is not a standalone tag. It lives inside Issuer Application Data, tag 9F10, binary, zero to thirty-two bytes, returned by the card in the GENERATE AC response.

There is no single layout. The Issuer Application Data is proprietary to the payment system and its internal structure is selected by the Cryptogram Version Number carried inside it. EMV defines a Card Verification Results only for Common Core Definitions applications, in Book 3, Annex C; everything else is published by the schemes.

Two layouts cover most of the estate. For Visa VSDC with Cryptogram Version Numbers 10 and 18, the Issuer Application Data is a length indicator, a one-byte Derivation Key Index, a one-byte Cryptogram Version Number, a four-byte Card Verification Results and optional Issuer Discretionary Data, so 06 00 0C 03 A0 10 00 carries a Card Verification Results of 03 A0 10 00. For Mastercard M/Chip, an eighteen-byte Issuer Application Data is a one-byte Key Derivation Index, a one-byte Cryptogram Version Number, a six-byte Card Verification Results, a two-byte DAC or ICC Dynamic Number and eight bytes of counters.

What it reports, across all the schemes, is the card’s own account of the transaction and its recent history: the cryptogram type returned at each GENERATE AC; whether offline PIN verification was performed and succeeded; whether the PIN try limit is exceeded; whether the previous transaction went online and completed; whether issuer authentication was attempted and failed; whether the card’s velocity counters are exceeded; whether an issuer script was received and failed; and counts of consecutive offline transactions and, in some schemes, cumulative offline amounts. Bit positions differ between schemes and between cryptogram versions within a scheme, so there is no generic Card Verification Results decoder; any tool claiming to be one is guessing at the version. And for most cryptogram versions the Issuer Application Data is included in the data over which the Application Cryptogram is computed, so the Card Verification Results is sealed. That asymmetry matters: the terminal’s tick sheet is a claim the terminal makes about itself, whereas the card’s is signed.

The GENERATE AC exchange#

The first GENERATE AC is formatted according to Card Risk Management Data Object List 1, tag 8C, supplied by the card, which for a typical application includes 9F02 Amount Authorised, 95 Terminal Verification Results, 5F2A Transaction Currency Code, 9A Transaction Date, 9C Transaction Type and 9F37 Unpredictable Number. The second is formatted from Card Risk Management Data Object List 2, tag 8D, whose critical addition is Authorisation Response Code, tag 8A, two bytes. The terminal must never modify an Authorisation Response Code obtained from a response message; Book 4, Annex A6, is explicit. But when the transaction is not authorised online the terminal generates the code itself, and Book 4, Table 35, defines exactly four values:

The distinction between Y1 and Y3, and between Z1 and Z3, is precisely the distinction between the second comparison and the third: Y1 and Z1 mean the terminal decided offline because its policies told it to, Y3 and Z3 mean it decided offline because it had no choice. Issuers price offline risk on that difference, and a terminal reporting Z1 when it meant Z3 is misrepresenting an outage as a policy decline.

Where an online response arrives containing Issuer Authentication Data, tag 91, the terminal delivers it to the card — through EXTERNAL AUTHENTICATE or inside the second GENERATE AC, depending on the application — and sets TSI byte 1 b5; if the card rejects it, TVR byte 5 b7 is set. Book 4 section 12.2.2 covers the case that trips people up: when the response contains no Issuer Authentication Data at all, the terminal must not execute EXTERNAL AUTHENTICATE and must set the TSI bit to 0, continuing on the Authorisation Response Code alone. That is a downgraded authorisation, not a failure, and the TVR bit must stay clear.

Why a fuel pump, an aircraft seatback and a supermarket till behave differently#

EMV encodes the answer in one byte. Terminal Type, tag 9F35, is two digits: operational control and environment. Book 4, Annex A1, gives the full table.

There are no attended cardholder-controlled types. Terminal types 14, 15 and 16 with cash disbursement capability — Additional Terminal Capabilities, tag 9F40, byte 1, cash bit set to 1 — are ATMs; nothing else is, and any logic that decides “is this an ATM” from the merchant category code rather than from those two data elements is doing it wrong.

The supermarket till is 22: attended, merchant-controlled, offline with online capability, with a modest floor limit, a working keypad, a person behind it and a network it expects to be up. All three comparisons are available to it, and on an ordinary day it goes online above the floor limit and approves the rest itself.

The fuel pump is 25 — unattended, merchant-controlled, offline with online capability — with merchant category code 5542, automated fuel dispensers, as distinct from 5541, service stations. Its problem is not connectivity. It is that the amount is not known when the decision has to be made: the pump must be authorised to dispense before anyone knows how much fuel will come out.

That breaks the arithmetic. The Amount, Authorised, tag 9F02, that goes into the cryptogram is an estimate, and the cryptogram covers the estimate and only the estimate. The final amount, which is what actually clears, was never seen by the chip. Every scheme therefore wraps automated fuel dispensers in its own rules rather than leaving it to EMV: the Visa Core Rules and Visa Product and Service Rules carry a section on Automated Fuel Dispenser Transactions with tables specifying status check authorisations, maximum amount initial authorisations and maximum allowed amounts, while Mastercard classifies the same devices through the cardholder-activated terminal levels in DE 61, subfield 10 of the authorisation message.

Everything else follows from that estimate: a hold for an amount unrelated to the fuel taken, a reconciliation between hold and clearing, and a figure on the cardholder’s statement that never appeared on the pump. It is not a bug. It is the only way to run a device that must commit before it knows.

The aircraft seatback is 26 or 36 — unattended, offline only. “Offline only” is a specification term with a precise meaning, given in Book 4, Table 1: the transaction can only be completed offline by the terminal. On such a terminal the second comparison never happens; Terminal Action Code – Online and Issuer Action Code – Online are read and never used. The decision reduces to the denial test and then the default test, which is exactly why Issuer Action Code – Default falls back to all ones when absent, and why a card carrying no Issuer Action Code – Default is declined by an aircraft for the smallest observation.

Mastercard’s terminology for this environment is CAT level 4, in-flight commerce, alongside level 1 for automated dispensing machines, level 2 for self-service terminals, level 3 for limited amount terminals and level 9 for mobile point-of-sale acceptance devices; the Mastercard Switch Rules manual sets out the requirements for each. Two further differences bite on an aircraft: the exception file can be no fresher than the last time someone updated it on the ground, and there is no attendant to compare a signature, so cardholder verification collapses to whatever the card’s CVM List permits an unattended device to do — in practice No CVM Required or offline PIN.

Transit gates are a fourth case, frequently confused with the third. A gate is unattended and often offline at the moment of the tap, but it is usually not an offline-only terminal: it is an online-capable terminal deliberately deferring the online request under a scheme-sanctioned transit model, which is not an EMV offline approval. The regulatory position differs too. Article 12 of Commission Delegated Regulation (EU) 2018/389, the regulatory technical standards on strong customer authentication, exempts unattended terminals for the purpose of paying a transport fare or a parking fee with no monetary ceiling, whereas an ordinary contactless purchase falls under Article 11 with its ceiling of EUR 50 for a single transaction, EUR 150 cumulative since the last strong authentication, and no more than five consecutive transactions. A seatback screen selling a gin and tonic is not paying a transport fare, and does not get Article 12. The United Kingdom’s own figures were £100 single and £300 cumulative until the Financial Conduct Authority removed the mandatory caps on 19 March 2026, leaving issuers with adequate fraud controls to set their own.

Offline approval and its risk#

The risk in offline approval is not that the cryptogram is weak; it is exactly as strong as an online one. The risk is that nobody with a balance in front of them has looked at it. Four things are unknown at that moment: whether the account has funds; whether the card has been reported lost or stolen since the exception file was last updated; whether the cryptogram is even valid, because as Chapter 15 established the terminal has no key and cannot check; and whether this is the fifteenth offline transaction on that card in an hour at fifteen terminals, none of which can see the others.

The controls against all four are the card’s own. Offline data authentication establishes that the chip is genuine before any offline approval is contemplated, which is why Book 4 recommends so firmly that the authentication-failure bits be set in Terminal Action Code – Default and – Online, and why offline approval following a failed authentication is the single most dangerous configuration in EMV. Beyond that, the consecutive offline limits force a card back online after a defined number of unseen transactions, and scheme-proprietary cumulative amount limits do the same on value. The gap between the Application Transaction Counter and the Last Online ATC Register is literally a measure of the issuer’s current exposure on that card.

Liability follows configuration, and configuration is auditable after the fact: the Terminal Verification Results, Terminal Type, Terminal Capabilities and cryptogram all travel in the clearing record. A terminal that approved offline above its scheme-permitted floor limit, or after data authentication failed, has departed from the rules visibly, and scheme chargeback rules attach consequences to exactly that.

Store-and-forward#

Store-and-forward is what an online-capable terminal does when it cannot reach the acquirer and its policies still permit completion: it stores the full transaction, cryptogram included, and transmits it when connectivity returns. Some acquirers call it deferred authorisation. It is not offline approval, because the answer is still outstanding.

The cryptogram in a stored transaction is an ARQC nobody has verified, or a TC generated against an Authorisation Response Code of Y3, and either way the issuer receives it late. Hosts enforcing a strict Application Transaction Counter ceiling will reject it, because by then the card has almost certainly been used elsewhere and the host has seen higher counter values. This is one of the concrete reasons issuer hosts apply a counter window rather than a hard ceiling.

The obligation to send a reversal is not discretionary. Book 4 section 12.2.3 covers the response that is not received, is received too late, or is malformed: after any permitted repeats the terminal processes the transaction as unable to go online, runs the default comparison, and issues the second GENERATE AC. Then, where online data capture is performed by the acquirer, the terminal shall send a reversal message regardless of the final decision on the transaction, so that if the host did receive the request and send a response, that transaction is cancelled. If the card’s final answer was a TC, the terminal must also create a financial record for the acquirer.

Third, storing a transaction before authorisation means holding cardholder data before authorisation, the one window in which PCI DSS permits sensitive authentication data to exist at all, and only under specific protection; such an implementation must be designed against the standard’s pre-authorisation storage requirements, not retro-fitted to them. Fourth, presentment windows are set by scheme rules and measured in days, and a queue surviving a long outage may hold transactions that are no longer presentable.

The messages are ordinary ISO 8583 — authorisation 0100 and 0110, financial 0200 and 0210, advice 0220, reversal 0400 with 0410 or advice-form 0420 with 0430. Whether a stored transaction goes as a financial request or as an advice depends on the acquirer’s specification, and determines whether the issuer is asked a question or told a fact.

When the network dies mid-transaction#

Sort the failures by where the transaction was when the line went.

Before the request was sent. Book 4 section 12.2.1: the terminal compares the Terminal Verification Results with Terminal Action Code – Default and Issuer Action Code – Default, decides, and issues the second GENERATE AC with an Authorisation Response Code of Y3 or Z3. Nothing has happened at the issuer, no reversal is required, and the card’s answer in the Cryptogram Information Data is final.

After the request was sent, with no response, or with a response that arrives too late. Section 12.2.3. The terminal may repeat the request if the acquirer requires it — repeat requirements are explicitly outside the scope of EMV — and then must treat the transaction as unable to go online. Same default comparison, same Y3 or Z3. But the reversal is now mandatory under online data capture, because the issuer may have approved and debited. The late response is the case most often implemented wrongly, because the response is there and a naive implementation will process it after the card has already been given a Z3 and returned an AAC. The transaction is then declined at the card and approved at the issuer, and only the reversal reconciles them.

Response arrives without Issuer Authentication Data. Section 12.2.2, and not a network failure at all. The terminal does not execute EXTERNAL AUTHENTICATE, sets the TSI issuer-authentication bit to 0, leaves the TVR issuer-authentication-failed bit clear, and proceeds on the Authorisation Response Code.

The card leaves mid-transaction. Common on a contactless reader: the cardholder lifts the device between command and response. Kernel 2 long addressed it with a Torn Transaction Log, governed by Max Lifetime of Torn Transaction Log Record, tag DF811C, an integer in seconds, and Max Number of Torn Transaction Log Records, tag DF811D, together with the RECOVER AC command, which retrieves from the card the last transaction it completed so that a returning card can be matched against a stored torn record and the transaction finished rather than restarted — which would burn a second Application Transaction Counter value. That machinery is now historical. EMVCo’s Specification Bulletin number 261 of October 2021, applying to Book C-2 version 2.10 and effective from the first of January 2022, states that torn transaction recovery is no longer supported in Kernel 2, retires the Torn Transaction Log, deletes the RECOVER AC section on the grounds that the command is no longer used, and strikes the torn data objects, tags DF811C and DF811D among them, from the data dictionary. The revision log of Book C-2 version 2.11, published in June 2023, records that bulletin as incorporated, and the current Kernel C-2 conformance statement offers implementers only mag-stripe mode and data exchange as options. A reader still running an older kernel will meet the mechanism; a newly approved one will not.

The issuer is down but the network is up. Not a terminal problem at all, and the terminal will never know. The scheme answers on the issuer’s behalf — Visa calls it Stand-In Processing, Mastercard calls it Stand-In Processing Service — applying issuer-supplied parameters and reconciling afterwards. To the terminal this is an ordinary online authorisation, typically arriving without Issuer Authentication Data, which returns us to the downgraded authorisation case and a TSI with the issuer authentication bit at zero. If a large share of an estate’s transactions show issuer authentication not performed, stand-in is the first place to look, not a terminal fault.

What to check when it goes wrong#

Every terminal runs the denial test. Only online-capable terminals run the online test; offline-only terminals go straight from denial to default. And every terminal reaches the default test eventually, which is the point most often missed: an online-only terminal is not exempt from it, it simply expects never to get there. When it does, it needs a sensible Terminal Action Code – Default loaded, and online-only estates are precisely the ones that never bothered. With the fallback of all zeros and a card whose Issuer Action Code – Default is present and permissive, such a terminal will approve offline in exactly the circumstances its operator assumed impossible.

Four diagnostics recover most of the ground in this chapter. If an estate is sending everything online, pull the Terminal Verification Results and both online action codes from a sample of transactions and do the AND yourself; almost always the card carries no Issuer Action Code – Online, so the all-ones default applies, or data authentication is silently failing and byte 1 lights up every time. If an estate is approving too much offline, check whether the Terminal Action Codes were ever loaded, because all-zero terminal action codes plus a permissive card will pass every certification test and lose money in production. If cryptograms fail at the issuer only during outages, check whether the terminal is building the GENERATE AC data from a stale copy of the Terminal Verification Results after it has finished setting bits. And if duplicate debits appear after an outage, check the reversal path first: when online data capture is performed and the terminal was unable to obtain a valid response, a reversal is sent regardless of what the card finally decided.

The deeper point behind all four is the one this chapter opened with. There is no single authority in a card transaction: there is a terminal with an acquirer’s policy, a card with an issuer’s policy, a merged bitmap neither party can see in full, and a network that is sometimes there. Everything that looks arbitrary about card acceptance — why the pump held £100, why the aeroplane refused a perfectly good card, why the corner shop kept working when the supermarket stopped — falls out of that arrangement, one five-byte comparison at a time.

16.98 Common wrong ideas#

Wrong: The terminal reads the issuer’s list and the acquirer’s list and matches against either. Right: The two five-byte codes are ORed together and the result ANDed with the Terminal Verification Results, so neither party can ever remove a condition the other has set and every configuration change either adds strictness or does nothing.

Wrong: A card carrying no Issuer Action Code – Online is permissive. Right: The fallback for a missing issuer online or default list is all ones, making such a card maximally strict, whereas an unconfigured Terminal Action Code falls back to all zeros — the two defaults point in opposite directions.

Wrong: The Terminal Verification Results is a report of what went wrong. Right: It is an input, handed to the chip inside the command that asks for a cryptogram and covered by that cryptogram, and several of its bits — “online PIN entered”, “transaction selected randomly for online processing” — are set on perfectly successful transactions.

Wrong: A terminal can tell you why it went online. Right: It holds a five-byte mask, a five-byte sheet of observations and a non-zero AND result, and records neither which bit caused it nor which policy contributed that bit, so you must fetch all three from the transaction record and do the arithmetic yourself.

Wrong: The floor limit is one number. Right: There is the acquirer’s per-application terminal floor limit, a set of contactless reader limits, the card’s own offline limits set by the issuer, and the scheme and regulatory limits, and confusing them is the most common error in this whole area.

Wrong: The lower and upper consecutive offline limits are soft and hard versions of the same control. Right: The lower is the issuer’s preference for a terminal that has online capability and the upper for one that has not, and reading them as a graduated pair makes velocity behaviour wrong at exactly the unattended terminals where it matters.

Wrong: Setting the terminal floor limit to zero means every transaction goes online. Right: It means only that the floor-limit observation is recorded every time, and whether that produces an online request still depends on whether either policy lists that bit, so a hand-configured pair that both leave it clear gives a zero floor limit approving everything offline.

Wrong: Store-and-forward is a kind of offline approval. Right: Offline approval is a decision nobody will revisit, while store-and-forward holds a cryptogram that still says “please ask the bank” and defers the question, and the two put the loss in different places under different rules.

Wrong: When no response arrives, the terminal simply decides locally and moves on. Right: The issuer may well have approved and debited a shadow balance, so under online data capture a reversal must be sent regardless of what the terminal and the card finally decided, and skipping it is the classic way to produce duplicate debits during an outage.

Wrong: An online-only terminal never needs a Terminal Action Code – Default. Right: Every terminal reaches the default test eventually, and an online-only estate that never loaded one falls back to all zeros and, against a permissive card, approves offline in exactly the circumstances its operator assumed impossible.

16.99 Chapter summary in 20 lines#

1. A meaningful fraction of card transactions in the world are approved without any message ever reaching the issuer, and much of the decision is made locally even when a message does travel.
2. Two organisations write risk policies for the same transaction: the acquirer’s, loaded into the terminal, and the issuer’s, carried on the card.
3. Each policy is three five-byte lists — denial, online and default — laid out bit for bit like the terminal’s own record of what it observed.
4. That record is the Terminal Verification Results, five bytes of specific findings, most of which stay clear on most transactions and some of which are neutral observations rather than faults.
5. Terminal Action Analysis runs three comparisons in a fixed order, each ORing the two matching action codes and ANDing the result with those observations.
6. Denial comes first and produces an offline decline with no online attempt; online comes second, and only where the terminal has online capability; default comes third, for an offline-only terminal or one that cannot reach the network.
7. Because the two policies are ORed before the comparison, neither party can relax what the other has demanded, and there is no negotiation, no priority and no override.
8. The defaults for absent codes are asymmetric — a missing issuer online or default list counts as all ones, a missing terminal action code as all zeros — and Book 4 separately recommends that the four data-authentication failure bits be set in the terminal’s online and default codes.
9. The observations are not a report but an input, since their five bytes go into the command that asks for a cryptogram, so a terminal that sets a bit after sending them produces a cryptogram the issuer cannot verify.
10. They are also a claim the terminal makes about its own behaviour, whereas the card’s account of itself, the Card Verification Results inside the Issuer Application Data, is sealed by the cryptogram.
11. Whatever the terminal requests, Card Action Analysis lets the chip return the same type or a more restrictive one and never a less restrictive one, so there are two risk managers and not one.
12. Terminal risk management sets the decisive bits: floor limit checking, random selection biased towards amounts near the limit, velocity checking on the gap between the transaction counter and the Last Online ATC Register, and the exception file.
13. In the worked example a £42.50 basket at a till with a £30 floor limit goes online on the floor-limit bit alone, and the identical basket with the line dead is declined by the default comparison — same card, same till, a different list consulted.
14. “Floor limit” is really several limits owned by different parties, and the card’s two consecutive-offline limits are preferences for terminals that do and do not have online capability rather than a soft and hard pair.
15. Terminal Type, one byte of operational control and environment, is why a supermarket till, a fuel pump, an aircraft seatback and a transit gate behave differently.
16. A fuel pump’s difficulty is not connectivity but that the amount is unknown when the decision must be made, so the cryptogram covers an estimate and every scheme wraps such devices in rules of its own.
17. An offline-only terminal never runs the online comparison at all, which is exactly why the issuer’s default list falls back to all ones and why a card carrying none is refused by an aircraft for the smallest observation.
18. Offline approval is cryptographically as strong as an online one and commercially riskier, because nobody with a balance in front of them has looked at it and the only controls are the card’s own.
19. Store-and-forward is a deferral rather than a decision, and the three shapes of network failure have three correct responses, one of which makes a reversal mandatory whatever the terminal and card decided locally.
20. There is no single authority in a card transaction — a terminal with an acquirer’s policy, a card with an issuer’s policy, a merged bitmap neither party can see in full, and a network that is sometimes there — and everything that looks arbitrary about card acceptance falls out of that arrangement.

Sources: EMV Integrated Circuit Card Specifications for Payment Systems, Book 3 (Application Specification) and Book 4 (Cardholder, Attendant, and Acquirer Interface Requirements), EMVCo; EMV Contactless Specifications for Payment Systems, Book C-2 (Kernel 2) and Book C-5 (Kernel 5), EMVCo; Visa Core Rules and Visa Product and Service Rules; Mastercard Switch Rules and Mastercard Developers authorisation message documentation; Commission Delegated Regulation (EU) 2018/389; UK Finance and Financial Conduct Authority guidance on contactless limits; ISO 8583 and ISO 18245.