Payments Glossary
ARQC, CDCVM, DPAN, PAR, TSP: the acronyms, without the circular definitions.
Runs entirely in your browser. Nothing you paste is uploaded, logged or stored.
Try:
Payments glossary
| Term | What it actually is |
|---|---|
| Chip and terminal | |
| AAC | Application Authentication CryptogramThe cryptogram a chip returns when it refuses the transaction. The card has decided, on its own, that this transaction will not proceed. Nothing downstream can overturn it. |
| AC | Application CryptogramThe umbrella term for the three values a chip can return from GENERATE AC: an ARQC to go online, a TC for an offline approval, or an AAC for a decline. Which one arrived is in tag 9F27. |
| AFL | Application File Locator, tag 94A list of the records the terminal must read off the card, given as file and record ranges. It also marks which of those records are covered by the offline data authentication signature.EMV TLV Parser |
| AID | Application IdentifierNames one payment application on a card, as an RID identifying the scheme followed by a PIX identifying the product. A terminal SELECTs by AID, which is how one card can hold debit, credit and a domestic scheme side by side.AID Lookup |
| AIP | Application Interchange Profile, tag 82Two bytes in which the card states what it is capable of: which offline authentication methods it supports, whether cardholder verification is supported, and whether the terminal should perform risk management. Capability only, not what happened.EMV Bit Field Decoder |
| APDU | Application Protocol Data UnitOne command sent to the chip, or one response it sends back, as defined by ISO/IEC 7816-4. Every response ends with the two status bytes SW1 SW2, which is where 9000 and 6A82 come from.APDU Status Word Lookup |
| ARPC | Authorisation Response CryptogramThe issuer's cryptographic reply to an ARQC, sent back in the authorisation response. It proves to the card that a real issuer, holding the right key, saw the request. The card checks it before completing the transaction. |
| ARQC | Authorisation Request CryptogramA cryptogram computed by the card over the transaction data, using a key only the card and its issuer hold. It travels online in the authorisation and lets the issuer confirm that a genuine chip, not a copy of its data, produced this transaction. |
| ATC | Application Transaction Counter, tag 9F36A counter the card increments on every transaction it processes. Because it never repeats, an issuer seeing a value it has already seen is looking at a replay, and a large jump means transactions it never received. |
| ATR | Answer To ResetThe first bytes a contact card sends when powered up, describing the protocols and timing it will speak. It arrives before any payment application is selected, so an ATR alone tells you nothing about what the card can pay with. |
| CDA | Combined Data AuthenticationOffline data authentication in which the card signs the application cryptogram along with the transaction data, in one step. Unlike DDA, this ties the signature to the actual approval, closing the gap where a signature is valid but the cryptogram beside it was swapped. |
| CDCVM | Consumer Device Cardholder Verification MethodCardholder verification performed by the phone or watch rather than the terminal: a fingerprint, a face, or the device passcode. The device asserts to the terminal that it verified the cardholder; the terminal never sees the biometric.CVM List Parser |
| CID | Cryptogram Information Data, tag 9F27One byte saying which cryptogram the card just returned, and whether it wants advice sent. The top two bits carry the answer: ARQC, TC or AAC.EMV Bit Field Decoder |
| CTQ | Card Transaction Qualifiers, tag 9F6CThe card's contactless instructions to the terminal, chiefly whether a CVM is required and whether to go online. The card's counterpart to the terminal's TTQ.EMV Bit Field Decoder |
| CVM | Cardholder Verification MethodThe step that checks whether the person is entitled to use the card: online PIN, offline PIN, signature, CDCVM, or none. Which methods are attempted, and in what order, is set by the CVM List in tag 8E.CVM List Parser |
| CVR | Card Verification ResultsThe card's own account of what it did during the transaction, carried inside Issuer Application Data. The layout is proprietary to each scheme, so a generic parser shows it as raw bytes. |
| DDA | Dynamic Data AuthenticationThe terminal sends a random number and the card signs it with a private key held in the chip. Because the challenge changes every time, a recording of a previous transaction cannot be replayed, which is the flaw that killed SDA. |
| DOL | Data Object ListA list, supplied by the card, of the tags it wants and the length of each. The terminal concatenates just the values, with no tags and no lengths, in exactly that order. PDOL is used at GET PROCESSING OPTIONS, CDOL1 and CDOL2 at the two GENERATE AC calls.EMV TLV Parser |
| EMV | The chip card specifications, and the body that maintains themOriginally the initials of Europay, Mastercard and Visa, who wrote the first version. Now maintained by EMVCo, whose scope has grown well past contact chip to contactless, QR, tokenisation and 3-D Secure. |
| EMVCo QR | The merchant-presented QR payload formatNot TLV, despite the family resemblance: a flat string of two-digit ids, two-digit lengths and values, ending in a CRC over everything before it. Pix and PromptPay are the same format underneath.EMVCo QR Decoder |
| GPO | GET PROCESSING OPTIONSThe command that begins the transaction proper. The card answers with the AIP, saying what it supports, and the AFL, saying which records to read next. |
| IAC | Issuer Action CodeThe issuer's thresholds, held on the card, for what the terminal should do about each TVR bit. Denial forces an offline decline, Online forces the transaction online, Default decides when going online was not possible.Why Did It Decline? IAC vs TVR |
| ICC | Integrated Circuit CardThe chip card itself, as distinct from the magnetic stripe on the same piece of plastic. Specifications use ICC where everyone else says chip. |
| Kernel | The EMV implementation inside a terminalThe software that runs the card conversation for one scheme or one contactless flow. A terminal carries several, and which kernel handled a transaction can change the outcome, which is why contactless behaviour differs between cards on the same terminal. |
| ODA | Offline Data AuthenticationThe terminal checking, without going online, that the card data is genuine and issuer-signed. SDA, DDA and CDA are the three methods, in increasing order of strength. It authenticates the card, not the cardholder. |
| PIX | Proprietary Application Identifier ExtensionThe part of an AID after the five-byte RID, chosen by the scheme to identify the specific product. In A0000000031010 the RID is A000000003 and 1010 is the PIX.AID Lookup |
| RID | Registered Application Provider IdentifierThe first five bytes of an AID, registered to one scheme. A0000000031010 and A0000000032010 are different products, but both start A000000003 and are therefore both Visa's.AID Lookup |
| SDA | Static Data AuthenticationThe original offline authentication: the terminal verifies an issuer signature over data that never changes. Since the same signature is valid every time, it can be copied wholesale onto a counterfeit card. That flaw is what made it obsolete. |
| TAC | Terminal Action CodeThe acquirer-set counterpart to the IAC, held in the terminal rather than on the card. The terminal combines the two, so either the issuer or the acquirer can force a transaction online or force a decline.Why Did It Decline? IAC vs TVR |
| TC | Transaction CertificateThe cryptogram meaning the transaction is approved and complete. Returned when a card approves offline, and again at the end of an online-approved transaction as the record submitted for clearing. |
| TLV | Tag-Length-Value encodingThe BER-TLV structure all chip data uses: an identifying tag, a length, then that many bytes of value. Tags can nest, so a template holds further TLV objects, which is how DE 55 carries a whole tree in one field.EMV TLV Parser |
| TSI | Transaction Status Information, tag 9BWhich processes actually ran during the transaction: offline authentication performed, cardholder verification performed, and so on. The TVR says what went wrong; the TSI says what was attempted at all.EMV Bit Field Decoder |
| TTQ | Terminal Transaction Qualifiers, tag 9F66Four bytes in which a contactless terminal announces what it supports and what it requires: online capability, CVM requirements, and which contactless schemes it will run. Read by the card before it decides how to respond.EMV Bit Field Decoder |
| TVR | Terminal Verification Results, tag 95Five bytes of everything the terminal noticed going wrong: authentication failures, expired application, PIN issues, limits exceeded. Every bit set is a finding, not a decision. Comparing it against the IAC and TAC is what produces the decision.EMV Bit Field Decoder |
| UN | Unpredictable Number, tag 9F37Four random bytes generated by the terminal for each transaction and fed into the cryptogram. It is what makes a captured cryptogram useless for the next transaction, so a terminal with a weak random source undermines the whole scheme. |
| Messages and money | |
| Advice | A message that reports rather than asksTells the other side that something has already happened, so the answer cannot change the outcome. An offline approval or a completion is sent as an advice; a system that treats one as a request will get the accounting wrong.ISO 8583 MTI Decoder |
| AFT | Account Funding TransactionA card transaction whose purpose is to pull funds in order to fund something else: a wallet top-up, a transfer, a remittance. Schemes classify it separately from a purchase because the risk and the rules differ. |
| ARN | Acquirer Reference Number23 digits assigned by the acquirer when a transaction is submitted for clearing, carrying an acquirer BIN and a processing date inside it. It is the identifier a dispute is argued over, and it does not exist at authorisation time.ARN Decoder |
| Auth code | The issuer approval code, DE 38Six characters returned by the issuer on an approval and quoted back in clearing to tie the capture to the authorisation. It identifies the approval, not the transaction, and a decline has none.STAN vs RRN vs ARN vs Auth Code |
| Authorisation | The issuer's answer to whether it will payA check of funds and risk that places a hold on the account. No money moves. A transaction can be authorised and then never captured, in which case the hold simply expires. |
| Bitmap | The index of which data elements a message carriesSixty-four bits, one per field, right after the MTI. Bit 1 set means a second bitmap follows for fields 65 to 128. Nothing in the message says where a field starts, so reading the bitmap wrongly desynchronises everything after it.ISO 8583 Bitmap Decoder |
| Capture | Claiming an authorised amountThe merchant confirming that an authorisation should turn into an actual charge, usually at shipment or end of day. This is the step that starts the money moving, and an uncaptured authorisation is never charged at all. |
| CIT | Customer-Initiated TransactionA transaction the cardholder is present for and actively triggered. The distinction matters because a CIT can be challenged with 3-D Secure and an MIT cannot, and because the schemes require the two to be flagged differently. |
| Clearing | Exchanging the transaction records that settlement is calculated fromThe daily process where acquirers submit captured transactions and the scheme works out who owes whom. Distinct from authorisation, which happened earlier, and from settlement, which is the payment that follows. |
| COF | Credential On FileA card stored for future use. The first transaction must flag that the credential is being stored, and later ones must reference that agreement, which is what separates a legitimate stored card from an unexpected charge. |
| Country code | ISO 3166-1, usually as a numberPayments messages carry the numeric form rather than the letters everyone recognises, so terminal country in tag 9F1A and DE 19 arrive as 826 or 840. Numeric codes are also not in alphabetical order, so they cannot be guessed.Country Code Lookup |
| DE | Data ElementOne numbered field in an ISO 8583 message. Which elements are present is announced by the bitmap, so DE 39 means field 39, the response code, and its position in the message depends on which fields before it were included.ISO 8583 Data Element Reference |
| EBCDIC | The character encoding IBM mainframes useNot ASCII, and not a variant of it: the letters are not contiguous and the digits sit at F0 to F9. Mainframe acquirers still speak it, so a field that decodes to punctuation in ASCII is often perfectly good EBCDIC text.Hex, ASCII, EBCDIC & BCD Converter |
| Force post | Submitting a charge without a matching online authorisationUsed when the approval was obtained out of band, typically by voice. It carries the auth code that was given at the time. Since no online authorisation record exists to match it against, it is scrutinised and disputed more often than a normal capture. |
| Incremental authorisation | Increasing an existing hold rather than creating a new oneAdds to an authorisation already in place, for a hotel stay or fuel pump where the final amount grows. It keeps one authorisation rather than stacking several, which matters because stacked holds tie up the cardholder's balance. |
| Interchange | The fee the acquirer pays the issuer on each transactionSet by the scheme, not negotiated between the two banks, and the largest component of what a merchant pays. The rate depends on how the transaction was made, so entry mode, MCC and authentication have a direct effect on cost.POS Entry Mode Lookup |
| ISO 8583 | The message format for card transactionsDefines an MTI, a bitmap of which fields are present, and the fields themselves. Every processor customises it, so a message that decodes cleanly against one endpoint may not against another. The 1987 edition is the one most traffic still resembles.ISO 8583 Message Decoder |
| MCC | Merchant Category CodeA four-digit code for what a merchant sells, defined by ISO 18245. It drives interchange, issuer risk rules, and whether a transaction is treated as cash-like, so an incorrect MCC affects both cost and approval rate.MCC Lookup |
| MIT | Merchant-Initiated TransactionA transaction the merchant triggers against a stored credential while the cardholder is not present: a subscription renewal, a delayed charge, a no-show fee. It must reference the original customer-initiated transaction that set the agreement up. |
| Minor units | How many decimal places a currency hasAmounts travel as integers with no decimal point, so the currency decides where it goes. Most have two, JPY has none, and a few such as KWD have three. Assuming two turns 1000 JPY into 10 and a KWD amount into a hundredfold error.Currency Minor Units |
| MTI | Message Type IndicatorFour digits at the front of an ISO 8583 message giving its version, class, function and origin. 0100 is an authorisation request and 0110 its response; the second digit is the class and the third says whether it is a request, a response or an advice.ISO 8583 MTI Decoder |
| OCT | Original Credit TransactionA push of funds to a card rather than a pull from it: payouts, disbursements, transfers to a card. It is a separate transaction type with its own rules, and it is not a refund, because it is not tied to any earlier purchase. |
| Partial authorisation | Approving less than the amount requestedThe issuer approves what is available on a prepaid or low-balance account instead of declining outright. The terminal must then collect the remainder another way. A system that ignores the approved amount and assumes the full request will be short of funds at settlement. |
| Presentment | The clearing record that claims payment for a transactionWhat the acquirer submits so the issuer is billed. First presentment is the original claim; second presentment is the acquirer re-submitting it after a chargeback, which is why representment and second presentment mean the same thing. |
| Quasi-cash | A purchase treated as though it were a cash withdrawalGambling chips, some crypto purchases, money orders and similar. The MCC marks it, and issuers then apply cash-advance fees, cash limits, and much sharper risk rules, so approval rates drop.MCC Lookup |
| Refund | Returning money after a transaction has clearedA new transaction in the opposite direction, submitted through clearing and settled like any other, so the cardholder waits days for it. Distinct from a reversal, which cancels an authorisation that has not yet been paid. |
| Response code | The issuer verdict in DE 39Two characters saying approved, declined, or declined for a specific reason. The ISO set is the starting point that every scheme diverged from, so the same code can carry different meanings on different networks, and issuers deliberately blur the reason on fraud declines.Decline Code Translator |
| Reversal | Cancelling an authorisation that has already been sentReleases the hold, ideally within seconds. Used when the transaction failed after the authorisation was approved, or when a timeout leaves it unclear whether an approval happened. Sending one is what stops a customer seeing a phantom pending charge for days.ISO 8583 MTI Decoder |
| RRN | Retrieval Reference Number, DE 37Twelve alphanumeric characters set by the acquirer, echoed in the response and carried into clearing. That makes it the identifier to quote before an ARN exists. Any date structure inside it is an acquirer convention, not part of the standard.STAN vs RRN vs ARN vs Auth Code |
| Settlement | The actual movement of money between institutionsNet positions calculated in clearing are paid, usually once a day. It is the last step, and it happens long after the cardholder has walked out of the shop believing the transaction finished. |
| STAN | System Trace Audit Number, DE 11Six digits set by whoever sent the message and echoed back unchanged, which is how a response is matched to its request. It wraps at 999999 and terminals often reset it, so it is not unique for long and nothing downstream of authorisation carries it.STAN vs RRN vs ARN vs Auth Code |
| STIP | Stand-In ProcessingThe scheme answering on the issuer's behalf when the issuer cannot be reached, using limits the issuer set in advance. The merchant sees a normal approval. The issuer finds out afterwards, so a stand-in approval can still be followed by a problem on the account. |
| Void | Cancelling a transaction before it clearsRemoves the charge on the same day, before the batch is submitted, so the cardholder may never see it at all. Once clearing has happened, a void is no longer possible and a refund is the only remaining route. |
| Card numbers and tokens | |
| BIN | Bank Identification NumberThe leading digits of a card number that identify the issuer. ISO/IEC 7812 calls it the IIN, and defined the eight-digit form in 2017; the schemes finished moving to it in April 2022. Code that hardcodes a six-digit prefix now groups unrelated issuers together.PAN & BIN Validator |
| CVV | Card Verification Value, the family of themSeveral different values share the name. CVV1 lives in the magnetic stripe, CVV2 is printed on the card for online use, iCVV is in the chip, and dCVV is generated per transaction for contactless. They are not interchangeable, and that is the point of having four.AVS & CVV Result Codes |
| DPAN | Device Primary Account Number, the tokenThe card number a wallet actually presents, distinct from the real card number behind it. It is restricted to that device and channel, so capturing one does not yield a card that can be used elsewhere. |
| Expiry | The card expiration date, year first in every payment fieldNote the order: ISO 8583 DE 14 is YYMM and chip tag 5F24 is YYMMDD, while the card face and most checkout forms are MM/YY. Reversing the two is a classic source of transactions declined for an expired card that is perfectly valid. The DD in 5F24 is the last day of validity, not the first. |
| FPAN | Funding Primary Account NumberThe underlying real card number that a token maps back to. The issuer sees it; the merchant, in a properly tokenised flow, never does. |
| IIN | Issuer Identification NumberThe formal ISO/IEC 7812 name for the issuer-identifying digits at the start of a card number. Everyone says BIN; the standards say IIN; they are the same thing.PAN & BIN Validator |
| Luhn | The mod-10 check digit algorithmCatches single-digit typos and most transpositions in a card number. It proves nothing about whether the card exists or has funds: any correctly formed number passes, which is exactly how test card numbers work.Luhn Check Digit Calculator |
| PAN | Primary Account NumberThe card number itself, 12 to 19 digits: issuer digits, an account portion, and a check digit. It is the single most sensitive field in a payment message, and every standard here has rules about storing it.PAN & BIN Validator |
| PAR | Payment Account ReferenceA 29-character value that is the same for a card and every token made from it, and which cannot be used to pay. It lets a merchant recognise one customer across a physical card and two wallets without ever handling the real card number. |
| Service code | Three digits in the track data saying how the card may be usedThe first digit covers interchange and technology, notably whether a chip is present; the second covers authorisation processing; the third covers PIN and permitted services. A terminal that ignores it will happily swipe a card whose service code says chip only.Track 1 & 2 Parser |
| Token | A surrogate value standing in for a card numberTwo unrelated things go by this name. A network token is issued by the scheme, restricted in scope, and works as a payment credential. A gateway or vault token is just a reference within one provider and cannot be presented for payment anywhere. |
| Track data | The magnetic stripe contents, and their chip equivalentsTrack 1 holds the PAN, the cardholder name and discretionary data; track 2 holds the PAN, expiry and service code. Chip cards carry a track-2 equivalent in tag 57. All of it is cardholder data and none of it may be stored after authorisation.Track 1 & 2 Parser |
| TSP | Token Service ProviderThe party that issues tokens and holds the mapping back to the real card number, usually the scheme. Wallets ask it for a token; issuers approve; and at authorisation it is the TSP that converts the token back for the issuer. |
| Authentication and security | |
| 3DS | 3-D SecureA protocol letting an issuer authenticate a cardholder during an online purchase, before authorisation. Success shifts fraud liability to the issuer. It does not guarantee approval: the authorisation is a separate decision that can still decline.3DS ECI & Status Codes |
| ACS | Access Control ServerThe issuer-side component in 3-D Secure that decides whether to challenge the cardholder and, if so, presents that challenge. When a customer says the one-time code screen looked wrong, it came from here, not from the merchant.3DS ECI & Status Codes |
| AVS | Address Verification ServiceA check of the numeric parts of the billing address and postcode against the issuer's records. It returns a result code, never an approval or decline; deciding what to do with a partial match is the merchant's call.AVS & CVV Result Codes |
| DS | Directory ServerThe scheme-operated component in 3-D Secure that works out which issuer a card belongs to and routes the authentication to that issuer's ACS. It sits between the merchant's 3DS Server and the issuer.3DS ECI & Status Codes |
| DUKPT | Derived Unique Key Per TransactionA key management scheme, defined in ANSI X9.24, where every transaction is encrypted under a different key derived from a base key and a counter. Recovering one transaction key gives an attacker nothing about the previous ones. |
| ECI | Electronic Commerce IndicatorA value sent in the authorisation saying what happened during 3-D Secure, and therefore who carries fraud liability. Visa and Mastercard use different numbers for the same three outcomes, and in opposite order, which makes a single shared mapping table actively dangerous.3DS ECI & Status Codes |
| HSM | Hardware Security ModuleA tamper-resistant device that holds keys and performs the operations that use them, so the keys themselves never appear in ordinary memory. PIN translation, cryptogram verification and key management all happen inside one. |
| KSN | Key Serial NumberAccompanies DUKPT-encrypted data and identifies which device produced it and which transaction counter was used, so the receiving HSM can derive the matching key. It is not secret and is sent in the clear. |
| P2PE | Point-to-Point EncryptionCard data encrypted in the reader itself and only decrypted at the far end, so the merchant's own systems never see it in the clear. Under a validated P2PE programme this substantially reduces what falls in PCI DSS scope. |
| PCI DSS | Payment Card Industry Data Security StandardThe security requirements for anyone who stores, processes or transmits card data. The rule people trip over most: the PAN may be stored under strict conditions, but the security code and full track data may never be stored after authorisation, not even encrypted. |
| PIN block | An encrypted PIN, formatted before encryptionISO 9564 defines the formats. Format 0 combines the PIN with part of the PAN so the same PIN encrypts differently on different cards. Format 4 is the AES-era replacement. A PIN is never transmitted or stored in the clear at any point. |
| SCA | Strong Customer AuthenticationA European requirement under PSD2 to verify the cardholder with two of three factors: something they know, something they have, something they are. 3-D Secure is how it is normally satisfied for card payments online.3DS ECI & Status Codes |
| TRA | Transaction Risk Analysis exemptionLets a low-risk transaction skip an SCA challenge, where the acquirer or issuer keeps its fraud rate under published thresholds. The exemption is requested, not granted: the issuer can still challenge.3DS ECI & Status Codes |
| Who is who | |
| Acquirer | The merchant's bank in a card transactionHolds the merchant agreement, submits transactions into the scheme, receives the settlement and pays the merchant. It also carries the risk if the merchant fails to deliver and cannot fund the refunds. |
| Gateway | The technical connection between a merchant and an acquirerTakes the transaction from a website or terminal and delivers it in the format the acquirer expects. A gateway is not a party to the money: it does not hold funds and is not who the merchant is settled by, though many companies do both jobs. |
| Issuer | The bank that gave the cardholder the cardOwns the account, decides every authorisation, and carries the credit risk. When a transaction is declined for reasons nobody downstream can explain, the issuer is where the reason lives, and often it will not say more than the response code. |
| ISO | Independent Sales Organisation, and separately the standards bodyIn payments, an ISO resells acquiring services under a sponsoring bank. The collision with the International Organization for Standardization, which publishes ISO 8583, is unfortunate and permanent. Context is the only way to tell which one a document means. |
| Merchant of record | The entity legally selling to the cardholderWhoever appears on the statement, owes the tax, and answers the chargeback. It is not always the business that shipped the goods, which is the entire basis of the marketplace and platform model. |
| PayFac | Payment FacilitatorHolds one merchant agreement with an acquirer and boards sub-merchants underneath it, so a small seller can start taking payments in minutes rather than weeks. The PayFac takes on the underwriting and the losses those sub-merchants generate. |
| Processor | The party that runs the transaction processing itselfOperates the switch, the authorisation systems and the clearing files, on either the issuing or the acquiring side. Banks frequently outsource this entirely, which is why the name on the card is often not the company answering the message. |
| PSP | Payment Service ProviderA broad term for a company sitting between merchant and acquirer, covering anything from a pure gateway to a full acquirer. Because the term says nothing about who holds the funds or the risk, always establish which role is meant. |
| Scheme | The card network itselfVisa, Mastercard, Amex, Discover, JCB, UnionPay and the domestic networks. It writes the rules, operates the switch between issuers and acquirers, sets interchange, and arbitrates disputes. In most cases it does not issue cards or hold accounts. |
| Disputes | |
| Arbitration | The scheme deciding a dispute the two banks could not settleThe final stage, reached after a chargeback and its rebuttals have run out. The scheme rules, charges a fee, and the losing side pays both. It is expensive enough that most disputes are abandoned before reaching it. |
| Chargeback | The issuer reversing a settled transactionMoney is taken back from the acquirer, and from the merchant, on the cardholder's behalf. It is not a refund: the merchant does not consent to it, it carries a fee, and too many of them threaten the merchant account itself. |
| Compelling evidence | The documentation an acquirer submits to defend a chargebackDelivery confirmation, prior undisputed transactions on the same card, signed receipts, usage logs. What qualifies is defined by the scheme for each reason code, and evidence that does not match the code is dismissed however convincing it reads. |
| Friendly fraud | A dispute filed by the genuine cardholder over a transaction they madeSometimes deliberate, more often the cardholder failing to recognise a descriptor. It looks identical to real fraud in the data, and the fix is usually a clearer statement descriptor rather than anything in the fraud stack. |
| Reason code | The scheme code stating why a transaction is being disputedIt determines the deadline, what evidence is acceptable, and whether the dispute can be defended at all. Each scheme has its own set, so the same words mean different codes at Visa and Mastercard. |
| Representment | The acquirer resubmitting a charge after a chargebackThe merchant's answer to a dispute, arguing with evidence that the original transaction was valid. Also called second presentment, because that is literally what it is: the same transaction presented for payment a second time. |
| Retrieval request | An issuer asking for the details of a transactionA request for the receipt or record, usually because a cardholder queried it. Answering it promptly can end the matter; ignoring it commonly turns into a chargeback that is then harder to defend. |
Definitions come from the public specifications and from the schemes' own published documentation. Where a term means different things to different parties, that is said in the entry rather than resolved by picking one.
Why another glossary
Most payments glossaries expand the acronym and stop. "ARQC: Authorisation Request Cryptogram" tells you nothing you could not have guessed, and leaves you no better off than before you looked it up. Every entry here says what the thing is, what produces it, or what it decides.
Where a term has a tool behind it, the tool is the faster answer. An ARQC arrives in EMV tag 9F26, which the TLV parser will pull out of a trace, and a decline reason arrives in DE 39, which the decline code translator reads directly.
The terms that are actually two terms
A few entries exist mainly to warn you. ISO is a standards body and a kind of
reseller, and payments documents use both meanings freely. Token covers a network
token, which can be presented for payment, and a gateway vault reference, which cannot; a
conversation where each side means a different one goes wrong slowly. CVV is four
distinct values with four different jobs, and the
CVV result codes are a fifth thing again.
BIN and IIN are the same thing under two names, one of them the
standard's, and the PAN validator works in both.
Where the money actually is
Authorisation, capture, clearing and settlement are four separate events, separated by days, and only the last one moves money. A great deal of confusion in support tickets comes from treating an approval as a payment. If you read nothing else here, read those four.
What is not here
Scheme-specific terminology whose only published source is a member-licensed manual is left out rather than paraphrased from memory. If a term you need is missing, that is the likeliest reason, and your scheme's own documentation is the right place for it.
More Reference tools
All Reference toolsMinor units
ISO 4217 codes and exponents, with a converter so you stop getting JPY and KWD wrong.
Country codes
ISO 3166-1 numeric to alpha, because EMV tag 9F1A and DE 19 speak in numbers.
Data converter
Convert between every encoding a payments message uses, including EBCDIC, which mainframe acquirers still speak.
MCC lookup
Merchant category codes with descriptions and the special handling that comes with them.
3DS codes
ECI values differ between Visa and Mastercard. Here is the mapping, plus 3DS transStatus.