Reference
The data a chip and a terminal exchange, term by term. Each entry says what the field is for, what it changes in a real transaction, and where you will run into it. Same source as the tools on this site – so a definition never exists in two versions.
82 terms shown
The AID identifies the payment application on the chip: the first 5 bytes (RID) designate the network (Visa, Mastercard, CB…), the rest specifies the product. A French co-badged card typically carries two AIDs: CB and Visa or Mastercard.
The application name as the card offers it for display (e.g. "CB", "VISA"). This is the label a terminal shows when it asks the customer to choose between the brands on a co-badged card.
Reproduces the data from the old magnetic stripe: PAN, expiry date, service code. Separator "D". Present for compatibility with legacy systems, this is sensitive (PCI) data: never paste a real capture here.
The card number encoded in BCD. Sensitive PCI data: in logs and tools it must always be masked or truncated (first 6 + last 4 digits at most).
Container for one directory entry: a candidate application (AID + label + priority). In the PPSE of a co-badged card you'll see two 61 templates, one per brand. Order and tag 87 decide priority.
The card's response to a SELECT command: it announces the selected file (84) and its metadata (A5). This is the starting point of every EMV transaction.
Generic wrapper for records read via READ RECORD: the card's application data (PAN, dates, CVM lists, certificates…) live inside these records.
A command sent by the issuer to the card via the terminal, executed before the final GENERATE AC: block the application, reset the PIN try counter… This is the remote card-management channel.
Same principle as tag 71, but executed after the final GENERATE AC.
TLV-explicit response format, typically the response to GENERATE AC: cryptogram (9F26), cryptogram type (9F27), ATC (9F36), IAD (9F10).
Compact response format: values are concatenated WITHOUT TLV structure, in an order mandated by the command. Classic beginner trap: it doesn't parse like TLV, the order comes from the spec.
The card announces here what it can do: which offline authentications (SDA/DDA/CDA), whether it supports cardholder verification, issuer authentication… The terminal adapts the whole transaction to this profile. 2 bytes of flags.
Bit labels – the detailed bit-by-bit explanation is coming in a later pass.
| Byte 1 · bit 7 | SDA supported (static authentication) |
| Byte 1 · bit 6 | DDA supported (dynamic authentication) |
| Byte 1 · bit 5 | Cardholder verification supported (CVM) |
| Byte 1 · bit 4 | Terminal risk management to be performed |
| Byte 1 · bit 3 | Issuer authentication supported |
| Byte 1 · bit 2 | On-device cardholder verification (CDCVM) supported |
| Byte 1 · bit 1 | CDA supported (combined authentication) |
| Byte 2 · bit 8 | MSD mode supported (contactless, legacy) |
| Byte 2 · bit 2 | Relay resistance protocol supported (contactless, Kernel 2) |
Name of the selected directory or application. "2PAY.SYS.DDF01" = contactless selection directory (PPSE); otherwise it's generally the AID of the chosen application.
One byte that settles two things in the application directory (each candidate application is listed there in an Application Template, tag 61): the high-order bit (b8) indicates whether explicit cardholder confirmation is required before selecting this application (1 = yes); the 4 low-order bits give the priority rank, from 1 (highest priority) to 15, with 0 meaning the issuer expresses no preference among several applications. On a co-badged card in France, the merchant can configure its display preference, but the customer keeps the right to choose the brand (IFR regulation, art. 8).
Short identifier for the file where the directory's records are read. A plumbing detail of application selection, useful when stepping through a SELECT PSE by hand.
The verdict from the authorisation circuit, 2 characters: 00 = approved, 05 = declined… The Y1/Z1/Y3/Z3 codes are generated by the terminal itself when the transaction is decided offline. Don't confuse this with the cryptogram: the ARC is the verdict, the cryptogram is the proof.
The card's shopping list for the first GENERATE AC: which terminal tags (amount, TVR, date, nonce…) it requires, and in what order. The terminal concatenates them WITHOUT tags, which is why you can't parse CDOL data as TLV.
Same principle as CDOL1, for the second GENERATE AC (after the online authorisation result comes back): the card typically asks here for the ARC and the issuer authentication results.
The cardholder verification policy, written into the card by the issuer: a sequence of "method + condition" rules evaluated in order. Typical example in France: enciphered offline PIN, else online PIN, else signature.
Index of the certificate authority's public key (per network) that the terminal must use to walk up the certificate chain. If the terminal doesn't have this key in store, offline authentication fails, the corresponding TVR bit is set.
Certificate for the issuer's public key, signed by the network's CA. The first link in the offline trust chain: CA → issuer → card.
Data returned by the issuer (ARPC + code) letting the card verify that the authorisation response genuinely came from it, authentication in the other direction.
The remainder of the issuer's public key that didn't fit in certificate 90. Concatenated to reconstruct the full key.
The card's static data signed by the issuer, the core of SDA. Weak by design (replayable): this is why SDA was superseded by DDA/CDA.
The card tells the terminal which records to read (file, range, and which ones take part in offline authentication). Read in groups of 4 bytes: SFI, first record, last record, number of records covered by signature.
The terminal's logbook: 5 bytes of flags, each recording a check that failed or an event (failed authentication, expired card, floor limit exceeded…). Cross-referenced with the TAC/IAC thresholds, THIS is what decides whether the transaction goes offline, online, or gets declined. The single most valuable tag in a transaction log.
Bit labels – the detailed bit-by-bit explanation is coming in a later pass.
| Byte 1 · bit 8 | Offline data authentication not performed |
| Byte 1 · bit 7 | SDA failed (static authentication) |
| Byte 1 · bit 6 | ICC data missing |
| Byte 1 · bit 5 | Card on terminal exception file |
| Byte 1 · bit 4 | DDA failed (dynamic authentication) |
| Byte 1 · bit 3 | CDA failed (combined authentication) |
| Byte 2 · bit 8 | ICC and terminal have different application versions |
| Byte 2 · bit 7 | Expired application |
| Byte 2 · bit 6 | Application not yet effective (future effective date) |
| Byte 2 · bit 5 | Requested service not allowed for card product |
| Byte 2 · bit 4 | New card (first use) |
| Byte 3 · bit 8 | Cardholder verification was not successful |
| Byte 3 · bit 7 | Unrecognised CVM |
| Byte 3 · bit 6 | PIN Try Limit exceeded |
| Byte 3 · bit 5 | PIN entry required but PIN pad not present or not working |
| Byte 3 · bit 4 | PIN entry required, PIN pad present, but PIN was not entered |
| Byte 3 · bit 3 | Online PIN entered |
| Byte 4 · bit 8 | Transaction exceeds floor limit |
| Byte 4 · bit 7 | Lower consecutive offline limit exceeded |
| Byte 4 · bit 6 | Upper consecutive offline limit exceeded |
| Byte 4 · bit 5 | Transaction selected randomly for online processing |
| Byte 4 · bit 4 | Merchant forced transaction online |
| Byte 5 · bit 8 | Default TDOL used |
| Byte 5 · bit 7 | Issuer authentication failed |
| Byte 5 · bit 6 | Script processing failed before final GENERATE AC |
| Byte 5 · bit 5 | Script processing failed after final GENERATE AC |
List of data to include in the TC Hash calculation. Rare in practice, hence the TVR's "default TDOL used" bit.
A hash of the transaction data, little used in modern deployments.
The PIN, enciphered in transit to the card for offline verification. Must NEVER appear in the clear in a log.
Date of the transaction on the terminal side (YYMMDD). Feeds into the cryptogram calculation, an inconsistent date and the cryptogram no longer verifies.
TVR's companion: which steps were ATTEMPTED (authentication, cardholder verification, scripts…). The TVR says "what went wrong", the TSI says "what was done". Read the two together.
Bit labels – the detailed bit-by-bit explanation is coming in a later pass.
| Byte 1 · bit 8 | Offline data authentication performed |
| Byte 1 · bit 7 | Cardholder verification performed |
| Byte 1 · bit 6 | Card risk management performed |
| Byte 1 · bit 5 | Issuer authentication performed |
| Byte 1 · bit 4 | Terminal risk management performed |
| Byte 1 · bit 3 | Issuer script processing performed |
Type of operation (ISO 8583 processing code): 00 = purchase, 01 = cash withdrawal, 09 = purchase with cashback, 20 = refund…
Name of a directory file for directory-based selection (the legacy PSE method).
The "metadata" part of the SELECT response: labels, priority, PDOL, proprietary data (BF0C). This is where a co-badged card lists its applications.
The cardholder's name as embossed. Often filled with generic values on recent cards ("/" or spaces) to limit exposure of personal data.
The application's expiry date (YYMMDD). This is what the terminal compares against today's date, the TVR's "expired application" bit comes from this check.
Start-of-validity date (YYMMDD). A card used before this date triggers the TVR's "application not yet effective" bit.
Country of the issuing bank (ISO 3166 numeric). Used in particular to distinguish domestic from international transactions, which changes interchange and routing rules.
Currency of the transaction (ISO 4217 numeric). 0978 = euro. If it differs from the card's currency, you're in dynamic currency conversion (DCC) territory.
The cardholder's preferred languages (ISO 639 codes), in order of preference. This tag is why a terminal shows "SAISISSEZ VOTRE CODE" rather than "ENTER PIN" to a French cardholder.
A service code inherited from magnetic stripes (ISO/IEC 7813): interchange conditions, authorisation restrictions, PIN requirements. The chip has its own controls, but this code is still read by legacy systems.
Distinguishes multiple cards carrying the same PAN (reissue, primary/secondary card). Essential on the issuer side to look up the card's correct cryptographic keys.
Number of decimal places for the transaction currency (2 for the euro: amounts travel in cents).
Transaction amount in BCD, in the currency's smallest unit (cents for the euro). 000000010000 = 100.00. The amount is part of the data signed inside the cryptogram.
A second amount, distinct from the main amount (9F02), whose exact meaning depends on terminal/issuer context: most often a cashback amount, but sometimes a service fee or a tip. Zero in the vast majority of French transactions.
The AID as seen on the terminal side (during selection). Same meaning as tag 4F on the card side.
Usage restrictions set by the issuer: is the card valid abroad? at ATMs? for cashback? The terminal checks these against context, a disallowed use sets the TVR's "service not allowed" bit.
Version of the application spec supported by the card. Compared against the terminal's (9F09), a mismatch sets a TVR bit, generally without blocking the transaction.
Version of the application spec on the terminal kernel side.
An identifier registered with EMVCo (Spec Bulletin 175) letting a market or issuer expose a proprietary feature during application selection. The content depends on the entity that registered the ID, not decodable without their documentation.
The issuer's fallback thresholds: if the transaction should have gone online but the terminal can't (offline), these bits say what to decline. Read as a mask applied to the TVR.
The issuer's hard-decline thresholds: any bit shared between this mask and the TVR means an immediate offline decline, without even attempting to go online. A cautious issuer would put, say, "expired card" here.
The issuer's go-online thresholds: any bit shared with the TVR sends the transaction to online authorisation. In France almost all transactions go online anyway, so these masks matter most where offline is common.
Issuer-proprietary data returned with the cryptogram: card risk management results (CVR), internal counters… The exact format depends on the network and application profile, the most "black box" tag in a GENERATE AC response.
The application's preferred display name, possibly in a dedicated character set (9F11). Takes precedence over tag 50 if the terminal can display it.
Country of the terminal (ISO 3166). Compared against the issuer country (5F28) to determine domestic vs international.
The reader's serial number. Physically identifies the device in logs, data to anonymise before sharing any capture.
Local time of the transaction (HHMMSS), a companion to tag 9A.
A non-sensitive identifier (up to 29 alphanumeric characters) that links a tokenised PAN (mobile wallet, virtual card) back to its original PAN, without ever exposing that original PAN. A given PAR stays stable across all tokens issued from the same physical card, which lets a merchant or issuer reconcile a physical-card payment with a wallet payment with zero PCI exposure.
THE cryptographic proof of the transaction: a MAC computed by the chip with its secret keys. The exact list of data feeding this calculation isn't fixed: the card itself chooses it, transaction by transaction, via the CDOL1 (8C) and CDOL2 (8D) tags, and it almost always includes the amount, the date and the TVR. In a stream that contains an 8C or an 8D, open it: you'll see the exact list this card requested for this cryptogram. Unforgeable without the card's key, the issuer verifies it to authenticate the transaction. Its type (ARQC/TC/AAC) is given by tag 9F27.
The type of cryptogram returned by the card, i.e. its decision: AAC = decline, TC = offline approval, ARQC = "ask the issuer". The card can be stricter than the terminal, never more lenient.
Public exponent of the issuer key (3 or 65537). Together with certificate 90 and remainder 92, it lets you reconstruct the full public key.
What the terminal can do, in 3 bytes: card entry modes, supported CVMs, offline authentications. An ATM and a restaurant's card terminal don't share the same profile.
Bit labels – the detailed bit-by-bit explanation is coming in a later pass.
| Byte 1 · bit 8 | Manual key entry (terminal keypad) |
| Byte 1 · bit 7 | Magnetic stripe read |
| Byte 1 · bit 6 | Contact chip read |
| Byte 2 · bit 8 | Plaintext offline PIN verified by the card |
| Byte 2 · bit 7 | Enciphered PIN verified online |
| Byte 2 · bit 6 | Handwritten signature (paper) |
| Byte 2 · bit 5 | Enciphered offline PIN verified by the card |
| Byte 2 · bit 4 | No CVM required |
| Byte 3 · bit 8 | Static authentication (SDA) |
| Byte 3 · bit 7 | Dynamic authentication (DDA) |
| Byte 3 · bit 6 | Card capture possible |
| Byte 3 · bit 4 | Combined authentication (CDA) |
The result of cardholder verification: which method was applied (from CVM List 8E), under what condition, and whether it succeeded. An essential companion to the TVR for understanding a PIN-related decline.
A 2-digit code that crosses two axes: who controls the terminal (financial institution, merchant, cardholder) and its environment (attended or not, ability to go online). The vast majority of attended merchant terminals in France fall in the 21-23 range; the exact value depending on offline capability depends on the acquirer contract.
A counter incremented by the chip on every transaction. It stops an intercepted transaction from being replayed as-is: since it feeds into the cryptogram calculation, no two transactions ever produce the same one. An abnormal jump in ATC is a fraud signal on the issuer side.
The terminal's nonce: randomness injected into the cryptogram calculation to prevent pre-computation and replay. A predictable UN has already broken the security of entire terminal fleets, a classic audit point.
The list of terminal data the card wants to receive right from GET PROCESSING OPTIONS. Same logic as the CDOLs: tag references, and the values then travel without structure.
Companion to tag 9F33: supported transaction types (cash, purchase, withdrawal…) and the terminal's display/entry capabilities.
Bit labels – the detailed bit-by-bit explanation is coming in a later pass.
| Byte 1 · bit 8 | Cash advance |
| Byte 1 · bit 7 | Goods |
| Byte 1 · bit 6 | Services |
| Byte 1 · bit 5 | Cashback |
| Byte 1 · bit 4 | Inquiry |
| Byte 1 · bit 3 | Transfer |
| Byte 1 · bit 2 | Payment |
| Byte 1 · bit 1 | Administrative |
| Byte 2 · bit 8 | Cash deposit |
| Byte 3 · bit 8 | Numeric keys |
| Byte 3 · bit 7 | Alphabetic and special-character keys |
| Byte 3 · bit 6 | Command keys |
| Byte 3 · bit 5 | Function keys |
| Byte 4 · bit 8 | Print, attendant |
| Byte 4 · bit 7 | Print, cardholder |
| Byte 4 · bit 6 | Display, attendant |
| Byte 4 · bit 5 | Display, cardholder |
| Byte 4 · bit 2 | Code table 10 |
| Byte 4 · bit 1 | Code table 9 |
| Byte 5 · bit 8 | Code table 8 |
| Byte 5 · bit 7 | Code table 7 |
| Byte 5 · bit 6 | Code table 6 |
| Byte 5 · bit 5 | Code table 5 |
| Byte 5 · bit 4 | Code table 4 |
| Byte 5 · bit 3 | Code table 3 |
| Byte 5 · bit 2 | Code table 2 |
| Byte 5 · bit 1 | Code table 1 |
Transaction counter on the terminal side, the terminal's counterpart to the card's ATC.
The card application's reference currency (the one used by its internal offline counters).
Position of the decimal separator for the application's currency (2 for the euro).
Code produced by SDA authentication, stored for use in DOLs. Legacy, rare on modern cards.
Certificate for the card's public key, signed by the issuer. The last link in the CA → issuer → card chain, used by DDA/CDA.
Public exponent of the card's key.
Remainder of the card's public key that didn't fit in certificate 9F46.
List of extra tags included in the statically signed data, in practice almost always the AIP (82), to prevent it from being tampered with.
The dynamic signature produced by the card during DDA/CDA: it notably covers the terminal's nonce, proving the card is live and present, which SDA could never prove.
In contactless: the terminal announces to the card what it supports and requires (EMV mode, online PIN, signature, CDCVM…). The first negotiation of a tap.
Bit labels – the detailed bit-by-bit explanation is coming in a later pass.
| Byte 1 · bit 8 | Mag-stripe mode supported |
| Byte 1 · bit 6 | EMV mode supported |
| Byte 1 · bit 5 | EMV contact chip supported |
| Byte 1 · bit 4 | Offline-only reader |
| Byte 1 · bit 3 | Online PIN supported |
| Byte 1 · bit 2 | Signature supported |
| Byte 1 · bit 1 | Offline Data Authentication for Online Authorizations supported |
| Byte 2 · bit 8 | Online cryptogram required |
| Byte 2 · bit 7 | CVM required |
| Byte 2 · bit 6 | (Contact Chip) Offline PIN supported |
| Byte 3 · bit 8 | Issuer Update Processing supported |
| Byte 3 · bit 7 | Consumer Device CVM supported |
The card's response to the TTQ in contactless: its own requirements (ask for online PIN, fall back to contact…).
Outside the base EMV spec: its meaning depends on the network. At Visa, it's the Form Factor Indicator, 4 bytes describing the payment form factor (card, mobile, wearable…) and its capabilities. At Mastercard, the same tag carries Third Party Data, a variable-length format (country, identifier, form factor type). The tool detects the format from the value's length and decodes both.
The issuer's discretionary area within the FCI, directory entries (61) live here, along with proprietary network or domestic tags (including some unpublished CB tags).
No match. Try a tag number (9F33) or a word from the label.
They are here because people look them up constantly. Unless stated otherwise, they carry labels only, no explanation.
An AID names the payment application the chip and the terminal are going to use. It is 5 to 16 bytes long and reads in two parts: the first 5 bytes are the RID, the application provider identifier, assigned by ANSI under ISO/IEC 7816-5; the rest is the PIX, free-form, chosen by the network to tell its products apart. A000000003 is Visa’s RID, 1010 the PIX for Visa debit or credit.
On a co-badged card – in France, CB plus Visa or Mastercard on roughly 77 of 110 million cards – the chip carries one application per brand, each with its own AID. The terminal intersects the card’s list with its own, and tag 87 ranks whatever is left, from 1, the highest priority, to 15.
A subtlety most explanations get wrong: the tag 87 bit meaning “cannot be selected without cardholder confirmation” only exists in contact. In contactless, the high bits are reserved and a value of 0 means the lowest priority, tied with 15 – selection there is fully deterministic, with no cardholder step foreseen by the specification. That is where the technology and the law part ways: article 8(6) of Regulation (EU) 2015/751 lets the merchant pre-set a priority brand in their own equipment, but forbids them from stopping the cardholder overriding it.
| AID | RID | Network | Product | Evidence level |
|---|---|---|---|---|
| A0000000031010 | A000000003 | Visa | Visa debit or credit | Specification or network |
| A0000000032010 | A000000003 | Visa | Visa Electron | Specification or network |
| A0000000032020 | A000000003 | Visa | V PAY (Europe only) | Specification or network |
| A0000000033010 | A000000003 | Visa | Visa Interlink (US debit) | Specification or network |
| A0000000038010 | A000000003 | Visa | Plus (ATM) | Specification or network |
| A0000000980840 | A000000098 | Visa | Visa U.S. Common Debit | Specification or network |
| A000000003101001 | A000000003 | Visa | Visa Credit (PIX extension) | Cross-checked |
| A000000003101002 | A000000003 | Visa | Visa Debit (PIX extension) | Cross-checked |
| A0000000041010 | A000000004 | Mastercard | Mastercard credit or debit | Cross-checked |
| A0000000042203 | A000000004 | Mastercard | US Maestro, a.k.a. Mastercard U.S. Common Debit | Cross-checked |
| A0000000043060 | A000000004 | Mastercard | Maestro (international debit) | Cross-checked |
| A0000000046000 | A000000004 | Mastercard | Cirrus (ATM only) | Cross-checked |
| A0000000048002 | A000000004 | Mastercard | Chip Authentication Program (CAP) | Cross-checked |
| A0000000049999 | A000000004 | Mastercard | Mastercard PayPass | Cross-checked |
| A0000000050001 | A000000005 | Mastercard | Maestro UK (formerly Switch) | Cross-checked |
| A00000002501 | A000000025 | American Express | American Express (AEIPS, contact and contactless) | Cross-checked |
| A0000000421010 | A000000042 | CB | CB (Cartes Bancaires, French domestic scheme), credit or debit | Cross-checked |
| A0000000422010 | A000000042 | CB | CB (Cartes Bancaires, French domestic scheme), debit | Cross-checked |
| A0000001523010 | A000000152 | Discover | Discover and Diners Club (D-PAS) | Cross-checked |
| A0000001524010 | A000000152 | Discover | Discover U.S. Common Debit | Cross-checked |
| A0000003241010 | A000000324 | Discover | Discover ZIP | Cross-checked |
| A000000333010101 | A000000333 | UnionPay | UnionPay debit | Cross-checked |
| A000000333010102 | A000000333 | UnionPay | UnionPay credit | Cross-checked |
| A000000333010103 | A000000333 | UnionPay | UnionPay quasi-credit | Cross-checked |
| A000000333010106 | A000000333 | UnionPay | UnionPay electronic cash | Cross-checked |
| A000000333010108 | A000000333 | UnionPay | UnionPay U.S. Common Debit | Cross-checked |
| A0000000651010 | A000000065 | JCB | JCB (J/Smart Credit) | Cross-checked |
| A0000003591010028001 | A000000359 | girocard | girocard (Germany) | Cross-checked |
| D27600002545500100 | D276000025 | girocard | Geldkarte (Germany) | Cross-checked |
| A0000001211010 | A000000121 | Dankort | Dankort (Denmark) | Cross-checked |
| A0000001410001 | A000000141 | Bancomat | PagoBancomat (Italy) | Cross-checked |
| A0000002771010 | A000000277 | Interac | Interac (Canada) | Cross-checked |
| A0000005241010 | A000000524 | RuPay | RuPay (India) | Cross-checked |
| A0000006581010 | A000000658 | Mir | Mir credit (Russia) | Cross-checked |
| A0000006582010 | A000000658 | Mir | Mir debit (Russia) | Cross-checked |
| A00000038410 | A000000384 | eftpos | eftpos Savings (Australia) | Cross-checked |
| A00000038420 | A000000384 | eftpos | eftpos Cheque (Australia) | Cross-checked |
| A0000003710001 | A000000371 | Verve | Verve (Nigeria) | Cross-checked |
| D5780000021010 | D578000002 | BankAxept | BankAxept (Norway) | Cross-checked |
| A0000002281010 | A000000228 | SPAN | SPAN (Saudi Arabia), M/Chip | Cross-checked |
| A0000001544442 | A000000154 | Banricompras | Banricompras Débito (Brazil) | Cross-checked |
| A0000000291010 | A000000029 | LINK | LINK (ATM, United Kingdom) | Cross-checked |
| A0000004391010 | A000000439 | Exchange | The Exchange Network (ATM, United States and Canada) | Cross-checked |
| A0000004360100 | A000000436 | Edenred | Ticket Restaurant (Belgium) | Cross-checked |
| A0000006200620 | A000000620 | DNA | Debit Network Alliance Shared Debit (United States) | Cross-checked |
Every row carries its evidence level. To date, only Visa publishes its AIDs in a public document. For the other networks, values marked “cross-checked” come from several concordant public documents: licensed EMV test card sets, the U.S. Payments Forum, published domestic specifications. Any value carried by a single secondary source was dropped – which is why this table is shorter than the ones circulating elsewhere.
The RID is the stable part of the AID: 5 bytes identifying the application provider, one per organisation. A RID starting with A is registered internationally; a RID starting with D is national.
| RID | Holder | Region |
|---|---|---|
| A000000003 | Visa International | International |
| A000000098 | Visa USA (US Common Debit) | United States |
| A000000004 | Mastercard International | International |
| A000000005 | Switch Card Services (Maestro UK) | United Kingdom |
| A000000025 | American Express | International |
| A000000029 | LINK Interchange Network | United Kingdom |
| A000000042 | Groupement des Cartes Bancaires CB | France |
| A000000059 | Zentraler Kreditausschuss (ZKA) | Germany |
| A000000065 | JCB Co., Ltd. | Japan |
| A000000121 | PBS Danmark (Dankort) | Denmark |
| A000000141 | Consorzio Bancomat | Italy |
| A000000152 | Diners Club International | International |
| A000000154 | Banrisul | Brazil |
| A000000228 | Saudi Arabian Monetary Agency (SPAN) | Saudi Arabia |
| A000000277 | Interac Association | Canada |
| A000000324 | Discover Financial Services | United States |
| A000000333 | China UnionPay | China |
| A000000359 | girocard – holder disputed across sources (Die Deutsche Kreditwirtschaft or EAPS) | Germany |
| A000000371 | Verve / Interswitch | Nigeria |
| A000000384 | eftpos / AusPayNet | Australia |
| A000000436 | Edenred | Belgium |
| A000000439 | ACCEL / The Exchange Network | United States and Canada |
| A000000524 | RuPay / NPCI | India |
| A000000620 | Debit Network Alliance | United States |
| A000000658 | Mir / NSPK | Russia |
| D276000025 | ZKA (girocard, Geldkarte) | Germany |
| D578000002 | BankAxept | Norway |
| Code | Meaning |
|---|---|
| 51 | Insufficient funds |
| 54 | Expired card |
| 55 | Incorrect PIN |
| 00 | Approved |
| 01 | Refer to card issuer (call) |
| 02 | Refer to card issuer, special conditions |
| 05 | Do not honour |
| Y1 | Offline approved (the transaction did not go online) |
| Z1 | Offline decline |
| Y3 | Unable to go online, offline approved |
| Z3 | Unable to go online, offline decline |
| Code | Meaning |
|---|---|
| 0 | Fail CVM processing |
| 1 | Plaintext offline PIN, verified by the card |
| 2 | Online PIN (verified by the issuer) |
| 3 | Plaintext offline PIN + paper signature |
| 4 | Enciphered offline PIN, verified by the card |
| 5 | Enciphered offline PIN + paper signature |
| 30 | Paper signature |
| 31 | No CVM required |
| 63 | No CVM performed |
| Code | Meaning |
|---|---|
| 17 | Cash disbursement at a counter |
| 20 | Refund |
| 30 | Balance inquiry |
| 00 | Purchase |
| 01 | Cash withdrawal / cash advance |
| 09 | Purchase with cashback |
| Code | Meaning |
|---|---|
| 11 | Financial institution, attended, online only |
| 12 | Financial institution, attended, offline with online capability |
| 13 | Financial institution, attended, offline only |
| 14 | Financial institution, unattended, online only |
| 15 | Financial institution, unattended, offline with online capability |
| 16 | Financial institution, unattended, offline only |
| 21 | Merchant, attended, online only |
| 22 | Merchant, attended, offline with online capability |
| 23 | Merchant, attended, offline only |
| 24 | Merchant, unattended (self-service), online only |
| 25 | Merchant, unattended (self-service), offline with online capability |
| 26 | Merchant, unattended (self-service), offline only |
| 34 | Cardholder, personal terminal, online only |
| 35 | Cardholder, personal terminal, offline with online capability |
| 36 | Cardholder, personal terminal, offline only |
| Code | Meaning |
|---|---|
| AAC | Declined by the card |
| TC | Offline approval |
| ARQC | Online authorisation requested |
| RFU/AAR | Reserved value |
The glossary answers “what is it”. The episodes answer “how does it actually work”.
See the episodes