Put Card payment authorization back in order

THE DRILL AS TEXT

1. In Card payment authorization, what happens first, and what follows?
   • Maya presents her card — Maya taps her card for a EUR 42.50 catering order. The terminal reads the chip or contactless data defined by EMV (the chip-card standard maintained by EMVCo) — including a one-time cryptogram that proves a real card was present.
   • The terminal builds and sends the authorisation request — The terminal packs the card data, amount and merchant details into an authorization request — a 0100 message in ISO 8583, the card industry's messaging standard — and sends it to Meridian Bank, the acquirer that serves Demo Coffee.
   • Meridian Bank forwards the request to Cardnet — The acquirer checks the merchant is one of its own and the message is well formed, then forwards the request into the card network. The acquirer cannot approve — only the card's issuer can say yes.
   • Cardnet routes the request to Bank Alfa — The network reads the bank identification number (BIN) — the opening digits of the card number — recognises Bank Alfa as the issuer, and delivers the request to it.
   • Bank Alfa checks the card, the funds and the risk — The issuer decides in well under a second: is the card open, does the EMV cryptogram verify, do funds cover the amount, and does the fraud engine trust this purchase? Approve or decline — the whole flow exists for this moment.
   • Bank Alfa approves and responds — The issuer answers with a 0110 response carrying an approval and an authorisation code — a short reference that will later tie the clearing record back to this exact approval.