False declines: why good customers get blocked, and how to approve more of them

A false decline happens when a legitimate customer's payment is rejected because it looked risky. It can come from your own fraud rules, from the issuing bank or from a failed authentication step. False declines cost sales and customer trust, and they are easy to miss because they never show up as fraud losses or chargebacks.

Updated 1 November 2026 · RiskCogs team

Fraud losses are easy to see. They arrive as chargebacks with amounts, dates and reason codes, and someone in finance adds them up every month. False declines leave no such trail. A customer tries to pay, gets an error, and either tries another card, goes to a competitor or gives up. Your reports show one fewer order, and nothing else.

That imbalance shapes behaviour. When fraud rises, the pressure is to add rules and lower thresholds, because the losses are visible and someone is accountable for them. The cost of those rules in lost good orders is spread thin across many customers and never lands on one report. Over time, many merchants end up blocking more revenue than they save.

There is also a lasting cost. A customer who is declined on their first order often does not come back, even if the next attempt would have worked. A loyal customer declined on a large order may feel accused. Neither shows up in fraud metrics.

Your own rules. Fraud rules written in a hurry are often too broad. Blocking every order from a country, every prepaid card or every billing and shipping mismatch will stop some fraud and many good customers: travellers, gift buyers, students abroad and people who moved recently.

The issuer. Even when you approve a payment, the cardholder's bank makes its own decision. Issuers decline for suspected fraud, insufficient funds, card restrictions or simply because the transaction looks unusual for that cardholder. Decline codes are often generic, which makes it hard to know which case you are in.

Authentication. When a payment goes through 3-D Secure, some customers fail or abandon the challenge: the code arrives late, the banking app is not installed, or the window does not load on their phone. From the customer's side, that is a decline.

1. Log every decline with its source: your rule or score, the issuer response code, or an authentication failure.
2. Track customers who retry after a decline and then succeed with the same or another card; many of those first declines were false.
3. Sample declined orders and review them manually, or contact a few customers, to estimate how many were good.
4. Run new rules in shadow mode and compare what they would block with later outcomes before enforcing them.
5. Report decline rate next to fraud rate, so both sides of the trade-off are visible in the same meeting.

• Replace single-signal rules with scored decisions. One mismatch is rarely enough evidence; several together often are.
• Use a review or step-up band instead of a hard block for medium risk.
• Build allow lists for proven customers: earlier undisputed orders, same device and same card.
• Give every rule an owner and a reason, and remove rules nobody can explain.
• Re-test thresholds after every major change in traffic, such as a new market or a big sale.

Some rules show up again and again when merchants audit their false declines. Each has a reasonable idea behind it and a group of good customers it hurts.

Billing and shipping address mismatch. Fraudsters often ship to an address that does not match the card. So do people sending gifts, people shipping to work, and students. On its own this signal is weak. Combined with a new device, a data-center IP and a first order, it becomes meaningful.

Country blocks. Blocking all orders from a country with high fraud also blocks every legitimate customer there, and every traveller whose IP shows that country. A scored approach, or a review band for that country, keeps most of the protection with far less damage.

IP and card country mismatch. Travellers, expats, VPN users and people on corporate networks trigger this constantly. It is useful as one input to a score, rarely as a block rule.

Order value caps. A hard cap on order size stops some fraud and annoys exactly your best customers. A higher score requirement or step-up authentication for large first orders is usually a better trade.

Velocity limits set too low. Card testing does produce bursts of attempts, but so do customers fixing a typo in their card number. Count failed attempts per card and per device over short windows, and set limits from your own data rather than a default.

You cannot control the issuer's decision, but you can give it better information. Send complete data with each authorisation: billing address, CVV, a clear and consistent merchant descriptor and the right merchant category code. Use network tokens where your payment provider supports them, since issuers tend to trust them more than raw card numbers.

Look at your decline codes by issuer and by country. A cluster of declines from one bank or region may point to a routing problem, a missing data field or a descriptor that looks suspicious. For recurring payments, use the correct flags for stored credentials and merchant-initiated transactions, and use account updater services so expired cards do not cause failed renewals.

Retry carefully. Some soft declines succeed on a later attempt, but repeated retries on hard declines can look like card testing and can be penalised by card networks. Follow your payment provider's retry guidance.

Strong customer authentication is mandatory for many payments in Europe, but not every payment has to be challenged. Exemptions exist for low-value payments and for low-risk payments assessed through transaction risk analysis, within limits set by the regulation. Sending only the riskier payments through a challenge keeps friction where it adds value.

Where you do challenge, make it work well: test the flow on mobile, keep the checkout page stable while the challenge loads, and offer a clear retry path. Our article on 3-D Secure and risk-based authentication covers how to choose which payments to challenge.

The goal is not zero fraud or zero declines. It is the lowest total cost across fraud losses, chargeback fees, review time and lost good orders. Write that total down, even roughly, and judge every rule change against it.

In practice, this means accepting a little fraud in exchange for approving many more good customers, especially for repeat buyers and low-value orders. It also means being strict where it matters: clear card testing, data-center traffic with mismatched details, and high-value first orders with several risk signals together.

RiskCogs returns a score and reason codes rather than a bare yes or no, so you can send the middle band (40 to 69 by default) to review or 3-D Secure and only block from 70. Trust signals such as trust_same_device_as_last_approved help proven customers through.

Shadow mode shows what a rule or threshold would block before it touches a customer, and outcomes sent to POST /v1/risk-feedback make the score reflect your own good customers over time. You can start on the free Shadow plan.

• Commission Delegated Regulation (EU) 2018/389 (RTS on strong customer authentication), Articles 16 and 18.
• Visa, Visa Core Rules and Visa Product and Service Rules (public edition).

• Transaction risk scoring
• Fraud rules engine
• 3-D Secure and risk-based authentication
• Testing fraud rules in shadow mode
• Pricing
• Talk to the RiskCogs team