Partial Approval & DE 54: When the Approved Amount Isn't What You Asked For

What a partial approval is

An ordinary authorization is all-or-nothing: the issuer either approves the full DE 4 amount or declines the whole thing. A partial approval is the third outcome. When the account can cover some of the purchase but not all of it, the issuer approves exactly what the balance allows and reports the approved figure back to the terminal.

The classic customers are cards whose balance nobody knows off-hand: gift cards (who remembers there is 7.42 left on it?), prepaid cards, and debit cards running low. For the merchant it converts a dead decline into most of a sale — 30.00 captured now, 20.00 collected in cash or on another card. That is valuable enough that card networks push acceptance of it hard for common merchant segments on prepaid products.

Mechanically there is nothing exotic: no new message type, no special MTI. It is the same 0100/0110 authorization pair (or 0200/0210 financial pair) you already know, with three fields carrying the whole story:

• DE 39 — a dedicated response code that means "approved, but for less";
• DE 4 — rewritten in the response to the amount actually approved;
• DE 54 — the additional-amounts field, telling you what is left on the account.

No opt-in, no partial approval

The issuer never springs a partial approval on a terminal that isn't ready for it. It will only answer with one if the authorization request declared support first — a partial-approval support indicator set by the terminal or acquirer. No indicator, and the same card in the same shop gets a plain DE 39 = 51 insufficient-funds decline; the sale dies even though 30.00 was sitting right there. (Some issuers still attach the available balance in DE 54 of the decline, but nothing is approved.)

Where does the indicator travel? This is the one part of the flow ISO 8583 itself does not pin down. Each network defines its own subfield for it inside the additional-data fields (the DE 48 / DE 60 family), so the exact tag and position come from your interface spec, not from the standard. What is universal is the contract: the flag in the request is what unlocks code 10 in the response.

Setting that flag is a promise, not a formality. It commits the POS side to three behaviours: display and print the approved amount rather than the requested one, run a split-tender flow for the difference, and reverse the authorization if the customer abandons the sale. If your terminal software can't do all three, don't set the flag.

One transaction, two different DE 4s

Here is the whole exchange at a glance — the same purchase, request and response side by side:

Three things to internalise, one per field:

• DE 39 is 10, not 00. In the two-digit response-code table used across 1987-based interfaces, 10 means "partial approval" — you can confirm it in the DE39 lookup. Any approval logic written as if (de39 == "00") will route this to the decline path — while the issuer has already placed a 30.00 hold. The customer sees "declined", the money is frozen anyway, and nobody sends a reversal because the POS thinks nothing was approved. Its close cousin is 87 ("purchase amount only, no cashback") — same family of "approved, but not for what you asked".
• The response DE 4 is the approved amount. In a normal approval the response echoes the requested amount; in a partial approval it doesn't. 000000005000 went out, 000000003000 came back. Validators that echo-check DE 4 against the original will flag a perfectly healthy response as corrupt, and any downstream step that posts the request amount books money that was never authorized. The completion or clearing record must carry 30.00 — clear 50.00 and you are inviting a dispute you will lose.
• DE 54 tells you what is left. Here 0002840C000000000000: the available balance after the approval is exactly 0.00 — the issuer gave you everything the card had. How to read that string is the next section.

Want to poke at it yourself? Paste these two ASCII messages into the parser — the request first, then the response, and watch DE 4 change between them:

01007020000000808000164000001234567890000000000000005000123456TERM0001840

0110302000000680840000000000000000300012345665432110TERM00018400200002840C000000000000

Slicing DE 54 — Additional Amounts

DE 54 is a variable-length field (LLL, up to 120 characters) whose content is one to six fixed 20-character groups, concatenated with no separators. The length is therefore always a multiple of 20, and the only correct way to parse it is index arithmetic: take the LLL length, divide by 20, cut. Each group reads:

Apply that to our response value:

0002840C000000000000
│ │  │  │└───────────┘
│ │  │  │ amount: 000000000000 → 0.00
│ │  │  └ sign: C (positive)
│ │  └ currency: 840 = USD, exponent 2
│ └ amount type: 02 = available balance
└ account type: 00 = default

Reading: "the default account's available balance is now USD 0.00." A two-group value is just two of these back to back — 40 characters, e.g. ledger balance followed by available balance:

0001840C000000003000  ← ledger balance 30.00
0002840C000000003000  ← available balance 30.00
(on the wire: one 40-character string, no separator)

That shape — same structure, different amount type — is also how balances come back on ATM balance inquiries and on declines that report the balance. Learn to cut it once and you can read all of them.

After the approval: collect the rest, or give it back

A partial approval leaves the sale unfinished by design, and the two loose ends are both the terminal's job:

• The remaining 20.00 is a split tender. The gap is collected through another payment method — cash, or a second card, which means a second, completely independent authorization on its own rails. The 30.00 approval doesn't cover it and can't be stretched to.
• An unused hold must be released. If the customer can't cover the difference and walks away, the 30.00 authorization is still live and the card is now — in our example — at zero available balance. The POS must send a reversal for the approved amount promptly; otherwise the hold sits on the account until it expires, which on a gift card can mean the entire card is unusable for days. The mechanics are the same as for any other reversal — see reversals, timeouts & repeats.

Read next

• ISO 8583 DE39 Response Codes: Full Reference
• Why Do Amounts Have No Decimal Point?
• Reversals, Timeouts & Repeats: The ISO 8583 Failure Paths
• The Transaction Lifecycle: Authorization → Clearing → Settlement