Reducing your decline rate. 7 chapters and a final quiz.

Chapter 1. Breaking down declines before reducing them.

An overall decline rate does not tell you what to fix, because it lumps together causes that have nothing to do with one another. An internal filter set too tight, a customer who abandons authentication, a wary foreign issuer, an expired card sitting in a vault: each one opens a different workstream, with a different owner. The first job is to break the number apart. The second is to put a sales value on each piece.

The minimum breakdown: six dimensions, no fewer

A metric only means something against a baseline, so freeze four weeks of data before you change anything. Keep the raw code of every attempt, untranslated: provider labels change without notice, and a mapping written against a label breaks silently. The before-and-after comparison will use the first-attempt rate, at a constant mix.

Chapter 2. Qualifying a code: hard, conditional, or misclassified.

Everyday jargon splits declines into soft and hard, but that split is a merchant abstraction. The networks do not talk that way. Visa sorts its response codes into four categories and attaches a reattempt rule to each. Mastercard adds a Merchant Advice Code to the response code, addressed to the merchant rather than the acquirer. The provider then layers its own label on top, often translated and sometimes stripped of detail. That makes three vocabularies for a single event.

Four questions that qualify any decline

• Who declined? The merchant's filter, the provider, the acquirer, or the issuer. A decline that never reached the issuer cannot be fixed at the issuer.
• Could the same attempt succeed later? That is the only useful definition of a conditional decline: nothing needs to change except the timing.
• What would have to change for it to go through? A data element, an authentication, a card credential, an entire payment instrument. The answer names the workstream.
• Who owns that change? The merchant, the cardholder, or the issuer. A workstream with no owner will not get done.
• How many retries does the network allow? The cap is not a guideline: it is billed and monitored.

At Mastercard, declines arrive already sorted

Mastercard groups its card-not-present declines into three families: 79 lifecycle, 82 policy, 83 security. The Merchant Advice Code then says what to do. 01 signals that updated account information exists. On a 79 or 82 decline it points to the account updater; on an 83 it points to a retry with EMV 3-D Secure. 02 allows a later retry, 03 forbids one, and 21 closes out the payment, while codes 24 to 30 set a specific wait, from one hour to 10 days.

{
  "tentative_id": "att_2026_08_07_0001",
  "commande_id": "CMD-2026-8842",
  "rang_tentative": 2,
  "carte_ref": "pan_ref_9f2b",          // stable card reference, never the PAN
  "pays_emission": "BR",
  "produit_carte": "credit",
  "instrument": "network_token",         // pan | psp_token | network_token | wallet
  "initiateur": "MIT_recurring",         // CIT | MIT_recurring | MIT_industry
  "montant_mineur": 4990,
  "devise": "BRL",
  "authentification": "3ds_frictionless",
  "code_reseau_brut": "51",              // NEVER the provider's label
  "merchant_advice_code": "02",
  "categorie_visa": 2,
  "psp": "psp_a",
  "acquereur": "acq_br_1",
  "horodatage": "2026-08-07T09:14:22Z"
}

Chapter 3. Retrying without getting billed for it.

A retry is money spent to recover a declined sale. Each attempt costs an authorization fee, draws down a counter the networks monitor, and hurts the reputation of the merchant ID when repeated. So write the retry policy like a budget: a number of attempts, a trigger, and a stop condition.

What the networks count, and how

• The counter runs per card and per merchant, across all providers. Splitting your retries between two providers does not divide anything.
• Visa allows no more than 15 reattempts in 30 days for categories 2, 3, and 4, and none for category 1 (Visa Rules, article AI10325 of September 3, 2020, effective April 17, 2021).
• Beyond that, reattempts incur a fee: $0.10 for domestic transactions and an extra $0.05 for cross-border ones, per the fee schedule documented by Qualpay (2022).
• The networks define excessive attempts as 10 declines in 24 hours or 20 declines in 30 days on the same card (TD Merchant Solutions, November 2025).
• Retrying after Merchant Advice Code 03 or 21 triggers a specific fee. TD Merchant Solutions' November 2025 fee schedule raises it to $0.78 per reattempt as of February 1, 2026.
• Code classifications change: 39, 52, and 53 moved from category 4 to category 2, and code Z5 was created in category 2 on April 13, 2024 (Visa, Merchant Business News Digest).

# A retry fires only if its expected value exceeds its cost.
#   marge        : gross margin recovered if the retry succeeds
#   p_succes     : OBSERVED success rate for this family, on your own data
#   cout_essai   : authorization fee + reattempt fees beyond the cap
#   essais_faits : counter kept PER CARD and PER MERCHANT, across all providers

def reprise_autorisee(avis_mastercard, categorie_visa, essais_faits,
                      essais_24h, plafond_famille):
    if avis_mastercard in ("03", "21"):
        return False                      # hard stop, whatever the schedule
    if categorie_visa == 1:
        return False                      # no reattempt allowed
    if essais_24h >= 10 or essais_faits >= 20:
        return False                      # excessive-attempt zone
    return essais_faits < plafond_famille


def reprise_rentable(marge, p_succes, cout_essai):
    return marge * p_succes > cout_essai

# How to read it, not a market measurement:
# a margin of 12 units, an observed success rate of 18%, and an attempt
# cost of 0.3 units give 12 * 0.18 = 2.16 > 0.3. The retry is justified.
# At a 2% success rate, it no longer is: 0.24 versus 0.3.

Success rates by family are measured, not assumed. Log every retry with the original code, the attempt number, the time elapsed, and the outcome. After a month, recalibrate the schedule table on those numbers. Families that recover nothing drop out of the retry plan, while those that pay off earn one extra attempt, within the network cap.

Chapter 4. Measuring what network tokens actually deliver.

A network token changes what the issuer sees, because the number presented was issued by the network's token service after the cardholder was verified at enrollment. Each transaction carries its own cryptogram. The token is restricted to a domain of use, so it is useless elsewhere if it leaks. The issuer is scoring a transaction of proven origin, so the risk score eases and the authorization rate rises. EMVCo publishes the technical framework, and version 2.4 of its tokenization specification is dated July 9, 2026.

Three workstreams, one tracking metric

• Become a token requestor, directly or through your provider. The token requestor ID determines the domain of use and future portability.
• Migrate the existing vault: card numbers already on file convert to tokens without the customer reentering anything. It is the part that pays back fastest, and the part people forget.
• Track coverage: the share of stored credentials actually tokenized, by market and by issuer. An average uplift means nothing while coverage is stuck at 40%.
• Handle what cannot be tokenized: nonparticipating issuers and domestic schemes with no token service. That remainder is covered in the next chapter, on refreshing stored credentials.

In some markets the question is moot. The Reserve Bank of India has required stored credentials to be tokenized since October 1, 2022, so a merchant that keeps a card number on file there is in breach. Elsewhere, the decision remains an economic one. Domestic schemes complicate the picture: Elo in Brazil, RuPay in India, Verve in Nigeria, Meeza in Egypt, mada in Saudi Arabia, and TROY in Turkey do not follow the international networks' timeline. Measure coverage scheme by scheme, never in aggregate.

Chapter 5. Refreshing stored credentials: the procedure, not the tool.

A base of stored cards decays on its own, through expirations, reissues after loss, product upgrades, and account closures. Each event turns a scheduled charge into a decline, and then a decline into involuntary churn. The networks' updater services sync the provider's vault with issuer records. The service has been around for a long time. What is usually missing is a procedure for using it.

The weekly procedure, in five steps

• Extract the active credentials, excluding accounts already closed and tokenized cards, which are remapped automatically.
• Submit the batch to the updater service, network by network. Pricing is often per match found.
• Apply the responses in the vault before the next billing date: a fix made after the charge has run is useless.
• Retry just once the charges declined for an out-of-date credential, after the fix is applied.
• Contact the customer when the response says “account closed” or “contact cardholder.” No tool replaces that message.

The return is easy to calculate: multiply the number of matches found by the success rate of the retry that follows, then by the remaining value of a subscription. Compare that with the cost of the batch. If the service costs more than it saves, restrict it to segments with high residual value. Redo this math every quarter, because token coverage keeps growing and the useful scope of the service keeps shrinking.

• Outside cards, there is no equivalent. A direct debit mandate, an Indian e-NACH, an Australian PayTo agreement, or a Brazilian Pix Automático cannot be refreshed through a network service.
• The reject itself serves as the signal: account closed, mandate revoked, insufficient funds. Each reason calls for different handling on the merchant side.
• Treat a mandate revocation as a cancellation, not a technical incident. Retrying a charge on a revoked mandate invites a dispute.
• The vault must know the instrument: a single customer relationship can involve a tokenized card, a local mandate, and a wallet, with three different lifecycles.

Chapter 6. Authenticating where it pays.

3-D Secure is configured segment by segment, with each segment getting its own authentication decision. Authenticating adds a step and costs abandonment. Not authenticating exposes you to declines that the issuer would have approved with authentication, and leaves fraud liability with the merchant. The right setting depends first on the market's regime, then on the transaction profile. EMVCo maintains the specification: versions 2.2.0 through 2.3.1.1 are in force, and a draft of version 2.4.0.0 was published on June 3, 2026.

Three uses that are often confused

• Fill in the optional fields of the authentication request: billing address, email, phone, customer account age, purchase history. They make the difference between a frictionless flow and a challenge.
• Declare the channel honestly, along with the merchant risk indicator: an incomplete request gets challenged as a precaution.
• Measure the frictionless rate by issuing country, not in aggregate. An issuer that challenges everything is an identifiable problem, and one you can negotiate through your acquirer.
• Measure challenge abandonment separately from authorization declines. They are two distinct leaks, with two distinct fixes.
• Retry codes `65` and `1A` once, with a challenge: they are not declines but demands for authentication.

Exemption policy is driven by the fraud rate: the PSD2 RTS tier the transaction risk analysis exemption by the fraud rate of the provider requesting it. Slipping above a threshold removes the right to exempt in the higher band. The effect is mechanical: more challenges, more abandonment, fewer sales. The fraud rate therefore becomes a conversion parameter, not just a risk metric.

Chapter 7. Building the decline dashboard.

A decline dashboard answers three questions, and no more: how much are we losing, where, and since when? Any screen that does not help answer them is clutter. Six metrics are enough to run the whole workstream, as long as each one has a written definition and a set level of granularity. A metric without a shared definition produces two different numbers in two meetings.

Six metrics, and nothing more

-- 1. Authorization rate on the FIRST ATTEMPT: the only comparable series
SELECT
  pays_emission,
  produit_carte,
  COUNT(*)                                                  AS tentatives,
  AVG(CASE WHEN code_reseau_brut = '00' THEN 1.0 ELSE 0 END) AS taux_premier_essai
FROM tentatives
WHERE rang_tentative = 1
  AND jour >= CURRENT_DATE - 7
GROUP BY 1, 2
HAVING COUNT(*) >= 200;   -- below 200 attempts, noise drowns out the signal

-- 2. MIX alert: a code whose share doubles over 24 hours
WITH hier AS (
  SELECT code_reseau_brut,
         COUNT(*) * 1.0 / SUM(COUNT(*)) OVER () AS part
  FROM tentatives
  WHERE code_reseau_brut <> '00' AND jour = CURRENT_DATE - 1
  GROUP BY 1
),
reference AS (
  SELECT code_reseau_brut,
         COUNT(*) * 1.0 / SUM(COUNT(*)) OVER () AS part
  FROM tentatives
  WHERE code_reseau_brut <> '00'
    AND jour BETWEEN CURRENT_DATE - 15 AND CURRENT_DATE - 2
  GROUP BY 1
)
SELECT h.code_reseau_brut, r.part AS part_reference, h.part AS part_hier
FROM hier h JOIN reference r USING (code_reseau_brut)
WHERE h.part > 2 * r.part
  AND h.part > 0.02;      -- ignore marginal codes

One last habit protects everything else. Roll out every settings change on a fraction of traffic, with a randomly drawn control group, and compare first-attempt rates at a constant mix. Without a control group, seasonality, a shift in product mix, and an issuer decision all get mistaken for the effect of the change. A decline reduction program that does not measure its own gains ends up inventing them.