A technical guide to card payment infrastructure — from EMV chips and network routing to PCI DSS compliance, fraud scoring, and settlement.
$25T+
Combined Visa + MC volume (FY2024)
1–3s
Typical authorisation round-trip
ISO 8583
Core messaging standard
The 4-party model — how every card transaction works
Sources —
$25T+: Visa FY2024 Annual Report (~$15T) + Mastercard FY2024 Annual Report (~$10T) payment volumes combined. ·
1–3s: EMVCo performance guidelines target <2s; real-world round-trip varies 500ms–3s depending on issuer geography and network conditions. ·
All figures are industry estimates and may change. This site is an independent educational reference — not affiliated with Visa, Mastercard, or EMVCo.
I'm building a...
E-commerce checkout
Online shop or marketplace
Accept card payments, handle 3DS, fulfil orders via webhooks.
↗
SaaS / subscription
Recurring billing platform
Monthly/annual charges, stored credentials, MIT flows, dunning.
ISO 8583, EMV, token lifecycle, PCI DSS, scheme rules.
↗
POS / terminal
In-person payment terminal
EMV L1/L2/L3, ISO 7816, contactless NFC, PCI PTS.
↗
Payment schemes & acquirer
Scheme integration & certification
Acquirer domain cert, card-present flows, DE 22, Field 55.
↗
Dispute management
Chargebacks & dispute processing
Visa & MC reason codes, CE 3.0, monitoring programmes.
↗
Core Concepts
01 — Participants
The Four-Party Model
Cardholder, merchant, acquirer, issuer and the network rails in between.
↗
02 — Authorisation
Auth & Decline Codes
How a 2-character response code decides the fate of every transaction.
↗
03 — Settlement
Clearing & Settlement
Why money doesn't actually move when a card is approved.
↗
04 — Security
EMV, 3DS & Tokenisation
Chip cryptograms, dynamic CVV, and network tokens explained.
↗
05 — Compliance
PCI DSS
The 12 requirements, SAQ levels, and scoping your cardholder data environment.
↗
06 — Fraud
RBA & Fraud Scoring
Risk-based authentication signals, ML scoring, and 3DS2 decision logic.
↗
07 — Economics
Interchange & Scheme Fees
Where the 1.5–3% merchant fee goes and who sets it.
↗
08 — Errors
Declines & Retries
Hard vs soft declines, retry logic, and the do-not-retry list.
↗
09 — Standards
ISO 7812, 7813, 7816 & 14443
The four core ISO standards behind every card swipe, dip, and tap.
↗
10 — Tokenisation
Token Provisioning
How Apple Pay and Google Pay provision tokens — from eligibility check to active DPAN.
↗
11 — Authentication
EMV 3DS 2.2 & 2.3
Frictionless vs challenge flows, decoupled auth, SCA exemptions, and ECI values.
↗
The Four-Party Model
Core concept
Every card payment involves four entities. The cardholder initiates, the merchant accepts, the acquirer processes on behalf of the merchant, and the issuer approves on behalf of the cardholder. Visa/Mastercard are network rails — they don't hold money.
CardholderCustomer with card
MerchantAccepts payment
Acquirer (PSP)Merchant's bank
IssuerCardholder's bank
NetworkVisa / Mastercard rails
MDR (merchant rate)~1.5–3.5%
Interchange (to issuer)~1.0–2.0%
Scheme fee~0.1–0.3%
Acquirer margin~0.2–0.5%
Liability shiftEMV → issuer
Authorisation Response Codes
ISO 8583 Field 39
The issuer returns a 2-character code in Field 39. 00 = Approved. Your integration must handle at minimum: 00, 05, 51, 54, 61, 65.
00APPROVED
05Do Not Honour — hard decline
51Insufficient Funds — soft decline
54Expired Card
61Exceeds Withdrawal Limit
65Exceeds Frequency Limit
14Invalid Card Number
91Issuer Unavailable — retry safe
Clearing & Settlement Timeline
Auth ≠ settlement
Authorisation creates a hold. Clearing is the batch file sent at end-of-day. Settlement is when funds actually move — typically T+1 to T+2 via the scheme's net settlement process.
T+0 (real-time)Auth routed via network
T+0 (real-time)Issuer approves, hold placed
T+0 (end of day)Merchant sends batch clearing
T+1Scheme net settlement calc
T+1 / T+2Funds credited to merchant
T+30–120Chargeback window open
EMV, 3DS & Tokenisation
Dynamic credentials
EMV chips generate a unique ARQC per transaction — replaying captured data is useless. 3DS2 adds issuer auth for e-commerce. Network tokens replace the PAN with a merchant/device-scoped token.
The merchant pays the MDR to their acquirer. The acquirer passes interchange to the issuer and a scheme fee to the network. Interchange varies by card type, channel, and region.
Consumer debit (CP)~0.2% + £0.02
Consumer credit (CP)~0.3% (EU regulated)
Premium / World card~1.5–1.8% (non-EU)
Corporate card~2.0–2.5%
CNP surcharge+0.2–0.4%
Refund interchangeReversed on refund
Declines & Retry Logic
Hard vs soft
Hard declines (05, 14, 54, 57) must never be retried. Soft declines (51, 61, 65, 91) may resolve after a delay. Excessive retries on hard declines attract scheme fines.
Full lifecycle of a card-present authorisation, step by step.
Authorisation Path
A card-present transaction traverses five hops in under 2 seconds. Each hop adds latency and can introduce a failure mode. The ARQC cryptogram generated by the chip proves the card is genuine before the 0100 message even reaches the network.
Step 1Chip generates ARQC cryptogram using session key — proves card is genuine
Step 2Terminal builds ISO 8583 0100 with DE 2 (PAN), DE 4 (amount), DE 55 (EMV TLV data)
Step 3Acquirer routes to scheme via leased line / IP; adds DE 32 (Acquirer ID), DE 41 (Terminal ID)
Step 4Scheme runs fraud scoring, BIN lookup, routes 0100 to issuer via hot standby path
Step 5Issuer verifies ARQC, checks balance / velocity rules, returns 0110 with DE 39 response code
Step 6Approval code (DE 38) printed on receipt; chip generates TC (transaction certificate) for settlement
ISO 8583 Key Fields
iso8583_0100.hex
/* Key fields in a 0100 Authorisation Request */
Field 2 PAN "4532015112830366"// primary account number
Field 3 Proc Code "000000"// purchase
Field 4 Amount "000000001500"// £15.00 in minor units
Field 7 Trans Date "0314143022"// MMDDHHmmss
Field 11 STAN "000042"// systems trace audit number
Field 22 POS Entry "051"// chip + PIN
Field 39 Resp Code —// set by issuer in 0110
Field 41 Terminal ID "TERM0042"
Field 55 EMV Data [TLV blob]// ARQC, ATC, TVR, IAD
Settlement Flow
Settlement is a two-stage process. Clearing happens same-day as batch files flow from acquirer to scheme. Net settlement — the actual movement of funds between banks — happens T+1. The merchant typically sees funds T+1 to T+2 depending on their acquirer agreement.
T+0 clearingMerchant batches transactions; acquirer submits CTF/BASE II clearing file to scheme before cut-off
T+1 nettingScheme multilaterally nets all members; net positions settled via central bank or nostro accounts
InterchangeIssuer receives interchange from acquirer — set by scheme, varies by card type, MCC, auth method
Merchant payoutAcquirer pays merchant net of interchange + scheme fees + acquirer margin (MDR)
Chargeback windowOpens at settlement — cardholder has up to 120 days (Visa) to dispute
Timing Summary
Authorisation~1–3 seconds real-time
Clearing batchT+0 end of business day
Net settlementT+1 via scheme
Merchant fundingT+1 to T+2
Chargeback windowUp to 120 days
Single Message System (SMS) vs Dual Message System (DMS)
The fundamental architectural difference
In a Dual Message System, authorisation and clearing are two separate events — the authorisation happens online in real time, and clearing travels later as a batch file. In a Single Message System, authorisation and clearing are combined into one online message: the 0200 Financial Transaction Request. The issuer's response to the 0200 both approves the transaction and triggers settlement in the same cycle. The cardholder's account is debited immediately — there is no separate capture step.
Dual Message System (DMS)
Message 10100 Authorisation Request — approve or decline
Message 2Clearing file sent later (BASE II / VisaNet batch)
Capture requiredYes — merchant must capture to initiate clearing
Auth ≠ settlementFunds reserved but not moved at auth time
Use casesCredit cards, hotels, car rental, e-commerce
Visa systemV.I.P. (auth) + BASE II (clearing)
MC systemMastercard Network (auth) + Dual Message Switch
Common inSMS dominant in North America and ATM networks. DMS dominant in Europe
VISASingle Message System — V.I.P. SMS
Source: Visa TADG v3.3, Aug 2025 · VisaNet patent disclosures
VisaNet architecture — V.I.P. and BASE II
VisaNet runs two parallel processing pipelines. V.I.P. (VisaNet Integrated Payments) handles all online authorisation messages — both SMS 0200 and DMS 0100. BASE II is the batch clearing system for dual-message transactions. For SMS transactions, V.I.P. also handles clearing and feeds settlement automatically to VSS (VisaNet Settlement Service) — BASE II is not involved. For DMS transactions, BASE II handles the second message. A bridge between V.I.P. and BASE II allows an SMS acquirer to transact with a DMS issuer and vice versa.
CutoverVSS daily settlement cutover — transactions submitted before cutover settle T+0, after = T+1
Interchange downgradeSMS txn not cleared before cutover = interchange downgrade — acquirer's responsibility
MCSingle Message System — Mastercard Banknet / MDS
Source: MC SMS Specifications, 16 April 2024 (proprietary — concepts only)
Mastercard network architecture
Mastercard operates two parallel networks. The Dual Message Switch handles credit card authorisations (0100) and clearing files. The Single Message System — also called Banknet SMS or the Mastercard Debit Switch (MDS) — handles Maestro, Debit Mastercard, and Cirrus ATM transactions using 0200 Financial Transaction messages. Like Visa, Mastercard bridges automatically between SMS issuers and DMS acquirers and vice versa using a bridging path that translates the processing code account type fields.
Mastercard SMS message family — Banknet 0200 series
0200Financial Transaction Request — acquirer to issuer
0210Financial Transaction Request Response — issuer approve or decline
6-digit field: transaction type + from account + to account
DE 3 is a 6-digit field split into three 2-digit subfields. Subfield 1 defines the transaction type. Subfield 2 defines the "from" account type. Subfield 3 defines the "to" account type. Combined they tell the issuer exactly what to do — e.g. 012000 = withdrawal from checking account. When the acquirer sends "no account specified" (00), the issuer may specify the account type in the 0210 response.
Subfield 1 — Transaction type
00Purchase
01Withdrawal (ATM)
09Purchase with cash back
17Cash disbursement (Debit MC)
20Refund / correction
21Deposit
28Payment transaction
30Balance inquiry
40Account transfer
91PIN unblock (chip only)
92PIN change
Subfield 2 & 3 — Account type
00No account specified (issuer selects)
10Savings account
20Checking account
30Credit card account
Common combined codes
010000 Withdrawal, no acct specified
012000 Withdrawal from checking
011000 Withdrawal from savings
000000 Purchase, no acct specified
090000 Purchase with cash back
300000 Balance inquiry
Mastercard SMS — products and use cases
MaestroPrimary MC debit product — online-only PIN debit, always SMS
Debit MastercardSMS for PIN-authenticated transactions; DMS for signature debit
CirrusMastercard's ATM network — all ATM cash withdrawals, SMS via MDS
Debit Mastercard (US)Routes through MDS for PIN debit; DMS for signature transactions on same card
Stand-in processing (STIP)
STIP triggerIssuer system unavailable — no response within timeout window
STIP actionMC network approves or declines on issuer's behalf using pre-set rules
0220 adviceMC sends 0220 Financial Advice to issuer when STIP was applied — issuer must accept
Debit MC STIPSeparate STIP rules for Debit Mastercard — issuer configures floor limits and rules
Force N0Processing code N0 in DE 39 forces STIP explicitly (Visa equivalent: stand-in indicator)
Inter-network gateway routing
What happens when a Visa acquirer processes a Mastercard or Amex card
Every acquirer connects to one primary scheme network. When a cardholder presents a card from a different scheme at that acquirer's terminal, the acquirer's network must route the transaction to the correct issuer — which sits on a completely different network, speaking a different dialect of ISO 8583. The Visa Credit Gateway Service (CGS), Mastercard's equivalent gateway function, and similar inter-network routing layers handle this translation automatically. The acquirer sees a single standardised response regardless of which issuer network processed it.
How the Visa gateway (CGS) works
Step 1 — Acquirer submits
VisaNet format (0100 / VIP)
A Visa-connected acquirer submits all card transactions in VisaNet's V.I.P. message format — regardless of card scheme. The acquirer does not need to implement Banknet or CAPN formats directly.
Step 2 — Gateway identifies scheme
BIN lookup → route decision
V.I.P. identifies the card scheme from the PAN's BIN/IIN. Visa cards route internally. Mastercard/Diners Club cards route to Banknet. American Express cards route to CAPN (Card Acceptance and Processing Network). Discover and JCB remain in VisaNet format.
Step 3 — Field mapping
VisaNet fields → scheme fields
CGS translates V.I.P. fields to the receiving network's format. This is not a simple renaming — some fields require cross-referencing multiple source fields. For example, Visa Field 62.1 (CPS Auth Characteristics Indicator) maps to Mastercard DE 48.91. Fields 44 and 48 are swapped between networks.
Step 4 — Network delivers
Banknet / CAPN → issuer
The translated message travels the receiving scheme's network to the issuer. The issuer processes it natively in its own format and responds. Discover and JCB receive messages in VisaNet format — no translation required — because they accept the Visa format directly.
Step 5 — Response translated back
Scheme response → VisaNet format
The issuer's response returns through the receiving network to V.I.P., which re-maps it back to the VisaNet format. The acquirer receives a standard 0110 response. Any scheme-specific data (e.g. Mastercard downgrade reason codes) is carried in Field 62 subfields.
Acquirer requirement
Prepare for Field 62 data
Visa acquirers processing non-Visa cards must be prepared to receive Field 62 subfields in responses even for non-Visa programmes — these carry scheme-specific data returned by the gateway translation. Ignoring unknown Field 62 subfields safely is the correct approach.
Private data fieldsVisa: Field 62 (CPS fields) · MC: DE 48 (Additional Data) · not directly equivalent
Field 44 / DE 48Swapped in gateway responses — Visa Field 44 ← MC DE 48 data; Visa Field 48 ← MC DE 44 data
Discover / JCBRouted in VisaNet format — no field mapping required. CGS forwards as-is
PIN-based POSVisa CGS does not forward PIN-based MC or Amex POS transactions — returns response code 81
Diners Club via BanknetMC/Diners Club alliance — Diners PANs routed through Banknet, same mapping as Mastercard
DE 3 processing code — cross-network comparison
Same field number, same structure — different valid values
All three networks use Field/DE 3 as the Processing Code with the same 6-digit structure (transaction type + from account + to account). However the valid values differ. Visa uses its own transaction type codes in subfield 1. Mastercard uses its own set (00 purchase, 01 withdrawal, 09 cash back, 17 cash disbursement, 20 refund, 28 payment, 30 balance inquiry, 40 transfer). American Express uses a different coding system entirely. The gateway translates subfield values as part of the field mapping process — an acquirer sending a Visa-format Processing Code for a Mastercard card will have the values translated before the message reaches Banknet.
processing_code_cross_reference.txt
// DE 3 subfield 1 (transaction type) — Mastercard SMS values// Acquirer sends in VisaNet format → Gateway translates → Banknet delivers00 Purchase // most POS transactions01 Withdrawal // ATM cash — always SMS, always 020009 Purchase with cash back // cashback at POS — amount in DE 2817 Cash disbursement // Debit Mastercard teller cash (not ATM)20 Refund / correction // online refund — no PIN required21 Deposit // ATM deposit28 Payment transaction // bill payment — mandated for issuers to receive30 Balance inquiry // checking or savings — issuer may return both40 Account transfer // between accounts — e.g. 401020 = savings→checking91 PIN unblock // chip only — DE 55 must be present92 PIN change // chip or magstripe// Subfield 2 & 3 — account type (from / to)00 No account specified // issuer may specify in 0210 response10 Savings
20 Checking
30 Credit card account
// Combined example — 012000// 01 = withdrawal | 20 = from checking | 00 = no "to" account
Multicurrency through the gateway
Visa multicurrencyField 4 (amount) and Field 49 (currency) forwarded as submitted by acquirer
MC multicurrencyAmount and currency forwarded as submitted — no USD conversion by default
Fields excludedField 6 (cardholder billing), Field 10 (billing rate), Field 51 (billing currency) excluded from gateway msgs
SMS settlement fieldsSMS multicurrency settlement fields also excluded from gateway messages
DCCDynamic currency conversion handled pre-gateway — gateway sees post-DCC amount
Gateway routing does not change acquirer certification requirements
Acquirers already certified for VisaNet reversal messages do not need to re-certify for Amex or Mastercard reversals processed through the gateway. However, the reversal must comply with existing Visa 0400/0410 format requirements — Field 38 must contain the original approval code and Field 90 positions 1–4 must contain the original MTI (0100). Mastercard acquirers should only generate 0400 reversals for approved transactions.
API Concepts
Building on payment APIs
Key patterns, data structures, and gotchas for payment integrations.
Idempotency
Rule #1
Always pass an Idempotency-Key on every mutation. The server stores the response for 24h and returns the same result on duplicate requests — critical for network timeout recovery.
create_payment_intent.ts
constintent = await stripe.paymentIntents.create({
amount: 1500, // always minor units (pence, cents)
currency: 'gbp',
payment_method_types: ['card'],
capture_method: 'manual', // auth-only, capture later
metadata: { order_id: 'ord_abc123' },
}, {
idempotencyKey: uuid(), // critical for retry safety
});
// Status: created → requires_payment_method → processing → succeeded
Network tokenisation replaces the PAN with a merchant/device-scoped token. Card updates (expiry, reissue) propagate automatically. Reduces PCI DSS scope.
Real PAN4532 0151 1283 0366
Network token4895 5500 1234 5678
Token scopemerchant + device bound
TRID40010030273
TAVV (cryptogram)dynamic per-auth value
Auto-update on reissueyes — account updater
Token Provisioning
How tokens get into digital wallets
The end-to-end lifecycle of a network token — from a consumer adding a card to Apple Pay or Google Pay, through issuer authentication, to the token being active and ready to transact.
Token provisioning vs token use
There are two distinct token flows developers often conflate. Provisioning is what happens when a consumer adds their card to a wallet — a token is created and bound to that device. Transacting is what happens at payment time — the token plus a dynamic cryptogram (TAVV) is used instead of the PAN. This page covers provisioning. The transaction flow is covered in the Tx Flow tab.
Participants in token provisioning
Cardholder
Initiates by adding their card to Apple Pay, Google Pay, Samsung Pay, or a merchant app.
Wallet Provider (TRID)
Apple Pay, Google Pay, Samsung Pay. Each has a unique Token Requestor ID (TRID) assigned by the scheme. Sends the provisioning request to the Token Service Provider.
Token Service Provider
Visa Token Service (VTS) or Mastercard Digital Enablement Service (MDES). Orchestrates the provisioning, creates the token, and manages its lifecycle.
Issuer
The cardholder's bank. Called by the TSP to verify the card is eligible, authenticate the cardholder, and approve or decline the provisioning request.
Token Requestor IDs — who's who
Apple PayTRID: 40010030273 (Visa) / 20015021091 (MC)
Google PayTRID: 40010075001 (Visa) / 20015029767 (MC)
Merchant token (CoF)Merchant has own TRID — token bound to merchant
TRID in authorisationAppears in ISO 8583 Field 123 — identifies wallet at auth time
End-to-end provisioning flow
Token provisioning involves six parties exchanging cryptographic material. The entire flow — from cardholder tapping "Add Card" to the token being active and ready to transact — typically takes 3–10 seconds for an NFC wallet and longer for card-on-file merchants awaiting issuer approval.
Step-by-step breakdown
01
Consumer initiates — card entry in wallet app
The consumer enters their card details in Apple Pay Settings, Google Pay, or a merchant app. The wallet captures the PAN, expiry, and CVV2 temporarily to send to the TSP. At this point the PAN is in transit — it is not stored by the wallet provider.
02
TSP checks issuer eligibility
The Token Service Provider (Visa VTS or Mastercard MDES) validates the BIN against its participation registry and calls the issuer's eligibility API to confirm the card is eligible for tokenisation. The issuer can accept, decline, or defer to the TSP for on-behalf-of processing. If the issuer doesn't respond in time, the TSP uses pre-configured rules to decide.
03
TSP calculates provisioning risk score
Before calling the issuer for authentication, the TSP runs its own risk model against signals like device reputation, account history, velocity of provisioning attempts, and wallet provider trust score. The outcome is one of three decisions: Approved (no step-up), Step-Up Required, or Declined. Most Apple Pay provisioning attempts with a known device score as no-step-up.
04
Issuer authenticates the cardholder (step-up, if required)
If step-up is required, the issuer chooses a verification method. The three options are: OTP delivered via SMS or email, authentication through the issuer's mobile banking app (using a cryptographic OTP generated by the app), or the cardholder calling the issuer's contact centre, after which the issuer sends an Activate lifecycle command directly to the TSP. OTPs have a configurable TTL and retry limit — typically 3 attempts before the method is locked.
05
TSP creates the token and delivers it to the wallet
On successful authentication, the TSP generates a Device PAN (DPAN) — a token that looks like a valid card number (same BIN range, passes Luhn) but maps back to the real PAN only inside the TSP's vault. The DPAN is provisioned into the device's Secure Element (SE) or Host Card Emulation (HCE) environment, along with a set of limited-use keys (LUKs) used to generate per-transaction cryptograms (TAVV). The issuer receives an ISO advice message confirming token activation.
06
Token is active — issuer notified
The issuer receives an activation advice message and should update their records to associate the DPAN and its TRID with the underlying PAN. Subsequent transactions arrive at the issuer with the DPAN in Field 2 and the TRID in Field 123 — the issuer must demap the DPAN to the PAN to apply account-level rules (credit limit, fraud blocks, etc.). The TSP handles the DPAN-to-PAN translation before the authorisation reaches the issuer in most architectures.
Token lifecycle states
Issuers can control token state
After provisioning, issuers can send lifecycle commands directly to the TSP to change a token's state — for example suspending a token when a consumer reports their phone lost, or deleting it permanently on card cancellation. These are asynchronous API calls, not ISO 8583 messages.
Inactive
Provisioned but not yet activated. Step-up authentication pending. Cannot transact.
Active
Authentication completed. Token can be used for contactless and in-app payments.
Suspended
Temporarily disabled — e.g. lost device. Can be resumed. Cannot transact.
Deactivated
Permanently removed. Cannot be resumed. Token is dead — a new provisioning is required.
Valid state transitions
Inactive → ActiveIssuer sends Activate command after cardholder auth
Active → SuspendedIssuer suspends (lost device) — consumer initiated or issuer decision
Suspended → ActiveIssuer resumes — device recovered. Only the suspending party can resume.
Active → DeactivatedDelete command — card cancelled, device reset, or fraud confirmed
Suspended → DeactivatedDelete command while suspended — permanent
Token expiryExpired tokens unavailable for reuse for 24 months after expiry
Secure Element vs Host Card Emulation
Secure Element (SE)
A dedicated tamper-resistant hardware chip — either embedded in the device (eSE, used by Apple Pay on iPhone) or on a SIM card. The DPAN and limited-use keys are stored inside the SE and never leave it. Cryptograms are generated on-chip. Highest security — the key material is never exposed to the device OS or apps. Used by Apple Pay.
Host Card Emulation (HCE)
Software-based emulation of a contactless card, running in the device OS. The DPAN and keys are stored in software (typically in a Trusted Execution Environment). Used by Google Pay on Android. Keys are refreshed regularly from the cloud rather than stored long-term on the device. Slightly lower physical tamper resistance than SE but functionally equivalent for most fraud scenarios.
What developers need to implement
token_provisioning_integration.pseudo
// If you are a MERCHANT integrating Apple Pay / Google Pay:// ─ You don't call the TSP directly.// ─ The wallet SDK handles provisioning entirely.// ─ At payment time you receive a payment token (DPAN + TAVV)// ─ encrypted in a payment data blob — pass it to your PSP.// Apple Pay payment data blob (simplified)
{
paymentData: {
data: "<base64 encrypted DPAN + TAVV + expiry>",
signature: "<Apple's ECDSA signature>",
header: {
ephemeralPublicKey: "<EC key>",
publicKeyHash: "<your cert hash>",
transactionId: "abc123..."
},
version: "EC_v1"
}
}
// Decrypt on your backend using your Apple Pay merchant cert// → pass decrypted DPAN + TAVV to acquirer/PSP in ISO 8583// If you are an ISSUER integrating with Visa VTS or MC MDES:// ─ Implement the CheckEligibility webhook (Visa calls you)// ─ Implement GetVerificationMethods (step-up options)// ─ Implement SendPasscode (deliver OTP to cardholder)// ─ Use SubmitLifecycleCommand to manage token states// ─ Use TokenInquiry to list all tokens for a PAN
Account updater — automatic token refresh
Why tokens survive card reissue
When an issuer reissues a card (new expiry, new PAN due to compromise), the TSP's account updater service automatically updates the DPAN mapping in the vault. The consumer doesn't need to re-add their card to Apple Pay or Google Pay. From the merchant's perspective, the same DPAN keeps working — the underlying PAN mapping is updated silently inside the TSP.
Expiry updateTSP updates vault mapping — DPAN unchanged, no re-provisioning
PAN compromise reissueNew PAN mapped to existing DPAN — wallet unaffected
Card cancellationIssuer must send Delete lifecycle command to TSP
PAN reference IDStable identifier across PAN changes — use for lifecycle API calls
TAVV refreshLimited-use keys replenished from cloud — transparent to merchant
PCI & Compliance
Compliance framework for card payment systems
PCI DSS, SAQ levels, sensitive data rules, and EMV terminal certification — the full compliance picture for anyone building on or within card payment infrastructure.
Scope first
PCI DSS scope is determined by your Cardholder Data Environment (CDE) — any system that stores, processes, or transmits PAN, SAD, or CVV. Reduce scope aggressively: use network tokens and hosted fields so raw PANs never touch your servers.
Compliance = mandatory rules enforced by regulators or scheme contracts — penalties for non-compliance. ·
Technical = interoperability specifications — systems that don't implement them correctly won't work, but there's no regulator.
Req 1
Network security controls
Firewalls and network segmentation isolating the CDE. No direct internet access to cardholder systems.
All merchants
Req 2
Secure configurations
Vendor defaults changed, unnecessary services disabled, system hardening standards applied.
All merchants
Req 3
Protect stored account data
PAN must be rendered unreadable (AES-256 or truncation). SAD must never be stored post-auth.
All merchants
Req 4
Encrypt data in transit
TLS 1.2+ for all PAN transmission. No fallback to SSL or early TLS. Certificate pinning recommended.
All merchants
Req 5
Protect against malware
Anti-malware on all systems, regular scans, log reviews. Anti-phishing controls for personnel.
SAQ A-EP+
Req 6
Secure systems & software
Security patches within 1 month. OWASP Top 10 addressed. Change management enforced.
All merchants
Req 7
Restrict access by need
Least-privilege access controls. Role-based access to all CDE systems and data.
All merchants
Req 8
Identify users & authenticate
Unique IDs per user, MFA on all CDE access, password complexity, session management.
All merchants
Req 9
Restrict physical access
Physical access controls to CDE. Media destruction policy. POS device tamper monitoring.
SAQ B+
Req 10
Log & monitor all access
Audit logs for all CDE access. Log integrity, SIEM, 12-month retention, daily review.
All merchants
Req 11
Test security regularly
Quarterly ASV scans, annual penetration test, internal vulnerability scans, IDS.
SAQ A-EPJS on payment page, no SAD stored. ~191 controls.
SAQ BImprint or dial-out terminals, no e-commerce. ~41 controls.
SAQ CPayment app with internet connection. ~160 controls.
SAQ DAll others. Full 329 controls. QSA may be required.
Level 1 ROC6M+ Visa txns/yr. On-site QSA audit mandatory.
Sensitive Authentication Data — Never Store
Post-auth SAD prohibition
Even encrypted, SAD must not be retained after authorisation completes. This includes: full magnetic stripe / chip equivalent data, CAV2/CVC2/CVV2/CID, and PIN / PIN block.
pci_data_retention.ts
// ALLOWED — store for display / routingconst safe = {
pan_last4: '0366',
pan_first6: '453201', // BIN only
expiry: '12/28',
token: 'tok_live_abc123',
};
// NEVER store — hard delete after authconst forbidden = {
full_pan: '4532015112830366', // ← PCI violation
cvv: '737', // ← PCI violation always
track2: '4532...=2512...', // ← PCI violation always
};
POS Terminal Certification — EMV Levels 1, 2 & 3
Why terminal certification exists
Before a POS terminal can process live card transactions on a scheme network, it must pass a three-level certification programme defined by EMVCo and the individual card schemes (Visa, Mastercard, Amex). Each level tests a distinct layer of the terminal stack — hardware, application, and end-to-end scheme interoperability — and must be passed in sequence. Failing any level blocks the terminal from certification at the next.
Level 1 — Hardware
Physical & electrical interface
Tests the terminal's physical interface with the ICC (Integrated Circuit Card). Covers card insertion/removal mechanics, electrical signal integrity, power supply tolerances, and protocol timing at the ISO 7816 transport layer. Conducted by an EMVCo-accredited test laboratory.
StandardISO/IEC 7816-3
Tested byEMVCo-accredited lab
ScopeHardware only
Re-test triggerHardware change
Level 2 — Application
EMV kernel & payment app
Tests the terminal's EMV payment application — the software kernel that manages the transaction flow: application selection (PSE/AID), card authentication (SDA/DDA/CDA), cardholder verification (PIN, signature, no-CVM), and terminal risk management (floor limits, velocity checks). Each kernel version (contact, contactless, Visa payWave, MC PayPass) requires separate L2 approval.
StandardEMVCo Book 1–4
Tested byEMVCo-accredited lab
ScopeKernel software
Re-test triggerKernel update
Level 3 — End-to-End
Scheme & acquirer integration
Tests the complete payment flow from terminal through to the acquirer host and the card scheme network. Verifies correct ISO 8583 message construction, field population (including Field 55 EMV data), error handling, and scheme-specific rules. Must be repeated for each acquirer and each scheme (Visa, Mastercard, Amex, UnionPay each require separate L3 approval). This is the most time-consuming level — typically 3–9 months.
L3 timelineTypically 3–9 months per acquirer/scheme combination
Key Practical Considerations for Developers
Certification scope creep
Any change to the terminal software that touches the payment kernel or ISO 8583 message construction can invalidate L2 or L3 certification and trigger a full re-test cycle. Most terminal vendors maintain a frozen certified build and a separate development build to avoid this. Coordinate with your acquirer before shipping software updates to certified hardware.
PCI PTS
PIN Transaction Security
Separate from EMV levels. Tests physical tamper-resistance of PIN entry devices (PEDs). Required for any terminal accepting offline or online PIN. Approval lasts 5 years.
Contactless kernels
Separate L2 per kernel
Visa payWave (vVLP), Mastercard PayPass/MCCS, Amex ExpressPay, and Discover D-PAS each require independent L2 kernel certification — they are not covered by a generic EMV L2 pass.
SoftPOS / Tap-to-Pay
COTS device certification
Commercial off-the-shelf devices (smartphones) running a payment app require a CPOC (Contactless Payments on COTS) programme approval from PCI SSC, plus scheme-specific L2/L3 for the software kernel.
Re-certification triggers
When you must re-test
Hardware revision (L1), kernel version bump (L2), acquirer host migration or scheme rule change (L3). Minor cosmetic or UI changes that do not touch the payment path typically do not require re-certification.
Fraud & Risk
Risk-based authentication & fraud scoring
How issuers and networks score transactions in real time — and how to build with that in mind.
Live RBA Score Simulator
Transaction amount£45
Device trust scorehigh
Velocity (txns / hr)2
Geo anomalylow
Merchant category risklow
3DS2 enrichmentrich
Risk score
18
Frictionless — approve
Low risk profile. 3DS2 frictionless flow likely. No step-up required.
ApproveNo 3DS challenge
Signal Categories
Behavioural
Typing cadence & navigation
Keystroke timing, mouse movement, copy-paste detection. Collected via browser JS. Identifies bots and scripted attacks.
Chargeback codes are a lagging indicator — build upstream
By the time a chargeback code lands on your desk, the fraud has already happened. The reason codes (Visa 10.x, MC 48xx) tell you what type of fraud occurred — but they don't help you prevent the next one. Prevention happens at authorisation time through signals, velocity rules, and authentication. The full reason code reference is in the
Velocity rules — what to track per cardholder
txn_count_1hTransactions in last 1 hour — flag >3 on same PAN
txn_count_24hTransactions in last 24 hours — flag >10 on same PAN
amount_24hCumulative spend in 24h — set issuer-aligned limit (e.g. £500)
distinct_merchants_1hDifferent merchants in 1 hour — >4 is high risk for CNP
distinct_countries_24hCountries in 24h — >2 is near-certain flag for lost/stolen
card_testing_patternSequential small amounts (<£1) on same PAN — carding attack signature
decline_then_retrySame PAN declined then re-attempted within 60s — scheme retry rule violation
new_device_high_valueFirst transaction on device_id > £200 — step up to 3DS challenge
Device & session signals
Device fingerprint
browser_fingerprint / device_id
Hash of user-agent, screen resolution, timezone, fonts, canvas. Stable across sessions — links multiple transactions to one device. Essential for CE 3.0 matching (two prior undisputed txns must share device_id).
IP intelligence
ip_address + geo + proxy flag
IP geolocation vs billing address mismatch. VPN/Tor/datacenter IP flags. ASN-based proxy detection. High-risk: residential proxy with IP country ≠ card BIN country.
Behavioural biometrics
Typing cadence + mouse dynamics
Time between keystrokes on card field, copy-paste detected (instant field population), mouse movement linearity. Human entry takes 8–15 seconds; bots fill in <1s.
Session anomalies
Time on page + navigation path
Direct landing on checkout (no product pages visited). Session duration under 30s for first purchase. Multiple browser tabs open simultaneously (headless browser signal).
Token transactions carry a fresh cryptogram per transaction — unforgeable proof of a valid provisioned device. 3DS on a token transaction provides both device proof AND cardholder authentication.
Liability shift — what authentication buys you
No auth (plain CNP)Merchant bears 100% liability for fraud chargebacks
3DS attempted, issuer declinedPartial shift — depends on ECI value and scheme rules
A cardholder disputes a legitimate transaction — intentionally or because they don't recognise the merchant descriptor. Defence: clear merchant descriptor on statement, email receipts at time of purchase, proactive cancellation/refund policies, and CE 3.0 evidence (device_id + IP match across prior transactions). Visa 10.4 is the specific code to watch; MC 4853 covers the equivalent.
Authentication
EMV 3DS 2.2 & 2.3 — Issuer authentication for CNP
EMV 3-D Secure is the protocol that authenticates cardholders in card-not-present transactions. Version 2.2 is the current production baseline; 2.3 adds decoupled authentication and enhanced data fields. Both are mandated under PSD2 SCA in the EEA.
Version comparison — 2.1 → 2.2 → 2.3
3DS 2.1 — baseline
Initial EMVCo release. Introduced frictionless flow, 80+ data elements, browser fingerprinting, and liability shift. Replaced the universally hated 3DS1 redirect. Now considered legacy — schemes are deprecating it.
3DS 2.2 — current
Adds decoupled authentication (cardholder authenticates independently of the transaction), enhanced 3RI (3DS Requestor Initiated) for merchant-initiated transactions, and whitelisting (trusted beneficiary). Mandated in EU under PSD2. Current production standard.
3DS 2.3 — latest
Extends decoupled auth with a longer maximum timeout (7 days vs 30 minutes in 2.2). Adds new authentication methods (QR code, out-of-band), enhanced app-based flows, and additional data elements for improved risk scoring. Adoption growing — Visa and MC mandating from 2025.
Core concepts
How 3DS2 works at a high level
The merchant (3DS Requestor) sends a rich data packet — up to 150 fields covering device fingerprint, browser data, shipping address, purchase history, and more — to the issuer's Access Control Server (ACS) via the scheme's Directory Server (DS). The ACS runs its risk model and either approves frictionlessly or challenges the cardholder. A successful authentication generates a signed proof (the Authentication Value) that shifts chargeback liability to the issuer.
3DS RequestorMerchant or PSP initiating the authentication
Directory Server (DS)Visa (Visa Secure), MC (Identity Check), Amex (SafeKey)
ACSIssuer's Access Control Server — makes auth decision
The ACS risk score is low enough to approve without challenge. The cardholder sees nothing — authentication happens in the background in <1 second. Accounts for ~75–90% of transactions on well-optimised integrations. Requires sending maximum data elements.
Challenge
Cardholder must respond
The ACS requests additional verification. Challenge types: OTP (SMS or email), biometric (fingerprint, face ID via banking app), knowledge-based question, or out-of-band (push notification to banking app). The cardholder interacts within an iframe or redirect embedded in the checkout.
Decoupled (2.2+)
Authentication separate from checkout
The cardholder authenticates through a separate channel (banking app, email link) independently of the checkout session. Useful for recurring payments, subscriptions, and mail-order flows where the cardholder isn't actively browsing. 2.2 allows up to 30 minutes; 2.3 extends this to 7 days.
3RI — 3DS Requestor Initiated
No cardholder present
Used for merchant-initiated transactions (MITs) — recurring charges, instalment payments, and unscheduled credential-on-file (CoF). References a prior authenticated transaction. The merchant doesn't involve the cardholder at all; the prior authentication covers the transaction.
Protocol message flow
Browser / App
3DS method
AReq
3DS Server
requestor side
route
Directory Server
Visa / MC
forward
ACS
issuer decision
ARes
Auth Result
CAVV + ECI
Key message types
3ds2_messages.txt
── Preparation phase ────────────────────────────────────────PReq / PRes Preparation Request/Response
3DS Server registers with DS, retrieves DS cert
VReq / VRes Versioning Request/Response
Browser calls DS to get 3DS method URL + version
── Authentication phase ──────────────────────────────────────AReq Authentication Request (3DS Server → DS → ACS)
Up to 150 data fields. Core fields:
deviceChannel, messageCategory, purchaseAmount,
browserFingerprint, cardholderInfo, shipAddr,
threeDSRequestorID, threeDSServerTransID
ARes Authentication Response (ACS → DS → 3DS Server)
transStatus: Y/A/C/R/U/N
Y = authenticated, A = attempted,
C = challenge required, R = rejected,
U = unable to auth, N = not authenticated
── Challenge phase (if ARes transStatus = C) ─────────────────CReq Challenge Request (browser → ACS)
CRes Challenge Response (ACS → browser → 3DS Server)
── Result phase ──────────────────────────────────────────────RReq / RRes Results Request/Response
Final notification with CAVV/AAV + ECI value
Pass CAVV in ISO 8583 Field 126 at authorisation
ECI 06 (Visa) / 01 (MC)Attempted — card enrolled, auth attempted but not completed. Partial shift.
ECI 07 (Visa) / 00 (MC)Not authenticated / not enrolled. No liability shift — merchant bears risk.
ECI in ISO 8583Field 126 (Visa) or DE 48 subelement (MC)
CAVV in ISO 8583Field 126 alongside ECI — 28-char base64 value
What changed in 2.2 — key additions for developers
Decoupled auth
threeDSRequestorDecoupledInd
New field in AReq. Set to Y to request decoupled flow. ACS responds with decoupledAuthenticationInd confirming support. Max timeout: 30 minutes in 2.2.
Whitelisting
Trusted beneficiary (PSD2)
Cardholder can whitelist a merchant after a successful challenge. Subsequent transactions at that merchant bypass challenge. Stored by the issuer. Field: whiteListStatus / whiteListStatusSource.
3RI expanded
Merchant-initiated flows
3RI transaction types extended: recurring, instalment, add card, maintain card info, account verification, split/delayed shipment. Each maps to a specific threeDSRequestorAuthInd value.
SCA exemptions
Low-value + TRA
Requestors can request SCA exemptions via threeDSRequestorChallengeInd: 02 = no challenge (low value ≤€30), 03 = no challenge (whitelist), 07 = no challenge (TRA). Issuer can override and challenge anyway.
What changed in 2.3 — key additions for developers
Extended decoupled
7-day auth window
Decoupled authentication timeout extended from 30 minutes to 7 days. Enables use cases like invoicing and B2B payments where the cardholder may not be immediately reachable.
New auth methods
QR code + OOB enhanced
Challenge UI v2.3 supports QR code scanning as a challenge method. Out-of-band (OOB) authentication via banking app is enhanced with push notification data fields and cardholder app binding.
App-native flows
SDK challenge in-app
3DS SDK v2.3 renders the challenge UI natively inside the merchant's app — no webview. Cardholder sees a polished in-app biometric prompt instead of an HTML form in a webview. Significantly better conversion.
More data elements
Additional AReq fields
New fields: payTokenInd (token transaction flag), payTokenSource (wallet type), storedCredentialInd (CoF), recurringFrequency, recurringExpiry. Richer data improves frictionless rate.
Scheme mandate
Visa / MC timeline
Visa requires acquirer 3DS Server support for 2.3 from April 2025. Mastercard requires ACS support for 2.3 from October 2025. 3DS 2.1 deprecation in progress across major markets.
SPC support
Secure Payment Confirmation
2.3 introduces hooks for W3C Secure Payment Confirmation — a browser-native FIDO2-based authentication that replaces the challenge iframe with a native OS biometric prompt. Chrome and Edge support in 2024+.
Data elements that most improve frictionless rate
More data = higher frictionless rate
The single biggest lever a merchant has on their 3DS2 frictionless rate is the richness of the AReq data payload. Issuers with well-tuned ACS models grant frictionless on 80–95% of transactions when the full data set is sent — and challenge 30–50% of transactions when only mandatory fields are sent.
high_value_3ds2_fields.txt
// Highest-impact optional fields for frictionless rateacctInfo// Account age, purchase history, shipping addr ageacctInfo.chAccAgeInd// 01=guest 02=<30d 03=30-60d 04=60d-1y 05=>1yacctInfo.txnActivityDay// # purchases last 24h — high value flags velocityacctInfo.txnActivityYear// # purchases last year — establishes account historybrowserInfo// Full browser fingerprintbrowserInfo.browserJavaEnabledbrowserInfo.browserLanguagebrowserInfo.browserScreenHeightbrowserInfo.browserTZ// Timezone offsetshipAddrMatch// Y if ship = bill address — strong frictionless signaladdrMatch// Y if ship address matches accountcardholderInfo// Cardholder name + email (hashed is fine)email// SHA-256 of email — issuer matches to accountmobilePhone.subscriber// SHA-256 of mobile — issuer matches to accountmerchantRiskIndicator.shipIndicator// 01=ship to billing 02=verified addr 06=digital.deliveryTimeframe// 01=electronic 02=same day 03=overnight 04=2+ days.reorderItemsInd// 01=first time 02=reorder — reorders less risky.preOrderPurchaseInd// 01=merchandise available 02=future availability
PSD2 SCA exemptions — when you can skip the challenge
Low value ≤ €30Exempt — up to 5 consecutive or €100 cumulative, then SCA required
TRA (Transaction Risk Analysis)Acquirer or issuer exemption based on fraud rate below threshold
Trusted beneficiaryCardholder whitelisted merchant after prior SCA — 2.2+ only
Secure corporate paymentLodged card / virtual card with dedicated process — issuer applies
MOTOMail/telephone order — outside PSD2 scope, but still carries fraud risk
Issuer can overrideIssuer may still challenge even when exemption is requested
Integration checklist
Common integration mistakes
The most frequent 3DS2 integration errors are: sending only mandatory fields (kills frictionless rate), not handling the U/N transStatus gracefully (transaction should proceed to auth without 3DS rather than hard-fail), and not passing the CAVV correctly in the authorisation request (loses liability shift even on authenticated transactions).
01
Collect the full browser fingerprint before initiating AReq — run the 3DS Method URL in a hidden iframe to let the ACS pre-populate device data
02
Send all optional data elements — acctInfo, merchantRiskIndicator, hashed email and phone, and shipping address match flag
03
Handle all transStatus values — Y/A proceed, C show challenge, N/R soft-decline or re-offer, U attempt auth without 3DS
04
Pass CAVV + ECI in every authorisation — even for attempted (ECI 06) — otherwise the liability shift is lost regardless of auth outcome
05
For recurring / MIT flows use 3RI with the correct threeDSRequestorAuthInd and reference the original authentication's threeDSServerTransID
06
Test your SCA exemption requests — verify your acquirer's fraud rate is below the TRA threshold before applying TRA exemptions, or the issuer will override to challenge
07
Target 3DS 2.2 minimum — 2.1 is being deprecated. Implement 2.3 decoupled auth if your platform handles recurring or B2B payments
Card Standards
ISO standards underpinning card payments
Every tap, swipe, and dip is governed by a stack of ISO standards. This section breaks down the four core specifications every payment developer should understand.
ISO/IEC 7812 specifies the structure of the Primary Account Number (PAN) — the 8–19 digit card number — and the Issuer Identification Number (IIN, commonly called the BIN). It also mandates the Luhn algorithm (Mod 10) as the checksum that validates PAN structural integrity before any network lookup is attempted.
defluhn_valid(pan: str) -> bool:
digits = [int(d) for d in pan if d.isdigit()]
# Double every second digit from the rightfor i inrange(len(digits) - 2, -1, -2):
digits[i] *= 2if digits[i] > 9:
digits[i] -= 9returnsum(digits) % 10 == 0# 4532015112830366 → True (valid Visa test PAN)# 4532015112830367 → False (single digit changed)
StandardISO/IEC 7812-1:2017 + 7812-2
PAN length8–19 digits (most cards: 16)
IIN / BIN length6 digits (legacy) → 8 digits (2017+)
MII digit 4Visa
MII digit 5Mastercard (51–55 range)
MII digit 3Amex (34, 37) / JCB (35) / Diners
MII digit 6Discover (6011, 65) / UnionPay (62)
Check digitLuhn algorithm (ISO/IEC 7812-1 Annex B)
ISO/IEC 7813 — Magnetic stripe (financial cards)
What it defines
ISO/IEC 7813 defines the physical magnetic stripe on payment cards and the data encoding on Track 1 and Track 2. Track 3 is defined but not used by payment schemes. The stripe encodes the PAN, expiry, service code, and discretionary data in a format readable by any compliant card reader worldwide — which is also why skimming attacks are effective against magstripe-only terminals.
Track layouts
iso7813_track_data.txt
── Track 1 (210 bpi, 79 chars, alphanumeric, IATA) ──────────%B4532015112830366^SMITH/JOHN^2512201153260000000?
│ │________________│ │_________│ │____│ │_______│
│ PAN (≤19 digits) Name Expiry Service Discretionary
B = financial card (26 ch) YYMM code data + CVV1
── Track 2 (75 bpi, 40 chars, numeric only, ABA) ────────────;4532015112830366=2512201153260000?
│________________│ │____│ │_____│
PAN Expiry Service Discretionary
YYMM code data + CVV1
Track 2 is what EMV terminals read for fallback.Both tracks contain CVV1 — different from the printed CVV2.
Track data is Sensitive Authentication Data under PCI DSS. Storing it post-authorisation — even encrypted — is a hard violation. The full track data (which includes CVV1) cannot be reconstructed from the PAN + expiry alone, which is why its capture is the goal of most POS skimming attacks.
ISO/IEC 7816 is a multi-part standard covering the complete contact chip card interface: the physical card dimensions and contact positions (Part 1–2), the electrical signal protocol (Part 3), the APDU command/response structure (Part 4), and the file system and security architecture (Parts 4–9). EMV builds directly on ISO 7816-3 and 7816-4 for contact transactions.
── Command APDU (terminal → card) ───────────────────────────CLAINSP1P2LcDataLe00A4040007 A0000000031010 00
│ │ │ │ │ │ └ max resp bytes
│ │ │ │ │ └─ AID: Visa Credit (7 bytes)
│ │ └────┴────┴─ SELECT by AID, first occurrence
│ └─ INS: SELECT FILE
└─ CLA: ISO/IEC 7816 standard class
── Response APDU (card → terminal) ──────────────────────────Data (variable) SW1SW2
FCI template ... 9000// 9000 = success6A82// 6A82 = file not found63CX// 63CX = PIN wrong, X tries left
Key EMV commands (ISO 7816-4 / EMVCo Book 1–3)
emv_command_sequence.txt
1. SELECT PSE // INS A4 — find Payment System Environment2. READ RECORD // INS B2 — read AID list from PSE3. SELECT AID // INS A4 — select Visa / MC application4. GET PROCESSING OPTS // INS A8 — start txn, get AIP + AFL5. READ RECORD (×n) // INS B2 — read card data per AFL6. GET DATA // INS CA — fetch ATC, last online ATC7. VERIFY PIN // INS 20 — offline PIN (plaintext or enc.)8. GENERATE AC // INS AE — produce ARQC / TC / AAC9. EXTERNAL AUTH // INS 82 — send ARPC back to card (issuer auth)10. GENERATE AC (2nd) // INS AE — produce TC (commit) or AAC (abort)
Contact protocolsT=0 (byte-oriented) and T=1 (block-oriented)
Vcc supply1.8V, 3V or 5V — negotiated at reset
ATRAnswer To Reset — first bytes card sends on power-up
ISO/IEC 14443 defines the contactless interface between a proximity card (PICC) and a reader (PCD) operating at 13.56 MHz. It covers the RF power and signal interface (Part 1–2), the anti-collision protocol for handling multiple cards in field (Part 3), and the transmission protocol (Part 4 — essentially APDU over the air). EMV contactless (payWave, PayPass) and NFC phone payments all use ISO 14443-4 as their transport layer.
Standard parts
14443-1Physical characteristics — card dimensions, operating field
14443-2RF power and signal interface — 13.56 MHz, Type A (ASK 100%) / Type B (ASK 10%)
14443-3Initialisation and anti-collision — handles multiple cards in field simultaneously
14443-4Transmission protocol — T=CL (block-based APDU transport over NFC)
Type A vs Type B
Type A
Modulation: ASK 100% (on/off keying). Used by: Visa payWave, Mastercard PayPass, most Amex contactless, NFC phones (Apple Pay, Google Pay). Anti-collision: bit-level (slot ALOHA). UID: 4, 7, or 10 bytes.
Type B
Modulation: ASK 10% (amplitude shift). Used by: some national debit schemes (French CB, German girocard), biometric passports (e-MRTD). Anti-collision: slot-based (ATQB/ATTRIB). PUPI: 4-byte identifier.
NFC contactless transaction flow
iso14443_contactless_flow.txt
Reader (PCD) ────────────────────────────── Card/Phone (PICC)1. RF field on (13.56 MHz)← ATQA/ATQB (card responds)2. Anti-collision loop← UID/PUPI3. SELECT (halt others)← SAK / ATS4. RATS (T=CL init)← ATS (ATR equivalent)── now in ISO 7816-4 APDU space ─────────────────────────────
SELECT AID (Visa/MC) ← FCI + PDOL
GET PROCESSING OPTS ← AIP + AFL
READ RECORD (×n) ← card data
COMPUTE CRYPTOGRAPHIC CHECKSUM ← AC (ARQC for online, TC for offline)Total RF time target: < 500ms (scheme mandate)Max field range: ~10cm (ISO 14443 spec)
Frequency13.56 MHz (unlicensed ISM band)
Data rate106, 212, 424 or 848 kbps
Operating rangeUp to 10 cm (scheme tap limit ~4 cm)
Transaction timeTarget < 500ms (Visa/MC mandate)
Card emulation (phones)HCE (Host Card Emulation) or SE (Secure Element)
Apple Pay / Google PayISO 14443-4 Type A + EMV contactless kernel
Max offline CVM limit£100 UK / €50 EU (contactless PIN above)
Relay attack riskMitigated by transaction time limit + cryptogram
How standards layer together
standards_stack.txt
┌─────────────────────────────────────────────────────┐
│ Scheme rules (Visa payWave / MC PayPass / Amex) │ business
├─────────────────────────────────────────────────────┤
│ EMV application (kernel — Books 1–4) │ payment app
├─────────────────────────────────────────────────────┤
│ ISO 7816-4 APDU commands / responses │ protocol
├─────────────────────────────────────────────────────┤
│ ISO 14443-4 T=CL transport (contactless) │ transport
│ ISO 7816-3 T=0 / T=1 (contact chip) │
├─────────────────────────────────────────────────────┤
│ ISO 14443-2/3 RF + anti-collision (NFC) │ physical RF
│ ISO 7816-1/2 Electrical contacts │ physical
├─────────────────────────────────────────────────────┤
│ ISO 7812 PAN / IIN numbering + Luhn checksum │ card identity
│ ISO 7813 Magnetic stripe encoding (Track 1 / 2) │ legacy channel
└─────────────────────────────────────────────────────┘
The technical differences between CP and CNP, how a contactless tap actually works end-to-end, fallback handling, POS entry modes, and what acquirer domain certification involves.
Card-present vs card-not-present
Why CP and CNP are different channels
Card-present (CP) means the physical card or device was used at a terminal — the chip, contactless, or magstripe was read directly. Card-not-present (CNP) covers e-commerce and MOTO where only the card number, expiry, and CVV2 are provided. The distinction affects fraud liability, interchange rates, authentication requirements, and which data fields appear in the ISO 8583 message.
Card-present (CP)
Auth methodEMV chip / contactless / magstripe
Fraud liabilityIssuer bears (EMV chip used)
InterchangeLower — regulated EU/UK rates apply
3DS requiredNo — not applicable for CP
CVV2 requiredNo — CVV1 on stripe / chip cryptogram used
Fraud liabilityMerchant bears (no 3DS) or issuer (3DS auth)
InterchangeHigher — CNP surcharge applies
3DS requiredYes — mandated under PSD2 SCA in EEA
CVV2 requiredYes — only verifiable credential available
Chargeback riskHigher — no physical evidence of cardholder
POS entry modes — ISO 8583 Field 22 / DE 22
What DE 22 tells the issuer
Field 22 (Data Element 22) in the ISO 8583 message tells the issuer exactly how the card data was captured and what PIN verification method was used. It is a 3-digit field: the first two digits describe the card read method, the third describes cardholder verification. Issuers use this to apply the correct fraud rules, interchange category, and liability assignment.
051ICC (chip) read, PIN verified online
052ICC read, PIN verified offline (plaintext)
053ICC read, PIN verified offline (enciphered)
054ICC read, offline PIN + signature
071Contactless — ICC data, no CVM (tap < CVM limit)
072Contactless — ICC data, PIN verified online
079Contactless — no CVM, mobile/device
021Magstripe read, PIN verified online
022Magstripe read, no PIN (signature)
801Fallback — chip failed, magstripe used
010Manual keyed entry — PAN typed at terminal
010 (CNP)E-commerce / MOTO — no physical card
81Network token (Apple Pay / Google Pay in-store)
Contactless transaction flow — tap to approval
What happens in under 500ms
A contactless tap runs the full EMV transaction sequence over ISO 14443 NFC — but compressed into a single RF field encounter. The terminal and card exchange APDUs in a fraction of a second. The scheme mandates the entire card-to-terminal interaction completes within 500ms. If the transaction is above the offline CVM limit, an online PIN is required and the tap takes slightly longer.
contactless_flow.txt
── RF field phase (ISO 14443) ──────────────────────────────1. Terminal activates 13.56 MHz RF field
2. Card responds: ATQA / ATQB (Type A or B)
3. Anti-collision + SELECT — card gets unique slot
4. RATS → ATS (T=CL initialised)
── EMV application phase (ISO 7816-4 APDUs over NFC) ───────5. SELECT PPSE → FCI with AID list
6. SELECT AID → FCI + PDOL
7. GET PROCESSING OPTS → AIP + AFL
8. READ RECORD (×n) → card data
9. COMPUTE CRYPTOGRAPHIC CHECKSUM → AC
── CVM decision ────────────────────────────────────────────
Amount ≤ CVM limit → No CVM (DE 22 = 071) → tap complete
Amount > CVM limit → Online PIN (DE 22 = 072) → PIN entry
── Authorisation (ISO 8583 over acquirer network) ───────────10. Terminal builds 0100 msg with Field 55 (EMV data)
11. Routes via acquirer → scheme → issuer
12. Issuer validates ARQC, checks risk rules
13. 0110 response → DE 39 = 00 → beep + green light
Total target time: <500ms card-to-terminal, <2s total
Offline CVM limits by market
UK£100 — raised from £45 in October 2021
EU (EEA)€50 standard — some markets set lower limits
AustraliaAUD 200
USANo federal limit — issuer-defined (typically $50–$200)
When a chip card falls back to magstripe (because the chip failed to read), the transaction loses EMV liability shift — the merchant bears the fraud liability. Fallback transactions are also subject to higher interchange and are flagged by scheme fraud monitoring. Excessive fallback rates attract scheme investigations.
fallback_scenarios.txt
── Scenario 1: Chip fail → magstripe fallback ───────────────
Card inserted → chip fails to initialise
→ Terminal retries chip (typically 3 attempts)
→ Terminal prompts to swipe
→ Track 2 data read from magstripe
→ DE 22 = 801 (fallback indicator)
→ Issuer sees fallback flag → may decline or apply
higher fraud scoring
→ Liability: merchant bears (no EMV cryptogram)
── Scenario 2: Offline authorisation ───────────────────────
Terminal has no network connectivity
→ Terminal checks offline floor limit vs amount
→ Amount ≤ floor limit: TC generated offline (approved)
→ Amount > floor limit: AAC generated (declined offline)
→ On reconnection: batch clearing sent with offline TCs
── Scenario 3: Contactless → insert fallback ────────────────
Contactless tap fails (card not responding to RF)
→ Terminal prompts to insert chip
→ Normal chip-and-PIN flow resumes
→ Not a fallback in the fraud sense — no extra risk
── Scenario 4: Technical fallback (no chip on card) ─────────
Old magstripe-only card (service code 101 → chip expected
but not present)
→ Issuer may decline or apply manual review
→ Increasingly rare as chip adoption approaches 100%
Field 25POS condition code — 00 normal, 01 card not present, 08 mail/phone order
Field 41Terminal ID — 8-char acquirer-assigned identifier for the physical terminal
Field 42Merchant ID — 15-char acquirer-assigned identifier for the merchant location
Field 43Merchant name/location — name, city, country used for cardholder statement
Field 55EMV TLV data — ARQC, ATC, TVR, IAD, AIP — mandatory for chip transactions
Field 60Additional POS info — terminal type, entry capability, chip condition code
Field 52PIN data block — encrypted offline or online PIN
Acquirer domain certification
What acquirer domain certification covers
L3 certification proves a terminal works end-to-end within a specific acquirer and scheme combination. Each acquirer runs their own test suite — a terminal certified for Acquirer A cannot automatically be deployed by Acquirer B without re-certification. Scheme mandates (e.g. a new contactless kernel version) can invalidate existing L3 certs and require re-certification of the entire estate.
Visa VCMS
Visa Chip and Contactless Merchant Service
Required for any terminal accepting Visa chip or contactless. Tests auth, cryptogram validation, fallback handling, and contactless kernel behaviour.
MC MPE
Mastercard Payment Enablement
Covers Mastercard and Maestro contactless. Tests M/Chip kernel, CVM limits, floor limit processing, and Mastercard PayPass contactless flow.
Amex AEIPS
American Express Integrated Circuit Processing Spec
Required to accept Amex chip cards. Tests AEIPS kernel, contactless ExpressPay flow, and batch close procedures.
PCI P2PE
Point-to-Point Encryption
Optional but reduces PCI scope dramatically. Terminal encrypts PAN at card entry — acquirer receives only encrypted blob. Requires validated P2PE solution listing.
SoftPOS / CPOC
Contactless Payments on COTS
EMVCo CPOC standard for software-only contactless acceptance on commercial off-the-shelf (COTS) devices (smartphones, tablets). No dedicated hardware reader required.
Re-cert triggers
When you need to re-certify
New scheme, new acquirer, contactless limit change (scheme mandate), firmware update touching payment path, or major kernel version bump. Typically 3–9 months per cert cycle.
Terminal Action Codes (TAC)
What TACs are and why they matter
Terminal Action Codes are three 5-byte bitmasks configured by the acquirer in the terminal application. They are consulted during EMV Terminal Action Analysis — the step where the terminal decides whether to approve offline, request online authorisation, or decline without going online. TACs work alongside the card's Issuer Action Codes (IAC), which carry the issuer's equivalent policy. A misconfigured TAC is one of the most common causes of EMV certification failures and unexpected decline rates in production.
The three TAC types
TAC-Denial
Decline offline — do not go online
If any TVR bit set matches TAC-Denial, the terminal declines the transaction offline immediately — it does not attempt an online authorisation. Used for conditions so severe that even the issuer should not be consulted: e.g. card blocked, expired, or PIN tries exhausted. Example Visa default: FC50A8 0000
TAC-Online
Request online authorisation
If any TVR bit matches TAC-Online (and TAC-Denial didn't fire), the terminal sends an online authorisation request (ARQC). The issuer then makes the final approval/decline decision. Most transactions with any risk flags hit this path. Example Visa default: FC50A8 0000
TAC-Default
Offline fallback — no network available
Used only when the terminal cannot reach the network. If any TVR bit matches TAC-Default, the terminal declines offline. If no bits match, it approves offline (TC). Acquirers typically set this conservatively to decline most transactions offline when the network is unavailable. Example Visa default: FC50A8 0000
How TAC, IAC, and TVR interact
terminal_action_analysis.pseudo
// Terminal Action Analysis (EMVCo Book 3, Section 10.6)// Runs AFTER cardholder verification, BEFORE Generate AC// 1. Build combined action codes (OR of TAC + IAC)
denial_mask = TAC_Denial | IAC_Denial // acquirer | issuer
online_mask = TAC_Online | IAC_Online
default_mask = TAC_Default | IAC_Default
// 2. Read TVR — 5-byte bitmask set during card processing// Each bit = a specific condition that was flagged
tvr = get_TVR() // e.g. 0x0400000000 = offline PIN failed// 3. Apply decision logic (in strict order)if (tvr & denial_mask) != 0:
generate_AAC() // decline offline — do NOT go onlinereturnif terminal_can_go_online:
if (tvr & online_mask) != 0:
generate_ARQC() // request online authelse:
generate_TC() // approve offline — no risk flagselse:
// Terminal offline — use default pathif (tvr & default_mask) != 0:
generate_AAC() // decline offlineelse:
generate_TC() // approve offline
TVR — Terminal Verification Results
What the TVR encodes
The TVR is a 5-byte (40-bit) bitmask populated by the terminal throughout the transaction. Each bit represents a specific condition — whether the card was blacklisted, whether offline PIN failed, whether the amount exceeds the floor limit, and so on. The TAC/IAC masks are ANDed against the TVR to make the terminal action decision. TAC values are expressed as hex bitmasks matching the TVR bit positions.
Byte 1 bit 8Offline data authentication not performed
Byte 1 bit 7SDA failed
Byte 1 bit 6ICC data missing
Byte 1 bit 5Card on terminal exception file
Byte 1 bit 4DDA failed
Byte 1 bit 3CDA failed
Byte 2 bit 8ICC and terminal different app versions
Byte 2 bit 7Expired application
Byte 2 bit 6Application not yet effective
Byte 2 bit 5Requested service not allowed for card product
Byte 2 bit 4New card
Byte 3 bit 8Cardholder verification not successful
Byte 3 bit 7Unrecognised CVM
Byte 3 bit 6PIN try limit exceeded
Byte 3 bit 5PIN entry required but PIN pad not present
Byte 3 bit 4PIN entry required, PIN pad present, PIN not entered
Byte 3 bit 3Online PIN entered
Byte 4 bit 8Transaction exceeds floor limit
Byte 4 bit 7Lower consecutive offline limit exceeded
Byte 4 bit 6Upper consecutive offline limit exceeded
Byte 4 bit 5Transaction selected randomly for online processing
Byte 4 bit 4Merchant forced transaction online
Byte 5 bit 8Default TDOL used
Byte 5 bit 7Issuer authentication failed
Byte 5 bit 6Script processing failed before Final GENERATE AC
Byte 5 bit 5Script processing failed after Final GENERATE AC
Common TAC configurations by acquirer policy
typical_tac_values.txt
// TAC values are 5 bytes expressed in hex// Each bit position corresponds to a TVR bit── Conservative (online-first) acquirer ─────────────────────
TAC-Denial: FC 50 A8 00 00// Deny: severe auth failures
TAC-Online: FC 50 A8 00 00// Online: same — almost everything
TAC-Default: FC 50 A8 00 00// Default: decline offline if in doubt→ Result: most transactions go online; very few approved offline── Offline-capable acquirer (e.g. transit) ───────────────────
TAC-Denial: FC 50 A8 00 00// Hard failures still deny
TAC-Online: 00 00 00 00 00// Nothing forces online
TAC-Default: 00 00 00 00 00// Nothing forces offline decline→ Result: most low-value transactions approved offline (TC) Used in transit/vending where network unreliable── Visa recommended defaults ─────────────────────────────────
TAC-Denial: FC 50 A8 00 00
TAC-Online: FC 50 A8 00 00
TAC-Default: FC 50 A8 00 00// FC 50 A8 = 1111 1100 | 0101 0000 | 1010 1000// Key bits set: offline data auth not performed,// SDA/DDA failed, ICC missing, card on exception file,// expired app, CVM failure, PIN tries exceeded
TAC / IAC precedence and common pitfalls
TAC vs IAC precedence
Acquirer can only tighten, not loosen
The TAC and IAC are ORed together — a bit set in either one triggers the corresponding action. The acquirer's TAC cannot override the issuer's IAC to allow a transaction the issuer wants to deny. The acquirer can add more conditions for going online, but cannot remove the issuer's.
All-zero TAC-Online
Dangerous in high-fraud environments
Setting TAC-Online to 00 00 00 00 00 means no TAC condition forces an online request. If the IAC-Online is also permissive, the terminal approves offline even for risky conditions. Only appropriate for genuinely offline environments like transit.
TAC-Denial fires first
Online mask irrelevant if denial fires
TAC-Denial is checked before TAC-Online. If a TVR bit matches TAC-Denial, the terminal generates an AAC and the transaction is done — no online request is sent. This is intentional: certain failures (e.g. card on exception file) should never result in an online auth attempt.
Certification failure pattern
Most common EMV L3 TAC failures
Failing to generate AAC when TVR bit matches TAC-Denial, approving offline when TAC-Default should decline, and applying the wrong TAC in the wrong terminal mode (attended vs unattended). All are caught during L3 scheme test case execution.
How Visa and Mastercard handle disputed transactions — the full lifecycle from first notification to arbitration, reason code taxonomy, time limits, compelling evidence rules, and merchant monitoring programmes.
How disputes work
Visa calls them disputes — Mastercard calls them chargebacks
Visa officially retired the term "chargeback" and now refers to all reversals as "disputes." Mastercard still uses "chargeback" in its documentation. The underlying process is functionally identical: a cardholder contacts their issuing bank to contest a transaction, the issuer raises the dispute with the acquirer via the scheme network, the acquirer notifies the merchant, and the disputed funds are provisionally reversed pending resolution. The main interaction in every case is between issuer and acquirer — the merchant operates through their acquirer and is never a direct party to the scheme dispute process.
Visa terminologyDispute — all reversals are called disputes since 2018
Mastercard terminologyChargeback — term still used in official MC documentation
Merchant's roleProvides evidence to acquirer — no direct scheme access
Funds during disputeDebited from merchant account immediately on chargeback filing
Dispute lifecycle & time limits
Miss a deadline and you lose the right to respond — regardless of merit
Every stage of the dispute process has a strict time limit. Missing any deadline forfeits the right to challenge at that stage. Mastercard's response window for acquirers is 45 calendar days from chargeback initiation. Visa's collaboration workflow allows 30 calendar days; the allocation workflow allows 30 days for pre-arbitration. These are scheme-level deadlines — merchants typically receive roughly half that time from their acquirer or PSP to submit evidence, to allow the acquirer processing time.
Visa dispute lifecycle
Cardholder
files dispute
T+0
Issuer
raises dispute
funds debited
Acquirer
notifies merchant
≤30 days
Response
or accept
if escalated
Arbitration
Visa decides
Mastercard chargeback lifecycle
Cardholder
disputes txn
NoC
Issuer
chargeback filed
funds debited
Acquirer
≤45 days to respond
if rejected
Pre-arbitration
issuer escalates
if unresolved
Arbitration
MC decides
Visa — cardholder filing window120 calendar days from transaction date (most codes)
Visa — acquirer response (collaboration)30 calendar days from dispute initiation
Visa — acquirer response (allocation)30 calendar days for pre-arbitration
MC — cardholder filing window90–120 days (up to 540 days for non-receipt/not-as-described)
MC — acquirer response45 calendar days from chargeback initiation
MC — pre-arbitration45 days from defense upload date (Information Supplied date)
Arbitration filing fee$500 (Visa) / $250–$500 (MC) — loser pays
MC — RFI stageRemoved October 2021 — process now starts at NoC
VISA
Dispute framework
Source: Visa Dispute Management Guidelines, June 2024
Visa reason code taxonomy
Visa organises all dispute reason codes into four categories, each with a two-digit prefix. Fraud disputes (10.x) and authorisation disputes (11.x) follow the Allocation workflow — liability is assigned automatically. Processing errors (12.x) and consumer disputes (13.x) follow the Collaboration workflow — both parties present evidence before liability is determined.
Allocation workflow — Fraud & Authorisation
Category 10 — Fraud
Allocation — auto liability shift
10.1 EMV counterfeit — chip card used at non-chip terminal
10.2 EMV lost/stolen — chip card, PIN not required
10.3 Other fraud — card-present environment
10.4 Other fraud — card-absent (CNP) — most common
10.5 Visa Fraud Monitoring Programme
Category 11 — Authorisation
Allocation — auto liability shift
11.1 Card recovery bulletin — account on hotlist
11.2 Declined authorisation — txn processed after decline
11.3 No authorisation — includes late presentment (merged from 12.1, 2024)
Visa workflows — Allocation (10.x, 11.x): Visa assigns liability automatically based on rule compliance — limited merchant recourse. Use CE 3.0 for 10.4 friendly fraud.
Collaboration (12.x, 13.x): Both parties present evidence. Acquirer has 30 days to respond. Issuer can escalate to pre-arbitration before Visa decides.
MC
Chargeback framework
Source: Mastercard Chargeback Guide, May 2025
Mastercard reason code taxonomy
Mastercard uses four-digit codes in the 4800-series. Codes 4808, 4870, and 4871 go directly to arbitration if escalated — no pre-arbitration stage. The process starts at Notification of Chargeback (NoC) — the prior RFI stage was removed in October 2021. Codes 4855 and 4860 are being merged into 4853. Acquirer response window: 45 calendar days from NoC.
Fraud codes — direct to arbitration if escalated
Fraud
4863 — Cardholder does not recognise
Most common MC fraud code. Cardholder claims not to have authorised or participated in the transaction. Covers CNP fraud, lost/stolen, and family fraud. Defend with 3DS SecureCode, CVC2, AVS, and device fingerprint data.
Fraud — liability shift
4870 / 4871 — Chip liability shift
4870: Chip card used at non-chip terminal — merchant bears liability. 4871: Chip card, PIN not verified at terminal. Both skip pre-arbitration and go directly to MC arbitration if escalated.
Authorisation — direct to arbitration if escalated
Authorisation
4808 — Expired chargeback protection period
Transaction presented more than 7 days after authorisation (30 days for pre-auth). Also covers declined-then-forced transactions. Goes directly to arbitration if escalated — no pre-arbitration. Acquirer response: 45 days.
Point-of-interaction errors
POI errors
4834 — Consolidated POI error code
Consolidates prior ATM, amount error, and transaction processing codes. Covers incorrect amount, duplicate processing, DCC disputes, and loss/theft damage charges. Issuer includes Member Message Text specifying the exact sub-type.
Cardholder disputes — pre-arbitration applies
Cardholder disputes
4853 — Cardholder dispute (primary code)
Main consumer dispute code — covers not received, not as described, cancelled recurring, credit not processed, counterfeit merchandise. Codes 4855 and 4860 are being merged into this code. 540-day maximum filing window for non-receipt / not as described.
Cardholder disputes
4841 — Cancelled recurring / digital goods
Cardholder cancelled a recurring transaction or disputes a digital goods charge. 120-day filing window. Defend with recurring agreement, cancellation policy, and proof of prior undisputed transactions.
MC lifecycle —
NoC issued → acquirer has 45 days to respond → issuer reviews and accepts or files pre-arbitration → if unresolved, case goes to MC arbitration ($250–500 fee, loser pays). Codes 4808, 4870, 4871 skip pre-arbitration entirely.
Compelling evidence — what wins a dispute
Visa Compelling Evidence 3.0 (CE 3.0) — introduced 2023
CE 3.0 is Visa's framework for countering first-party (friendly) fraud on code 10.4. To qualify, the merchant must demonstrate at least two prior undisputed transactions from the same cardholder, between 120 and 365 days before the disputed transaction, sharing at least two matching data points with the disputed transaction. If the CE 3.0 threshold is met, liability is automatically shifted back to the issuer — the acquirer does not need to go through the full collaboration cycle.
CE 3.0 prior txn window120–365 days before disputed transaction
CE 3.0 minimum prior txns2 undisputed transactions required
CE 3.0 matching data points≥2 of: device ID, IP address, shipping address, phone number, fingerprint
CE 3.0 outcomeAuto liability shift to issuer — dispute closed in merchant's favour
Evidence formatLegible scan, English or with translation, submitted through acquirer
MC — prior txn evidenceRegistered device + IP address from prior undisputed transactions
Key ruleEvidence must be submitted at first response — no opportunity to update later
Visa: Allocation vs Collaboration workflows
Allocation — Fraud & Auth (10.x, 11.x)
Visa automatically assigns liability to the party deemed responsible based on the facts. The merchant has limited ability to contest — primarily through CE 3.0 for 10.4 disputes. If the merchant did not use chip + PIN when available, liability shifts automatically. No negotiation — Visa decides based on technical evidence of who complied with the rules.
Collaboration — Errors & Disputes (12.x, 13.x)
Both parties have the opportunity to present evidence before liability is determined. The acquirer submits a dispute response (representment) within 30 days. The issuer can then accept or escalate to pre-arbitration. Only after pre-arbitration fails does the case go to Visa arbitration. Merchants have more ability to win here with strong evidence.
Merchant monitoring programmes
Monitoring programmes can result in losing the ability to accept card payments
Both Visa and Mastercard operate merchant monitoring programmes that track chargeback-to-transaction ratios. Breaching programme thresholds results in escalating monthly fines and ultimately the ability to accept scheme payments being revoked. Merchants do not enroll voluntarily — they are placed in programmes when thresholds are breached.
VDMP
Visa Dispute Monitoring Programme
Monitors chargeback ratio across all categories. Early warning: 0.65% ratio and 75+ disputes/month. Standard: 0.9% and 100+/month. Excessive: 1.8% and 1,000+/month. Exit: ratio below threshold for 3 consecutive months. Fines apply at standard and excessive levels.
VFMP
Visa Fraud Monitoring Programme
Monitors fraud-related disputes (10.x codes) specifically. Early warning threshold applies before standard enrolment. Visa also introduced an Issuer Excessive Dispute Fee in the US — issuers face a $5 fee per dispute above thresholds when their dispute-to-sales ratio exceeds 150% of regional average.
MC ECP
Mastercard Excessive Chargeback Programme
Enrolled when merchant reaches 100–299 chargebacks in a calendar month or a 1.5% chargeback-to-transaction ratio. High ECP: 300+ chargebacks or 3.0%+ ratio. Monthly fines escalate progressively. Merchants can exit when ratio falls below thresholds for the required consecutive months.
QMAP
MC Questionable Merchant Audit Programme
Monitors for rule violations beyond chargeback ratios. Merchants listed on the Global Security Bulletin have violated QMAP rules. Transactions processed after listing result in reason code 4853 with a specific QMAP modifier. Requires immediate corrective action.
Dispute prevention checklist
01
Use 3DS2 authentication on all CNP transactions — successful auth shifts 10.4 liability to the issuer and eliminates the most common fraud chargeback
02
Use chip + PIN at CP terminals — any fallback to magstripe auto-shifts liability for 10.1 / 4870 to the merchant
03
Submit transactions within 7 days of authorisation (MC) to avoid code 4808 — late presentment is an entirely preventable chargeback
04
Use a clear, recognisable billing descriptor — a large proportion of "cardholder does not recognise" disputes are caused by an unrecognisable merchant name on the statement
05
Log device ID, IP address, and session data at checkout — these are the CE 3.0 matching data points needed to counter friendly fraud on code 10.4
06
Send cancellation confirmation emails with a reference number — essential evidence for 13.2 / 4841 cancelled recurring disputes
07
Obtain proof of delivery with signature for high-value physical goods — required to win 13.1 / 4853 not-received disputes
08
Monitor your chargeback ratio weekly — both Visa and Mastercard send early warnings before programme enrolment; acting on the warning avoids fines
09
Respond to every dispute — even disputes you cannot win should be responded to, since non-response counts against you in programme monitoring thresholds
Sources —
Visa: Dispute Management Guidelines for Visa Merchants, June 2024 (public PDF). Reason code structure and CE 3.0 rules sourced from Visa Core Rules and Visa Product and Service Rules, October 2025 (public). · Mastercard: Chargeback Guide (Merchant Edition), May 2025 (public PDF). Lifecycle and reason code details corroborated against Adyen technical documentation. · Programme thresholds are current as of early 2025 — schemes update these periodically; always verify against current scheme bulletins.
Glossary
Payment terminology
Essential terms for card payment integrations.
ARQC
Authorisation Request Cryptogram — 8-byte MAC generated by the EMV chip per transaction. Proves card presence; replay attacks fail on ARPC mismatch.
Acquirer
The bank holding the merchant's account, routing transactions to the card network on the merchant's behalf. Also called the merchant bank or PSP.
ACS
Access Control Server — the issuer's server that evaluates 3DS2 authentication requests and decides frictionless approval or challenge.
CDE
Cardholder Data Environment — any system that stores, processes, or transmits PAN or SAD. Minimising CDE scope reduces PCI compliance burden.
Chargeback
A dispute where the cardholder reverses a transaction through their issuer. Results in fee plus fund reversal. 3DS2 authentication shifts liability to the issuer.
CNP
Card Not Present — e-commerce and MOTO transactions. Higher fraud risk, higher interchange, requires 3DS2 under PSD2 in the EEA.
EMV
Europay–Mastercard–Visa chip standard. Defines the chip protocol including dynamic cryptogram generation, terminal risk management, and offline PIN verification.
Interchange
Fee paid by the acquirer to the issuer per transaction. Regulated at 0.2% debit / 0.3% credit in the EU and UK. Varies widely outside regulated regions.
ISO 8583
International standard for financial transaction messages. Defines message types (0100 auth, 0110 response, 0400 reversal) and data elements in fields 1–128.
Issuer
The bank that issued the card to the cardholder. Responsible for authorisation decisions, fraud scoring, and posting transactions to the cardholder's account.
MDR
Merchant Discount Rate — the total percentage fee charged by the acquirer to the merchant. Comprises interchange, scheme fees, and acquirer margin.
PAN
Primary Account Number — the 16-digit card number. Never log or store in plain text. PCI DSS scope is primarily defined by PAN presence in a system.
PCI DSS
Payment Card Industry Data Security Standard — 12 technical and operational requirements for any entity storing, processing, or transmitting cardholder data.
QSA
Qualified Security Assessor — PCI Council-certified auditor. Required for Level 1 merchants (6M+ Visa txns/yr) to conduct on-site ROC assessments.
RBA
Risk-Based Authentication — using transaction signals (device, geo, velocity, behaviour) to decide whether to approve frictionlessly or step up to a challenge.
SAD
Sensitive Authentication Data — full track data, CVV2/CVC2, PIN block. Must never be stored post-authorisation, even in encrypted form.
STAN
Systems Trace Audit Number — a 6-digit number assigned per transaction to match auth to capture and aid dispute resolution.
3DS2
3-D Secure v2 — issuer authentication for CNP. Passes up to 150 data elements to the ACS. Frictionless when risk is low; OTP or biometric challenge otherwise.
EMV Level 1
Terminal certification testing the physical and electrical interface between the terminal and the ICC. Covers ISO 7816-3 signal integrity, power tolerances, and contactless RF (ISO 14443). Conducted by an EMVCo-accredited lab.
EMV Level 2
Terminal certification testing the EMV payment application kernel — application selection, card authentication (SDA/DDA/CDA), cardholder verification method (CVM), and terminal risk management. Required separately for each kernel type (contact, contactless, per scheme).
EMV Level 3
End-to-end certification testing the full transaction path from terminal through acquirer host to the card scheme. Validates ISO 8583 message construction, Field 55 EMV data, and scheme-specific rules. Must be repeated per acquirer and per scheme. Typically takes 3–9 months.
PCI PTS
PIN Transaction Security — PCI SSC programme testing the physical tamper-resistance of PIN entry devices. Required for any terminal accepting PIN. Separate from EMV certification. Approval lasts 5 years from date of listing.
SoftPOS / CPOC
Contactless Payments on COTS — PCI SSC programme allowing a commercial smartphone to act as a POS terminal. Requires CPOC programme approval plus scheme-specific L2/L3 kernel certification for the payment software.
ISO/IEC 7812
Standard defining the structure of the Primary Account Number (PAN) and the Issuer Identification Number (IIN / BIN). Specifies the Major Industry Identifier (MII), BIN length (6 or 8 digits), and mandates the Luhn (Mod 10) checksum on all PANs.
ISO/IEC 7813
Standard defining the magnetic stripe data encoding on payment cards. Specifies Track 1 (IATA, 210 bpi, alphanumeric) and Track 2 (ABA, 75 bpi, numeric) formats including PAN, expiry, service code, and CVV1. Track data is SAD and must never be stored post-auth.
ISO/IEC 7816
Multi-part standard covering contact chip (ICC) cards. Parts 1–2 define physical dimensions and contact positions. Part 3 defines T=0/T=1 electrical protocols. Part 4 defines the APDU command/response structure used by EMV. EMV builds directly on 7816-3 and 7816-4.
ISO/IEC 14443
Standard defining the contactless card (PICC) and reader (PCD) interface at 13.56 MHz. Part 2 covers RF modulation (Type A: ASK 100%, Type B: ASK 10%). Part 3 defines anti-collision. Part 4 defines the T=CL block transmission protocol used by all EMV contactless and NFC phone payments.
APDU
Application Protocol Data Unit — the command/response message format defined in ISO 7816-4. Commands carry CLA, INS, P1, P2, Lc (data length), Data, and Le (expected response length). Responses carry Data plus a 2-byte status word (e.g. 9000 = success, 6A82 = file not found).
AID
Application Identifier — a 5–16 byte value registered under ISO 7816-5 that uniquely identifies a payment application on a chip card. Visa Credit uses A0000000031010; Mastercard uses A0000000041010. Terminals use the AID list to perform application selection.
Track 2
The numeric-only magnetic stripe track defined in ISO 7813. Contains PAN, expiry date, service code, and CVV1. Used by EMV terminals for fallback transactions when chip processing fails. Storing Track 2 post-authorisation is a PCI DSS violation.
DPAN
Device PAN — the token value provisioned to a digital wallet. Looks like a valid card number (passes Luhn, same BIN range) but maps to the real PAN only inside the Token Service Provider's vault. Used in contactless and in-app payments in place of the FPAN.
FPAN
Funding PAN — the real card number issued to the cardholder. Never exposed to the merchant in a tokenised payment. The TSP maps the DPAN back to the FPAN internally before passing the authorisation to the issuer.
TAVV
Token Authentication Verification Value — a dynamic cryptogram generated per transaction by the wallet using a limited-use key (LUK). Proves that the payment came from the legitimate device holding the token. Replaces the static CVV1 in tokenised transactions.
TSP
Token Service Provider — the entity that creates, manages, and vaults tokens. Visa Token Service (VTS) and Mastercard Digital Enablement Service (MDES) are the two main TSPs. They orchestrate provisioning, manage token lifecycle, and handle DPAN-to-FPAN mapping.
VTS
Visa Token Service — Visa's Token Service Provider. Issues and manages DPANs for Visa cards provisioned to Apple Pay, Google Pay, and other wallets. Communicates with issuers via a set of web service APIs (CheckEligibility, SubmitLifecycleCommand, TokenInquiry, etc.).
MDES
Mastercard Digital Enablement Service — Mastercard's equivalent of Visa VTS. Provides the same token provisioning and lifecycle management functions for Mastercard-branded cards in digital wallets.
HCE
Host Card Emulation — a software approach to NFC payments where the device OS emulates a contactless card without requiring a physical Secure Element. Used by Google Pay on Android. Limited-use keys are stored in the Trusted Execution Environment and replenished from the cloud.
LUK
Limited-Use Key — a session key provisioned to the wallet device and used to generate TAVV cryptograms for a finite number of transactions. Once a LUK is exhausted, the wallet replenishes it from the TSP cloud service. Prevents replay attacks even if a key is extracted.
STIP
Stand-In Processing — when an issuer's system is unavailable, Visa or Mastercard's systems approve or decline transactions on the issuer's behalf using pre-configured rules. Also applies during token provisioning — if the issuer doesn't respond to eligibility checks in time, the TSP makes the decision.
AReq / ARes
Authentication Request and Response — the core 3DS2 messages. The AReq carries up to 150 data fields from the merchant's 3DS Server to the issuer's ACS via the Directory Server. The ARes carries the authentication decision (Y/A/C/R/U/N) back.
CAVV
Cardholder Authentication Verification Value — Visa's cryptographic proof that 3DS authentication took place. Passed in ISO 8583 Field 126 alongside the ECI at authorisation time. Required to obtain liability shift. Mastercard equivalent is AAV.
ECI
Electronic Commerce Indicator — a 2-digit code passed in the authorisation request indicating the authentication outcome. Visa: 05 = fully authenticated (liability shift), 06 = attempted, 07 = not authenticated. Mastercard: 02, 01, 00 respectively.
Decoupled auth
A 3DS 2.2+ authentication mode where the cardholder authenticates through a separate channel (banking app, email) independently of the checkout session. The merchant sets a maximum wait time — up to 30 minutes in 2.2, up to 7 days in 2.3.
3RI
3DS Requestor Initiated — a 3DS2 flow for merchant-initiated transactions where the cardholder is not present. References a prior customer-initiated authentication. Used for recurring payments, instalments, and unscheduled credential-on-file charges.
TRA
Transaction Risk Analysis — a PSD2 SCA exemption allowing issuers or acquirers to skip authentication for low-risk transactions, provided their fraud rate stays below defined thresholds (0.13% for ≤€100, 0.06% for ≤€250, 0.01% for ≤€500).
SPC
Secure Payment Confirmation — a W3C browser API that uses FIDO2/WebAuthn to authenticate cardholders via a native OS biometric prompt instead of an HTML challenge iframe. Integrated into 3DS 2.3. Supported in Chrome and Edge from 2024.
Card-present (CP)
A transaction where the physical card or payment device is used at a terminal — the chip, contactless interface, or magnetic stripe is read directly. Carries lower fraud risk, lower interchange, and EMV liability shift (chip) compared to CNP.
DE 22 / Field 22
ISO 8583 Data Element 22 — POS Entry Mode. A 3-digit field indicating how the card data was captured (chip, contactless, magstripe, keyed) and which cardholder verification method was used (online PIN, offline PIN, no CVM). Used by issuers to apply fraud rules and interchange categories.
Fallback
When a chip card falls back to magstripe because the chip failed to read. Indicated by DE 22 = 801. The transaction loses EMV liability shift — the merchant bears fraud liability. Excessive fallback rates attract scheme fraud monitoring investigations.
Offline CVM limit
The transaction amount below which a contactless payment requires no cardholder verification (no PIN, no signature). Above the limit, online PIN is required. Limits vary by market: £100 (UK), €50 (EU). Mobile wallet payments bypass the limit via device biometric.
Acquirer domain cert
The certification process by which an acquirer host system is validated by a card scheme (Visa VCMS or Mastercard MPE) to correctly construct, route, and handle ISO 8583 messages. Required before processing live transactions. Distinct from EMV terminal certification and PCI DSS.
Floor limit
The maximum transaction amount an EMV terminal can approve offline without seeking online authorisation. Configured by the acquirer and scheme. Amounts above the floor limit require an online auth request. Contactless transactions typically have a floor limit of £0 — all taps go online.
TC / AAC / ARQC
The three types of Application Cryptogram generated by an EMV chip. ARQC (Authorisation Request Cryptogram) = card requests online auth. TC (Transaction Certificate) = card approves offline. AAC (Application Authentication Cryptogram) = card declines offline. All are 8-byte 3DES MACs.
TAC
Terminal Action Code — one of three 5-byte bitmasks (TAC-Denial, TAC-Online, TAC-Default) configured by the acquirer in the terminal. During Terminal Action Analysis, TACs are ORed with the card's IACs and ANDed against the TVR to decide whether to decline offline, request online auth, or approve offline.
IAC
Issuer Action Code — the card's equivalent of the TAC, stored in the card's application data. Three variants: IAC-Denial, IAC-Online, IAC-Default. ORed with the acquirer's TAC during Terminal Action Analysis. The issuer uses IACs to enforce their own risk policy regardless of what the acquirer configures.
TVR
Terminal Verification Results — a 5-byte bitmask populated by the terminal throughout the EMV transaction. Each bit represents a condition flagged during processing (e.g. offline data auth not performed, PIN tries exceeded, card on exception file). The TVR is ANDed against TAC/IAC masks during Terminal Action Analysis to determine the transaction outcome. Also sent to the issuer in Field 55.
AIP
Application Interchange Profile — a 2-byte field returned by the card in response to GET PROCESSING OPTIONS. Indicates which EMV capabilities the card supports: SDA, DDA, CDA, cardholder verification, terminal risk management, and issuer authentication.
Chargeback / Dispute
A reversal of a card transaction initiated by the cardholder's issuing bank. Visa officially calls these "disputes"; Mastercard still uses "chargeback." Funds are debited from the merchant account immediately on filing. The merchant responds through their acquirer — there is no direct merchant access to scheme dispute systems.
Representment
The process by which a merchant (via their acquirer) contests a chargeback by resubmitting the transaction along with compelling evidence. Also called a dispute response in Visa's terminology. Must be submitted within scheme time limits — typically 30 days (Visa) or 45 days (MC) from chargeback initiation.
Compelling Evidence 3.0
Visa's framework for countering first-party (friendly) fraud on code 10.4. Requires two prior undisputed transactions from the same cardholder (120–365 days prior) sharing at least two matching data points (device ID, IP, shipping address, phone, fingerprint). Meeting the threshold automatically shifts liability to the issuer.
Allocation workflow
Visa's dispute processing path for fraud (10.x) and authorisation (11.x) reason codes. Visa automatically assigns liability to the party responsible based on whether scheme rules were followed — primarily whether chip was used and 3DS authentication was performed. Limited merchant recourse.
Collaboration workflow
Visa's dispute processing path for processing errors (12.x) and consumer disputes (13.x). Both parties have the opportunity to present evidence before liability is determined. The acquirer submits a response within 30 days; the issuer can escalate to pre-arbitration.
NoC
Notification of Chargeback — Mastercard's first formal notification to the acquirer that a chargeback has been initiated. The RFI (Request for Information) stage was removed in October 2021; the process now starts directly at NoC. The acquirer has 45 days from NoC to respond.
Pre-arbitration
The escalation stage before formal scheme arbitration. If the issuer rejects the acquirer's dispute response, they can file a pre-arbitration case. For Mastercard, this applies to all reason codes except 4808, 4870, and 4871 — these go directly to arbitration. Visa equivalent: the pre-arbitration stage within the collaboration workflow.
VDMP / VFMP
Visa Dispute Monitoring Programme and Visa Fraud Monitoring Programme — the two scheme programmes that monitor merchant chargeback and fraud ratios. Breaching thresholds results in enrolment, escalating monthly fines, and ultimately loss of scheme acceptance rights. Early warning thresholds exist before formal enrolment.
Friendly fraud
When a cardholder disputes a legitimate transaction — either intentionally (to obtain goods for free) or unintentionally (failing to recognise the charge). Estimated by Visa to account for roughly 75% of all disputes. Visa CE 3.0 is specifically designed to counter friendly fraud on CNP transactions.
History
Evolution of card payments
Key milestones from charge plates to contactless and open banking.
50s
1950
Diners Club — first charge card
Paper-based, settled monthly. Frank McNamara's idea of one card accepted at multiple restaurants.
60s
1966
BankAmericard → Visa network
Bank of America licenses nationally. Interbank Card Association becomes Visa in 1976.
70s
1979
ISO 7813 magnetic stripe standard
Standardised Track 1/2/3 format, enabling interoperable terminal reads worldwide.
90s
1996
EMV specification published
Europay, Mastercard, Visa release the joint spec. Chip-and-PIN deployments begin in France and UK.
00s
2001
3-D Secure v1 (Verified by Visa)
First issuer authentication protocol for e-commerce. Widely criticised for redirect UX; superseded by 3DS2 in 2016.
00s
2004
PCI DSS v1.0 published
Card networks form PCI SSC. Merchants mandated to meet 12 requirements for cardholder data handling.
00s
2007
Contactless (ISO 14443 / NFC)
MasterCard PayPass and Visa payWave launch. UK limit started at £10, raised to £100 in 2021.
10s
2014
Apple Pay & network tokens
Device-bound DPAN tokens replace PAN in digital wallets. TRID framework established by schemes.
10s
2016
3DS2 & PSD2 SCA mandate
EMVCo releases 3DS2. EU PSD2 mandates Strong Customer Authentication for CNP — friction vs conversion war begins.
20s
2022
PCI DSS v4.0
Customised implementation approach introduced. New requirements for e-skimming (Magecart) defence. Full enforcement March 2025.
20s
2023+
Open Banking & A2A payments
PSD2 APIs enable VRP and Pay-by-Bank, bypassing card rails. Threatens debit card volume across Europe.
Developer Tools
Interactive utilities
Handy tools for card payment development and testing.
!
Test data only — not real card numbers
All PANs shown on this page are published test values from public payment gateway documentation (Stripe, Adyen, PayPal). They are structurally valid — they pass the Luhn checksum — but they are not associated with any real cardholder account, bank, or financial institution. They exist solely for developer testing. Never use real card numbers in any tool, log, or test environment.
Luhn / Mod 10 Checker
What is the Luhn algorithm?
The Luhn algorithm (ISO/IEC 7812) is a simple checksum formula used to validate card numbers (PANs). It catches single-digit errors and most transpositions. It does not prove a card exists or is active — only that the number is structurally valid.
Enter a card number above to validate
Quick test — click to load
Published test PANs — not real
Visa
4532 0151 1283 0366
Valid — passes Luhn
Mastercard
5425 2334 3010 9903
Valid — passes Luhn
Amex
3742 510187 20955
Valid — 15 digits
Invalid
4532 0151 1283 0367
Fails Luhn — wrong check digit
How the algorithm works
luhn.py
defluhn_check(card_number: str) -> bool:
digits = [int(d) for d in card_number if d.isdigit()]
# Step 1: reverse the digits
digits = digits[::-1]
total = 0for i, d inenumerate(digits):
if i % 2 == 1: # Step 2: double every second digit
d *= 2if d > 9: d -= 9# Step 3: subtract 9 if > 9
total += d
return total % 10 == 0# Step 4: valid if sum mod 10 = 0# Generate a valid check digit for a partial PANdefluhn_generate(partial: str) -> int:
digits = [int(d) for d in partial if d.isdigit()] + [0]
digits = digits[::-1]
total = sum(
d * 2 - 9if (d * 2 > 9and i % 2 == 0) else
d * 2if i % 2 == 0else d
for i, d inenumerate(digits)
)
return (10 - total % 10) % 10
Payment flow simulator
What this simulates
Enter card details and click Pay. The simulator checks the PAN with Luhn, validates expiry and CVV format, then replays realistic issuer logic — picking a decline reason based on the specific card number you enter. Use the quick-fill buttons to trigger specific DE 39 response codes. All numbers are test-only.
ISO 8583 response codes, merchant category codes, ISO 3166 country codes, and ISO 4217 currency codes — the lookup tables every payment integration needs close to hand.
ApprovedHard decline — never retrySoft decline — retry after delayReferral — call issuerSystem / processing
Code
Description
Category
Retry?
Source —
Numeric codes 00–96 sourced from ISO 8583-1:1987 Field 39. Alpha codes (N0, N7, R0, R1, R3, P-series, Q1) are Visa/MC extensions. Retry guidance is editorial based on Visa Retry Rules and MC Transaction Processing Rules.
Merchant Category Codes (MCC)
What MCCs are used for
A Merchant Category Code is a 4-digit ISO 18245 code assigned by the acquirer when a merchant account is created. MCCs affect interchange rates, card reward categories, purchase restrictions on commercial and prepaid cards, and appear in ISO 8583 Field 18 on every transaction. ATM cash withdrawals use 6011 (automated disbursement) or 6010 (manual/counter). Quasi-cash transactions (money orders, foreign currency, travellers cheques) use 6050 or 6051 depending on whether they occur at a bank or a merchant. These codes typically attract the highest interchange rates and are restricted on many corporate and prepaid cards.
MCC
Description
Category
Source: ISO 18245 / Visa/Mastercard MCC reference. Common codes shown — full list exceeds 500 codes. MCC is assigned by acquirer, not self-selected by merchant.
Country codes — ISO 3166-1
Where country codes appear in card payments
ISO 3166-1 alpha-2 (2-letter) and numeric-3 (3-digit) codes appear throughout card payment messages. The alpha-2 code is used in billing/shipping address fields, merchant location, and cardholder address verification (AVS). The numeric-3 code appears in ISO 8583 Fields 19, 20, and 21 (country codes for acquiring institution, PAN extended, and forwarding institution). Both are required for correct 3DS2 AReq field population.
Alpha-2
Numeric
Country
Source: ISO 3166-1 Maintenance Agency. Alpha-2 used in address fields and scheme messages; numeric-3 used in ISO 8583 Fields 19/20/21.
Currency codes — ISO 4217
Where currency codes appear in card payments
ISO 4217 defines both alphabetic (3-letter) and numeric (3-digit) currency codes. In card payments, the numeric code is used in ISO 8583 Fields 49 (transaction currency), 50 (settlement currency), and 51 (cardholder billing currency). The minor unit column defines how many decimal places the amount field uses — GBP uses 2 (pence), JPY uses 0 (no minor unit), and KWD uses 3 (fils). Passing the wrong minor unit is one of the most common amount-field errors in payment integrations.
Alpha-3
Numeric
Minor
Currency
Source: ISO 4217 Maintenance Agency. Numeric code used in ISO 8583 Fields 49/50/51. Minor unit = number of decimal places in amount field (JPY=0, GBP/EUR/USD=2, KWD=3).