False decline cost calculator: what refusing good customers costs

Start with the population. Order attempts times your approval rate gives approved orders, and everything else is a decline. A false decline is the subset of those declines that were good customers: a real cardholder, buying a real thing, refused by a rule rather than by a lack of funds. Nobody can tell you your share, so the False Decline Cost Calculator takes it as an input and shows what each value implies rather than pretending to know it.

Then split the falsely declined into three fates, because they cost wildly different amounts. Some retry and succeed, and those cost you nothing but friction. Some abandon this order and shop with you later, and those cost the gross profit on one order. Some never come back, and those cost the gross profit on the order plus every dollar of margin they would have delivered afterwards. The third group is where the money is, and it is invisible in every report a merchant already runs.

The arithmetic is deliberately in gross profit rather than revenue. A refused order does not cost you the sale price, because you never shipped the goods. It costs you the margin. Lost revenue is the bigger and more quotable figure and this page prints it, but the number that belongs in a business case is the profit. The lifetime value input is future gross profit beyond the declined order for the same reason: a lifetime value that already contains this order counts one sale twice.

The last step is the one nobody else takes. Fraud rules that refuse good customers also stop real fraud, and a blocked fraudulent order is a genuine saving: the goods you did not ship plus the dispute fee you were not charged. It is not the order value, because that revenue was always going to be reversed. Netting the two gives a position rather than a scare number, plus the break-even share of declines, the point below which your rules pay for themselves.

The authorization decision is not yours. When a customer clicks pay, the issuing bank's models decide, and Stripe's documentation lists what those models look at: spending habits, account balance, and card data including expiry date, address information and CVC. Your processor relays the answer. That changes what you can do about a decline: you cannot approve a transaction the issuer refused, you can only change what the issuer was looking at when it decided.

That leaves four levers. The first is the quality of the data on the authorization: address verification, the card security code and a consistent billing name are what let an issuer tell a returning customer from a stolen card. The second is authentication. Running 3-D Secure gives the issuer a verified cardholder rather than a guess, and where authentication succeeds it shifts liability for fraud disputes to the issuer, which Stripe describes as protecting businesses from liability for fraudulent card payments. It adds a step at checkout, so it is a trade rather than a free win.

The third lever is the credential itself. Network tokens replace the card number with a token specific to you that carries a cryptogram, and they update themselves when the card is reissued. Visa's own figures are the best evidence available: token based transactions drive a four percent uplift in authorization and a 30 percent reduction in fraud online against the plain card number, measured on VisaNet from October to December 2022. Account updater services do a slower version of the same job.

The fourth lever is the one you own outright, your own fraud tool. Everything above is an issuer decision. The rules you or your vendor wrote are yours, and so are the orders they block before an issuer ever sees them. If your fraud tool rejects orders itself rather than declining them at the bank, those rejections are not in your gateway's decline count at all, and you have to go and get them separately before this arithmetic is complete.

Visa groups authorization response codes into four categories, and the grouping decides what you may do next. Category 1 means the issuer will never approve: 04 pick up card, 41 lost card, 43 stolen card. Zero reattempts. Category 2 means the issuer cannot approve at this time, covering 51 insufficient funds, 61 and 65 limits and 91 issuer unavailable, and those may be reattempted up to 15 times in 30 days. Category 3 is data quality: correct the details, never resend the same ones. Category 4 is everything else, the generic codes. Visa's update of 3 September 2020, effective 17 April 2021, moved codes 03, 62, 78 and 93 out of Category 1 into Category 2 so merchants could stop discarding those sales.

So a retry program has to read the code, not just the failure. Reattempting a Category 1 decline is a rules breach whatever your success rate looks like, and a burst of retries on any code reads to issuers as card testing. Stripe's guidance is to stop at eight retries, and it says directly that additional retries can be seen as potential fraud and increase declines on legitimate charges. The network ceiling is 15 in 30 days; the working limit is well below it.

The largest and least useful group is the generic decline, Category 4, led by response code 05 do not honor. Stripe states that card issuers categorize most declines as generic, which makes the exact reason unclear. That is why false declines hide there: nothing in the code says the customer was bad. Read the advice code before you reattempt one, because Stripe returns do_not_try_again on some and try_again_later on others. Then send more data, not more attempts, because this is where a better authorization does more good than a second identical one.

The cheapest approval rate you will ever buy is in the system and routing group: issuer unavailable, system malfunction, reenter transaction. Nothing is wrong with the card or the customer, and every one you do not retry is a sale thrown away for a timeout. The False Decline Cost Calculator's third tab prices a retry program separately, and its figure overlaps with the first tab. Do not add the two together.

There is a large, round, frequently repeated dollar figure for the annual cost of false declines in US ecommerce. This page does not print it, because every trail leads back to a survey nobody can produce or a vendor with something to sell. What does exist is narrower and worth more. The Federal Reserve Board reported that in 2023, for issuers covered by Regulation II, fraud losses to all parties were 17.6 basis points of transaction value, up from 7.8 basis points in 2011, and merchants absorbed 49.9 percent of them. That report was released on 19 December 2025 and covers debit and prepaid cards only.

The same report gives the incidence, which is what puts a fraud ruleset in perspective. Fraudulent transactions were 0.12 percent of dual-message debit transactions in 2023, roughly one in 830. A rule tuned to catch that needle works through a great deal of hay, and every point of over-blocking costs real orders.

On the recovery side the strongest public evidence is Visa's, and it needs reading carefully, because Visa publishes two different kinds of number. The merchant level figures are relative lifts: four percent uplift in authorization from tokens, 4.6 percent globally on high volume tokenized merchants. The network level figure is absolute: tokenization has caused a six basis point increase in payment approval rates globally, alongside more than $40 billion of incremental ecommerce revenue, per Visa's press release of 4 June 2024. Both are true. Merchants who adopt tokens get the lift; the network average moves six basis points because most volume is not tokenized.

What nobody publishes is the two figures this calculator most wants: the share of declines that are false, and the mix of decline reasons across merchants. Every page quoting those is quoting itself. Both are inputs here, the default decline mix in the third tab is labeled an editorial placeholder rather than data, and the fix is the same for both: export your own decline codes for a month and put the real shares in.

Act when the net position is negative and the break-even share is close to plausible. On the defaults above the rules lose $107,827 a year and would break even at an 11.9 percent false decline share against the 20 percent entered. That is not a rounding error, and it survives being wrong: at half the assumed rate the case for loosening still holds. The second output is what wins the argument. One point of approval rate on 12,000 attempts is $58,061 a year of gross profit, which is why approval rate work loses budget to projects with smaller returns and better slides.

Do nothing when the loss is small against the fraud caught, when your margin is thin, or when a fraud spike would be existential rather than expensive. A merchant at a 12 percent gross margin recovers little from an extra approved order and loses a great deal on a fraudulent one, so tight rules are correct there and this arithmetic will say so. Near a card network chargeback monitoring threshold, loosening rules is the wrong move at the wrong time.

Before you touch a rule, do the free things. Send address verification and the card security code on every authorization. Turn on an account updater for cards on file. Adopt network tokens if your processor supports them. Retry the system and routing declines you currently discard. All four raise the approval rate without moving your risk appetite by a point, and three cost nothing but a configuration change. Loosening a fraud rule is the last lever to reach for, because it is the only one that trades directly against fraud losses.

Then measure. Pull a month of declines with their reason codes and order values, and find out how many were generic, how many were hard, and how many were never retried. Every number here becomes yours at that point, and the False Decline Cost Calculator stops being an argument and starts being an accounting entry.