diagram.mmd — sequence
Credit Card Authorization sequence diagram

Credit card authorization is the first of two phases in card-not-present payments: it asks the issuing bank to verify the card and reserve the requested funds without actually debiting the account. The debit occurs separately during the capture phase.

The authorization chain begins at the acquirer — the merchant's bank. The merchant's payment terminal or gateway packages the transaction details (PAN, expiry, CVV, amount, merchant ID) into an ISO 8583 message and sends it to the acquirer. The acquirer forwards the message to the appropriate card network (Visa, Mastercard, Amex) based on the card BIN prefix. The card network routes the request to the issuing bank that issued the card to the cardholder.

The issuer runs a battery of checks. First, it validates the card number using the Luhn algorithm and confirms the card is not expired or reported stolen. It checks that the CVV matches. It evaluates fraud rules: is this a typical transaction for this cardholder? Is the merchant category unusual? Is the amount within normal range? If the issuer has enrolled the card in 3D Secure, it may insert an additional cardholder verification challenge before responding — see 3D Secure Authentication.

The issuer responds with either an approval (including a six-digit authorization code that serves as a reference for settlement) or a decline with a reason code. Reason codes are standardized but some are intentionally vague — issuers do not want fraudsters to know exactly why a card was declined.

The response travels back through the card network to the acquirer and ultimately to the merchant. The merchant stores the authorization code, which is required to complete Payment Capture Flow later. Authorization holds typically expire after 7–30 days if not captured.

Free online editor
Edit this diagram in Graphlet
Fork, modify, and export to SVG or PNG. No sign-up required.
Open in Graphlet →

Frequently asked questions

Credit card authorization is the first phase of a card payment. The issuing bank verifies the card and reserves the requested funds without debiting the account. The reserved funds are only moved during a subsequent capture step.
The merchant or gateway packages the transaction details into an ISO 8583 message and sends it through the acquirer and card network to the issuing bank. The issuer validates the card, checks fraud signals, and returns an approval with a six-digit authorization code or a decline with a reason code.
Separate auth and capture when fulfilment is delayed — hotels pre-authorise at check-in and capture at checkout, marketplaces authorize at order time and capture on shipment. This avoids refunds for cancellations and keeps funds held only as long as necessary.
Common mistakes include not storing the authorization code for later capture, ignoring soft-decline codes that hint at retryable failures, capturing more than the authorized amount, and allowing authorization holds to expire before capturing.
mermaid
sequenceDiagram participant Merchant participant Acquirer as Acquirer Bank participant Network as Card Network participant Issuer as Issuing Bank Merchant->>Acquirer: Authorization request (PAN, CVV, amount) Acquirer->>Network: Route via card BIN prefix Network->>Issuer: Forward authorization request Issuer->>Issuer: Validate card number (Luhn check) Issuer->>Issuer: Verify CVV and expiry Issuer->>Issuer: Check available funds or credit limit Issuer->>Issuer: Evaluate fraud scoring rules alt Approved Issuer-->>Network: Approval + authorization code Network-->>Acquirer: Forward approval Acquirer-->>Merchant: Approval + auth code else Declined Issuer-->>Network: Decline + reason code Network-->>Acquirer: Forward decline Acquirer-->>Merchant: Decline + reason code end Merchant->>Merchant: Store auth code for capture
Copied to clipboard