Authorization Flow

The foundational structure of a payment authorization involves four distinct entities communicating in a precise sequence:

• Cardholder: Initiates the transaction at the point of sale.
• Merchant (Acquirer): The business accepting the payment, whose bank forwards the request.
• Acquiring Processor: The merchant's financial institution that routes the authorization request.
• Issuing Processor: The cardholder's bank that holds the funds and makes the final approve/decline decision. This model ensures liability and risk are distributed across known, authenticated parties.

The universal standard for financial transaction messaging. An ISO 8583 message is a tightly packed binary or ASCII frame containing:

• Message Type Indicator (MTI): A 4-digit code defining the message function (e.g., 0100 for an authorization request, 0110 for a response).
• Bitmaps: A binary map indicating which data elements are present, enabling efficient parsing.
• Data Elements: Standardized fields like Processing Code (DE 3), Transaction Amount (DE 4), and Response Code (DE 39). This strict schema allows heterogeneous systems across global networks to interoperate without ambiguity.

Not all authorizations require a live connection to the issuer. The flow bifurcates based on connectivity and risk:

• Online Authorization: A real-time request is sent to the issuer for a definitive approve/decline. Required for most card-not-present transactions.
• Offline Authorization: The terminal itself makes a decision using risk parameters stored on the chip card and floor limits. Common in transit systems with low connectivity.
• Stand-In Processing (STIP): The network acts as a proxy issuer when the issuer's system is unavailable, applying pre-agreed risk thresholds to prevent service disruption.

The issuer's decision is communicated via a standardized numeric code in the response message. Critical categories include:

• Approval (00): Transaction honored. Funds are earmarked for capture.
• Soft Decline (e.g., 51, 65): Insufficient funds or limit exceeded. The merchant can retry with a lower amount or different tender.
• Hard Decline (e.g., 05, 41): Do not honor or lost card. Retries are forbidden, and the card may be retained.
• Referral (01): The issuer requires the merchant to call for voice authentication before proceeding. These codes directly trigger the point-of-sale experience and fraud workflow.

The authorization flow is decoupled from the financial settlement in most card networks, creating two distinct processing paradigms:

• Dual-Message System: Authorization (0100/0110) and Clearing (0220/0230) are separate transactions. The merchant authorizes first, then submits a batch for settlement later. This is the standard for credit cards.
• Single-Message System: The authorization request simultaneously triggers the financial transaction and settlement. Used for PIN-based debit networks where funds are debited immediately. This distinction impacts liquidity, reversals, and the timing of fraud detection windows.

A robust authorization flow must gracefully degrade when primary paths fail. Key mechanisms include:

• Chip-to-Magstripe Fallback: If the EMV chip is unreadable, the terminal falls back to reading the magnetic stripe, shifting liability to the merchant.
• Circuit Breaker Pattern: If the fraud scoring engine times out, the system defaults to a safe mode—typically declining the transaction or routing to a static rules engine.
• Idempotency Keys: A unique key generated by the acquirer ensures that a retried authorization request does not result in a duplicate charge, maintaining exactly-once semantics.

A specialized software component that aggregates multiple analytical signals and applies machine learning models to calculate a numerical score representing the probability of fraud for a given transaction. It operates within the strict latency budget of the authorization window.

• Combines velocity checks, device fingerprints, and behavioral models
• Returns a score typically between 0 and 1000 to the authorization system
• Must execute with P99 latency under 50ms to avoid customer friction

A unique value generated by the client to ensure that a single operation is executed exactly once, preventing duplicate side effects in the event of network retries. Critical for payment authorization where a retry could result in a double charge.

• Typically a UUID v4 or a hash of the transaction payload
• Stored by the server and checked on subsequent requests
• Enables safe retry logic without risking duplicate financial postings

A software design pattern that prevents a system from repeatedly trying an operation likely to fail, allowing it to fail fast and gracefully degrade when an external service is unavailable. In authorization flows, this protects the payment ecosystem from cascading failures.

• Three states: Closed (normal), Open (failing), Half-Open (testing recovery)
• Prevents resource exhaustion when the issuer or network is unresponsive
• Often paired with a fallback mechanism like stand-in processing

The process of augmenting a raw transaction event in real-time with additional contextual data from external services. This transforms a basic authorization request into a feature-rich event for accurate risk assessment.

• Adds device fingerprinting data to identify returning devices
• Incorporates geolocation and IP intelligence for velocity checks
• Joins against watchlists and known fraud indicators via stream-table joins

A flow control mechanism that prevents a fast data producer from overwhelming a slower consumer by applying a feedback signal to slow down or buffer the incoming data stream. Essential when authorization traffic spikes during peak shopping periods.

• Implemented via reactive streams or message queue depth monitoring
• Prevents out-of-memory errors in scoring engines
• Can trigger adaptive throttling to maintain system stability