Partial Authorization

Partial authorizations are a specific issuer behaviour that many e-commerce integrations do not handle correctly — resulting in either declined transactions that could have partially succeeded, or authorization holds that capture more than the available balance.

When Partial Authorizations Occur

Partial authorizations are primarily triggered by:

Prepaid card balance limitations: A consumer with a $47 prepaid card attempting a $65 purchase receives a partial authorization for $47. Without explicit partial auth support, the merchant’s system sees a mismatched amount and declines or voids the transaction — leaving the consumer unable to complete the purchase.

Debit card daily limits: Some debit issuers impose daily transaction limits. If the full amount exceeds the remaining daily limit, a partial authorization returns the available amount.

Insufficient credit: Less common on credit cards (issuers more often soft-decline entirely) but can occur at the margins of a cardholder’s available credit.

Partial Auth Response

In the ISO 8583 authorization response, a partial authorization is indicated by:

• Response code 10 (Partial Approval) rather than 00 (Approved)
• The approved amount field containing a value less than the requested amount
• The merchant must compare the authorized amount against the requested amount to detect the partial approval

Not all PSPs surface the partial authorization to merchants — some suppress the response and return a decline. Merchants building custom payment integrations need to explicitly handle response code 10.

Split Tender

When a partial authorization is received, merchants can present a split tender flow:

1. Capture the partial authorization for the approved amount
2. Prompt the customer for a second payment method (another card, cash) for the remainder
3. Complete the transaction across two payment instruments

Split tender handling is standard at physical point of sale (POS systems have built-in split tender workflows) but rare in e-commerce — most online checkouts do not prompt for a second payment method, meaning partial auth scenarios typically result in transaction abandonment.

Scheme Requirements

Visa and Mastercard require merchants that accept debit and prepaid cards to support partial authorization acceptance. The practical compliance requirement:

• Merchants must not void a partial authorization simply because the approved amount is less than the requested amount
• Merchants must either complete the partial capture or explicitly reverse the authorization if the customer declines to pay the remainder

Merchants that automatically void partial authorizations are non-compliant with scheme rules and are also causing unnecessary transaction failures on prepaid card portfolios — a segment that is significant in markets where prepaid cards are used for salary disbursement (common in Southeast Asia and Latin America).

Authorization Rate Impact

For merchants with significant prepaid card volume, partial authorization support can measurably improve effective authorization rates. A merchant ignoring partial auth responses is converting potentially successful split tender transactions into declines — reducing conversion and creating negative cardholder experience.

The fix is straightforward in most PSP integrations: enable partial authorization acceptance in the payment request parameters and add split tender handling in the checkout UI for the remainder amount.