Payment Approval Rate Optimization

Measure before touching anything

Approval-rate work fails at the denominator more often than at the payments. Three measurement rules make everything after them possible:

Deduplicate to intent. One player deposit intent, many attempts. Intent-level success is the business metric; attempt-level approval per provider is the diagnostic. Mixing them makes every cascade change look like a payments regression.
Cell-level, never blended. Provider × method × market is the working grain. A blended rate is an average over populations that share nothing; every real problem lives in a cell.
Separate the decline families. Internal risk blocks, provider/infrastructure failures and issuer declines are three different problems owned by three different people. One funnel state for all three guarantees the wrong team gets paged.

The diagnostic ladder

Work the ladder in order — each rung is cheaper than the one below it, and each rung's fix invalidates the diagnosis of the rungs beneath until it is re-measured:

Rung	Question	Typical fix
1. Measurement	Are retries deduplicated? Are risk blocks separated?	Fix the funnel definitions before believing any number below
2. Data quality	Are the fields issuers score — names, addresses, descriptors — complete and correct?	Cashier form and descriptor fixes; cheap, fast, measurable
3. Method-market fit	Are players forced onto methods they don't trust locally?	Add the locally-native method before adding another card route
4. Retry policy	Are soft declines retried sensibly, hard declines never?	Per-code cascade policy — see orchestration
5. Provider performance	Does one provider underperform an alternative on matched cells?	Reroute the cell; renegotiate or replace with evidence in hand
6. Traffic risk profile	Is the residual decline rate the issuers' verdict on the traffic itself?	An acquisition and risk conversation, not a payments one

Note where "add a PSP" sits: rung five, with evidence. Most operators start there because it feels like action; the ladder exists because rungs one through four are where the recoverable money usually is.

Reading decline codes without folklore

Every payments team accumulates lore about what codes "really mean". Replace it with process: map every provider's raw codes into one internal taxonomy (retry-safe / verify-first / terminal), keep the raw code alongside the mapped class in the event record, and review the distribution shift per cell weekly. A moving mix of decline classes is the earliest signal you get — earlier than the approval rate itself — that an issuer, a provider or your own risk rules changed behaviour.

The player-visible layer

Approval work ends at the message the player sees. A decline with a dead-end error loses the deposit and often the session; a decline that immediately offers the next-best method for that player and market converts a payments failure into a routing event. Instrument abandonment after first decline as its own metric — it is the difference between the attempt funnel and the money funnel, and it is where cashier UX quietly decides FTD conversion.

Governance

Approval rate is a number three teams can move — payments, risk and acquisition — which is why it needs the dictionary treatment: one definition, intent and attempt variants both specified, owners named, and rule changes (routing, risk, retry) logged against the date they shipped. The weekly review then reads movements against changes, not against theories.

Continue reading: Payout operations — the other half of payments, where trust is actually earned. Approval rate — the glossary definition this page operationalises.

Approval rates — common questions

What is a good payment approval rate for an iGaming operator?

There is no defensible universal number — the honest baseline is your own, per method, per market, per provider, measured on deduplicated attempts. Approval rate moves with method mix, market mix, player mix and retry policy, so a single blended figure is not comparable between operators or even between months of the same operator. The metric definition matters as much as the value: see the glossary entry for the denominator traps.

What is the single most common measurement mistake?

Counting retries as independent attempts. A cascade that retries every decline once will halve your apparent approval rate while improving the player's actual success rate. Measure intent-level success (did the player's deposit intent end in money) separately from attempt-level approval (did a specific provider approve a specific attempt) — the first is the business number, the second is the diagnostic one.

When does adding another PSP help, and when doesn't it?

It helps when the diagnosis shows provider-specific failure: one provider's approval on a method-market cell sits materially below an alternative's on matched traffic. It does not help when declines are issuer-driven (bad data quality, missing fields, risk profile of the traffic itself) — those follow you to the new provider. Diagnose first; the new-PSP reflex is how operators end up with six integrations and the same approval rate.

How do risk rules interact with approval rate?

Internal risk declines and provider declines get mixed into one funnel unless you separate them deliberately. A tightened fraud rule shows up as 'payments got worse' two weeks later if the reporting cannot tell them apart. Tag internally-blocked attempts as their own terminal state, report them to the risk owner rather than the payments owner, and review the split whenever either team changes rules — the same route-on-both-dimensions discipline as abuse detection.

Which quick wins are usually real?

Correct and complete issuer data (names, addresses, descriptors), method-market fit (offering the locally trusted method rather than forcing cards), retry policy on soft declines with a per-code cap, and honest failure messaging that routes the player to an alternative method instead of a dead end. All four are cheaper than a new integration, and all four show up within days in the per-cell numbers.

Raising approval rates.