A CB card transaction, end to end. 6 chapters and a final quiz.

Chapter 1. From checkout to authorization request.

It all starts at checkout. In store, the cardholder presents the card at the POS terminal; online, they enter their details on a payment page. Either way, the process produces the same object: a standardized authorization message. It travels through the PSP, the acquirer, and the scheme to the issuing bank and back in under two seconds.

The ISO 8583 standard has structured these exchanges since the 1980s. Each message carries an MTI (Message Type Indicator, 4 digits) that identifies its type, followed by a series of data elements (DE): card number, amount, currency, terminal and merchant IDs, and EMV cryptographic data, among others. In France, the exchange between the acceptance point and the acquirer follows the CB2A protocol, derived from ISO 8583. Internationally, ISO 8583 remains the lingua franca of authorization, even as ISO 20022 takes over interbank messaging.

MTI   0100                        Authorization request (from acceptance point to issuer)
DE2   497010XXXXXX3742            Truncated PAN -- co-badged CB card (BIN 497010)
DE3   000000                      Processing code: purchase of goods or services
DE4   000000004250                Amount: 42.50 EUR (12 digits, no separator)
DE7   0709143205                  Transmission date/time (MMDDhhmmss)
DE11  002417                      STAN: unique trace number for the message
DE22  051                         Entry mode: EMV chip, PIN verifiable
DE41  POS00042                    Terminal ID
DE42  0451278900017               Merchant ID (acquirer contract)
DE49  978                         ISO 4217 currency: 978 = euro
DE55  9F2608A1B2C3D4E5F6A7...     EMV data: ARQC cryptogram, TVR, AIP

Matching 0110 response (the issuer returns, among other fields):
DE38  A1B2C3                      Authorization code issued by the issuer
DE39  00                          Response code: 00 = transaction approved

Chapter 2. Authorization and response codes.

On receiving the 0100, the issuer runs a series of checks in a few hundred milliseconds: the card is known and not expired, it is not blocked, the balance or credit line is sufficient, and payment and withdrawal limits are respected. Next come the validity of the EMV cryptogram, with the ARQC recomputed using the card's keys, and SCA compliance: authentication required, or an exemption that can be applied. Last comes real-time fraud scoring: geolocation, velocity, the cardholder's habits. The verdict fits in two characters, in field DE39.

Two resilience mechanisms are worth knowing. With stand-in processing, if the issuer doesn't respond, the scheme can answer on its behalf under agreed rules, using replicated limits and blocked-card lists; the issuer is notified of the transaction afterward. With timeouts, each link in the chain (terminal, PSP, scheme) sets a time limit. If no response arrives in time, the transaction is treated as incomplete and a reversal is sent to release any funds that may have been reserved (more on this in the incidents chapter).

Chapter 3. Capture and batching.

Authorization reserves the funds; capture (or completion) is when the merchant actually requests the debit. In store, authorization and capture happen almost simultaneously, but in e-commerce, scheme rules allow capture only once the goods ship. Hence deferred captures, partial captures (orders shipped in several packages), and incremental captures (hotels, car rentals).

Next comes the end-of-day batch upload (télécollecte in France): typically between 10 p.m. and 5 a.m., the terminal calls the acquirer and sends it the day's captured transactions as a single batch (remise). In e-commerce, the PSP builds and sends the capture files itself. The batch is the basic accounting unit shown on the merchant statement, and the merchant is credited batch by batch.

BATCH FILE -- batch 20260709-001
HEADER    TERM POS00042       merchant 0451278900017
          currency EUR        batch date 2026-07-09   time 22:04

DETAIL 01  PAN 497010XXXXXX3742   amount     42.50   auth A1B2C3   ref 002417
DETAIL 02  PAN 513120XXXXXX8821   amount    129.00   auth F7G8H9   ref 002431
DETAIL 03  PAN 497010XXXXXX0055   amount      8.90   auth K2L3M4   ref 002440   contactless

TOTAL      3 transactions         180.40 EUR
FOOTER     integrity check OK -- batch accepted by acquirer

Each DETAIL line carries the authorization code (DE38) and the trace
reference (STAN) obtained at authorization: this authorization -> capture
chain is what makes end-to-end reconciliation possible.

• Capture as close to authorization as possible: a late capture outside the validity window lowers the payment success rate and can be repriced by the scheme (late presentment).
• Partial capture rather than uncontrolled re-authorization: re-authorize only if the window has expired or the amount increases.
• Cancel authorizations you no longer need (a canceled order) with an explicit reversal: this frees up the cardholder's limit immediately.
• Track the triplet of authorized amount, captured amount, and authorization reference: it is the cornerstone of reconciliation.

Chapter 4. Clearing and settlement.

Two concepts you should never confuse. Clearing is information processing: matching batches and working out who owes how much to whom, usually as multilateral net positions, so that each bank ends up with a single balance against the system. Settlement is the actual transfer of funds, in central bank money; it extinguishes the interbank obligations for good.

For Visa or Mastercard transactions outside the domestic scope, clearing runs through the schemes' own systems: Base II clearing files at Visa, IPM/GCMS at Mastercard. The scheme handles multicurrency settlement across its member banks' settlement accounts. Timelines are longer: funds reach the acquirer on D+1 to D+3, plus any currency conversion fees.

Chapter 5. Interchange, fees, and co-badged cards.

The merchant service charge (MSC) the acquirer deducts is not an opaque lump. It stacks three layers: interchange, paid to the issuing bank; scheme fees, paid to the network (CB, Visa, or Mastercard); and the acquirer margin, which covers the service, the risk, and the technology. Pricing is called interchange++ when the three layers are billed separately and transparently. That model has become standard for larger merchants, while small contracts stay on blended flat-rate pricing.

The EU's IFR (Interchange Fee Regulation 2015/751) caps interchange on consumer cards: 0.2% on debit, 0.3% on credit. Commercial cards (business, corporate) are exempt from the caps. Their interchange can exceed 1.5%, which is why some merchants monitor them closely. The IFR also separated schemes from processing, and established freedom of routing on co-badged cards.

The quintessential French case: co-badged CB/Visa and CB/Mastercard cards

Nearly all French payment cards (~95%) carry two brands: CB (the domestic scheme) and Visa or Mastercard (the international brand). On the same domestic transaction, the merchant can therefore route to CB or to the international brand. Article 8 of the IFR splits the roles. The merchant can set a default choice (pre-selection) on its terminal or payment page, but the cardholder has the final say if they express a preference. In practice, the vast majority of cardholders leave it as is, so the merchant's pre-selection prevails and its configuration becomes a direct cost lever.

Chapter 6. Merchant statement, reconciliation, and incidents.

The merchant statement is the document (or data feed) through which the acquirer reports to the merchant: batches received, fees deducted, chargebacks debited, fixed charges. It is the bank-side source of truth, to be checked systematically against the merchant's internal data.

MERCHANT STATEMENT -- period 07/06 to 07/12/2026 -- contract 0451278900017

BATCH 07/06    gross  2,412.80   45 txns    <- end-of-day batch of 07/06
BATCH 07/07    gross  1,897.15   38 txns
BATCH 07/09    gross    180.40    3 txns    <- our batch 20260709-001
FEES           MSC 0.42%           -18.86   <- blended rate applied to gross
CHARGEBACK     ref 002198          -59.90   <- reason: goods not received
FIXED FEES     terminal rental     -12.00

NET SETTLED    4,399.59
               credited to account on 07/13, value date 07/13

Check: 2,412.80 + 1,897.15 + 180.40 = 4,490.35 gross
       4,490.35 - 18.86 - 59.90 - 12.00 = 4,399.59 net

Three-way reconciliation matches three independent sources: (1) orders or receipts in the merchant's system, in-store register or e-commerce; (2) transactions as seen by the PSP or acquirer: authorizations, captures, and batches; (3) actual credits on the bank statement, ideally in structured camt.053 format. Every discrepancy has a finite set of causes: a fee deducted, a refund issued, a chargeback debited, a value-date shift, a rejected batch, a rolling reserve holdback. Run daily and automated, it turns “unexplained discrepancies” into a simple list of exceptions to work through.

The last link, the chargeback, deserves a course of its own. Here, just remember its place in the chain: it comes after settlement, sometimes weeks later, and shows up as a retroactive debit on the merchant statement. A transaction can therefore be undone very late, so reconciliation never stops on the day of payment. It follows each transaction until the end of its full life cycle.