How Credit Card Transactions Actually Work: The 2-Second Journey Through 6 Different Systems

1 The Physical Layer: The Terminal Kernel & NFC Handshake (0ms–200ms)

Every card transaction starts in the physical world, long before any network request is sent or any fraud model runs. This first phase decides whether a transaction even has a chance to succeed. If something goes wrong here, nothing downstream matters.

From a systems perspective, this is the “edge” of the payment network. It’s an embedded environment with tight timing guarantees, limited power, and hard cryptographic rules enforced by hardware. The terminal and the card must complete a precise sequence of steps in a fraction of a second. If they don’t, the terminal has nothing usable to send to the network.

1.1 The Wake-Up Call: Inductive Coupling & Power Negotiation

When you tap a contactless card or phone, the card is not already running. It has no battery and no active CPU. The process only starts when the terminal generates a 13.56 MHz electromagnetic field.

That field powers the card through inductive coupling. As soon as the card harvests enough energy, it boots its chip, initializes cryptographic hardware, and prepares to communicate. From that moment on, the terminal has a limited window to exchange data before the card loses power or the user moves it away.

1.1.1 ISO 14443 (Type A/B) vs. ISO 7816

Card communication happens over one of two physical interfaces, and they behave very differently.

ISO 14443 (Type A/B — contactless) This is the protocol used for tap-to-pay. The terminal modulates the RF field—using amplitude modulation for Type A or phase modulation for Type B—and the card responds by slightly altering the load on the field. The card’s power level changes constantly based on distance, alignment, and interference.

Because of this, timing is unforgiving. Frames must be exchanged within microsecond-scale windows, or the kernel gives up and resets. Cryptographic operations must be optimized to run quickly and tolerate unstable power. There is no retry buffer and no long-running computation.

ISO 7816 (contact — 6-pin interface) With contact cards, the terminal supplies stable power and a clock through physical pins. Communication uses a UART-style protocol with predictable timing. The card can take longer to respond, retransmissions are simpler, and cryptographic operations behave consistently.

Long APDU exchanges, such as those required for RSA signatures, are much more reliable in this environment.

Why this matters architecturally ISO 14443 behaves like a low-power, lossy wireless link with strict real-time constraints. ISO 7816 behaves like a wired serial connection. The EMV kernel must support both, but it applies different performance assumptions and timeout behavior depending on which interface is in use.

1.1.2 The “Select” Command: Discovering the Payment System Environment (PSE)

Once communication is established, the terminal needs to know what kind of payment applications the card supports. It does this by issuing a standard APDU:

SELECT 2PAY.SYS.DDF01

This asks the card for its Payment System Environment (PSE), which is effectively a directory of supported payment applications.

The card responds with one or more Application Identifiers (AIDs), for example:

A0000000031010  -> Visa Credit
A0000000041010  -> Mastercard Credit
A0000001523010  -> Domestic Debit Network

The terminal chooses which AID to use based on its configuration and local rules. Regulatory requirements often apply here—for example, preferring a domestic debit network over an international credit network when both are available.

This choice locks in the rest of the flow. It determines which EMV rules apply, how cardholder verification works, which cryptograms are generated, and how the issuer will interpret the request.

1.2 The EMV Level 2 Kernel: The Embedded “Brain”

After an AID is selected, control shifts to the terminal’s EMV Level 2 kernel. This kernel is certified, audited software running inside the terminal. Merchants cannot change it, and terminals from different vendors must all behave the same way.

The kernel operates as a strict state machine. Each step happens in a defined order, with fixed inputs and outputs. There is no room for improvisation. The kernel must be fast, deterministic, and resilient, because any unexpected behavior results in a failed transaction.

1.2.1 Offline Data Authentication (ODA): RSA at the Edge

Before involving any network, the terminal needs to verify that the card itself is legitimate. Offline Data Authentication is how this happens.

Static Data Authentication (SDA) The card stores a static RSA signature over fixed data. The terminal verifies this using scheme root certificates. Because the signature never changes, it can be copied and replayed. For this reason, SDA is considered unsafe and largely deprecated.

Dynamic Data Authentication (DDA) The terminal sends a random challenge to the card. The card signs it using a private key that never leaves the chip. This proves the card is genuine even if all static data is copied.

Combined Data Authentication (CDA) CDA goes one step further by signing both the challenge and parts of the transaction data, including an unpredictable number. This prevents replay and transaction manipulation at the same time.

Most regions now require DDA or CDA. SDA alone is no longer sufficient.

All of these RSA operations must complete within a narrow power window—typically under 400 ms for contactless transactions. That constraint is why modern cards include dedicated cryptographic accelerators.

1.2.2 Cardholder Verification Method (CVM) List

The card also tells the terminal how the cardholder should be verified. It does this by providing a prioritized CVM list.

The kernel evaluates this list step by step:

If terminal supports CDCVM and device is mobile → use CDCVM
Else if amount < CVM floor limit → No CVM
Else if online PIN is supported → Use PIN
Else → Signature

CDCVM is common with mobile wallets. The device handles authentication using biometrics or a device PIN, and the card signals to the terminal that verification is already complete. The terminal never sees the biometric data.

1.2.3 Processing Restrictions

Before any online authorization, the card enforces local rules:

• Country code checks to block usage in unsupported regions
• Application version checks to detect outdated or incompatible terminals
• Currency checks to enforce supported currencies or limits

These checks are especially important when transactions might be approved offline.

1.3 Generating the Cryptogram (ARQC)

This is the final and most important step at the physical layer. The card now creates cryptographic proof that ties this transaction to this card, at this moment in time.

1.3.1 The GENERATE AC Command

The terminal sends a GENERATE AC APDU containing:

• Transaction amount
• Terminal unpredictable number
• Terminal country code
• Transaction date
• Terminal capabilities
• Application Transaction Counter (ATC)

The card responds with:

• The Authorization Request Cryptogram (ARQC)
• Application Interchange Profile (AIP)
• Additional EMV data such as TVR and TSI

The ARQC is what the issuer will later verify. Without it, the transaction cannot be authorized.

1.3.2 Session Key Derivation

Each transaction uses a one-time session key derived inside the card.

The inputs are:

• Master Key (MK) known only to the issuer
• Unique Derivation Key (UDK) specific to the card
• ATC, which increments on every transaction

The session key is derived as:

SK = AES(MK ⊕ UDK, ATC)

The ARQC is then computed as:

ARQC = AES(SK, TransactionData)

Because the ATC changes every time, the cryptogram cannot be reused. Even if intercepted, it is useless for future transactions.

Architect’s Note The EMV specification requires the card to respond within 500 ms. If the response is late, users instinctively pull the card away and the transaction fails. This tight deadline is why edge cryptography must be fast, deterministic, and hardware-assisted.

---

2 The Gateway & Switch: Message Parsing and Security (200ms–500ms)

At this point, the terminal has done its job. It has powered the card, authenticated it locally, and produced a cryptographic proof of the transaction in the form of the ARQC. Now the transaction leaves the tightly controlled world of embedded hardware and enters merchant infrastructure.

The problems change immediately. Instead of power constraints and APDU timing, the system now has to deal with network latency, encryption boundaries, protocol translation, retries, and routing decisions. This layer exists to safely move sensitive payment data from a retail terminal to the correct issuing bank without exposing it to the merchant or breaking legacy network expectations.

2.1 Payload Encryption: P2PE (Point-to-Point Encryption)

From the moment card data is read, it is encrypted inside the terminal. Nothing in the merchant’s application stack is ever allowed to see raw card data. This is deliberate. It limits blast radius, reduces compliance burden, and makes large-scale breaches significantly harder.

2.1.1 DUKPT (Derived Unique Key Per Transaction)

DUKPT is the mechanism that makes terminal-side encryption practical at scale. Instead of reusing a single encryption key, each transaction uses a different symmetric key derived from a secure root.

A terminal is provisioned with:

• BDK (Base Derivation Key), which never leaves the processor’s HSM
• IK (Initial Key), injected securely into the device during manufacturing or onboarding

For every transaction, the terminal derives a new key:

Key = Derive(IK, TransactionCounter)

The transaction counter increments with each use. This means that even if a terminal is compromised, the attacker can only decrypt a very small number of transactions. They cannot recover the BDK or decrypt historical data.

This is a classic example of limiting damage through key isolation. The system assumes compromise is possible and designs for containment.

2.1.2 Decrypting at the Edge

The encrypted payload travels over the merchant’s network and the public internet without being decrypted. It only becomes plaintext again inside a secure gateway environment, typically inside an HSM or a tightly controlled PCI-certified enclave.

Merchants never see the PAN, track data, or cryptographic keys. From their perspective, the transaction payload is opaque. This significantly reduces PCI-DSS scope and shifts most of the compliance responsibility to the payment processor.

In practice, this also simplifies merchant architecture. Applications can focus on business logic while treating payment authorization as a secure remote call.

2.2 Protocol Translation: JSON to ISO 8583

Once decrypted inside the gateway, the transaction still isn’t ready for the card networks. Most modern systems speak JSON or gRPC, but the global card infrastructure still relies on ISO 8583, a bitmap-based binary protocol designed decades ago.

The gateway’s job is to translate between these two worlds without losing meaning or breaking scheme rules.

2.2.1 The Modern Wrapper

Gateways such as Adyen, Stripe Terminal, or Checkout.com typically expose a clean, developer-friendly interface. A request might look like this:

{
  "amount": 4200,
  "currency": "USD",
  "emv_data": "9F2608A1B23F...",
  "terminal_id": "T12345"
}

Internally, the gateway converts this into an ISO 8583 authorization request:

• MTI: 0100 (authorization request)
• Bitmap: flags which fields are present
• Field 2: PAN
• Field 4: Transaction amount
• Field 55: EMV ICC data

This transformation is deterministic but brittle. ISO 8583 has no strict schema, and field meanings vary by network, region, and transaction type. Gateways encode years of scheme rules into mapping logic to make sure issuers can parse the message correctly.

2.2.2 Bitmaps and Fields

ISO 8583 uses a bitmap to declare which fields are present. The receiver must interpret the message based entirely on that bitmap.

Some of the most critical fields include:

• Field 2: PAN
• Field 3: Processing code (purchase, refund, cash advance)
• Field 4: Amount
• Field 39: Response code (used later in the response)
• Field 55: EMV ICC data

Field 55 is especially important. It contains the raw EMV tags generated by the card, including the ARQC and ATC. This field is passed through unchanged so the issuer can independently verify the card’s cryptographic proof.

2.3 The Payment Switch (The Router)

After the gateway constructs the ISO 8583 message, it hands it off to a payment switch. Conceptually, the switch is a router optimized for financial messages. Its job is to decide where the message goes next and get it there as quickly and reliably as possible.

2.3.1 BIN Routing Logic

The switch examines the first 6 to 8 digits of the PAN, known as the Bank Identification Number (BIN). From this, it determines:

• Which card scheme applies (Visa, Mastercard, AmEx, domestic debit)
• Which issuing bank owns the account
• Whether the transaction must stay on a domestic network

This lookup determines the next hop. A misroute here means either a decline or a costly network fallback.

2.3.2 Dynamic Routing

Modern switches do more than static routing. They continuously optimize for cost and availability.

Common strategies include:

• Least Cost Routing (LCR) to prefer lower-fee debit networks when allowed
• Smart retries that automatically fail over to a secondary endpoint within milliseconds
• Geo-routing to send traffic to the nearest network data center

These decisions are made under tight latency budgets. A retry that takes too long is worse than a fast failure.

Open Source Spotlight

• jPOS (Java) is widely used in banks and processors for ISO 8583 handling
• Hyperswitch (Rust) represents a newer generation of high-throughput, low-latency payment switches designed for cloud-native environments

Together, the gateway and switch form the bridge between the modern internet and legacy card networks. If this layer works well, the issuer sees a clean, standards-compliant request. If it doesn’t, the transaction fails long before any balance check happens.

---

3 Fraud Detection: The Real-Time Risk Engine (500ms–800ms)

By the time the transaction reaches the fraud layer, it already looks legitimate. The card was authenticated, the cryptogram is valid, and the request is correctly routed. Now the system has to answer a different question: Does this transaction look like something the cardholder would actually do?

This stage is where things get hardest to predict. Fraud systems operate under tight latency limits while processing data that is noisy, incomplete, and constantly evolving. Attackers change tactics quickly, and the system has to adapt without slowing down approvals. Even a single inefficient lookup or feature calculation can push the request past the issuer’s timeout and cause a decline.

Architecturally, the fraud engine sits inline between the payment switch and the issuer. In many modern setups, it runs as a dedicated microservice that receives the authorization request, enriches it with context, scores the risk, and returns a decision—all before the issuer ever sees the transaction.

The constraints are unforgiving:

• Hard SLA: under 300 ms for enrichment and scoring combined
• High throughput: thousands to tens of thousands of transactions per second
• Accuracy pressure: false positives directly reduce merchant revenue
• Distributed state: decisions depend on history, but no single node can hold all of it

Balancing speed, accuracy, and scale is what makes fraud engineering one of the most difficult parts of the payment flow.

3.1 The Data Payload for Risk

Fraud systems don’t rely on a single signal. Instead, they combine many small pieces of context to build a picture of behavior. By 2025, most processors ingest data from card networks, wallets, 3-D Secure flows, and merchant SDKs to enrich each authorization request.

The key idea is context. A $50 transaction isn’t risky by itself. A $50 transaction from a new device, in a new country, at an unusual time of day might be.

3.1.1 3-D Secure 2.x Data

3-D Secure 2.x introduces a rich set of device and behavioral signals that go far beyond what ISO 8583 can carry on its own. This data typically originates at the Access Control Server (ACS) during authentication and is forwarded to the fraud engine for real-time evaluation.

Common signals include:

• Device entropy: font counts, timezone, CPU class, WebGL vendor
• Operating system state: jailbreak or root indicators, patch level
• Network characteristics: VPN or proxy likelihood, ASN reputation
• Runtime behavior: touch frequency, pointer movement, activity timing
• Wallet context: Apple Pay or Google Pay attestation strength from the token service

Sensitive values such as emails or phone numbers are usually hashed before entering the fraud system. The goal is pattern matching, not identification. Consistency across transactions matters more than the raw value itself.

3.1.2 Velocity Checks: Redis as a Real-Time Risk Cache

Some fraud signals are about speed and repetition. Velocity checks look for patterns that happen too quickly to be normal human behavior.

Redis is commonly used here because it offers predictable, low-latency reads and writes with built-in expiration. Counters naturally decay over time without requiring cleanup jobs.

Typical counters look like:

• card:{PAN_hash}:attempts:60s
• ip:{ipv4}:unique_cards:24h
• device:{device_id}:merchant:{mid}:amount_sum:1h

These counters are rarely evaluated in isolation. Fraud engines combine them into simple, fast rules. For example:

If IP velocity > threshold
AND device velocity > threshold
AND amount > 90th percentile
→ escalate to ML scoring

Velocity checks act as a first pass. They are fast, deterministic, and cheap, allowing the system to filter obvious abuse before invoking heavier models.

3.2 Machine Learning Pipeline (In-Line)

Once a transaction passes basic rules and velocity filters, it moves into the machine learning layer. This is where the system looks for subtle patterns that can’t be expressed as simple thresholds.

In high-volume environments, this layer runs as a tightly optimized inference service, often written in Rust or Go, or in Python using ONNX Runtime for predictable performance.

3.2.1 Feature Engineering: Real-Time Transformations

Feature engineering happens on the hot path, so every operation must be fast and non-blocking. Anything that requires network I/O or complex joins is precomputed and cached ahead of time.

Common real-time features include:

• Geospatial drift: distance between IP location and billing or merchant location
• ATC anomalies: unexpected gaps or reversals in the EMV transaction counter
• Merchant similarity: how this merchant compares to others in the same MCC
• Graph-based signals: shared devices, IPs, or cards derived from offline graph analysis

The fraud engine treats each transaction as independent, pulling only what it needs from fast in-memory stores like Redis or ScyllaDB.

3.2.2 Scoring Models: Forests vs. Neural Networks

Different model types serve different purposes.

Random forests and gradient-boosted trees These work well with structured, tabular data. They’re fast, interpretable, and predictable, which matters for audits and regulatory reviews. Inference usually takes a few milliseconds.

Neural networks and embedding models These capture nonlinear relationships and shared behavior across cards, devices, and IPs. They adapt better to evolving fraud patterns but require careful tuning to avoid latency spikes, especially during cold starts.

Most processors use a layered approach: quick rules first, then a lightweight model, and finally a deeper model only when risk is elevated.

3.2.3 The Circuit Breaker Pattern

Fraud systems are critical, but they cannot be allowed to block the entire payment flow. When the fraud engine slows down or fails, the system must degrade gracefully.

Common strategies include:

• Fail open for low-risk merchants to preserve authorization rates
• Fail closed for high-risk categories like digital goods or prepaid value
• Fail fallback to a simplified in-memory ruleset when ML inference is unavailable

Every fallback decision is logged with precise timestamps. These logs are essential for audits, chargeback reviews, and post-incident analysis.

At the end of this phase, the transaction has a risk score and a decision. Only then is it forwarded to the issuing bank, which will combine this signal with its own controls to make the final call.

---

4 The Networks: VisaNet / Mastercard Packet Switching (800ms–1200ms)

Once the fraud engine has finished its work, the transaction is ready to leave the acquiring side of the world. At this point, the ISO 8583 authorization message is handed off to the card network. This is where the transaction enters one of the most reliable distributed systems ever built.

VisaNet and Mastercard’s Banknet are global packet-switched networks designed to move financial messages with extreme predictability. Latency is tightly controlled, message formats are rigidly enforced, and availability targets are measured in “never go down.” These networks sit between acquirers and issuers as neutral intermediaries, enforcing scheme rules, applying additional risk controls, and ensuring that every message arrives at the correct bank in a form it understands.

Failures here are visible immediately. If these networks stall, commerce around the world stalls with them. That’s why almost every design choice in this layer favors determinism and safety over flexibility.

4.1 The Dual Message System (Auth vs. Clear)

At first glance, a card transaction looks like a single request and response. In reality, the networks treat authorization and settlement as separate concerns. Whether they happen together or apart depends on how the card product is designed.

Understanding this split is critical, because it explains why an approval doesn’t always mean money has moved yet.

4.1.1 Single Message (SMS) vs. Dual Message (DMS)

In a Single Message System (SMS), authorization and clearing are combined. The issuer receives one message, makes a decision, and immediately updates the account balance. This model is common in U.S. debit networks, where transactions are typically PIN-based and finalized in real time.

In a Dual Message System (DMS), authorization and clearing are separate steps. The first message (ISO MTI 0100) asks, “Can this transaction happen?” The second message (0220 or 0420) arrives later to finalize the amount and move money. Most credit card transactions use DMS because merchants often don’t know the final amount at authorization time—think restaurant tips, hotel stays, or partial shipments.

From a system design perspective, SMS behaves like a single RPC that mutates state once. DMS looks more like a distributed workflow with a confirmation phase. Gateways and issuers must handle retries, reversals, and idempotency differently depending on which model applies.

4.1.2 Stand-In Processing (STIP)

Card networks can’t afford to wait indefinitely for an issuer to respond. If an issuer’s host becomes unreachable or starts missing latency SLAs, the network steps in using Stand-In Processing, or STIP.

When STIP is triggered—often after latency exceeds a threshold like 1500 ms—the network temporarily authorizes transactions on the issuer’s behalf. These decisions are based on rules and card profiles that the issuer has pre-configured and replicated into the network.

Typical STIP checks include:

• The card is not reported lost or stolen
• The transaction amount is below a configured limit
• The merchant category looks normal for the card
• The EMV transaction counter (ATC) is progressing correctly

The goal is continuity, not generosity. STIP logic is intentionally conservative. The issuer later receives a batch of STIP-approved transactions and must honor them, so the network errs on the side of declining anything suspicious.

Conceptually, STIP behaves like a fallback service backed by cached issuer state. Keeping that state fresh and consistent across global data centers is itself a non-trivial distributed systems problem.

A simplified internal decision function might look like this:

public bool ShouldStipAuthorize(Transaction txn, CardProfile profile)
{
    if (profile.IsHotlisted) return false;
    if (txn.Amount > profile.StipLimit) return false;
    if (!profile.MccAllowList.Contains(txn.Mcc)) return false;
    if (txn.Atc <= profile.LastAtc) return false; // ATC regression

    return true;
}

If STIP approves, the transaction continues as if the issuer had responded directly.

4.2 Network Tokenization (TSP)

Another responsibility handled at the network layer is tokenization. Instead of passing real card numbers through wallets and devices, networks replace them with tokens that are only meaningful inside their infrastructure.

This reduces exposure and limits how far sensitive data can spread.

4.2.1 The Detokenization Step

When a transaction comes from a mobile wallet, it usually carries a device-specific token (DPAN) instead of the real funding PAN (FPAN). The acquirer doesn’t try to interpret it. The token is passed unchanged into the card network.

Inside VisaNet or Banknet, the Token Service Provider (TSP) performs a secure lookup:

• Map the DPAN back to the FPAN
• Retrieve token metadata such as device ID and token status
• Validate that the token was provisioned correctly

This process happens inside an HSM-protected vault. The merchant and gateway never see the real PAN. For hardware-secured wallets, the network also evaluates signals like secure element identifiers and provisioning risk scores before proceeding.

4.2.2 Cryptogram Validation

Mobile wallets don’t just send a token; they also include a cryptogram that proves the transaction originated from a legitimate secure element. Visa calls this value the TAVV; Mastercard uses a similar construct.

Before forwarding the authorization to the issuer, the network validates this cryptogram. Conceptually, the process recreates the expected value using shared secrets and transaction-specific inputs, then compares it to what was received.

A simplified Python-style illustration:

def validate_tavv(token_crypto, device_key, txn_data):
    session_key = derive_session_key(device_key, txn_data.nonce)
    expected = aes_cmac(session_key, txn_data.payload)
    return hmac_compare(expected, token_crypto)

If validation fails, the network declines the transaction immediately with a cryptogram-related error. If it succeeds, the network annotates the authorization message with indicators that tell the issuer this transaction came from a strongly authenticated device.

Issuers trust these signals. As a result, wallet-based transactions often see higher approval rates and lower fraud losses than traditional card-present transactions.

At the end of this phase, the network forwards a fully validated, scheme-compliant authorization request to the issuing bank. From here on, the decision is no longer about routing or cryptography—it’s about money.

---

5 The Issuing Bank: The Ledger of Truth (1200ms–1800ms)

At this stage, the transaction has crossed terminals, gateways, fraud systems, and global networks. Now it reaches the only system that actually controls the money: the issuing bank.

Everything before this point was about trust and delivery—proving the card is real, the request is intact, and the transaction looks reasonable. The issuer’s job is different. It must decide whether to reserve funds on a real customer account and take financial responsibility for the approval. That decision has to be correct, fast, and fully auditable.

Issuer processing systems are built like high-integrity financial engines. They prioritize consistency over flexibility and correctness over convenience. Once the issuer responds, that decision propagates back through every system the transaction passed on the way in.

5.1 The Host Security Module (HSM)

Before the issuer looks at balances or limits, it verifies cryptographic integrity. This work is handled by the Host Security Module (HSM), which is the most trusted component in the issuer’s environment.

The HSM is the only place where issuer master keys live. It validates EMV cryptograms, translates PIN blocks, and ensures that sensitive operations happen in tamper-resistant hardware.

5.1.1 Validating the ARQC

The Authorization Request Cryptogram (ARQC) is the issuer’s proof that the transaction really came from a genuine card and hasn’t been altered in transit.

To validate it, the issuer repeats the same steps the card performed earlier. Using its Issuer Master Key (IMK) and the card’s Application Transaction Counter (ATC), the HSM derives the session key. It then recomputes the cryptogram over the transaction data.

If the result matches the ARQC sent by the terminal, the issuer knows the card is authentic and the data is intact.

A simplified C# example illustrates the idea:

public bool ValidateArqc(byte[] arqc, byte[] imk, ushort atc, byte[] txnData)
{
    var sessionKey = DeriveSessionKey(imk, atc);
    var expected = AesEncrypt(sessionKey, txnData);
    return ConstantTimeEquals(arqc, expected);
}

The comparison must be constant-time to avoid leaking information through timing differences. Because this work runs inside specialized hardware, validation usually completes in just a few milliseconds.

5.1.2 PIN Translation

For transactions that use a PIN, the issuer must also verify that the correct PIN was entered—without ever exposing it.

PIN blocks are encrypted multiple times as they move from terminal to gateway to network. Each hop uses a different key. When the PIN reaches the issuer, the HSM decrypts it using the acquirer’s zone key, then re-encrypts it using the issuer’s own key so it can be validated.

Conceptually, the flow looks like this:

pin_clear = decrypt_zpk(acquirer_zpk, encrypted_pin_block)
pin_reenc = encrypt_zpk(issuer_zpk, pin_clear)

This translation must be atomic and fully logged. Any inconsistency—wrong format, mismatched PAN, or invalid PIN—results in an immediate decline.

5.2 The Balance Check & Reservation

Once cryptographic checks pass, the issuer moves to the part that customers care about most: Do I have enough money, and can this transaction go through?

This is where the issuer’s ledger comes into play.

5.2.1 ACID Transactions

Issuer ledgers are designed for strict consistency. An authorization touches several pieces of state at once:

• The card account record
• Available balance
• Pending authorization (shadow ledger)
• Fraud and risk flags
• Card controls and account restrictions

These updates must happen atomically. If two transactions race against the same balance, the system must not approve both. For this reason, issuers often use serializable isolation, stored procedures, or per-account locking.

At scale, ledgers are usually sharded by account identifier so transactions on different accounts can proceed independently without contention.

5.2.2 “Shadow Limits” vs. Posted Balance

What customers see as their balance is not the full picture. Internally, issuers track pending authorizations separately using shadow or memo-post balances.

For example, at a fuel pump, the issuer might approve a small pre-authorization but reserve a larger amount in the shadow ledger. The posted balance doesn’t change yet, but the available balance reflects the hold.

When approving a transaction, the issuer considers:

• Merchant category rules
• Card-level limits and controls
• Currency conversion buffers
• Real-time risk signals

Each shadow entry includes details like amount, authorization code, ATC, and an expiration time—often one to three days. If the merchant never submits a clearing message, the hold expires and the funds are released automatically.

5.2.3 Overdraft Logic

If the account doesn’t have enough available funds, the issuer has to decide how strict to be. Overdraft handling varies widely between banks and products.

Decision logic typically considers:

• Whether overdraft protection is enabled
• The customer’s risk tier and history
• The merchant and transaction type
• Real-time fraud confidence

Depending on those factors, the issuer may approve:

• A partial amount, common in some debit systems
• The full amount with an overdraft fee
• Or decline the transaction, sometimes allowing a retry

A simplified evaluator might look like this:

def evaluate_overdraft(account, txn):
    if account.balance >= txn.amount:
        return True, 0

    deficit = txn.amount - account.balance
    if deficit <= account.overdraft_limit:
        fee = calculate_fee(account, deficit)
        return True, fee

    return False, 0

All of this logic must complete quickly—typically within a few tens of milliseconds—so the issuer can respond within network timeouts.

5.3 Response Generation (ARPC)

Once the issuer makes its decision, it needs to prove that decision to the card. That proof comes in the form of the Authorization Response Cryptogram (ARPC).

5.3.1 Authorization Response Cryptogram (ARPC)

ARPC generation mirrors the earlier ARQC process. Using the same session key, the issuer signs the original cryptogram along with an authorization response code indicating approval or decline.

Conceptually:

public byte[] GenerateArpc(byte[] arqc, byte[] sessionKey, byte[] arc)
{
    return AesEncrypt(sessionKey, arqc.Concat(arc).ToArray());
}

The ARPC is sent back in Field 55 of the ISO 8583 response. When the terminal receives it, it passes the value to the card and issues a final GENERATE AC command.

The card verifies the ARPC. If it’s valid, the card generates either a Transaction Certificate (TC) for approval or an Application Authentication Cryptogram (AAC) for decline. That final step closes the loop, cryptographically binding the issuer’s decision to the card and the transaction.

At this point, the real-time phase of the transaction is complete. The money hasn’t moved yet—but the issuer has committed to the outcome, and everything that follows builds on that decision.

---

6 Closing the Loop & Asynchronous Settlement (Post-Transaction)

When the terminal displays “Approved” and the customer walks away, the visible part of the transaction is over. From the user’s point of view, the payment is done. From the system’s point of view, the most time-consuming work is just beginning.

Everything up to this point has been about making a fast, real-time decision: is this transaction valid, and should the issuer commit to it? What follows is slower and deliberately asynchronous. Clearing, settlement, reconciliation, and exception handling happen in the background, often hours or days later. These steps don’t need millisecond latency, but they must be correct, repeatable, and auditable because they define how money actually moves between institutions.

6.1 The “Capture” Batch (Clearing)

Authorization only reserves funds. Clearing is the step where the merchant tells the network, “This is the final amount—please collect it.” Most merchants don’t do this transaction by transaction. Instead, they capture many transactions together in batches.

Batching reduces overhead and gives merchants flexibility. It allows tips to be added, orders to be partially fulfilled, or transactions to be reversed before anything is finalized.

6.1.1 T+1 Batch Processing

In practice, merchants accumulate approved authorizations throughout the day and generate a clearing file near the end of business. Some use ISO 8583 formats, but many processors accept simpler proprietary files that include only what’s needed to settle the transaction.

A typical clearing record contains:

• Authorization code
• Final amount
• Currency
• Merchant and terminal reference
• Capture timestamp

For example:

{
    "auth_code": "ABC123",
    "amount": 7000,
    "currency": "USD",
    "acquirer_reference": "MID123_TID456_987654321",
    "capture_timestamp": "2025-01-11T23:59:59Z"
}

Although merchants often generate the batch on the same day (T+0), acquirers commonly forward it to the network the next morning (T+1). Before forwarding, the acquirer runs validations: does each capture match a prior authorization, is the amount within tolerance, and has the transaction already been captured?

Failures here don’t affect the customer directly, but they trigger reconciliation workflows. Missing authorizations, duplicate captures, or amount mismatches are either corrected automatically or routed to operations teams.

6.1.2 Interchange Fee Calculation

Once the clearing batch reaches the card network, the economics of the transaction are finalized. This is where interchange fees are calculated.

Interchange depends on many factors:

• Merchant Category Code (MCC)
• Card type (debit, standard credit, premium rewards)
• Whether the transaction is domestic or cross-border
• Authentication strength (for example, 3-D Secure)

The network applies large, frequently updated rules tables to determine how much the issuer earns and how much the acquirer owes. The scheme itself also takes a separate assessment fee.

A simplified illustration looks like this:

public decimal CalculateInterchange(Transaction txn)
{
    var rate = InterchangeTables.GetRate(txn.Mcc, txn.CardType);
    return txn.Amount * rate.Percentage + rate.FixedFee;
}

In real systems, these tables contain thousands of entries and change multiple times per year. That’s why processors treat interchange logic as versioned configuration rather than hard-coded rules.

6.2 Settlement (The Money Move)

Clearing answers what should be paid. Settlement answers how the money moves. This is where balances between banks are actually adjusted.

Settlement typically runs in scheduled windows and relies on existing bank-to-bank payment rails such as ACH, Fedwire, SEPA, or domestic real-time gross settlement systems.

6.2.1 Net Settlement

Rather than moving money for each individual transaction, networks calculate net positions for each participant. This dramatically reduces the number of transfers required.

For example, if Bank A owes Bank B $5 million and Bank B owes Bank A $4 million, only a single $1 million transfer is required. Everything else nets out.

Each network maintains settlement accounts for issuers and acquirers, often at designated settlement banks. During the settlement window, the network posts debits and credits to these accounts based on the net positions.

Conceptually:

def compute_net_settlement(positions):
    net_results = {}
    for bank, entries in positions.items():
        net_results[bank] = sum(entries)  # net debit or credit
    return net_results

These positions include not just purchase amounts, but also interchange fees, reversals, chargebacks, and scheme assessments.

6.2.2 ISO 20022 Migration

The final step is instructing banks to move funds. Historically, this was done using SWIFT MT messages. Today, the industry is moving toward ISO 20022, which provides richer structure and better reconciliation.

Common settlement messages include:

• pacs.008 for financial institution credit transfers
• pacs.004 for returns and reversals

A highly simplified example:

<CdtTrfTxInf>
    <PmtId>
        <InstrId>SETTLEMENT_20250112_001</InstrId>
    </PmtId>
    <Amt>
        <InstdAmt Ccy="USD">1000000.00</InstdAmt>
    </Amt>
    <DbtrAgt>
        <FinInstnId><BIC>ACQBUS33</BIC></FinInstnId>
    </DbtrAgt>
    <CdtrAgt>
        <FinInstnId><BIC>ISSUUS44</BIC></FinInstnId>
    </CdtrAgt>
</CdtTrfTxInf>

Most processors now maintain mapping engines that convert clearing data—often still derived from ISO 8583—into ISO 20022 settlement instructions. These systems must remain backward compatible because not all banks migrate at the same pace.

At the end of settlement, the issuer has been paid, the acquirer has been debited, and the transaction is fully complete. What began as a 2-second tap has now passed through days of controlled, auditable financial workflows—all built on top of that original authorization decision.

---

7 System Architecture Patterns for Architects

After following a transaction from the terminal to settlement, a few architectural themes show up again and again. None of them are exotic, but all of them are easy to get wrong. Payments look simple on the surface, yet behind the scenes they rely on careful coordination of distributed state, retries, and observability across dozens of systems.

This section pulls those patterns together. Think of it as the checklist you end up with after operating a payment system in production for a few years.

7.1 Idempotency & Distributed State

Card payments are synchronous, but the infrastructure they run on is not. Networks fail, terminals retry, and gateways occasionally time out after a message has already been processed. The system must assume that the same request can arrive more than once and still behave correctly.

The hardest failure mode to prevent is charging or authorizing twice.

7.1.1 Idempotency Keys

Idempotency keys are how systems recognize duplicate requests. Every authorization attempt is tagged with a unique identifier, typically a UUID generated by the gateway or merchant. If the same request is retried, the key stays the same.

When a request arrives, the system checks whether it has already seen that key. If it has, it returns the original result instead of processing the transaction again.

A simplified C# example shows the pattern:

public bool TryProcessWithIdempotency(string idempotencyKey, Func<bool> action)
{
    if (Cache.Exists(idempotencyKey))
        return Cache.Get<bool>(idempotencyKey);

    bool result = action();
    Cache.Set(idempotencyKey, result, TimeSpan.FromHours(24));
    return result;
}

The retention window matters. It must be long enough to survive worst-case retries and network delays, but short enough to avoid unbounded growth. In practice, processors tune this based on scheme retry rules and merchant behavior.

7.1.2 The “Advice” Message (0220)

Sometimes retries aren’t possible. If the acquirer can’t reach the issuer at all, the switch may authorize the transaction locally and send an “Advice” message later.

An advice message tells the issuer, “This transaction already happened—here are the details.” The issuer records it without re-running authorization logic. This keeps ledgers consistent even when parts of the network are temporarily unavailable.

Advice handling must also be idempotent. The issuer has to recognize whether it has already processed the transaction:

def handle_advice(advice_msg):
    if ledger.exists(advice_msg.txn_id):
        return "IGNORED"

    ledger.record(advice_msg)
    return "RECORDED"

Advice flows are especially important for offline environments like airplanes, trains, or remote locations where connectivity is intermittent. Without them, those transactions would simply disappear.

7.2 High Availability & Geo-Redundancy

Card payments don’t have maintenance windows. Customers expect them to work everywhere, all the time. That means every layer—from gateway to switch to issuer—must tolerate failures without taking the system down.

High availability is not just about adding replicas. It’s about designing for failure as a normal condition.

7.2.1 Active-Active Deployments

Most modern payment gateways and switches run in active-active configurations across multiple availability zones or regions. Traffic is distributed continuously, not held in reserve for failover.

Routing decisions consider both geography and health. For example, a transaction may be sent to the nearest healthy region that supports the relevant card network:

public string RouteToNearestRegion(string cardBin)
{
    var region = BinTable.GetRegion(cardBin);
    return LoadBalancer.SelectHealthy(region);
}

Active-active designs raise hard questions about state. HSMs are difficult to replicate. Caches must resolve conflicts. Configuration changes must roll out safely across regions. These constraints often drive architectural trade-offs more than raw throughput requirements.

Issuer systems typically take a stricter approach, using synchronous replication or per-account partitioning to preserve strong consistency.

7.2.2 Database Sharding

Issuer ledgers grow constantly and must scale without sacrificing correctness. The most common approach is sharding by account identifier so that all activity for a single account is routed to the same shard.

This avoids hot partitions and allows authorizations on different accounts to proceed in parallel.

A basic shard selector might look like:

def select_shard(account_id):
    return account_id % NUM_SHARDS

In practice, large issuers layer additional logic on top—consistent hashing, tenant-aware routing, or special handling for high-volume accounts. The goal is always the same: isolate contention while keeping per-account logic simple and deterministic.

7.3 Observability

When something goes wrong in payments, the symptoms are often subtle: a small drop in approval rate, a slight latency increase, a spike in retries. Without strong observability, these issues are easy to miss until customers notice.

Observability is what allows engineers to answer the question, “What happened to this specific transaction?”

7.3.1 Distributed Tracing

Distributed tracing ties together every step of a transaction’s journey. A single TraceID follows the request from the terminal SDK, through the gateway, switch, fraud engine, network, and issuer host.

OpenTelemetry is widely used for this purpose. Each service adds spans as the request passes through:

using var span = tracer.StartActiveSpan("iso8583_forward");
span.SetAttribute("mti", "0100");
span.SetAttribute("acquirer_host", host);

Sensitive data must be redacted, but enough context must remain to understand timing, routing, and failures. When approval rates drop, traces often reveal the root cause faster than logs alone.

7.3.2 Key Metrics

Certain metrics matter more in payments than almost any other domain:

• TPS: how many transactions the system can process right now
• ASR: approval success rate, often segmented by issuer or scheme
• Latency P99: critical because authorizations are synchronous
• Queue depth: especially for clearing and settlement pipelines
• Fraud fallbacks: how often circuit breakers are triggered

These metrics must be visible in near real time. Many processors also run automated canaries—small test transactions sent continuously—to detect outages before merchants or customers notice.

Taken together, these patterns reflect a simple truth: payments are less about clever algorithms and more about disciplined engineering. The systems that work best are the ones that assume failure, handle retries safely, and make it easy to see what’s happening when something goes wrong.

---

8 Future Trends: The Next 5 Years

Card payments don’t change overnight. Most of the systems described in the earlier sections will still be in place five years from now. What does change is where responsibility sits, how quickly money moves after approval, and how long today’s cryptography can be trusted.

The trends below don’t replace the card transaction flow you’ve just seen. They layer on top of it. Each one shifts assumptions that architects have relied on for years—about who authenticates the user, when settlement happens, and which cryptographic primitives are safe to deploy long term.

8.1 Biometric Cards

Biometric cards move cardholder verification directly into the card itself. A fingerprint sensor is embedded in the plastic, and the fingerprint template is stored securely inside the chip. Nothing leaves the card. When the card is presented, it verifies the fingerprint locally and only then proceeds with the transaction.

From the transaction flow’s perspective, everything still looks familiar. The terminal powers the card, selects an application, and runs the EMV kernel. The difference is that cardholder verification no longer depends on a PIN pad or a mobile device. The card tells the terminal, through CDCVM-style indicators, that the cardholder has already been verified.

For issuers, this closes a long-standing gap. They get strong, card-present authentication without relying on terminals being tamper-free or customers owning smartphones. For merchants, nothing changes operationally—the tap or insert flow stays the same. The cardholder simply touches the card instead of entering a PIN.

Biometric sensors consume more power, which is a challenge for contactless transactions. Card manufacturers address this with efficient wake-up cycles and tightly optimized secure enclaves. Once verification succeeds, the rest of the flow is unchanged: the card derives a session key and generates the ARQC.

A simplified view of the internal decision might look like this:

public bool ValidateBiometricAndAuthorize(byte[] fingerprintSample, byte[] txnData)
{
    if (!MatchFingerprint(fingerprintSample))
        return false;

    var sessionKey = DeriveSessionKey(txnData);
    var arqc = GenerateArqc(sessionKey, txnData);
    return arqc != null;
}

As pilots expand—especially in markets that still rely heavily on PINs—biometric cards are likely to become a standard option rather than a niche product.

8.2 FedNow / RTP Integration

Another shift is happening after authorization, not during it. Instant payment rails such as FedNow in the U.S. and RTP in other regions are changing expectations around settlement speed.

Traditionally, card transactions authorize in seconds but settle in days. Instant rails flip that model by moving money between banks in near real time. Instead of competing with cards, many processors are now looking to combine the two.

One emerging pattern is a card-overlay flow. The transaction still starts exactly as described earlier: terminal interaction, network routing, fraud checks, issuer approval. The difference comes later. Instead of settling through the usual clearing and net settlement cycles, the issuer triggers an instant bank-to-bank transfer.

For the cardholder and merchant, nothing looks different. The same card is used, the same approval happens, and the same dispute rules apply. Behind the scenes, however, the merchant receives funds much faster.

A simplified hybrid settlement decision might look like this:

def settle_via_instant_rail(txn):
    if txn.instantEligible:
        request = build_fednow_request(txn.account, txn.amount)
        response = fednow_api.send(request)
        return response.status
    return "FALLBACK_DMS"

The hard part isn’t sending the instant payment. It’s reconciling it later. Chargebacks, reversals, and adjustments still follow card rules, even though the money has already moved. Over time, processors will expose routing logic that decides—transaction by transaction—whether to use traditional settlement or instant rails.

8.3 Quantum Resistance

Every step in the card flow relies on cryptography: NFC authentication, EMV signatures, network tokenization, and issuer validation. Today, that cryptography is based on RSA and elliptic-curve algorithms. In the long term, those algorithms are vulnerable to quantum attacks.

Quantum computers capable of breaking modern cryptography aren’t available yet, but payment systems evolve slowly. Terminals stay in the field for a decade or more. HSMs often last even longer. That means planning for post-quantum cryptography has to start well before it’s strictly necessary.

The challenge is practical, not theoretical. Cards have limited processing power. Terminals must remain backward compatible. HSMs need to support both classical and post-quantum algorithms during a long transition period. Post-quantum signatures are larger and slower, which directly affects contactless latency budgets.

The most likely path forward is hybrid cryptography. In this model, transactions carry both a classical signature and a post-quantum one. Legacy systems validate the classical signature, while newer systems validate both.

Conceptually:

public bool ValidateHybridSignature(byte[] data, SignatureBundle sig, Keys keys)
{
    bool classicalOk = VerifyRsa(data, sig.RsaSignature, keys.RsaKey);
    bool pqcOk = VerifyDilithium(data, sig.PqcSignature, keys.PqcKey);

    return classicalOk && pqcOk;
}

This mirrors the early EMV transition, when magnetic stripe and chip transactions coexisted. Card networks will likely introduce PQC-capable ARQC and ARPC formats gradually, alongside updated certification programs.

Over the next five years, expect pilot programs, dual-key strategies, and new HSM firmware rather than a sudden cutover. The flow you’ve just followed—from tap to settlement—will stay recognizable. The cryptography underneath it will quietly change to ensure it remains trustworthy for decades to come.