Response Codes

29.0 What this chapter gives you#

1. You will be able to point to the two-character field that carries the entire verdict of a card authorisation, name it as DE39, and say why a database column typed as an integer is a defect waiting for a Tuesday.
2. You will be able to explain why an issuer refuses to tell a merchant the reason for a decline, and show with arithmetic that a fully specific vocabulary would let an attacker take a bare card number to a working expiry, security code and liveness check in about a thousand probes.
3. You will be able to take a batch of failed subscription charges and split it into the group that deserves a retry timed around payday, the group that needs a new card number, and the group that must never be attempted again.
4. You will be able to name the four separate mechanisms by which blind retrying damages a business, only one of which shows up in the conversion number.
5. You will be able to identify the values that are approvals despite not being 00 — partial approval, VIP approval, honour with identification, no reason to decline — and say what a merchant throws away by treating them as failures.
6. You will be able to read a Mastercard decline as a pair, the response code plus the merchant advice code, and follow it to the correct next action rather than to a queue.
7. You will be able to place a Visa decline in one of the four decline categories and explain why the most common code of all sits in the generic bucket.
8. You will be able to explain why the same two characters mean a PIN verification problem on one network, a fraud decline on another and a token restriction on a third, and why storing the code without the scheme destroys the information.
9. You will be able to distinguish a timeout from a decline and send a reversal carrying the original trace number instead of a second identical request.
10. You will be able to recognise a strong customer authentication soft decline and route it through EMV 3DS rather than retrying it or losing the sale.

The plain version#

Think about a door with a bouncer on it.

You want to get into a club. The bouncer looks at you, looks at your ID, thinks for a second or two, and gives you one of two kinds of answer. The first kind is “in you go”. There is only one way to say that. The second kind is “not tonight” — and behind those two words sit fifty different reasons, and the bouncer will not tell you which one applies to you.

He knows perfectly well. Maybe you are too young. Maybe your name is on a list behind the counter. Maybe the fire officer capped the building at three hundred people and you are number three hundred and one. Maybe he does not like the look of the four people standing behind you and has decided to break up the group by refusing the one at the front. But what he says is “not tonight”, in the same flat voice, every time.

This is not laziness and it is not bad manners. It is the job. If the bouncer said “your ID is fake, the hologram is wrong”, the next person along would bring a better hologram. If he said “you are on the barred list”, the barred person would learn to send a friend in first to test the water. Every extra word he gives away is a free lesson for the next person who wants in and should not get in. So the club has a rule: one way to say yes, one flat phrase for no, and the real reason stays inside the building.

Now notice something else about “not tonight”. It comes in two flavours that sound identical.

One flavour is temporary. We are full. Come back at midnight and there will be room. The door has not shut on you personally; it has shut on this moment.

The other flavour is permanent. You are barred. You were barred in January and you will be barred in December. Coming back at midnight achieves nothing, and the only thing that will change your position is a conversation with the manager during the day.

And here is the thing that catches people out. If you cannot tell the two apart, the sensible-looking strategy is to keep trying. So you come back at ten past, and twenty past, and half past, and by eleven o’clock the bouncer has stopped seeing a customer and started seeing a problem. You are no longer being refused because the club is full. You are being refused because you are the man who keeps coming back. Your own persistence has converted a temporary no into a permanent one.

A card payment works exactly like this, and the whole thing turns on a box in the reply message that holds two characters. When a card is tapped, a message goes out asking whether this card may be charged nine pounds ninety-nine. A message comes back, and near the front of that reply there is a small fixed slot, two characters wide, carrying the entire answer. If it contains 00, the answer is yes. If it contains anything else at all, the answer is no. There are about sixty values that mean no, and the difference between a payments operation that works and one that quietly bleeds money is almost entirely in what you do with those two characters.

Take a real example. Ravinder runs a gym in Coventry. He has 1,000 members paying £24.99 a month, which is £24,990 a month if everybody pays, and he collects it all on the first of the month by charging the card each member has left on file. On 1 March he sends 1,000 requests. Nine hundred and forty-seven come back 00. Fifty-three do not, and this is roughly how they break down:

Now, the wrong thing to do, and the thing an awful lot of software does, is to treat all fifty-three the same. Put them in a queue. Try each of them again four times a day for a week. That is 53 × 4 × 7 = 1,484 additional attempts. It will recover something — a handful of the empty accounts will fill up when wages land — but it will recover perhaps twenty of them. The other 1,464 attempts achieve nothing at all except to make Ravinder’s gym look, to a computer at each member’s bank, exactly like somebody testing stolen card numbers. Some of those attempts carry a fee. Some of them make the next attempt more likely to be refused.

The right thing to do is to read the two characters and treat the five groups as five different problems.

The thirty-one members with code 51 have a working card and an empty account. Nothing is wrong with the card, the merchant or the amount. What is wrong is the date. Retrying on the second of the month is close to pointless; retrying on the fourth, after most people have been paid, is not. Two attempts, spaced out, will typically bring back most of them. Call it twenty-four of thirty-one, £599.76 recovered, at a cost of sixty-two attempts rather than 868.

The six members with code 54 have a card that expired. There is no number of retries that unexpires a card. The only two things that work are asking the member for a new one, or using the card networks’ own updating service, which quietly hands merchants the replacement card number when a bank reissues. Retrying is not merely useless here, it delays the one action that would have worked.

The three members with codes 41 and 43 have had their cards reported lost or stolen. That card is dead. It will be dead tomorrow and dead in a year, and both card networks will charge Ravinder for continuing to ask.

The two members with code 91 did not get an answer because their bank’s computer was not responding. This one genuinely does deserve an immediate retry. It is the only code in the list where “just try again” is the whole correct answer.

And then there are the eleven with code 05, do not honour, which is the bouncer’s flat voice. Do not honour means the member’s bank has decided not to pay and is not going to say why. It might be a closed account, a fraud score, or the member having told their bank to stop this subscription and the bank doing as it was asked. Ravinder cannot tell, and — this is the important part — he is not supposed to be able to tell. The correct handling is one further attempt after several days, and if it comes back 05 again, an email to the member. Not a queue.

Total: about ninety extra attempts instead of 1,484, and about £800 of the £1,324 recovered instead of about £500. Same fifty-three customers. The only difference is that somebody read the two characters.

That is the plain version. One value means yes, everything else means no, and the no is deliberately vague because a specific no is a free lesson for a criminal. There are two kinds of no, temporary and permanent, and they look identical from the outside, which is precisely why blind retrying is so tempting and so expensive.

Where the plain version stops being true#

The bouncer is not always the bank, and often nobody’s bank was asked. The analogy has one door and one man on it. A real card transaction can be refused at five different points, and the two-character code you eventually see does not say which. The chip in the card can decline the transaction by itself, offline, before any message goes anywhere. The terminal or the point-of-sale application can refuse it on a floor limit or a configuration rule. The merchant’s own fraud screening can block it before it ever reaches the acquirer. The acquirer or its gateway can reject it for a malformed field, an unsupported currency, or a merchant-level velocity rule. The card scheme itself can answer on the issuer’s behalf when the issuer’s systems are unreachable, using parameters the issuer lodged in advance — Visa calls this stand-in processing. Only after all of those does the actual issuer get a vote. So “your bank declined this” is a sentence customer service staff say many times a day and which is frequently untrue. Worse, several of those layers write into the same field using the same vocabulary, so the shape of the answer tells you nothing about its author.

“00 is yes and everything else is no” is a good rule with real exceptions, and you must know them. Code 10 is a partial approval: the issuer has approved a smaller amount than you asked for, and if your software treats that as a decline you have just thrown away a sale you had already won, and possibly left a hold on the customer’s account for money you will never take. Code 11 is an approval. Code 08, honour with identification, is an approval conditional on the merchant checking something. Code 85 is not a decline at all — it is the answer to a question you asked without wanting money, such as “is this card real and does this postcode match”, and it means “no reason to decline”. And 00 in the response to a reversal means the reversal was accepted, which tells you nothing whatever about whether the original transaction was approved. Meanwhile 00 on an authorisation does not mean money has moved. It means a bank has set some of its customer’s money aside and promised to pay if you ask properly. Those are different facts and they live in different chapters.

The vagueness is being unwound on purpose, but only in one direction. The plain version says the reason stays inside the building. That was true for thirty years and it is becoming less true, because the card schemes worked out that total opacity was costing everybody money in failed recurring payments. Mastercard now requires issuers to split their generic declines into three buckets and to attach a separate advice field telling the merchant what to do next. Visa now classifies every decline code into one of four categories and penalises merchants who ignore the classification. But look carefully at what the schemes added. They added what to do, not why. “Do not try again” is a much more useful message than “do not honour”, and it still does not tell the merchant that the account was closed on 3 March because the customer died. The direction of the disclosure is deliberate: the merchant learns enough to stop wasting attempts and not one thing more about the cardholder. The reason itself is still available, but only to the cardholder, from their own bank, over a channel where the bank has already checked who it is talking to.

Soft and hard are not properties of the code. Nowhere in the international standard that defines this field is there any concept of a soft decline or a hard decline. Those are operational categories invented afterwards by the card schemes, published in rulebooks that are revised on an annual cycle, and they differ between schemes, differ between regions, and move. A code that sits in the never-retry bucket this year may be moved to the retry-later bucket next year by a bulletin. More disconcertingly, the same two characters mean genuinely different things on different networks: code 79 means “already reversed by the switch” on Visa and “life cycle” on Mastercard, which are not remotely the same event. Any system that stores a decline as a normalised boolean, or that stores the code without also storing which scheme produced it, has destroyed the information it will need later.

The technical version#

Where the field sits#

Card authorisation messages are ISO 8583 structures. The message type indicator is four digits: position one gives the version of the standard (0 for the 1987 edition, 1 for 1993, 2 for 2003), position two the message class (1xx authorisation, 2xx financial, 3xx file actions, 4xx reversal and chargeback, 8xx network management), position three the function (0 request, 1 request response, 2 advice, 3 advice response), and position four the origin (0 acquirer, 2 issuer, 4 other). An authorisation request is 0100 and its response 0110; a financial request is 0200 and its response 0210; a reversal request is 0400 and its response 0410; a network management request is 0800 and its response 0810.

After the MTI comes the primary bitmap, sixty-four bits marking the presence of data elements 1 to 64, with bit 1 signalling a secondary bitmap covering 65 to 128. Data element 39, the response code, is an 2 in the 1987 catalogue: exactly two alphanumeric characters, fixed length, no more and no less. It is present in response messages — 0110, 0210, 0410, 0430, 0810 — and absent from requests.

The elements it must be read alongside are these.

Two implementation notes follow immediately from that table and are worth stating flatly. DE38 is populated only when the transaction is approved, so an implementation that decides “approved” by checking whether an authorisation code is present is doing the right thing for the wrong reason and will eventually meet an issuer that populates DE38 with 000000 on a decline. DE39 is the authoritative field; everything else is corroboration. And DE39 is two characters, not two digits: values such as 1A, N7, R0, Q1, Z3, 5C and 9G are all in live use, so a column typed as an integer is a defect waiting for a Tuesday.

The 1987 catalogue#

Almost all card scheme traffic still uses the two-character response codes of the 1987 edition, and the base catalogue is worth having in front of you. It is grouped by intent rather than numerically, which is why the numbering looks arbitrary.

The catalogue reserves 45 to 50 and 69 to 74 for ISO use, 97 to 99 for national use, and the ranges beginning with a letter for national and private use, which is where every scheme’s proprietary values live. Note the duplication the standard itself contains: 33 and 54 both say expired card, 34 and 59 both say suspected fraud, 38 and 75 both say PIN tries exceeded. The difference historically was whether the card was to be captured. That distinction is dead and the duplication survives, which is one small demonstration that this vocabulary is an archaeological site rather than a design.

The 1993 renumbering, and why you have probably never seen it#

The 1993 revision of ISO 8583 replaced the two-character response code with a three-digit action code, still in DE39, and gave it a genuinely rational structure: the range says what happened, the value says why.

Inside those ranges the values are systematic. 000 is approved, 002 approved for partial amount, 007 approved and update the chip. 100 is do not honour, 101 expired card, 116 not sufficient funds, 117 incorrect PIN. The 200 range is the same list again but with the card to be captured: 200 do not honour, 208 lost card, 209 stolen card. And 907 is card issuer or switch inoperative, 911 card issuer timed out, 912 card issuer unavailable — three distinct failures that the 1987 catalogue collapses into 91.

This is a better design in every respect and it is not what the card networks run. Visa, Mastercard, American Express and Discover all froze their dialects on the 1987 shape and then extended it privately, so the 1993 action codes appear mainly in domestic switches, ATM networks and newer national schemes. A practitioner must know which one is on the wire before writing any comparison, because 10 and 100 are an approval and a decline respectively and are distinguishable only by knowing the version.

The published Visa set#

Visa publishes its action code list openly on Visa Developer, and it is the closest thing to an authoritative reference for what a merchant will actually receive on Visa rails. The list includes the ISO base plus a substantial private extension. Some entries that matter:

Several of these repay attention. R0, R1 and R3 are the cardholder speaking through their bank: the customer has instructed the issuer to stop this payment, all future payments to this merchant, or all merchant-initiated payments respectively. A merchant that retries an R1 is not fighting a machine, it is overriding an instruction its customer gave to their own bank, and both the scheme rules and consumer protection law take a dim view of it. 85 is the affirmative answer to a zero-amount verification, which is how a merchant checks that a card is real and that a billing address matches without taking any money. 80, “no financial impact”, is what a reversal response carries when the original was declined anyway.

Why the issuer is deliberately vague#

The vagueness of 05 is not a documentation gap that somebody will fix. It is a control, and the argument for it is arithmetic.

Consider an attacker holding a list of 10,000 candidate card numbers of unknown quality, obtained from a breach, generated against a known issuer range, or scraped. They want to convert that list into a smaller list of numbers that can actually be charged. Now suppose issuers returned a fully specific decline for every case. Watch what the attacker learns from a single one-pound probe against a single card:

A response of 14, invalid account number, tells them the number does not exist. Cross it off.

A response of 54, expired card, tells them something far more valuable: the number does exist and their expiry date is wrong. An expiry is a month and a year, and cards are typically issued for three to five years, so a complete search of the plausible space is at most sixty combinations.

A response of N7 or 82, a card verification failure, tells them the number and expiry are both correct and only the three-digit security code is wrong. That is a thousand probes, with the response code confirming the moment they hit it.

A response of 51, not sufficient funds, tells them everything is correct: number, expiry, security code, and a live account that is merely empty at this instant.

So a fully specific decline vocabulary converts an unstructured guess into a staged search with a feedback signal at every stage: roughly 1,061 probes to take a bare card number and establish its expiry, its security code and its liveness. That is the definition of an oracle, and building one into the response field of the world’s payment network would be an extraordinary thing to do.

Collapse all of it to 05 and the attacker learns exactly one bit per probe: not this one, for some reason, at this moment. The staged search collapses. This is why issuers’ risk engines map dozens of distinct internal outcomes — negative file hit, velocity breach, device reputation, machine-learning score above threshold, account under investigation, merchant category blocked by the cardholder, sanctions screening alert, a mismatch the issuer would rather not name — onto a single unhelpful value.

There is a second reason, and it is legal rather than technical. Some declines cannot be explained to a merchant without breaking the law. If a payment is stopped because a sanctions or anti-money-laundering screen fired, telling the merchant why can constitute tipping off. Code 93, “transaction cannot be completed, violation of law”, is about as much as anyone will say, and many issuers will not even say that much and will send 05 instead. Similarly, where the decline is about the merchant rather than the cardholder — an issuer that has decided to block a whole category, or a specific acceptor, because of chargeback history — an explicit code would amount to publishing a commercial judgement about a business to that business.

The disclosure is therefore directional rather than absent. The cardholder can find out. They ring the number on the back of the card, the bank authenticates them, and the bank tells them exactly what happened, because it is their money and their account. The merchant cannot, because the merchant is not the customer and is, statistically, sometimes the attacker. The right thing for a merchant to say to a customer holding a declined card is not “your bank rejected it” but “your bank has not told us why; if you ring them they will tell you”.

Soft and hard, in the schemes’ own words#

Because “do not honour” wrecked recurring billing, both major schemes built classification systems on top of the code set. They are not the same system.

Visa assigns every decline code to one of four decline categories:

Category 1 is populated with the codes where the account or the card is simply gone: 04, 07, 12, 14, 15, 41, 43, 46, 57, and the stop-payment family R0, R1 and R3. Category 2 holds the temporary conditions: 03, 19, 51, 59, 61, 62, 65, 75, 78, 86, 91, 93, 96, N3, N4, 5C, 9G. Category 3 holds the data problems, which is where the retry actually has to change something before it is sent: 54, 55, 70, 82, 1A, 6P, N7. Category 4 is everything else, and — this is the sharp part — 05, do not honour, sits in category 4. The generic code is in the generic category, and Visa has been pressing issuers to reduce their use of it in favour of a code from categories 1 to 3, because the whole scheme is worth less when the biggest single bucket is unclassifiable.

Mastercard went the other way. Rather than classifying the existing codes, it introduced three replacement values in DE39 and a separate advice field. Mastercard’s own developer documentation defines them plainly, noting that the response code “is passed to Mastercard in Data Element (DE) 39 of the issuer’s network response message”:

So a Mastercard decline that would once have arrived as 14 or 54 now arrives as 79, life cycle, meaning something about the credential itself has changed. A decline that reflects an issuer rule arrives as 82, policy. A decline that reflects a fraud judgement arrives as 83. And alongside it, in DE 48 subelement 84, comes the merchant advice code, which is where the actual instruction lives.

Codes 24 through 30 are the most quietly remarkable thing here: the issuer telling the merchant, in the decline message itself, when the account is likely to have money in it. That is the answer to code 51 delivered as data instead of guesswork.

The Mastercard Switch Rules set out the intended pairings directly:

Read that table as a decision tree and the design becomes obvious. 79 or 82 with MAC 01 means go to the Account Billing Updater and get the new card number. 83 with MAC 01 means the credential is probably fine but the transaction was not authenticated, so run it through EMV 3DS and come back. Anything with MAC 03 means stop, permanently. MAC 21, payment cancellation, means the cardholder has cancelled the recurring arrangement and the merchant’s next move is a conversation, not a request.

Retry logic, and the four ways blind retries make it worse#

Practitioners talk about retries as though the only question were how many attempts convert. There are four separate mechanisms by which unstructured retrying damages a business, and only one of them is visible in the conversion number.

The schemes charge for it. Visa operates an Excessive Reattempts rule under which a reattempt of a transaction that returned a category 1 decline is chargeable from the very first reattempt, and reattempts beyond a threshold within a rolling thirty-day window are chargeable for categories 2 and 3. The commonly published threshold is fifteen reattempts in thirty days, on the same account number at the same merchant, with the fee applying from the sixteenth; some acquirers publish the limit as twenty, and both figures appear in current merchant-facing guidance, which tells you that the rule has been revised and that regional variants exist. Mastercard runs an equivalent programme within Transaction Processing Excellence, assessing a fee for authorisation attempts beyond a threshold of previously declined attempts on the same account number, at the same card acceptor, and for the same amount, with published thresholds around ten declined attempts in twenty-four hours or thirty-five in a rolling thirty days, again with explicit regional variation. Mastercard additionally charges where a merchant retries a transaction that was declined with MAC 03 or MAC 21 and receives another 03 or 21. The per-attempt amounts sit in the schemes’ own fee schedules, which are not published, so no primary document will confirm a figure; what can be checked is what the acquirers and payment service providers who pass the charge on tell their merchants, and they quote it consistently. Adyen’s published scheme fee documentation, to take one, puts the Mastercard excessive authorisations fee at USD 0.30 in the United States rising to USD 0.50 from the first of January 2025, EUR 0.55 in Europe, and USD 0.50 across Asia-Pacific, Canada and Latin America, and notes that the permitted retry counts themselves vary by region. The engineering conclusion does not depend on the figure: cap attempts below the lowest published threshold in any region you operate in, count them per account number per merchant per thirty days, and treat category 1 and MAC 03 as absolute.

The issuer scores you. Every authorisation request a merchant sends is a data point in the issuer’s model of that merchant. A retry pattern of two attempts spaced four days apart looks like a subscription business. Four attempts a day for a week against cards that keep saying no looks like card testing, because that is precisely what card testing looks like. Issuers respond by declining more of that merchant’s traffic, including the good traffic, and the merchant discovers that its approval rate on healthy cards has fallen for reasons nobody can point at. The retry strategy that recovered an extra one per cent of failed subscriptions has cost two per cent of successful ones.

A timeout is not a decline, and treating it as one creates duplicates. This is the failure that produces the angriest customers. If a request goes out and no response comes back, the correct action is a reversal — a 0400 carrying the original message’s trace number — followed by a fresh attempt. It is not a retry of the same request, because the first request may well have been approved by an issuer whose response was lost on the way home. Retry without reversal and the customer has two holds on their account for one purchase. This is why every terminal and gateway implementation must write a durable local record of the request, including the trace number, before the request goes on the wire: the case in which you most need to reverse is exactly the case in which nothing came back to tell you what to reverse.

Every attempt costs money even when it fails. Authorisation requests carry scheme fees, gateway fees and, in some acquiring arrangements, per-transaction charges regardless of outcome. At any volume the difference between ninety attempts and 1,484 is not a rounding error.

The retry logic that follows from all of this is short enough to state in full. Read the merchant advice code first if there is one, because it is an instruction and it overrides your own heuristics. If there is none, read the scheme’s category. Never retry a Visa category 1 code, a Mastercard MAC 03 or 21, or any of R0, R1, R3. For data-quality declines, do not retry until the data has changed — a new expiry from the account updater, a corrected security code, a completed 3DS authentication. For temporary declines, retry on a schedule shaped by the customer’s payday rather than by your batch window, and prefer the interval the issuer told you in MAC 24 to 30 if it gave you one. Cap total attempts well under the scheme threshold. Store the raw code, the scheme that produced it, the advice code and the timestamp for every attempt, and never collapse the outcome to a boolean, because the day you need to explain a fall in approval rates is the day you will need the codes.

Scheme differences in the code sets#

The single most dangerous assumption in this area is that a two-character code means the same thing everywhere. It does not, and the collisions are not obscure.

Code 83 is the cleanest illustration: on Visa a PIN verification problem, on Mastercard a fraud decline, on Discover a token domain restriction failure. Three networks, one value, three unrelated events. A normalisation layer that maps 83 to a single internal meaning is wrong on at least two of them.

American Express does not use the two-character scheme at all in its own dialect. Its published set is three digits wide: 00 approved, 100 deny, 101 expired card or invalid expiration date, 109 invalid merchant, 110 invalid amount, 111 invalid account, 116 not sufficient funds, 117 invalid PIN, 122 invalid card security code, 130 additional customer identification required, 181 format error, 200 deny, pick up card, 912 issuer not available. An integration that assumes two characters will truncate every one of them.

The strong customer authentication soft decline deserves its own note because it is the newest common case and it is not handled correctly in a great deal of live code. Under the second Payment Services Directive an issuer may refuse a card-not-present transaction not because there is anything wrong with it but because the cardholder has not been authenticated. Visa signals this with 1A, “additional customer authentication required”. Mastercard signals it with 65. American Express’s 130, “additional customer identification required”, occupies the same position in its set. The correct response is neither a retry nor a failure message to the customer: it is to run the transaction through EMV 3DS, obtain the authentication data, and submit a new authorisation carrying it. A merchant that treats 1A as a hard decline is turning a completable sale into a lost one, and a merchant that retries the identical message without authentication will receive 1A again, indefinitely, while accumulating reattempt fees.

Note also that Mastercard’s 65 is doing double duty — the ISO meaning is a withdrawal frequency limit and the European meaning in card-not-present contexts is an authentication requirement. Disambiguating it requires the context of the transaction rather than the code alone, which is a good final reminder that DE39 is two characters and two characters cannot carry a complete explanation of anything.

Codes the network writes rather than the bank#

A final category worth separating out, because it changes what the right action is.

When an issuer’s systems are unreachable, Visa’s V.I.P. system can authorise on the issuer’s behalf using parameters the issuer has lodged in advance. This is stand-in processing, and its fingerprints are all over the code set. Visa’s own description of 91 is not “the issuer declined” but “issuer or switch inoperative and STIP not applicable or not available for this transaction; time-out when no stand-in”. That is a statement about network availability, and it is the one decline where an immediate retry is genuinely the right move, because the condition it describes is measured in minutes. N0, “force STIP”, is an issuer deliberately routing a transaction into stand-in rather than answering it itself. When stand-in approves, the approval code in DE38 was minted by the scheme and the issuer may not know about it until the advice message arrives, which is a small but real source of reconciliation surprise.

At the other end, Z3, “unable to go online; offline-declined”, is written by the terminal after the chip demanded an online authorisation and the terminal could not get one. No bank saw the transaction at all. A chip that declines outright produces an application authentication cryptogram rather than an authorisation request cryptogram, and the terminal reports the refusal without any message leaving the shop. In both cases the customer is told their card was declined while their bank has no record of anything having happened, which is exactly the conversation that ends with a customer insisting there is nothing wrong with their card and being entirely correct.

The practical instruction that closes the chapter is a small one. Log DE39 verbatim, as characters, alongside the scheme, the acquirer, DE38, DE44, the merchant advice code from DE48 where present, DE4, DE49, the MTI and the time. Do not normalise on the way in. Do not map to a boolean. The two characters are the most compressed piece of information in the entire payment system, and every layer that helpfully simplifies them destroys the only evidence you will have when somebody asks, six months later, why the approval rate moved.

29.98 Common wrong ideas#

Wrong: A decline means the cardholder’s bank refused the payment. Right: A transaction can be refused at five points — the chip, the terminal, the merchant’s own fraud screening, the acquirer or its gateway, and the scheme standing in for the issuer — and the two characters do not say which, so “your bank declined this” is frequently untrue.

Wrong: 00 means yes and every other value means no. Right: Code 10 is a partial approval, 11 is an approval, 08 is an approval conditional on identification and 85 is the affirmative answer to a zero-amount verification, so software that treats anything other than 00 as a failure discards sales it had already won.

Wrong: An approval means the money has moved. Right: It means a bank has set some of its customer’s money aside and promised to pay if you ask properly, and 00 in a reversal response says only that the reversal was accepted, which tells you nothing about the original.

Wrong: Soft and hard declines are categories defined by the standard. Right: Nowhere in ISO 8583 is there any such concept; the categories were invented afterwards by the schemes, published in rulebooks revised on an annual cycle, and they differ by scheme, differ by region and move.

Wrong: The schemes are gradually opening up the reasons behind declines. Right: What Visa’s categories and Mastercard’s merchant advice codes added is what the merchant should do next, not why the issuer said no; the reason itself remains available only to the cardholder, from their own bank, over an authenticated channel.

Wrong: A two-character code means the same thing on every network. Right: Code 83 is a PIN verification problem on Visa, a fraud decline on Mastercard and a token domain restriction failure on Discover, and American Express does not use two characters at all, so a normalisation layer that maps a code to one internal meaning is wrong on most of them.

Wrong: If no response comes back, send the request again. Right: The first request may well have been approved by an issuer whose response was lost on the way home, so the correct action is a reversal carrying the original trace number followed by a fresh attempt; retrying without reversing gives the customer two holds for one purchase.

Wrong: Retrying a decline costs nothing but a little effort. Right: The schemes charge for reattempts beyond published thresholds and from the very first reattempt on the never-retry category, issuers read the pattern as card testing and decline more of the merchant’s healthy traffic, and every attempt carries scheme and gateway fees whatever its outcome.

Wrong: A stop-payment code is just another decline to work around. Right: R0, R1 and R3 are the cardholder speaking through their bank to stop this payment, all future payments to this merchant, or all merchant-initiated payments, and a merchant that retries one is overriding an instruction its own customer gave to their own bank.

Wrong: Recording the outcome as approved or declined is enough. Right: Collapsing the response to a boolean, or storing the code without the scheme that produced it, destroys the only evidence available on the day somebody asks why the approval rate moved six months ago.

29.99 Chapter summary in 20 lines#

1. A card authorisation reply carries its entire verdict in a single two-character field, DE39, and everything else in the message is corroboration.
2. 00 means approved, about sixty other values mean refused, and the gap between a payments operation that works and one that quietly bleeds money is almost entirely in what is done with those two characters.
3. The refusal is deliberately vague, because a specific reason is a free lesson for the next person who should not get in.
4. The arithmetic is the argument: a fully specific decline vocabulary turns an unstructured guess into a staged search, taking a bare card number to its expiry, its security code and its liveness in roughly a thousand probes.
5. Collapsing everything to 05, do not honour, reduces the attacker to one bit per probe, and some declines — sanctions and money-laundering stops — cannot lawfully be explained to a merchant at all.
6. The disclosure is therefore directional rather than absent: the cardholder can ring their bank and be told exactly what happened, and the merchant cannot, because the merchant is statistically sometimes the attacker.
7. Refusals come in two flavours that look identical from the outside, temporary and permanent, which is precisely why blind retrying is so tempting and so expensive.
8. Ravinder’s gym puts numbers on it: fifty-three failures treated identically generate 1,484 attempts and recover about £500, while treating them as five different problems generates about ninety attempts and recovers about £800.
9. Insufficient funds is a date problem that answers to a retry timed around payday, while an expired card, a lost card and a stolen card answer to nothing a retry can do.
10. Code 91 is the one entry in the list where “just try again” is the whole correct answer, because it describes a network outage measured in minutes.
11. Several values that are not 00 are nevertheless approvals — partial approval, VIP approval, honour with identification, no reason to decline — and treating them as declines gives away sales already won.
12. An approval is not a payment: it is a promise to pay if the merchant presents properly, and the authorisation identification response is populated only on approval, so deciding “approved” from its presence is the right answer for the wrong reason.
13. The 1993 revision replaced the two characters with a rationally structured three-digit action code, the card networks never adopted it, and as a result 10 and 100 are an approval and a decline distinguishable only by knowing which version is on the wire.
14. Soft and hard are not properties of the code but operational categories layered on afterwards, published in annually revised rulebooks and differing by scheme and by region.
15. Visa sorts every decline into four categories — never reattempt, cannot approve now, cannot approve on this data, and generic — with 05 sitting in the generic bucket the scheme is pressing issuers to shrink.
16. Mastercard went the other way, replacing the code with life cycle, policy and fraud values and putting the actual instruction in the merchant advice code, whose retry-after values tell the merchant how many days to wait.
17. Blind retrying damages a business in four ways: scheme reattempt fees, issuers scoring the traffic as card testing, duplicate holds when timeouts are mistaken for declines, and a per-attempt cost on every message.
18. A timeout demands a reversal carrying the original trace number, which is why that trace number must be written to durable local storage before the request ever goes on the wire.
19. The strong customer authentication soft decline is neither a retry nor a lost sale but an instruction to authenticate through EMV 3DS and submit a new authorisation carrying the result.
20. Log the response code verbatim as characters alongside the scheme, the acquirer, the authorisation code, the additional response data, the merchant advice code, the amount, the currency, the message type and the time, and never normalise on the way in, because every layer that helpfully simplifies those two characters destroys the evidence.

Sources: ISO 8583:1987 and ISO 8583:1993 data element and response code catalogues as tabulated in the ISO 8583 reference literature; Visa Developer published Request and Response Codes (action code, address verification result, CVV2 result and CAVV result tables); Visa BASE I / V.I.P. System technical specification descriptions of stand-in processing and offline-decline codes; Mastercard Switch Rules (Mastercard, 2016-2025) on DE 39 and DE 48 subelement 84 pairings; Mastercard Developers network response code and merchant advice code definitions; Worldpay Access published scheme response code tables for Visa, Mastercard, American Express and Discover, including Visa decline category assignments; Adyen raw acquirer response documentation and 3-D Secure soft-decline guidance; CardPointe and Payway merchant guidance on the Visa Excessive Reattempts rule; PayPal Braintree and TabaPay published merchant advice code tables.