Partial approvals: what terminals and hosts must do when the card pays only part

contact@corebaseit.com (Vincent Bevia) — Mon, 25 May 2026 10:00:00 +0200

A €100 checkout receives an authorization approval. The cashier releases the goods. The card only covered €63.42.

That is a partial approval: the issuer approved less than the requested amount. The transaction is not declined. The sale is also not complete. Many POS and host stacks still behave as if payment were binary — approved means done, declined means stop. Partial approval sits in between and breaks that assumption.

Requested	Approved	Remaining
€100.00	€63.42	€36.58

This pattern is common with prepaid and gift cards, debit cards with low available balance, benefit or restricted-balance products, fuel and unattended flows, and any retail environment that supports split tender.

Confirmed: A partial approval changes the amount that must be carried consistently across the terminal, merchant host, acquirer/processor interface, receipt, clearing, reconciliation, and customer-facing flow [3][4].

The architectural point: The system must answer not only “approved?” but “approved for how much?”

Beyond binary approval

A full approval answers: can this card pay the requested amount?

A partial approval answers: this card can pay part of it. What happens to the unpaid balance?

A workable model:

Outcome	Sale status
Approved full amount	Card tender complete; sale may complete
Approved partial amount	Card tender partial; sale still open
Declined	No usable authorization on that card

Partial approval is a state transition, not a cosmetic variant of response code 00 or 10.

Visa’s documented retail flow: the authorization request carries a partial-authorization indicator; the issuer returns a partial amount; the merchant subtracts it from the total and requests another form of payment; if the customer does not complete the sale, the merchant initiates an authorization reversal [3].

ISO 8583: response code is not enough

ISO 8583 defines a message framework. Schemes, acquirers, and processors define the field usage. You cannot infer partial-approval behavior from “ISO 8583” in the abstract — you need the acquirer or scheme specification [1][2][6].

A card-present authorization request typically carries processing code (DE3), requested amount (DE4), STAN (DE11), terminal and merchant IDs (DE41/DE42), currency (DE49), EMV data (DE55) where applicable, and often private or additional fields for capability indicators. The response adds response code (DE39), and frequently additional amounts (DE54).

Advertising support on the request

The request should tell the issuer that the terminal or merchant can handle partial approval. Visa documents a partial authorization indicator in the authorization request [3]. Processor formats vary: Worldpay documents a Terminal Partial Authorization Support Indicator in Field 60 subfield 6 (value P) for credit partial authorization [6]. FIS describes an additional authorization indicator for requests that may be authorized for less than the requested amount [8].

Do not advertise partial approval support unless the POS can display it, handle split tender, reverse on cancel, print split receipts, and clear the correct amount.

Reading the response: common patterns

Pattern	How partial approval appears
DE39 = 10 (1987-style) or 0002 / 0006 (ISO 8583:2023)	Explicit partial approval by response code [2][6]
DE39 = 000, response DE4 < request DE4	Partial approval by amount comparison (FIS debit-style) [8]
DE39 partial code, DE4 = requested, DE54 = approved amount	Common credit flows; Worldpay uses DE54 amount code 56 [6]
DE54 balance / authorized amount fields	Prepaid, gift, benefit cards

Worldpay also documents an alternate EMD configuration: partial authorized amount in Field 4 and original requested amount in DE54 amount code 57 [6].

Confirmed: Do not identify partial approvals from DE39 alone [6][8].

A host should evaluate response code, requested amount, approved amount, DE54 and private fields, processor configuration, terminal capability, and transaction type together.

Terminal behavior

When a partial approval arrives, the terminal should enter a split-tender pending state — not mark the sale complete.

Display at minimum:

Total purchase amount
Amount approved on this card
Remaining amount due

A generic green APPROVED is dangerous. A cashier may release €100 of goods when only €63.42 was authorized.

Better:

PARTIAL APPROVAL
Approved on card: €63.42
Amount still due: €36.58

The sale completes only when the remaining balance is paid with another tender or the transaction is cancelled.

Receipts should show each tender separately (card amount, cash or second card, total paid). Visa’s partial authorization flow includes printing a receipt with each payment amount [3].

Vertical rules (confirmed where scheme guidance applies):

Fuel / unattended: Dispense only up to the partially approved amount; stop automatically; clear for fuel actually dispensed, which may be less than the approved cap [3][4].
Restaurant / tip environments: In tip environments, scheme rules may restrict adding gratuity to a partially approved amount. For Visa-specific flows, treat this as a special case and follow the current Visa/acquirer guidance rather than applying normal tip tolerance [4][5].

If the customer cancels

Do not abandon the authorization. Send an authorization reversal for the amount actually authorized — not the originally requested amount.

Requested	Approved	Customer action	Correct reversal
€100.00	€63.42	Cancels	€63.42

CyberSource / Visa Acceptance documentation states that for debit or prepaid partial approvals, the reversal amount must be the amount authorized, not the amount requested [9].

Preserve matching data for reversals: original STAN (DE11), RRN (DE37), authorization code (DE38), terminal and merchant IDs, and approved amount. Missing or mismatched elements can prevent issuers from matching authorization, reversal, and clearing messages [4].

Host behavior

Preserve three amounts

Do not collapse partial approval into a single “transaction amount” too early.

Field	Meaning
Requested amount	Original authorization request (DE4 in request)
Approved amount	Amount the issuer actually authorized
Remaining amount	Balance still due from the customer

You need all three for UI, receipts, reporting, reconciliation, reversal, and clearing.

Detection logic (configuration-driven)

Pseudo-flow:

Determine whether the response is an approval (not decline).
Resolve approved amount from DE54, response DE4, or processor-specific fields per acquirer config.
Mark partial if response code explicitly indicates partial approval, or approvedAmount < requestedAmount, or a private indicator says so.
Full approval → card tender complete.
Partial approval → mark tender partial, calculate remaining, prompt for another tender or cancel.
On cancel → reverse approved amount only.

Treat DE39 = 10 or 0002 as partial when configured — but never ignore amount fields when they disagree with the code.

Clearing

As a general rule, presentment for that card tender should reflect the authorized amount or the final permitted amount under the applicable scheme, MCC, and processor rules:

\[ \text{clearing amount} \leq \text{authorized amount} \]

For fuel, clearing may reflect actual dispensed volume below the partial approval cap [3]. Incremental authorization or adjustment flows apply only where the scheme and MCC allow them.

Recommended transaction states

A explicit state model prevents “approved partial” from being stored as “sale complete”:

INITIATED → AUTH_SENT → AUTH_APPROVED_FULL | AUTH_APPROVED_PARTIAL
AUTH_APPROVED_PARTIAL → REMAINING_TENDER_PENDING
REMAINING_TENDER_PENDING → SALE_COMPLETED | SALE_CANCELLED
SALE_CANCELLED → REVERSAL_SENT → REVERSAL_CONFIRMED
SALE_COMPLETED → CLEARING_READY → CLEARING_SENT

Confirmed: AUTH_APPROVED_PARTIAL ≠ SALE_COMPLETED. The card tender may be approved while the commercial sale remains open.

Sequence sketches

Split tender succeeds: Authorize €100 on card → partial approval €63.42 → display €36.58 remaining → customer pays remainder → sale complete → clear card tender for €63.42, record other tender separately.

Customer cancels: Partial approval €63.42 → customer refuses remainder → reversal for €63.42 → sale cancelled, goods not released.

Fuel: Preauth €100 → partial approval €35 → pump stops at €35 → clear actual dispensed amount (e.g. €34.78).

Failure modes worth testing

Failure	Consequence
Terminal shows “APPROVED” on partial	Goods released without full authorization
Host treats DE39 = 10 / 0002 as decline	Valid partial sale lost
Host treats partial as full approval	Merchant believes full amount secured
Reversal for requested amount, not approved	Reversal mismatch; hold may remain
Clearing for requested amount	Exceeds issuer liability
Partial support flagged, terminal cannot split tender	Integration mismatch; stranded authorizations

Test partial approval as its own lifecycle: split tender completion, cancel with reversal, timeout, POS crash recovery, clearing file amounts, fuel cap, and restaurant tip restrictions.

The message-level rule

The response code tells you the authorization outcome. The amount fields tell you the commercial reality. You need both.

Partial approval is simple at the counter — “your card covered part of this; please pay the rest another way.” At the ISO 8583 and host layer it touches UI, split tender, reversals, clearing, settlement, receipts, reconciliation, and dispute exposure.

Treat partial approval as a distinct transaction state, not a variation of ordinary approval. That one design choice prevents most of the expensive mistakes.

References

ISO, ISO 8583-1:2003 — Financial transaction card originated messages — Interchange message specifications — Part 1: Messages, data elements and code values.
Accredited Standards Committee X9, ISO 8583:2023 — Annex D Code Listings, 2024. (Response codes 0002, 0006 — approved for partial amount.)
Visa Inc., Visa Partial Authorization Service, Visa Merchant Resource Library, 2017.
Visa Inc., Authorization and Reversal Processing Requirements for Visa Merchants, 2024.
Visa Inc., Best Practices for Authorization and Reversal Processing for Lodging, Car Rental and Cruise Line Merchants, 2016. (Tip and clearing constraints on partial approvals.)
Worldpay, Worldpay ISO 8583 Reference Guide, Version 2.56, February 2025. (Response code 10; Field 60 partial authorization indicator; DE54 amount codes 56/57.)
Worldpay, Partial Authorisation, Worldpay Developer Documentation.
FIS Global, ISO 8583 Host Capture Message Specification — LISO, Version 1.2, 2022. (Debit partial authorization via DE4 comparison.)
Visa Acceptance Solutions / CyberSource, Authorization Reversal Processing — Basic Authorization Reversal. (Reversal amount for partial approvals.)

Terminal-Design on Corebaseit — POS · EMV · Payments · AI · Telecommunications