Authorization Basics (Operator Field Manual)
- 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 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 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
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 | Retry later or different 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 October 2025, section 5.7.3.5, Table 5-11; 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.
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:
- System timeout with customer present
- Referral response (01, 02)
- POS failure with customer waiting
Voice Auth Process
- Call acquirer's voice auth center
- Provide card details verbally
- Receive approval code
- Enter approval code in terminal
- 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
- Get real-time authorization - Never process without auth
- Match amounts - Auth and capture should align
- Capture promptly - Don't let auths expire
- Handle declines gracefully - Good UX for soft declines
- Log everything - Auth code, timestamp, response
Never Do
- Force transactions - Don't override declines
- Process offline - Unless absolutely necessary with proper procedures
- Exceed tolerances - Re-auth if amount increases
- Ignore response codes - Each code means something
- 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?
- Learn the flow - Request to response
- Know auth vs capture vs settlement - Each stage
- Understand protection periods - 5 to 30 calendar days by type
Handling declines?
- Check soft vs hard - Retry vs don't retry
- Use appropriate retry logic - When to try again
- Handle referrals - Voice auth when needed
Avoiding authorization issues?
- Follow best practices - Always do, never do
- Know common issues - Expired, exceeded, declined
- Capture within tolerance - Know the limits