Card Auth Flow Visualizer

What happens in the two seconds after you tap your card. Pick a scenario, then step through the round trip: the panel shows the actual ISO 8583 fields riding along at each hop. New here? Read how card authorization works first.

What you are looking at

Five parties and nine steps. Steps 1 to 4 carry the request outward: from your card to the merchant's terminal, from the terminal to the merchant's bank (the acquirer), from the acquirer to the card network, and from the network to the bank or program that issued your card. Step 5 is the issuer's decision. Steps 6 to 8 bring the answer back along the same path. The whole round trip usually takes one to three seconds, and most of that is network latency rather than thinking.

Step 9 is the part the beep hides. "Approved" means the issuer has promised to pay; no money has moved. The merchant sends the final amount later in a daily batch, the network prices the transaction, and the banks settle the net difference between them, typically the next business day. Pending charges at the wrong amount, fuel-pump holds and slow refunds all live in that gap. Clearing vs settlement follows the money through it.

The fields in the panel

The message format is ISO 8583, first standardised in 1987 and still carrying most card payments. Fields are numbered rather than named, which is why the panel shows "DE" (data element) and a number. The ones the demo shows are the ones that decide the outcome.

Field	What it carries	Why it matters to you
MTI	Message type: 0100 is a request, 0110 the response, 0400 a reversal.	Tells every party what kind of message just arrived.
DE 2	The card number (PAN). Its leading digits are the BIN, which identifies the issuing program.	The network routes by BIN. A wrong-issuer route is impossible; a wrong-program decision is not.
DE 4	The amount, as twelve digits with no decimal point. 000000004312 is $43.12.	The currency in DE 49 says where the point goes. This is the figure the issuer reserves.
DE 11	The trace number (STAN).	The response carries the same number, so the terminal can match answer to question.
DE 18	The merchant category code (MCC), such as 5411 for groceries or 7995 for gambling.	Card programs block whole categories. Balance is irrelevant if the category is blocked.
DE 22	How the card was read: 07 means contactless.	A chip or tap is stronger evidence than a typed number, and is priced accordingly downstream.
DE 38	The approval code the issuer assigned.	Printed on your receipt. It is the reference for a later dispute.
DE 39	The response code: 00 approved, 51 insufficient funds, 57 transaction not permitted, 91 issuer unavailable.	The real reason behind a "Declined". Most declines are deliberate, readable decisions.
DE 41, DE 42	The terminal and merchant identifiers.	They are how a purchase is tied to a shop when you query it later.
DE 55	The chip cryptogram.	A one-time proof the card is genuine, which is why cloning a chip card is impractical.

Where a crypto card differs

Nothing about the route changes. The terminal, acquirer and network treat a stablecoin card as an ordinary Visa or Mastercard, because on the network it is one. The difference is inside step 5. The card program checks your stablecoin balance and converts just enough of it into the purchase currency to cover the amount, then answers like any issuer. Three consequences follow.

Response code 51 is the common decline. A crypto card balance is usually a small float, and it can run out because a network fee took the remainder or because a purchase in another currency cost more than the alert suggested.
Response code 57 has nothing to do with money. Prepaid and crypto card programs commonly block gambling, money services and quasi-cash categories outright. If a card with plenty of balance refuses one shop and works everywhere else, the merchant category is the first thing to check.
Holds bite harder. An authorization reserves the amount against your balance. On a credit card with a large limit nobody notices; on a float of a few hundred dollars, one hotel check-in can freeze everything you loaded until the hold clears.

The crypto card guide covers how these programs are put together, and what a depeg does to a U-card holder covers the case where the conversion at step 5 happens at a price below $1.

Reading a decline

The terminal says "Declined" and nothing else, but the response code in DE 39 carries the reason, and the merchant's receipt or your card app usually shows it. Read it before retrying. A 51 means add funds. A 57 means this shop's category is blocked and retrying will not help. A 91 means the issuer did not answer in time; that is not a judgement about you or your balance, and a retry a minute later often goes through. In the timeout scenario the network may also approve a small amount on the issuer's behalf using stand-in rules, and if a late approval then collides with the decline, a 0400 reversal cleans up the duplicate. Stand-in processing and reversals explains why that sometimes leaves a pending line on your statement for a few days.

What the demo leaves out

The pace is not real. The animation is slowed down so you can read it; a real round trip is over in a second or two.
A real message carries many more fields. The panel shows the ones that decide approval, pricing and matching, not the full record.
Phone wallets do not send your card number. When you pay with a phone, DE 2 carries a network token instead of your real PAN, and the whole chain works on the token. How tokenization works covers the substitution.
Online purchases add a step before this one. A website may authenticate you first (the bank's one-time code or app prompt) and only then send the authorization. 3-D Secure and strong customer authentication covers that step.
Step 9 is compressed. Clearing is also where the network prices the transaction and the merchant's bank pays your issuer interchange. That fee never touches your bill, but it explains why shops behave the way they do at the till.
PIN debit and ATM withdrawals work differently. They send authorization and clearing as a single message, so there is no pending stage and no amount that changes later. The demo shows the two-message flow used by credit and most card purchases.