# Authorization Basics (Operator Field Manual)
Source: https://paymentsandrisk.com/docs/payments/reference/authorization-basics

Last updated 22 October 2026.

TL;DR

-   Authorization is permission to charge, not the charge itself. Capture inside the auth window or the funds release back to the cardholder. That's a lost sale, not a delay
-   [Issuers](https://paymentsandrisk.com/docs/payments/payment-ecosystem/) approve or decline based on fraud score, available credit, and velocity rules - you don't see the reason on a hard decline, only the response code
-   Partial approvals (issuer approves less than the requested amount) are real: your integration must handle them or risk chargebacks and compliance issues
-   Increment authorizations (hotel, rental car) let you add to an existing auth without starting over. If your amount moves, that's what you want

Every [card transaction](https://paymentsandrisk.com/docs/payments/payment-methods/cards/) starts with authorization. Get it wrong and you lose the sale or you eat the chargeback. What follows is the request/response cycle, what the codes mean, and the edge cases you'll hit. It's the foundation for everything else.

_Last verified: Dec 2025. Response codes and rules evolve; confirm with your processor._

## What Matters (5 bullets)

-   **Authorization is permission, not payment.** Auth reserves funds; settlement moves money.
-   **Always authorize before capture.** Processing without auth = automatic chargeback liability.
-   **Response codes tell you why it failed.** Soft vs hard declines need different handling.
-   **Authorizations expire.** Protection periods vary by transaction type; clear within window.
-   **Match auth amount to capture amount.** Tolerance limits exist, but exceeding them creates disputes.

* * *

## How Authorization Works

### The Authorization Flow

```mermaid
sequenceDiagram
    participant C as Customer
    participant M as Merchant
    participant A as Acquirer
    participant N as Card Network
    participant I as Issuer

    C->>M: Enters card details
    M->>A: Auth request
    A->>N: Routes request
    N->>I: Routes to issuer
    Note over I: Checks: funds, fraud,<br/>velocity, account status
    I->>N: Response (approve/decline)
    N->>A: Routes response
    A->>M: Auth response
    M->>C: Transaction result
```

**Time elapsed:** 1-3 seconds typically

### What's in an Auth Request

| Field | Purpose |
| --- | --- |
| Card number (PAN) | Identifies account |
| Expiration | Validates card currency |
| CVV | Proves card possession (CNP) |
| Amount | Funds to reserve |
| Currency | Which currency |
| MCC | Merchant category |
| AVS data | Address verification |
| 3DS data | Authentication results |

### What's in an Auth Response

| Field | Meaning |
| --- | --- |
| Response code | Approve, decline, or refer |
| Authorization code | Approval reference (if approved) |
| AVS result | Address match result |
| CVV result | CVV match result |
| Network transaction ID | For tracking |

* * *

## Authorization vs Capture vs Settlement

| Stage | What Happens | When |
| --- | --- | --- |
| **Authorization** | Issuer reserves funds | At checkout |
| **Capture** | Merchant claims the auth | At fulfillment |
| **Settlement** | Money moves | Batch processing (daily) |

### Pre-Authorization vs Final Authorization

| Type | Use Case | Protection Period |
| --- | --- | --- |
| **Pre-auth** | Estimate before final (hotels, car rental) | 30 calendar days (Mastercard), but only if the message is flagged as a preauthorization |
| **Final auth** | Exact amount known | 7 calendar days (Mastercard, Amex) |
| **Incremental auth** | Adding to existing (hospitality) | Extends the clock on Mastercard, extends nothing on Visa |

Visa has its own 30-day route and it works differently. It needs the estimated authorization indicator plus an eligible MCC (cruise, lodging or vehicle rental) on the original authorization. Sending incremental requests afterward doesn't do anything. If you didn't flag it on the original auth, you don't have the 30 days.

* * *

## Response Codes

### Common Approval Codes

| Code | Meaning |
| --- | --- |
| 00 | Approved |
| 10 | Partial approval (debit) |
| 85 | No reason to decline (card verification) |

### Soft Declines (Retry May Work)

| Code | Meaning | Action |
| --- | --- | --- |
| 05 | Do not honor | Follow network and processor advice; don't retry a stop instruction. Ask the customer to contact their issuer or use another card |
| 51 | Insufficient funds | Retry later |
| 61 | Exceeds withdrawal limit | Retry smaller amount |
| 65 | Exceeds frequency limit | Retry later |
| N7 | CVV mismatch | Ask customer to re-enter |

### Hard Declines (Don't Retry)

| Code | Meaning | Action |
| --- | --- | --- |
| 04 | Pick up card | Do not process |
| 07 | Pick up card (fraud) | Do not process |
| 14 | Invalid card number | Check entry |
| 41 | Lost card | Do not process |
| 43 | Stolen card | Do not process |
| 54 | Expired card | Request valid card |
| 57 | Transaction not permitted | Different payment needed |

### Referrals

| Code | Meaning | Action |
| --- | --- | --- |
| 01 | Refer to issuer | Voice authorization available |
| 02 | Refer to issuer (special) | Voice authorization available |

* * *

## Authorization Protection Periods

Authorizations expire. Clear transactions within the protection window or risk chargebacks. Every figure below is calendar days, counted from the authorization approval date.

### Visa

Since 13 April 2024 Visa runs one clock. Authorization validity and the clearing deadline are the same number.

| Transaction Type | Protection Period |
| --- | --- |
| Card-not-present, cardholder-initiated | 10 calendar days |
| Card-present | 5 calendar days |
| Merchant-initiated (any channel) | 5 calendar days |
| Hotels, car rental, cruise lines with the estimated authorization indicator | 30 calendar days |

### Mastercard

Mastercard splits by authorization type, not by channel.

| Transaction Type | Protection Period |
| --- | --- |
| Final authorization | 7 calendar days |
| Pre-authorization | 30 calendar days |
| Final authorization, India domestic | 4 calendar days |
| Refunds | 5 calendar days |

### Amex

Seven calendar days, any channel. Lodging, cruise and vehicle rental on estimated charge amounts stay valid for the life of the stay or rental agreement, so those don't expire on you.

_Sources: Visa Core Rules 18 April 2026, section 5.7.3.5, Table 5-12; Mastercard Transaction Processing Rules 9 December 2025, sections 2.5.1 to 2.8; American Express Merchant Reference Guide - U.S., section 5.4. Full detail in [Authorization Windows Reference](https://paymentsandrisk.com/docs/payments/reference/auth-windows/)._

### Best Practice

-   Capture as close to auth as possible
-   Set alerts before protection expires
-   Re-authorize if you'll exceed the window

* * *

## Amount Tolerance

The capture amount can differ from auth amount within limits.

### Visa Tolerances

| Transaction Type | Tolerance |
| --- | --- |
| Standard retail | 0% |
| US restaurants | 20% (for tips) |
| Hotels | 15% |
| Car rental | 15% |

### Mastercard Tolerances

| Transaction Type | Tolerance |
| --- | --- |
| Chip + PIN | 0% |
| Contactless | 0% |
| US card-present | 30% |
| US CNP (restaurants) | 30% |
| Other card-present | 20% |

### Currency Conversion

10% tolerance for FX rate differences between auth and clearing.

* * *

## Common Authorization Issues

### No Authorization Obtained

**Problem:** Transaction processed without auth **Result:** Automatic chargeback liability (11.3, 4808) **Prevention:** Always require online auth; no offline processing

### Declined But Processed

**Problem:** Auth declined, transaction still processed **Result:** Automatic chargeback liability (11.2) **Prevention:** Never override declines; no "force" without real approval

### Authorization Expired

**Problem:** Too long between auth and capture **Result:** Chargeback (Visa 11.3 - authorization no longer valid) **Prevention:** Track auth dates; capture within window

### Amount Exceeded Tolerance

**Problem:** Captured more than allowed variance **Result:** Chargeback for overage **Prevention:** Know tolerance by transaction type; re-auth if needed

* * *

## Voice Authorization

When to use voice authorization:

1.  System timeout with customer present
2.  Referral response (01, 02)
3.  POS failure with customer waiting

### Voice Auth Process

1.  Call acquirer's voice auth center
2.  Provide card details verbally
3.  Receive approval code
4.  Enter approval code in terminal
5.  Document the call

### Voice Auth Risks

-   Fraudsters can obtain voice auths on stolen cards
-   No CVV/AVS protection
-   Higher scrutiny in disputes
-   Document everything

* * *

## Authorization Best Practices

### Always Do

1.  **Get real-time authorization** - Never process without auth
2.  **Match amounts** - Auth and capture should align
3.  **Capture promptly** - Don't let auths expire
4.  **Handle declines gracefully** - Good UX for soft declines
5.  **Log everything** - Auth code, timestamp, response

### Never Do

1.  **Force transactions** - Don't override declines
2.  **Process offline** - Unless absolutely necessary with proper procedures
3.  **Exceed tolerances** - Re-auth if amount increases
4.  **Ignore response codes** - Each code means something
5.  **Delay capture** - Risk expiration and chargebacks

* * *

## Scale Callout

| Volume | Focus |
| --- | --- |
| **Under $100k/mo** | Basic auth handling; never override declines; capture same-day |
| **$100k-$1M/mo** | Track auth expiration; implement retry logic for soft declines; monitor response code distribution |
| **Over $1M/mo** | Issuer-level auth analysis; optimize retry timing; network tokenization for recurring |

* * *

## Where This Breaks

-   **Offline terminals** - No real-time auth check; creates liability
-   **Staff override culture** - "Just run it through" = chargebacks
-   **Long fulfillment** - Auth expires before shipping
-   **Manual processes** - Voice auth without documentation
-   **Amount changes** - Final differs from estimate without re-auth

* * *

## Next Steps

**Understanding authorization?**

1.  [Learn the flow](https://paymentsandrisk.com/docs/payments/reference/authorization-basics/#how-authorization-works) - Request to response
2.  [Know auth vs capture vs settlement](https://paymentsandrisk.com/docs/payments/reference/authorization-basics/#authorization-vs-capture-vs-settlement) - Each stage
3.  [Understand protection periods](https://paymentsandrisk.com/docs/payments/reference/authorization-basics/#authorization-protection-periods) - 5 to 30 calendar days by type

**Handling declines?**

1.  [Check soft vs hard](https://paymentsandrisk.com/docs/payments/reference/authorization-basics/#response-codes) - Retry vs don't retry
2.  [Use appropriate retry logic](https://paymentsandrisk.com/docs/payments/reference/authorization-basics/#soft-declines-retry-may-work) - When to try again
3.  [Handle referrals](https://paymentsandrisk.com/docs/payments/reference/authorization-basics/#referrals) - Voice auth when needed

**Avoiding authorization issues?**

1.  [Follow best practices](https://paymentsandrisk.com/docs/payments/reference/authorization-basics/#authorization-best-practices) - Always do, never do
2.  [Know common issues](https://paymentsandrisk.com/docs/payments/reference/authorization-basics/#common-authorization-issues) - Expired, exceeded, declined
3.  [Capture within tolerance](https://paymentsandrisk.com/docs/payments/reference/authorization-basics/#amount-tolerance) - Know the limits

* * *

## Related

-   [Auth Optimization](https://paymentsandrisk.com/docs/payments/auth-optimization/)
-   [Decline Codes](https://paymentsandrisk.com/docs/reference/decline-codes/)
-   [Settlement & Reconciliation](https://paymentsandrisk.com/docs/payments/settlement/)
-   [Processor Reporting Checklist](https://paymentsandrisk.com/docs/reference/processor-reporting-checklist/)