Reversals, Timeouts & Repeats: The ISO 8583 Failure Paths

1. Why reversals have to exist

An authorization carries state. The instant the issuer approves a 0100, the cardholder's available balance drops by that amount (a hold), and it stays held until the transaction clears or the auth expires. That creates one fundamental problem:

A reversal is the mechanism that removes that disagreement: the originator tells the other side "that last one didn't happen — roll the state back." It is not a refund and not a new purchase; it is an instruction to undo one specific original transaction.

2. The message family: 0400 / 0410 / 0420 / 0430

Line up the MTI's second digit (message class) first: x1xx = authorization, x2xx = financial, and x4xx = reversal / chargeback. The third digit (function) separates a request from an advice:

Choosing 0400 vs 0420 is not a style preference. The test is: has the state change already happened on your side? If you merely *want* to undo it, send 0400 (a request). If you have already voided it locally, taken no money and booked it that way, you must send 0420 (an advice) — because you can no longer un-void it just because the other side said no. The classic failure is sending 0400, getting a decline, and being stuck: unable to reverse and unable not to.

3. A repeat is not a reversal: the MTI's fourth digit

This is the pair beginners conflate most often, and a rich source of incidents. A repeat re-sends the same transaction; a reversal sends a new message to undo it.

ISO 8583 marks repeats in the MTI's fourth digit (message origin):

When to repeat, when to reverse? In one line: unsure whether they processed it → repeat and ask again; sure they processed it but you no longer want it → reverse. The common production pattern is "repeat N times, still nothing, then reverse" rather than reversing immediately — because a repeat is harmless if the receiver is idempotent.

4. DE90: how a reversal finds its original

A reversal cannot just say "undo the last one" — the issuer may be handling thousands in the same second. It must carry enough identity to locate the original, and that is DE90, Original Data Elements: a fixed 42-digit field made of five parts:

Paste those 42 digits into the parser and it splits them for you. Three frequent mistakes:

• Filling in the reversal's own STAN/time. Every part of DE90 must be the original transaction's value; the reversal has its own fresh DE11/DE7. This is the most common bug, and it means the issuer can never match the original.
• Not zero-padding institution IDs to 11. DE32 is LLVAR on its own, but inside DE90 it is fixed at 11, zero-padded on the right. One digit short and the last 11 shift out of alignment.
• DE7 across midnight. If the original was at 23:59:58 and the reversal goes out at 00:00:03, DE90's MMDD must be the original's date. Reversal mismatches clustered around cutover are usually this.

Beyond DE90, a reversal normally echoes DE2 (PAN), DE3 (processing code), DE4 (amount), DE37 (RRN) and DE41/42 (terminal/merchant) so the receiver can cross-check. On several networks DE37 RRN is the actual primary match key, with DE90 as the fallback — check the counterparty's spec.

5. Partial reversals and DE95

Not every reversal is all-or-nothing. Classic cases: a fuel pump pre-auth of 150 where the customer actually pumped 92.40, or a restaurant pre-auth padded for tip that settles lower. You want to release the over-held portion, not cancel the whole thing — that's a partial reversal.

It travels in DE95, Replacement Amounts — fixed 42 characters in four parts:

And amounts are always integers in the currency's minor unit, left zero-padded — the yen has no decimals, the dinar has three; never blanket-multiply by 100. See why amounts have no decimal point.

6. Timeouts: three cases, only one is safe to retry

To the acquirer a timeout is one symptom: sent, no answer. Underneath it can be three completely different states — and the acquirer cannot tell which:

Since you can't distinguish them, the industry norm is to over-reverse rather than under-reverse: repeat first, then send a reversal if still nothing. Even if the original never reached the issuer (case A), the issuer receiving an unmatchable reversal still answers successfully and records it — an "unmatched reversal" is normal, not an error.

Also mind stand-in processing (STIP) when the issuer is unavailable (DE39=91): the network decides on the issuer's behalf and informs it afterwards with a 0120 / 0220 advice. Those are likewise faits accomplis — the issuer must book them, not refuse them. See the DE39 reference.

7. Idempotency: choosing the dedup key

Since both repeats and reversals can arrive more than once, the receiving side must be idempotent. The question is what the unique key is. DE11 STAN alone is not enough: six digits, unique only within a day by definition, guaranteed to recycle across days and liable to collide between terminals at peak. The composite key used in practice:

• DE37 RRN — 12 characters, cross-system, normally the preferred primary key (assuming the counterparty really generates it per spec). See STAN vs RRN.
• DE32 acquirer + DE11 STAN + DE7 date — the classic triple, unique by specification.
• Plus DE41 terminal / DE4 amount — defensive checks, not part of the key, but they catch "same STAN, different transaction" anomalies.

The dedup window must cover the counterparty's retry policy plus the day cutover — 24–48 hours is typical — and it must cache the response too: a duplicate must get back byte-identical results (same DE39, same DE38 auth code), not a fresh decision. Re-deciding produces the bizarre inconsistency of "approved first time, insufficient funds on the retry".

8. Reversal vs void vs refund vs chargeback

These four get used interchangeably in conversation, but at the message level they are four different things, with different money paths and timing:

The single most useful line for ops and support: reverse if you still can, refund only if you must. A reversal completes before clearing — the statement stays clean and the balance frees instantly. A refund is a new credit transaction that must clear in full: the cardholder waits days, sees two lines, and on cross-border transactions can lose money on the exchange rate because the amount is converted twice.

9. When a reversal is lost: the orphaned hold

If a reversal never lands — retries exhausted, or never sent at all — the issuer is left holding funds against a transaction that will never clear: an orphaned hold or dangling authorization. Symptoms:

• Cardholders complain that money is gone with no purchase, or that available credit doesn't add up.
• Utilised-limit or held-amount figures sit a constant amount off from what actually cleared.
• Reconciliation shows "authorized, never cleared" hanging entries.

The safety net is auth expiry: the issuer gives each hold a lifetime (7 days typically, 30 for hotels and car rental) and releases it automatically if nothing clears. But that's a backstop, not a fix — the cardholder waits a week. The real answer is all three of:

1. A durable pending-reversal queue on the acquirer side: persist the intent the moment you decide to reverse, survive restarts, and let a background worker drive it to success — rather than a request thread retrying a few times and giving up.
2. End-of-day handling of unmatched reversals on the issuer side: keep them, re-match against the auth log at cutoff (a late-arriving original will pair up then) and release when they do.
3. Active monitoring: count hourly the authorizations with neither clearing nor reversal after N hours. When that curve lifts, some link is dropping reversals. If you wait for complaints, there are usually hundreds already.

10. Production troubleshooting checklist

Given a "reversal didn't work" message in hand, walk these in order — nine times out of ten it lands:

1. Is the MTI right? 0400 or 0420 — is your case a request or a fait accompli? Is the fourth digit accidentally flagged as a repeat?
2. Split DE90's 42 digits and check each part: is the MTI the original's? Is the STAN the original's or a new one? Did the date cross midnight? Are the institution IDs padded to 11?
3. Does DE37 RRN match the original? Many networks match on RRN; a changed RRN guarantees a miss.
4. Amount: full or partial? For a full reversal DE4 must equal the original. For a partial, check DE95 carries the remaining amount, not the difference, in minor units.
5. What is the response DE39? 00 means they took it (so your own state machine is the issue); 25 means the match failed (back to steps 2–3); 91 means their host is down (switch to advice and re-send).
6. Time window: is it past the counterparty's reversal deadline? Beyond it, refund or dispute is usually the only route left.
7. Was a repeat treated as a new transaction? Diff DE11/DE7 across the two messages: if they differ, that wasn't a repeat — it was a genuine second transaction.

In short

• 0400 asks, 0420 tells — pick by whether your state has already changed.
• A repeat changes only the MTI's fourth digit; keep STAN and time identical or you've built a double charge.
• DE90 carries the original's identity; DE95 carries what the amount should become — reversing that direction is a classic incident.
• A timeout hides three states, so over-reverse rather than under-reverse; issuers should answer reversals 00 almost unconditionally.
• A lost reversal is an orphaned hold: catch it with a durable queue, end-of-day re-matching and monitoring — don't rely on auth expiry.

→ Decode a reversal in the parser