# Authorization and preauthorization

### Card Authorization Flow <a href="#id-5d01" id="id-5d01"></a>

<details>

<summary>Step 1: The Request Starts at the POS Terminal</summary>

The POS terminal reads the **Card Data** (PAN, expiry, secure EMV chip data).

The terminal captures the **Transaction Details** (amount, merchant ID, terminal ID).

Crucially, the EMV chip generates a **unique, one-time-use cryptographic code** to ensure the transaction is secure and cannot be cloned.

</details>

<details>

<summary>Step 2: POS → Acquirer (The First Leg)</summary>

The terminal takes all the data(Merchant ID, Cardholder data, Amount & Currency, Terminal ID, Location, Transaction type — chip, swipe, contactless) and packages it into an encrypted **Authorization Request** message (using the **ISO 8583 standard**).

This request is immediately sent to the **Acquirer** (or the Processor managing the merchant’s account). The Acquirer’s job is to prepare the message for the global network.

</details>

<details>

<summary>Step 3: Acquirer → Card Scheme (Routing the Message)</summary>

The Acquirer has received the request. Now it must find the correct Issuing Bank to approve the money.

1. The Acquirer routes the request to the relevant **Card Scheme** (Visa or Mastercard).
2. The Scheme acts as the central traffic cop. It reads the first 6–8 digits of the card (the **BIN Range**) to identify **which Issuer** around the world handles that card. E.g., Cards starting with *5xxxxxx* → Mastercard, ards starting with *4xxxxxx* → Visa
3. The Scheme then forwards the request packet to the correct Issuing Bank.

</details>

<details>

<summary>Step 4: Card Scheme → Issuer (The Decision Point)</summary>

This is the moment of truth. The Issuing Bank receives the request and performs a rapid-fire series of checks in milliseconds:

* <mark style="color:red;">**Validity Check:**</mark> <mark style="color:red;"></mark><mark style="color:red;">Is the card active, not expired, and not flagged as stolen?</mark>
* <mark style="color:red;">**Balance Check:**</mark> <mark style="color:red;"></mark><mark style="color:red;">Are there sufficient funds or credit available?</mark>
* <mark style="color:red;">**Security Check:**</mark> <mark style="color:red;"></mark><mark style="color:red;">Is the PIN/CVV correct? Does the unique</mark> <mark style="color:red;"></mark><mark style="color:red;">**EMV cryptogram**</mark> <mark style="color:red;"></mark><mark style="color:red;">validate?</mark>
* <mark style="color:red;">**Fraud Check:**</mark> <mark style="color:red;"></mark><mark style="color:red;">Does the transaction location, amount, or merchant type match the cardholder’s spending habits?</mark>
* <mark style="color:red;">Is the merchant category allowed?</mark>
* <mark style="color:red;">Is the user within their daily limits?</mark>

If all checks pass, the Issuer generates an **Approval** response and places a **hold** on the funds. If any check fails, it sends a **Decline**.

</details>

<details>

<summary>Step 5: The Response Returns to the POS</summary>

The Approval/Decline message travels back through the exact same path but in reverse:

*<mark style="color:red;">Issuer → Scheme → Acquirer → Processor → POS Terminal</mark>*

The POS displays the final result, and the merchant hands you your coffee. The entire journey, from tap to approval, took less time than a blink.

</details>

***

WHEN PREAUTHORIZATION

* A gas pump doesn't have the total sale amount until after the gas is dispensed.
* A car rental agency wants to cover the cost of a delayed return of the car, plus other unforeseeable costs.
* A hotel knows the cost of the room but doesn't know whether the minibar or other features will be accessed until checkout.
* A restaurant assumes that a tip will be added to the receipt.
* An online retailer knows the sale amount of the goods but does not know the shipment amount until after the order is processed at the warehouse.
* An online retailer preauthorizes $1 to check if the card is valid, and then immediately reverses the preauthorization.

***

### FIVE-STEP PREAUTH EXAMPLE

For a preauthorization with completion at a gas pump, <mark style="color:purple;">Visa Interlink (debit) rails</mark>, and an upcharge of $75, this is how a $25 purchase might appear, assuming $1000 available balance at the beginning of the purchase.

1 Preauth
\
2 Preauth backout
\
3 Completion
\
4 Completion backout
\
5 Settle

***

### INCREMENTAL AUTH EXAMPLE

In this example, a ride-share app gets an authorization for $15, then after arriving at the first destination the cardholder asks for a second destination, which is an additional $10. After arriving at the second destination the cardholder asks for a third destination for $5. The network is <mark style="color:purple;">Visa credit.</mark>

1 Auth
\
2 Preauth backout
\
3 Auth
\
4 Preauth backout
\
5 Auth
\
6 Backout
\
7 Settle

***

AUTH REVERSAL AND EXPIRY

In this example the cardholder makes a purchase in a mobile app for $40 but cancels it a few minutes later. The cardholder has a $500 available balance before the transaction, and it takes place over <mark style="color:purple;">Mastercard Banknet rails.</mark>

1 Auth
\
2 Reversal
\
3 Expire auth
\
4 Expire reversal

***

PARTIAL REVERSAL AND EXPIRY

This example shows a cardholder using a ride-share app. At the beginning of a ride, the app obtains a $15 preauthorization and then settles the actual amount ($10) at the end of the ride. The cardholder has an available balance of $500 prior to the ride. The network is <mark style="color:purple;">Mastercard Banknet (credit)</mark>.

1 Preauth
\
2 Reversal
\
3 Expire reversal
\
4 Backout
\
5 Settle

***

DISPUTES / CHARGEBACK

This example shows a chargeback and a second presentment over Visa rails for a disputed transaction of $70 that was not resolved in the cardholder's favor. The initial available balance is $500.

1 Auth
\
2 Backout
\
3 Settle
\
4 Chargeback
\
5 2nd present

***

GAS PUMP PLUS CONVENIENCE STORE

Cardholders frequently make purchases at the convenience store where they pump gas. These sample transactions assume Mastercard Maestro (debit) rails, a $75 upcharge, $45 total at the pump, $12 at the convenience store, and a starting available balance of $500.

1 Preauth
\
2 Preauth backout
\
3 Completion
\
4 Auth
\
5 Completion backout
\
6 Backout
\
7 Settle
\
8 Settle


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.xft.finance/learn/flows/payments/credit-card/authorization-and-preauthorization.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.