How Card Payments Work

Your $10 coffee purchase is a lot more complex than you think

Welcome and Context

Hello all.

Welcome and welcome back.

First of all, to my longtime readers, thank you for your continued readership and support. After some consideration, I’ve decided to pivot my content to focus almost exclusively on my area of interest these days, which is how money moves through engineered systems, or what I call money as infrastructure.

So, let’s get into the weeds of money as infrastructure. The most fitting place to start, and where a lot of basic payment understanding begins, is the anatomy of a payment, specifically, a card payment.

What Happens in a Payment?

Payments come in many flavors, and there isn’t just one way to move money. Over time, I’ll cover a wide range of models, but we’ll start with the most common transaction across digital rails, the card payment.

Broadly, card payments can be split into two types. Card Present (CP) occurs when the physical card, or a device such as your phone or watch, is tapped, dipped, or swiped at a terminal. Card Not Present (CNP) occurs when you pay online or in-app without the card being physically present.

To illustrate this, consider a simple case: a customer buys a $10 coffee in a store (get a load of these prices, huh). They swipe, and presto changeo, the vendor gets paid. On the surface, it looks trivial. Underneath, it is a carefully choreographed exchange of cryptography, risk checks, and structured messages flying across networks in well under a second.

The Payment Process

Before we proceed, a few abbreviations will keep us oriented. Customer (C) is the cardholder who pays. Card Issuer (CI) is the customer’s bank that issued the card. Merchant (M) refers to the business that accepts the payment. Acquirer (A) is the merchant’s bank or processor. A network (N) is the card network, such as Visa, Mastercard, and others, that routes messages and enforces rules.

In its simplest form, the chain looks like this:

Customer → Merchant → Acquirer → Network → Issuer → back again

Textually, the customer uses their bank-issued card with the merchant. The merchant’s acquirer sends the transaction through the network, which routes it to the issuer for authorization. The issuer replies with an approval or decline, and that answer propagates back to the point of sale.

Where do PSPs like Stripe fit in?

You might be wondering where the developer-friendly APIs, such as Stripe, Adyen, and Checkout.com, sit in this context. These companies are Payment Service Providers, PSPs. They abstract the old payment rails and present clean APIs, so that a merchant does not have to implement raw card network protocols, manage tokenization and vaulting, or handle PCI scope on their own. PSPs offer onboarding and KYC flows, risk tooling, tokenization and wallets, reporting, reconciliation aides, and payouts. They often also have acquiring capabilities (a fancy way to say they directly connect to the networks).

A quick but essential clarification about Merchant of Record: in a Payment Facilitator, PayFac model, such as Square, which serves many small merchants, the platform itself is the Merchant of Record and onboards individual businesses as sub-merchants under its umbrella. In other products and regions, companies like Stripe and Adyen operate as acquirers or processors, while the business itself remains the Merchant of Record with its own merchant ID. So, sometimes the PSP is effectively the MoR for sub-merchants, while at other times it serves as a gateway or acquirer, with the merchant remaining the MoR. It depends on the product and jurisdiction.

So how do merchants, or any of the parties in these transactions, make money?

Fantastic question. If you are unfamiliar with the term bps, coolly pronounced bips, this is a perfect place to learn it. One basis point is one hundredth of a percent, 1 bps = 0.01%. In card payments, everyone gets a few basis points, and that global fee waterfall is what funds the rails.

Using the $10 coffee as an example:

• The issuer, the cardholder’s bank, earns interchange, typically around 130 to 180 bps, 1.3 to 1.8 percent, for credit transactions and 20 to 80 bps for debit, because the issuer fronts the credit line, takes fraud risk, and often funds rewards.

• The network, such as Visa or Mastercard, charges an assessment fee of around 10 to 15 basis points (bps) for operating the rails.

• The acquirer or processor earns around 20 to 30 basis points (bps) plus a small fixed fee for connecting the merchant, handling clearing and settlement, and being within the PCI (Payment Card Industry) scope.

• The PSP, or PayFac, adds its markup, often 40 to 100 bps plus a fixed fee, which is typically 30 cents, because it provides the APIs, tokenization, fraud tooling, dashboards, and operational lift that make card acceptance feasible for thousands of businesses.

• The total cost to the merchant, known as the Merchant Discount Rate, typically ranges from 2 to 3 percent for credit and under 1 percent for debit, although actual pricing varies by country, card type, merchant category, volume, and deal terms.

Put simply, you pay $10, and the café typically sees around $9.70 to $9.80 after fees. Daylight robbery, I know! The rest of that cash funds the infrastructure that actually moved your money.

Edge cases you will actually hit

The in-person card-present flow is the happy path. But real life includes variations that every merchant eventually encounters. Let’s run through a few.

Card Not Present, CNP

CNP is the e-commerce or in-app world. There is no physical chip read; instead, the merchant collects the PAN (long card number), expiry date, CVC, billing address, and device or browser signals. Security here relies on EMV 3-D Secure, also known as 3DS, which can provide frictionless, risk-based approval with no challenge, or step-up, OTP, or app approval. Fraud risk is structurally higher online, which is why pricing is often higher; additionally, with 3DS liability, it can shift away from the merchant for many transactions.

Apple Pay and Other Wallets

Present but not present, Apple Pay deserves its own section. The wallet provides a DPAN, a device-specific token that substitutes for the real PAN, along with a payment cryptogram generated by the device’s secure element for that transaction. The real PAN never leaves the phone. These typically price like card-present transactions, with a better fraud profile, because tokenization reduces the payoff for stealing the primary account number. Interestingly, the invention of Apple Pay’s network tokenization required a substantive reinvention of how card payments worked under the hood. The technology was innovative and novel at the time, though we take it for granted now.

Adding Tips and Adjustments

There are often adjustments and incremental authorizations in verticals like hospitality and fuel. Restaurants usually do an initial approval and then adjust or capture the final amount once a tip is added. Hotels and car rentals run incremental authorizations for incidentals during the stay and complete the transaction at checkout. Fuel stations perform a pre-authorization for a fixed amount when you insert your card, and later complete the transaction for the pump total. The engineering ‘gotcha’ here is to make captures idempotent and to link every adjustment back to the original authorization via identifiers like the STAN and RRN so that you can reconcile cleanly.

Failures and Payment Fallbacks

Networks and banks are not always perfectly accessible in real-time. If the outcome is unknown because a response never came back, the merchant should send a reversal to clear any ghost hold on the cardholder account. Networks and issuers sometimes provide stand-in approvals with limited checks during outages to maintain commerce. If a chip or contactless flow fails, a magstripe fallback, swipe, can be used; however, it carries a higher fraud risk and may incur different fees.

The Engineering Deep-Dive

If you are an engineer, this is where it gets fun. If you are just curious about what is happening under the hood, it is equally fascinating.

Let’s recap the actors in the system:

1. The cardholder uses an EMV chip, contactless NFC, or a tokenized wallet, such as Apple Pay.

2. The merchant includes the point-of-sale terminal and backend system, or a website and gateway SDK in e-commerce.

3. The PSP, or PayFac, exposes the API that the merchant calls and either acts as an acquirer or routes to one.

4. The acquirer or processor communicates with the card networks using ISO 8583 and settles funds with the merchant.

5. The network routes and enforces rules.

6. The issuer, the cardholder’s bank, makes authorization decisions and ledger postings.

7. All of this is held together by HSMs, tamper-resistant hardware that stores keys and performs cryptographic operations, such as PIN encryption and EMV cryptogram verification.

Inside the Authorization Path

At the payment terminal, the EMV flow begins by selecting the AID (Application Identifier), reading card data, and generating an unpredictable number, known as the UN. The card computes an ARQC, a per-transaction cryptogram created with keys seeded from the issuer.

If a PIN is required, it never traverses the network in the clear; instead, it is encrypted using DUKPT (Derived Unique Key Per Transaction), so that each PIN entry uses a different key.

In Apple Pay or Google Pay, the device sends a DPAN token and a cryptogram generated by the secure element; the actual PAN is hidden in a network token vault.

The terminal forwards a bundle of fields, PAN or DPAN, amount and currency, terminal capabilities, the EMV tag set, Data Element 55, an optional PIN block, and timestamps, to the merchant backend.

From the terminal to the merchant backend, transport runs over TLS or TCP. The message may be vendor-specific JSON or already in ISO 8583 format. The backend enriches it with order ID, merchant identifiers, and location, then calls the PSP.

The PSP validates the schema, performs basic risk checks, including velocity limits and historical fraud signals, and device fingerprinting for CNP. It then decides how to route, choosing an acquirer and network path based on configuration, cost, and performance.

From PSP to acquirer or processor, the message is transformed into a formal ISO 8583 authorization request, MTI 0100, or the network’s native wire format. ISO 8583 is a compact, binary, packed bits protocol that has held this ecosystem together since the 1980s.

An authorization request can include:

• DE2, PAN or DPAN

• DE3, processing code

• DE4, amount in minor units

• DE11, STAN, System Trace Audit Number

• DE14, expiry

• DE22, POS entry mode

• DE23, PAN sequence, for EMV

• DE35 or DE45, track data, if the transaction is magstripe

• DE52, encrypted PIN block

• DE55, EMV data, with ARQC

• DE123 or DE127, private fields carrying 3DS or wallet risk signals

The acquirer’s HSM decrypts the PIN block if required, and the EMV data is forwarded intact so the issuer can verify it.

The acquirer routes the message to the network, adding identifiers, merchant category code, and interchange markers. The network performs checks and forwards the transaction to the issuer determined by the BIN, which is the first 6 to 8 digits of the card.

At the issuer, the authorization engine checks the card’s status, available balance or credit limit, and runs fraud scoring based on merchant type, geography, and velocity. It validates CVV and the EMV cryptogram.

If the transaction is CNP and the merchant invoked 3-D Secure, the issuer’s Access Control Server may provide frictionless approval or step-up verification. The issuer then approves or declines, generates an authorization code, and sets result codes, for example, DE39, AVS, or CVV result.

The response travels back through the network, to the acquirer, to the PSP, and finally to the merchant’s POS. The terminal displays ‘Approved’ or ‘Declined’ and prints a receipt with the authorization code, the last four digits, and the timestamp.

Two Edge Conditions

Two edge conditions matter most operationally.

1. Timeouts. If the merchant times out and is unsure whether the issuer has approved, it should send a reversal, MTI 0400, to clear any potential hold.

2. Speed. Because speed is a key part of the user experience, most stacks target sub-second decision-making, with an end-to-end latency of under 800 ms. PSPs and acquirers maintain warm connections and use efficient binary parsers for ISO 8583 to minimize latency.

That is the real-time path of a transaction.

When does the money actually move?

Those authorization steps occur in seconds, but the actual transfer of money happens later, through clearing and settlement.

After authorization, the merchant, or PSP, captures the transaction. For retail, this is usually immediate. For hotels or restaurants, the payment may be delayed until the final amount is confirmed.

Captured transactions are aggregated into clearing files, often in fixed-width or tag-value formats, which contain data for fees and postings. These transactions flow on a scheduled cycle from the merchant or PSP to the acquirer to the network, sometimes multiple times a day.

Networks compute interchange and assessments, net positions across acquirers and issuers, and initiate funds transfer. Actual money movement typically occurs on T+1 or T+2.

The acquirer then pays the merchant on the agreed cadence, daily or weekly, net of fees. On the merchant side, a reconciliation job matches authorizations, captures, clearing records, and deposits, and investigates any discrepancies, late presentments, or disputes.

The time it takes for a merchant to be settled is known as the settlement delay, which in some regions can extend to 30 days.

What is the language of these payments?

When I reached this point in my own research, my next question was simple: What programming language is this written in? More specifically, which languages and frameworks have been around since the early days of card payments, and which are still used now?

The answer is quite dissatisfying as it’s scattered across various languages and frameworks for different aspects of the card payment stack.

• Terminals and secure elements: C or C++

• Android POS apps: Java or Kotlin

• iOS wallets: Swift or Objective-C, cryptography handled by the OS secure element

• Merchant web checkouts: JavaScript or TypeScript

• Mobile apps: Swift or Kotlin

• Merchant backends: Go, Java, C#, or Node.js

• PSPs and gateways: Java or Go on the hot path, C# and Node.js in some shops, Python for model training and offline jobs

• Data and infra: Postgres or MySQL, Redis for hot keys, Kafka or NATS or RabbitMQ for streams, ClickHouse or BigQuery or Snowflake for analytics

• Acquirers and processors: historically C or C++ or Java, many modern switches are Java or Go

• Networks: heavy Java or C++ estates with mainframe COBOL or PL/I are still important for some clearing workloads

• Issuers: Java, C++, and sometimes Go, with extremely hot in-memory caches.

• Core ledgers: COBOL on mainframes in legacy cores, Java or C# in newer cores

• Fraud platforms: real-time scoring in Java or Go, analytics in Python

• Cryptography everywhere: HSMs integrated via PKCS#11 or vendor SDKs from C, Java, or C#

Closing Thoughts

Anyway, that’s all for today. Hopefully, this made the complex workings behind every card swipe a little clearer.

There are not many resources that combine engineering, economics, and operations of payments in one place, so I wanted to write the one I wished I had. If you want to delve deeper, the sources I found helpful were “Field Guide to Global Payments” by Sophia Goldberg, “The Anatomy of a Swipe: Making Money Move” by Ahmed Siddiqui, and “Payment Card Domain Knowledge” by Ajay Kumar.

Next time, we will examine how banks actually store money and how ledger systems operate.

Until then, thanks for reading.

Bye.