Acceptance rate forensics: how to find out why card approvals dropped and get them back.

First, define the number

Acceptance rate is approved authorisations divided by authorisation attempts. Decide, and write down, whether retries count as attempts, whether 3DS abandonment is in or out, and whether you measure at first attempt or final outcome. Half of the "acceptance has dropped" conversations I join are two teams measuring different things. For an acceptance-rate programme the headline KPI should be final-outcome acceptance per unique payment attempt, with first-attempt acceptance tracked alongside it.

Segment before you theorise

A blended acceptance rate hides everything. Break the drop down, in this order, and stop as soon as one segment explains most of it:

1. By acquirer and by MID. If one acquirer fell and the others did not, the cause is on that route.
2. By issuer and issuer country. If a handful of issuers fell, it is an issuer-side change: new fraud models, a BIN range reclassified, a scheme bulletin applied.
3. By card type and funding. Debit versus credit, consumer versus commercial, domestic versus cross-border. Cross-border debit is where regulatory and issuer changes show first.
4. By authentication path. 3DS challenged, 3DS frictionless, exemption applied, no 3DS. A shift in exemption acceptance or challenge abandonment looks like an acceptance drop and is not one.
5. By method, device and market. Wallets, tokens, cards on file; app versus web; each market separately.
6. By time. Hour of week against a baseline. A drop that starts at a release, a rule change or a Monday morning tells you where to look.

Read the decline codes properly

Group the response codes into families: insufficient funds, do-not-honour and generic declines, suspected fraud, authentication required or failed, invalid card data, issuer unavailable, and acquirer or gateway errors. Then look at which family grew. Insufficient funds growing is the economy or the customer base. Do-not-honour growing on a few issuers is their risk model. Authentication-required growing is exemption handling. Issuer-unavailable or gateway errors growing is infrastructure, and usually somebody's incident that was never reported to you.

Soft declines deserve their own line. A soft decline is a request to try again differently, usually with authentication. If your platform treats soft declines as final, you are leaving acceptance on the table every day.

Separate the three owners

Every cause belongs to one of three parties. Issuer causes: risk models, BIN changes, scheme mandates. You cannot change them, but you can route around them and present better data. Acquirer and gateway causes: routing, timeouts, data mapping, certificate and key changes, MCC and descriptor settings. You can escalate these with evidence. Merchant causes: checkout changes, new markets, promotional traffic, fraud rules set too tight, retry logic, token and credential-on-file handling. You own these. Most drops have one merchant cause and one issuer or acquirer cause compounding each other.

The fixes that recover the most

• Route by issuer performance, not by acquirer price alone. The cheapest route is rarely the best-accepting one for every issuer.
• Retry intelligently: soft declines with authentication, issuer-unavailable after a delay on another route, never retry hard declines.
• Send the data the issuer wants: full address and device data where available, correct MCC, clean descriptors, network tokens where the issuer accepts them better than PANs.
• Tune 3DS exemptions to the issuers that honour them, and challenge where frictionless is being declined anyway.
• Loosen fraud rules that block more good customers than fraud, measured by the loss they actually prevent.

Then make it permanent

The programme that added €8m a year across 20+ brands for one listed group was not a single fix. It was acceptance rate as the headline KPI, measured the same way everywhere, reviewed weekly by segment, with a live monitor that flagged any segment moving outside its baseline within minutes. That monitor is now the first thing I build for a client, usually in the first two weeks, with AI doing the baseline and anomaly work and a person deciding what to change. How that works, and what your data would show.