How a Payment Works

A point-of-sale receipt is more than a proof of purchase. It's a compressed record of a multi-party financial transaction that traveled across at least five organizations in under two seconds. Every line encodes a specific piece of the payments stack, from merchant identity to cryptographic verification.

Receipts serve a dual purpose. For the cardholder, they're a record of the transaction amount, date, and payment method, useful for expense tracking and dispute resolution. For the merchant, they satisfy compliance requirements set by card networks and acquirers.1 Visa and Mastercard mandate that certain fields appear on every receipt: the truncated card number, the authorization code, and the entry method, among others.

The format varies by POS system, but the data requirements don't. Whether it's a thermal paper roll from a countertop terminal or a digital receipt emailed from a tablet-based POS, the same core fields must be present.2 The card networks publish detailed receipt formatting guides as part of their merchant acceptance standards, and acquirers enforce them during merchant onboarding.

What makes receipts fascinating from an infrastructure perspective is their information density. A receipt contains the merchant's identity in the payments ecosystem (MID), the specific device that processed the transaction (TID), the card application that was selected during the EMV handshake (AID), the authorization decision from the issuing bank (auth code), and the settlement batch the transaction belongs to. Each of these fields represents a different layer of the payments stack, and together they form a complete audit trail.3

The merchant header (the business name, address, and phone number at the top of the receipt) seems purely informational, but it's actually one of the most carefully regulated fields. This is the merchant descriptor, and it's the first thing a cardholder sees when reviewing their bank statement.

When a merchant signs up to accept card payments, they go through an onboarding process with an acquiring bank (or "acquirer"). The acquirer is the financial institution that sponsors the merchant into the card network. During onboarding, the merchant registers their legal business name, DBA (doing business as) name, address, and merchant category code (MCC). This information is stored in the acquirer's systems and transmitted with every authorization request. A business named "Vandelay Industries, LLC" might register a DBA of "Vandelay Latex" for statement clarity.

The descriptor that appears on the cardholder's statement often differs from what's printed on the receipt. Statement descriptors are limited to 22–25 characters depending on the network and follow a format set by the card network.4 A diner named "Monk's Cafe, Inc." might show as MONKS CAFE NYC on a bank statement. Mismatched descriptors are one of the leading causes of friendly fraud: cardholders who don't recognize a charge and file a dispute.5

Modern payment facilitators like Stripe and Square have added dynamic descriptors, allowing merchants to customize what appears per transaction.6 But the underlying principle remains: the merchant header is the human-readable version of a registration that lives in the acquirer's merchant database, cross-referenced by the Merchant ID (MID) printed a few lines below.

The Merchant ID is a unique identifier assigned by the acquiring bank when a merchant is approved to accept card payments. On our receipt, it reads 4445129081571. This number is the merchant's address in the payments ecosystem; it tells every system in the authorization chain exactly who is requesting the funds.

MIDs are up to 15 alphanumeric characters (per ISO 8583 Field 42), though the exact format and length varies by acquirer.7 They're not random: the structure encodes information about the acquiring bank, the merchant's processing agreement, and sometimes the geographic region. When an authorization request travels from the POS terminal to the acquirer's processing platform, the MID is one of the first fields checked. It determines the merchant's processing rates, risk profile, and settlement account.

A single business can have multiple MIDs. A restaurant chain might have one MID per location, or one per payment channel (in-store vs. online). This allows the acquirer and the merchant to track transaction volumes, chargebacks, and revenue separately. High-risk merchants may be required to maintain separate MIDs to isolate risk.8

The MID is also critical for fund routing during settlement. When the acquirer processes end-of-day batches, it uses the MID to determine which merchant bank account receives the net deposit. If a MID is misconfigured, funds can be delayed or routed incorrectly, one of the most common onboarding issues in payments.9

The Terminal ID identifies the specific physical device that processed the transaction. On our receipt: TID-4821. If the MID identifies the merchant, the TID identifies the register. A single-location diner might have one MID but three TIDs, one for each POS terminal at the counter.10

TIDs are assigned during terminal provisioning, when the acquirer (or their processor) configures the device and loads it with encryption keys, merchant credentials, and network certificates. Each TID is linked to a specific MID in the acquirer's system. When the terminal sends an authorization request, both the MID and TID travel in the message header, giving the acquirer a precise origin point for the transaction.

This granularity matters for several reasons. Fraud detection systems use TID-level patterns to identify compromised devices; if one terminal suddenly processes an unusual volume of high-value transactions, it can be flagged independently without shutting down the entire merchant. Chargebacks can be traced to the specific terminal, helping merchants identify problematic registers or employees. And settlement reports can be broken down by TID, letting a merchant reconcile revenue per register.11

The TID also plays a role in encryption key management. Point-to-point encryption (P2PE) schemes assign unique encryption keys per terminal.12 If a TID is decommissioned, its keys are revoked. If a terminal is replaced, a new TID is provisioned and linked to the merchant's MID. This ensures that even if a device is physically stolen, the encryption keys can be invalidated remotely without affecting other terminals in the merchant's fleet.

The line items and totals section is where the POS system's work is most visible. Each line (1x TUNA ON TOAST $4.50) represents a SKU lookup, price retrieval, and running total calculation performed by the POS software before any payment processing begins.

What's interesting from a payments perspective is that standard consumer authorization messages don't include line items. The authorization sent to Visa or Mastercard contains only the total amount, the currency, and the merchant category code — the networks only see the total. The itemized breakdown lives entirely within the POS system and the merchant's records. This is why your bank statement shows "MONKS CAFE NYC $10.07" and not "1 tuna on toast + a big salad + a tea."

There are exceptions. Level II and Level III data (enhanced transaction data that includes line-item detail) is used in commercial card (corporate/purchasing card) transactions.13 Government and enterprise buyers often require Level III data for compliance and expense management. Payment processors like Stripe and Adyen support passing this data, and merchants who provide it may qualify for lower interchange rates.14

Tax is calculated separately and displayed on its own line (TAX 8.875% $0.82) for good reason. Sales tax rates vary by jurisdiction (state, county, and city) and certain items may be taxed differently or exempt. The POS system must apply the correct tax table based on the merchant's registered location. In New York City, the combined state + city rate is 8.875%. This tax logic is entirely local to the POS; it never enters the card network's authorization flow.15

The receipt reads VISA CREDIT: two words that identify both the card network and the product type. This distinction matters because it determines how the transaction is routed, what interchange rate applies, and which set of network rules govern the transaction.16

Card networks are the rails that connect acquiring banks (merchant side) to issuing banks (cardholder side). The four major US networks (Visa, Mastercard, American Express, and Discover) each operate their own authorization, clearing, and settlement systems. Globally, China's UnionPay is the largest by number of cards (~9 billion), and JCB is significant in Asia-Pacific. When the terminal reads a card, the first 6–8 digits of the card number (the BIN or IIN) identify the issuing bank and the network. The terminal uses this to route the authorization request to the correct network.

"CREDIT" vs. "DEBIT" isn't just about where the money comes from; it changes the entire economic model of the transaction. Credit transactions typically carry higher interchange fees (the fee paid by the merchant's bank to the cardholder's bank) because they involve an extension of credit and greater fraud protection. Debit transactions may be routed over PIN debit networks (like Pulse, Star, or NYCE) that charge lower fees, and in the US, the Durbin Amendment caps debit interchange for large issuers.17

Some cards support dual-network routing: a Visa debit card might also be routable over a PIN debit network. The terminal or POS may choose the cheapest route, a practice called least-cost routing. This is invisible to the cardholder but significantly affects the merchant's cost per transaction. The receipt only shows the network that was actually used for the authorization.18

The receipt shows **** **** **** 1989, the last four digits of the Primary Account Number (PAN), with all other digits masked. This isn't a design choice; it's a PCI DSS requirement.19 Specifically, PCI DSS Requirement 3.4 mandates that the full PAN must never be displayed or stored in an unprotected manner, and Requirement 3.3 states that when the PAN is displayed, it must be masked so that only personnel with a legitimate business need can see more than the first six and last four digits.

On receipts, the standard is even stricter: only the last four digits are permitted on receipts. FACTA technically allows up to five digits, but card network rules (Visa and Mastercard) further restrict receipts to the last four.20 Merchants who print more than the last four digits on receipts face network fines and potential PCI non-compliance penalties.21

There's an important distinction between masking and truncation. Masking replaces digits with asterisks or similar characters for display purposes, while the full number may still exist in the system. Truncation permanently removes the digits; the system only ever stores the last four. POS terminals that are PCI-compliant typically truncate at the point of receipt generation: the full PAN was used during the authorization flow (encrypted end-to-end), but by the time the receipt is printed, only the last four digits remain in memory.

The last four digits serve a practical purpose: they let the cardholder confirm which card was used. If you carry multiple Visa cards, seeing "1989" helps you match the transaction to the right account. This is especially important for dispute resolution, since the cardholder needs to know which issuer to contact.22

But here's something that catches people off guard: if you pay with Apple Pay or Google Pay, the last four digits on the receipt often don't match your physical card. You tap your phone, glance at the receipt, and see four digits you don't recognize. This isn't a glitch. The terminal never saw your real card number. What it received was a Device Account Number (DPAN) — a completely separate 16-digit number issued by the card network's Token Service Provider and stored in your phone's Secure Element, a hardware chip isolated from the phone's operating system.23 Your real PAN never left the issuer-network channel. Each device gets its own unique DPAN; the same Visa card provisioned on your iPhone and your Apple Watch will have two different DPANs, each cryptographically bound to that specific device.

This creates a real problem for receipts. Because the terminal only ever saw the DPAN, it prints the DPAN's last four digits — not the digits embossed on your card. When a cardholder later tries to match the receipt to their statement, or files a dispute and the merchant pulls up a receipt showing unfamiliar digits, confusion follows. The EMVCo tokenization spec addresses this by including a "PAN last 4" field in the tokenized authorization response, giving the merchant the option to display the real card's digits instead of the DPAN's. Modern processors like Stripe expose this as dynamic_last4, but adoption is still inconsistent across the industry.24

The security upside is substantial. Even if a merchant's database is breached, the stolen DPANs are cryptographically useless: each one is bound to a specific device and requires the Secure Element's cryptographic keys to generate valid transaction cryptograms. An attacker can't clone a DPAN onto another device or use it for card-not-present fraud. This is a fundamentally stronger security posture than the traditional model, where a single breach of stored PANs can compromise millions of cards at once.

Our receipt reads CONTACTLESS / TAP, indicating the card was read via NFC (Near Field Communication). The entry method field records how the card data was captured, and it significantly affects the transaction's security profile, liability rules, and interchange pricing.

There are three primary entry methods for card-present transactions:

Magstripe (Swipe). The oldest method.25 The magnetic stripe on the back of the card contains static data: the card number, expiration date, and a service code. This data is the same every time you swipe. Because it's static, it's trivially cloneable; a skimmer device can capture the stripe data and produce a counterfeit card. Magstripe transactions carry the highest fraud risk and the highest interchange rates. In many markets, networks have imposed liability shifts that penalize merchants who accept swipe when the card has a chip.

EMV Chip (Insert/Dip). The chip on the front of the card contains a microprocessor that generates a unique cryptogram for each transaction. Even if someone intercepts the data, they can't reuse it; each cryptogram is valid for exactly one authorization. This is why chip transactions dramatically reduced counterfeit card fraud. The chip and terminal perform a cryptographic handshake (the EMV kernel), selecting the appropriate application (AID) and generating the authorization request. This takes 1–3 seconds, which is why "dipping" feels slower than swiping.

Contactless / NFC (Tap). Uses the same EMV chip technology but communicates wirelessly over NFC at 13.56 MHz.26 The cryptographic security is identical to chip-insert; each tap generates a unique cryptogram. The speed advantage comes from optimizations in the EMV contactless kernel: for low-value transactions, the terminal can skip some of the back-and-forth with the chip, enabling sub-500ms transaction times. This is why tap-to-pay feels nearly instant compared to inserting a chip.27

It's worth noting that modern payment flows increasingly use network tokenization rather than the actual card number (PAN). Apple Pay, Google Pay, and many e-commerce transactions transmit a token PAN (DPAN) issued by the card network, which maps back to the real card number at the network level. The entry method and AID on the receipt still apply, but the underlying card data flowing through the system may be a token rather than the PAN printed on the physical card.

The AID on our receipt reads A0000000031010. This hexadecimal string identifies the specific EMV application that was used during the chip/NFC transaction. To understand what this means, you need to understand that a single card chip can contain multiple applications (a Visa credit application, a Visa debit application, a domestic debit application) and the terminal must select which one to use.

The AID follows a standardized format defined by ISO 7816-5.28 The first 5 bytes (10 hex characters) are the Registered Application Provider Identifier (RID), which identifies the organization. The remaining bytes are the Proprietary Application Identifier Extension (PIX), which identifies the specific application. Let's decode our AID:

A000000003: this is Visa's RID. Every Visa application on every chip card in the world starts with these bytes. Mastercard's RID is A000000004, Amex is A000000025, and Discover is A000000152.

1010: this PIX identifies "Visa Credit/Debit (Global)," the standard Visa credit application used internationally. Other PIX values include 2010 for Visa Electron and 8010 for Visa's contactless payment application (though in practice, modern cards consolidate these).

During the EMV transaction, the terminal and card perform an application selection process.29 The terminal has a list of AIDs it supports; the card has a list of applications installed. They negotiate a match. If the card has multiple matching applications (say, Visa credit and a domestic debit network), the terminal's priority list or cardholder input determines which one is used. This is the technical mechanism behind "credit or debit?" at checkout.30

The authorization code 070589 is the issuing bank's proof of approval.31 When the cardholder tapped their card, a chain of events fired: the terminal sent an authorization request through the acquirer to the card network, which routed it to the issuing bank. The issuer evaluated the request (checking available balance, fraud rules, card status, velocity limits) and returned a response. That six-character code is the issuer saying: "Approved. Here's your receipt number for this decision."32

Authorization codes are typically 6 alphanumeric characters, generated by the issuer's authorization system. They're not globally unique (an issuer may recycle codes over time) but they're unique within the context of a cardholder account and a reasonable time window. The combination of auth code + card number + date is sufficient to uniquely identify the authorization decision.

This code serves multiple purposes in the payments lifecycle. During clearing and settlement, the auth code is included in the clearing record to match the settlement request back to the original authorization. If there's a mismatch (say the merchant submits a settlement for $20 but the authorization was for $10) the auth code helps the system flag the discrepancy.

For dispute resolution, the auth code is critical evidence. When a cardholder disputes a charge, the merchant can reference the auth code to prove the transaction was authorized by the issuer. If the issuer approved it, liability for certain fraud types shifts away from the merchant. The auth code is effectively the issuer's signature on the transaction, their documented decision to approve the payment.33

It's worth noting that an authorization is not a completed payment. It's a hold on the cardholder's available credit or balance. The actual movement of money happens during settlement, sometimes days later. If a merchant never settles the transaction (or voids it), the authorization hold expires and the funds are released back to the cardholder.

Every card transaction involves five parties, and the entire authorization round-trip completes in roughly 1–2 seconds. This is the complete journey of our $10.07 lunch purchase, from tap to "APPROVED."

The Cardholder taps their Visa card on the terminal. The NFC chip generates a unique cryptogram and transmits the card data (PAN, expiry, cryptogram) to the terminal over the 13.56 MHz radio link. This happens in about 300 milliseconds.

The POS Terminal receives the card data, constructs an ISO 8583 authorization message34 (the standard message format used across the payments industry), and encrypts it using the terminal's P2PE keys. The message includes the MID, TID, amount, currency, card data, entry method, and the EMV cryptogram. It's sent to the acquirer's processing platform over the merchant's network connection.

The Acquirer (Merchant's Bank) receives the authorization request, validates the merchant credentials (MID/TID), performs initial fraud screening, and routes the message to the appropriate card network based on the card's BIN. The acquirer adds its own identifiers and forwards the request. (In practice, the "acquirer" is often two entities: the acquiring bank that holds the merchant relationship and a separate processor like Fiserv, FIS, or Global Payments that runs the authorization platform. Many merchants deal with their processor, not the acquiring bank directly.)

The Card Network (Visa) receives the message, performs network-level fraud scoring (Visa's Advanced Authorization, for example, evaluates hundreds of risk signals in real time), and routes the request to the card's issuing bank. The network acts as the central switch; its primary role is routing, not decisioning — though networks can and do decline transactions in certain cases (network-level blocks, stand-in processing when the issuer is unreachable, and velocity checks). Visa's Advanced Authorization also provides risk scores that influence issuer decisions.35

The Issuing Bank (Cardholder's Bank) receives the authorization request and makes the final decision. It checks: Is the card valid and active? Is there sufficient credit/balance? Does this transaction trigger any fraud rules (unusual location, high velocity, known compromised merchant)? Does the cardholder have any spending restrictions? If everything passes, the issuer deducts the amount from the cardholder's available balance, generates an authorization code (070589), and sends an approval response back through the same chain: issuer, network, acquirer, terminal.

The cardholder taps, the terminal encrypts, the acquirer routes, the network switches, the issuer decides. Or, to summarize: tap, yada yada yada, approved. The terminal receives the approval, prints the receipt, and the cardholder walks away with their meal. But the money hasn't moved yet; that happens during settlement, covered in the next section.36

On the receipt: BATCH #: 0180 SEQ #: 0009. This tells us that our transaction is the 9th in batch 0180. But what does that mean? Authorization and settlement are two separate processes in card payments, and understanding the gap between them is key to understanding how money actually moves.

When you tap your card and see "APPROVED," the issuer has reserved $10.07 of your available credit. But no money has changed hands. The authorization is essentially a promise: "If you submit this transaction for settlement, we'll honor it." The actual transfer of funds happens during batch settlement.

Throughout the business day, the terminal accumulates authorized transactions into a batch, essentially a collection of all the approved transactions since the last settlement. Think of a batch like George Costanza's wallet: it can only hold so many transactions before it needs to be closed and processed. And just like George's wallet, waiting too long to settle creates problems. At the end of the day (or at a scheduled time), the merchant or POS system initiates a batch close. This sends all the transactions in the batch to the acquirer for processing.

The acquirer takes the batch and initiates the clearing process. Clearing is the exchange of financial details between the acquirer and issuer through the card network. The acquirer submits each transaction with its authorization code, amount, and merchant details. The network matches each clearing record to its original authorization. Discrepancies (like a different amount or a duplicate submission) are flagged.

After clearing comes funding. The issuer transfers the transaction amount (minus interchange fees) to the card network, which passes it to the acquirer (minus network fees), which deposits it into the merchant's bank account (minus the acquirer's processing fee).37 For a typical merchant, this end-to-end settlement takes 2–3 business days. On that $10.07 transaction, the merchant might receive roughly $9.77 after all fees are deducted, depending on their negotiated rates.38

The sequence number (SEQ #: 0009) is simply the transaction's position within the batch. If the merchant processes 200 transactions today, they'll be numbered 0001 through 0200 in the batch. This sequential numbering helps with reconciliation; the merchant's POS system can match each sequence number to its internal transaction record.39

The receipt reads CVM: NO CVM REQUIRED. CVM stands for Cardholder Verification Method, the mechanism used to confirm that the person using the card is actually the cardholder. In our case, no verification was required. This might seem insecure, but it's actually a deliberate decision encoded in the card's chip and negotiated during the EMV transaction.

The EMV specification defines several CVMs, arranged in a priority list on the chip. During the transaction, the terminal and card negotiate which CVM to use based on the transaction amount, the terminal's capabilities, and the card's CVM list. The main options are:

Online PIN. The cardholder enters a PIN on the terminal keypad, and it's verified in real-time by the issuing bank. The PIN is encrypted at the terminal using a PIN encryption key (PEK) and sent within the authorization message. This is the strongest cardholder verification for card-present transactions and is the standard in most markets outside the US.

Offline PIN. The PIN is verified locally by the chip on the card, without contacting the issuer. The chip stores an encrypted version of the correct PIN and compares it to what the cardholder enters. This is used in scenarios where the terminal might not have reliable network connectivity.

Signature. The cardholder signs the receipt or a digital pad. This is the weakest form of verification (signatures are rarely compared to anything) and has been largely phased out.40 Visa and Mastercard stopped requiring signatures in the US in 2018.

No CVM. No verification is required. This is common for contactless transactions below a certain threshold (often $100 in the US).41 The logic is that low-value tap transactions are already protected by the per-transaction cryptogram, and adding a PIN entry would negate the speed benefit of contactless. The card's CVM list explicitly says: "For contactless under [threshold], no CVM is acceptable." Our $10.07 meal falls well below this threshold, which is why the receipt shows NO CVM REQUIRED.

The CVM used for a transaction affects liability and interchange. Transactions with PIN verification generally have lower fraud rates and may qualify for lower interchange.42 No-CVM transactions are accepted because the fraud risk is mitigated by the low transaction amount and the EMV cryptogram; even without identity verification, the cryptographic proof that a genuine chip was present makes counterfeit fraud extremely difficult.