🎓 CoursesAcceptance & card systemsAdvanced⏱ 60 min
📈
Optimizing your payment success rate, level 2. 6 chapters and a final quiz.
Expert-level acceptance: segmentation by BIN and by issuer, issuer-friendly data, network tokens, fine-tuned SCA exemptions, smart retries, and multi-acquirer routing. The course closes with how to measure uplift, covering the methodology and case studies with real numbers.
Segmenting the payment success rate by BIN, issuer, country, and card type to pinpoint where you lose payments
Building issuer-friendly authorization requests: descriptor, MCC, and enriched data
Deploying network tokens and understanding their lifecycle
Fine-tuning SCA exemptions (TRA, low value, MIT) without driving up the fraud rate
Chapter 1. Segmenting to diagnose: BIN, issuer, country.
An overall payment success rate of, say, 90% tells you almost nothing, because it is just an average. It mixes French cards approved at 96% with Brazilian cards at 60%, immediate debit cards with prepaid cards, and tokenized transactions with raw PANs. Level 2 optimization always starts with the same discipline: it breaks the rate down into homogeneous segments and treats each segment as a separate problem.
🔑
The golden rule of diagnosis
You never optimize “the payment success rate.” You optimize the rate for a segment × decline reason pair, such as “UK credit cards × decline 05 (do not honor) on amounts > €150.” Any action taken without segmentation is a shot in the dark.
The segmentation dimensions that matter
Axis
Example segments
Question to ask
BIN / issuer
BNP Paribas, Chase, Nubank, neobanks
Which issuers decline more than their country's average?
Card country
Domestic vs. intra-EU vs. non-EU
Is cross-border traffic routed to the right acquirer?
Product type
Debit, credit, prepaid, commercial
Do prepaid cards fail on MITs?
Credential
Keyed PAN, card on file, network token, wallet
Does the network token outperform the PAN on this BIN?
Amount
< 30 €, 30-100 €, 100-250 €, > 250 €
Where do the exemption and risk thresholds kick in?
Authentication
Frictionless, challenge, exemption, MIT
Does the 3DS challenge hurt conversion on mobile?
Segmentation grid for a payment success rate
Since April 2022, the ISO/IEC 7812 standard has extended BINs from 6 to 8 digits, making them far more granular. An 8-digit BIN often identifies a specific issuer portfolio (a card range, a co-brand, or a prepaid program). Your reporting tables need to be migrated to 8 digits. Otherwise, you are lumping together very different populations.
Reading decline codes like an issuer
Code
Meaning
Takeaway
Typical action
05
Do not honor
Generic decline from the issuer's risk scoring
Enrich the data, test the network token, reroute
51
Insufficient funds
Insufficient funds
Deferred retry (after payday), partial amount
54
Expired card
Expired card
Account updater or network token, never a blind retry
14 / 41 / 43
Invalid / lost / stolen
Invalid card, or card blocked as lost or stolen
No retry (category 1): ask for another payment method
59 / 63
Suspected fraud / security
The issuer suspects fraud
Force 3DS authentication, then resubmit
Common decline codes (ISO 8583) and what they mean in practice
≈ 85-90 %
average e-commerce authorization rate in Europe, all cards
PSP studies, 2024–2025
$50.7B
in sales lost each year to false declines across four major markets (US, UK, France, Germany)
Checkout.com, 2023
≈ 0,16 %
fraud rate on online card payments in France
OSMP, 2024 annual report
🎯 Quick question
Why can an overall payment success rate of 90% hide a serious problem?
Chapter 2. Issuer-friendly data: getting the authorization request right.
The issuer's risk engine scores every authorization within tens of milliseconds, and it only “sees” what you send it. A sparse, inconsistent, or badly coded authorization message automatically pushes up the risk score and the likelihood of a 05 (do not honor) decline. Being issuer-friendly means giving the issuer every reason to say yes.
🏷️
Readable descriptor
A clear soft descriptor (“PAYPEDIA*ABO-PRO” rather than an obscure abbreviation) reduces declines, as well as “unrecognized transaction” chargebacks further down the line.
🗂️
Accurate MCC
The MCC determines the risk profile, the interchange, and certain exemption rules, so a wrong MCC skews the issuer's scoring and exposes you to network penalties.
👤
Enriched customer data
Email, phone number, shipping address, and customer history, when sent in the dedicated fields (authorization and 3DS), push the issuer's scoring in the right direction.
🔧
Technical consistency
A stable merchant ID, a consistent city and country, and the same identifiers in 3DS authentication and authorization. Any inconsistency is a fraud signal for the issuer.
Scope
Impact if filled in wrong
Best practice
Soft descriptor
Declines + “unrecognized” disputes
Brand + product, 22 characters max, tested on a real statement
MCC
Skewed scoring, network fines
Matches the actual business, reviewed for each new product
COF/MIT indicators
“SCA required” soft declines
Correctly flag the initial storage and subsequent transactions
3DS data (device, email)
Fewer frictionless approvals
Fill in as many EMV 3DS fields as possible, not just the required ones
Amount/currency
Avoidable cross-border declines
Present the transaction in the card's currency where relevant
Declaring a “convenient” MCC to lower interchange or avoid a high-risk profile violates Visa and Mastercard rules. The networks audit, reclassify, and charge penalties to the acquirer, which passes them on to the merchant. The correct MCC also determines how reliable your TRA exemptions are.
Each scheme publishes its own data quality guidesVisaMastercardCACartes Bancaires CB
Audit a sample of real bank statements to check how the descriptor appears at the main issuers.
Compare your authorization message, field by field, against the Visa and Mastercard data quality guides.
Measure the effect of each enrichment with an A/B test (chapter 6), never by gut feeling.
🎯 Quick question
What is the main risk of a miscoded MCC?
Chapter 3. Network tokens: the credential with a life of its own.
A network token replaces the PAN with a token issued by the network (Visa, Mastercard) through its Token Service Provider (TSP), bound to a merchant × card pair. A PSP token is just an alias in a provider's vault, whereas a network token is recognized end to end. The issuer knows it is authorizing a restricted-use credential, accompanied by a dynamic cryptogram for each transaction.
Criterion
Stored PAN
PSP token
Network token
Issued by
–
The PSP (PCI vault)
The network (TSP), with the issuer's approval
Visible to the issuer
Yes (PAN)
No (detokenized before sending)
Yes, as a restricted-use token
Update when the card is reissued
No (54 decline)
Via account updater (batch)
Automatic and continuous, by the issuer/TSP
Security
PAN exposed to theft
PAN protected at the PSP
PAN never held by the merchant + dynamic cryptogram
Portability across PSPs
Yes (PCI export)
Depends on the contract
Re-provisioning required (tied to the token requestor)
Raw PAN, PSP token, and network token: three credentials, three logics
10B
network tokens issued by Visa worldwide, a milestone passed in June 2024
Visa, June 2024
+$40B
in incremental e-commerce revenue attributed to tokens over one year, plus $650 million in fraud prevented
Visa, June 2024
100 %
Mastercard's target for tokenizing European e-commerce by 2030
Mastercard, 2024
🔑
Why issuers are more willing to approve a token
A network token comes with a unique cryptogram for each transaction (TAVV/DTVV), so the issuer has cryptographic proof that the request really comes from the merchant the token is bound to. The risk of replay or stolen cards drops sharply, and the issuer's scoring eases. The observed authorization uplift is typically +2 to +3 points, depending on the corridor.
Provisioning a network token
Merchant / PSP
Requests tokenization of the PAN from the TSP
As a registered token requestor
➜
TSP (network)
Asks the issuer for approval
The issuer can approve, decline, or require verification
➜
Issuer
Approves and binds the token to the card account
The token is restricted to the merchant's domain
➜
TSP (network)
Returns the token + PAR to the merchant
The PAR (Payment Account Reference) links tokens to the PAN for reporting
➜
Merchant
Uses the token + cryptogram for every payment
The PAN never passes through its systems again
⚠️
Measure before rolling out everywhere
On some BINs, especially outside Europe or at issuers with immature tokenization infrastructure, the network token can underperform the PAN. Hence a BIN-by-BIN rollout with A/B testing, and a data-driven fallback to the PAN (or a PSP token). That is exactly what smart routing does.
🎯 Quick question
What happens to a network token when the underlying card is reissued (new expiration date or new PAN)?
Chapter 4. Fine-grained SCA exemptions and 3DS steering.
PSD2 requires strong customer authentication (SCA), but its regulatory technical standards (RTS) provide exemptions and place certain flows outside its scope. Fine-grained steering sends each transaction down the best path: an exemption without 3DS, frictionless 3DS, or a full challenge. The trade-off is between conversion, fraud, and liability shift.
Case
Conditions
Who bears the fraud loss?
Acquirer TRA
≤ €100 if the acquirer fraud rate is ≤ 0.13%; ≤ €250 if ≤ 0.06%; ≤ €500 if ≤ 0.01%
Acquirer/merchant chain (no liability shift)
Low value
≤ €30, max. 5 consecutive transactions or €100 cumulative without SCA
Acquirer/merchant chain
Trusted beneficiary
The customer has whitelisted the merchant with their issuer
Issuer
MIT (out of scope)
Merchant-initiated transactions, after an authenticated setup (initial SCA)
Merchant (no authentication)
Corporate cards
Lodged or virtual cards used through secure processes
Issuer
One-leg-out / MOTO
Issuer or acquirer outside the EEA; mail and telephone orders: outside SCA scope
Standard network rules apply
SCA exemptions and exclusions at a glance (PSD2 RTS)
⚠️
Exemption = giving up the liability shift
A transaction processed under a TRA or low-value exemption without 3DS gets no liability shift, so if it turns out to be fraud, the merchant bears the chargeback. Fine-grained exemptions only make sense on segments where expected fraud is far smaller than the conversion gain. And the issuer can always reject the exemption with a soft decline (Visa 1A, Mastercard 65) that requires the transaction to go back through 3DS.
Requesting a TRA exemption in the API call (example)
Score every transaction in-house (expected fraud, customer value, sensitivity to friction).
Choose the path: a direct exemption if the score is very low and the amount is within the TRA thresholds; otherwise 3DS, aiming for frictionless with rich data.
Handle the soft decline: resubmit automatically with 3DS, with no action required from the customer, or you lose the sale.
Monitor the acquirer fraud rate: if your acquirer crosses a TRA threshold, your entire exemption program drops down a tier.
> 50 %
of authenticated transactions in France go through frictionless (no challenge)
OSMP, 2024
0,01 %
maximum acquirer fraud rate for exempting up to €500 under TRA
PSD2 RTS
1A / 65
Visa / Mastercard soft decline codes meaning “SCA required, resubmit with 3DS”
network rules
🎯 Quick question
An issuer responds with a soft decline (Visa code 1A) to a TRA exemption request. What is the right response?
Chapter 5. Smart retries and multi-acquirer routing.
When a payment is declined, you still have two levers. You can retry the transaction (later, or differently), or reroute it to another acquirer. Both are powerful, and both are governed by rules. Since 2021, the networks have penalized abusive retries, and routing is only worth something when it is driven by data.
Switch to an account updater or network token, or ask for another payment method
Category 2: retryable
05, 51, 61, 65 (do not honor, insufficient funds, limits)
Maximum 15 retries over 30 days per transaction (Visa, since 2021)
Data-driven timing: payday, local time, BIN behavior
SCA soft declines
1A (Visa), 65 (Mastercard)
Immediate retry expected
Automatically resubmit with 3DS, with no added friction
Retry policy by decline category (Visa framework; Mastercard follows similar logic)
⚠️
Brute-force retries are expensive
Every retry generates authorization fees, and the networks' integrity programs (such as Visa's VAMP, rolled out across the board in 2025) monitor acquirers' anomaly ratios. A merchant that keeps hammering category 1 declines damages its reputation with issuers… and therefore its overall payment success rate. Retries are a scalpel, not a sledgehammer.
Multi-acquirer routing: the right path for every transaction
Routing cascade on a technical or suspicious decline
Orchestrator
Routes the transaction to acquirer A
Chosen by rules: domestic BIN → local acquirer
➜
Acquirer A
Decline 05 or outage
The decline is classified in real time
➜
Orchestrator
Reroutes to acquirer B
A single cascade, on eligible codes only
➜
Acquirer B
Authorization approved
The sale is saved; the data feeds future rules
Mature routing rules combine several criteria. Domestic acquiring comes first, because a French issuer responds better to an acquirer that processes locally. Next come the choice of scheme on co-badged cards (CB vs. Visa/Mastercard, a right guaranteed by the IFR) and the token-or-PAN preference by BIN. Last come acquiring costs and each acquirer's real-time health. Moving to well-managed multi-acquiring typically lifts the payment success rate on cross-border flows by +1 to +3 points.
Typical players in a multi-acquirer setupAdyenStripeWorldlineNUNuvei
🎯 Quick question
A transaction is declined with code 41 (lost card). What does a compliant retry strategy call for?
Chapter 6. Measuring uplift: methodology and case studies.
Most “uplifts” claimed in card payments are artifacts of seasonality, a shift in country mix, or a marketing campaign running at the same time. An improvement can only be credited to an optimization if it holds up in a controlled comparison. That check is the least glamorous part of the job, and the most profitable.
A/B traffic split: the same population is randomly split between the old configuration (control) and the new one (treatment). This is the gold standard.
Permanent holdout: keep 5–10% of traffic on the old configuration for weeks to measure the lasting effect, not just the novelty effect.
Compare like-for-like segments: any difference in mix (country, BIN, amount) between the two arms invalidates the result. Check the balance before drawing conclusions.
Measure net revenue: authorization rate + fraud + fees (retries, routing, tokens) + chargebacks. An authorization uplift that drives up fraud is a loss.
Reading a test: authorization rate by arm and by segment
SELECT
experiment_arm,
card_country,
bin_8,
COUNT(*) AS attempts,
AVG(CASE WHEN approved THEN 1 ELSE 0 END) AS auth_rate,
SUM(fraud_loss_eur) AS fraud_eur,
SUM(net_revenue_eur) AS net_revenue_eur
FROM authorizations
WHERE created_at >= DATE '2026-05-01'
GROUP BY 1, 2, 3
ORDER BY attempts DESC;
🔑
The ultimate metric is net revenue per attempt
The authorization rate is an intermediate metric. The decision to roll out an optimization is made on net revenue per payment attempt (approved sales − fraud − fees), measured over time against a holdout. That is the only number that speaks to a CFO.
Three case studies with real numbers (realistic orders of magnitude)