Library · Payment orchestration · Calculator on this page
Payment orchestration
First-try approval is not net. Unique billing is not net either when retries stay in the attempt count. Recover orders without polluting auths.
First-try vs net vs unique billing
CalculatorFirst-try is attempt 1. Net is the same orders after retries. Unique billing keeps those retries in the attempt count. Type your counts. No 80% default.
Type counts from this CRM or gateway. We do not assume a “good” approval rate.
Keep retries in the attempt count. Unique billing will sit below net.
Type unique orders, first-try approvals, and net approvals.
First-try approval is whether the first route billed. Net approval is whether that same order billed after allowed retries. Unique billing is unique successful bills over attempts that still include those retries. They are three numbers. Mixing them is how a cascade looks healthy while it burns auths.
The three rates
First-try. Unique orders approved on attempt 1, divided by unique orders you tried to bill. Routing is judged here. If first-try is weak, the first MID is the problem, not the retry list.
Net. Unique orders that eventually billed, divided by the same unique-order set. Do not put retry rows in this denominator. Adyen calls the sibling idea “net auth”: did the order get through, however many issuer messages it took. CheckoutChamp Billing Report splits Initial vs Recycle vs Total for the same reason.
Unique billing rate. Unique successful bills divided by attempts that still include cascade retries. If you leave unique bills blank, the calculator uses net approvals. If you run one MID with no retry, attempts equal unique orders and unique billing matches net. That is the point.
The phrase is overloaded. Time-billing tools use “unique billing rates” for hourly prices. Sticky.io uses “unique billing frequency” for how often a sub bills. CheckoutChamp “unique products” and “unique declines only” collapse retries so the % looks like net. Gateways such as NMI count messages. If your CRM already grouped declines, unique billing will match net until you type gateway attempts.
When they diverge
They stay together on a single MID with one attempt per order. They split as soon as a cascade retries.
Net can rise while unique billing falls. That means you recovered orders and you spent extra auths to do it. A fat lift is not proof the account is healthier. Hard declines retried onto a second MID look like net lift and can stack chargebacks.
This only works if
Cascade / extra attempts. You can name the order across hops (order id, or an Adyen-style merchant order reference). First-try is recycle 0. Net is unique orders with at least one approval. Unique billing keeps every hop in the attempt count.
One MID, no retry. First-try equals net. Unique billing equals net unless you still count extra auths (voice, AVS-only, duplicate posts). If you do, type those as attempts.
Do not mix a CRM unique-order export with a gateway attempt file and call it one rate. Pick a grain. Say which.
What to do
If first-try is the hole, fix routing: BIN, MCC, 3DS placement, the first MID. If net is the hole after a clean first-try, the cascade is not recovering. If net looks fine and unique billing does not, cut hops. Auths per recovered order, extra chargebacks on those hops, and hard-fail rules live on cascade.
Type your counts in the calculator. We do not assume an 80% “good” line. Pair: Run first-try, net, and unique billing. When the CRM unique-decline export already collapsed retries and the gateway still lists every message: CRM unique declines vs gateway messages. Soft retries still sit inside a written retry window — type the limit from your notice. Adding 3DS on a recycle: step-up retry — get whether it still burns the window in writing. When the vault path is dead: clear-PAN retry — not updater, not NSF. Leaving the vault: token migration. Kill vs updater enrollment: token kill vs updater. When retries pollute a merchant account. Failover hop count: failover auth count. Attempt fees ÷ net approvals: retry cost waterfall. Slow hop abandon $: cascade latency cost. Cascade fails ÷ cascade attempts: cascade fail share. Soft declines ÷ all declines: soft-decline share. 3DS abandons ÷ 3DS challenges: 3DS-abandon share. Workflow times out before auth: workflow timeout cost. Route p95 vs timeout ms: route latency p95. Condition misses ÷ routes: condition miss rate. Fallback volume share + fee delta: fallback gateway share. Network token fail then PAN: token fallback. Vault network-token share: network token coverage. Gateway outage attempt share: gateway outage share. Retry success after outage: retry after outage. Retries that succeed ÷ attempts: retry-success share. ACH vs card approval mix: ACH vs card approval. Step-up / 3DS abandon $: step-up abandon cost. Hard-block vs review mix: block vs review mix. Step-up vs hard-block mix: step-up vs block mix. 3DS-routed abandon: 3DS route abandon. CRM Recycle 1–3+ vs those hops: recycle ladder vs cascade. Gateway attempt share vs MID plan: gateway attempt skew. Processor response-code bucket vs expected mix: processor response skew. Soft vs hard next action: Soft vs hard decline: next action. Fraud-tool stop vs issuer no: fraud block vs issuer. Front-end paid, upsell declined: upsell decline after front-end. Checkout bump take vs decline: bump take vs decline. Method decline drop: payment method drop. Timer-step exits before pay: funnel timer drop. Idle session timeouts: session timeout drop. Soft/hard campaign buckets: campaign decline bucket. Upsell-chain step drop: upsell chain drop. Wallet vs card checkout mix: payment method mix. Wallet fail at checkout: wallet decline recovery — one card path, not a wallet-token cascade. Required fields before auth: checkout field friction. Guest vs forced account: guest vs account. 3DS dollars: Place 3DS only when the tax pays. First-try vs step-up: pre-auth vs post-auth 3DS.
AVS fail share of auths: AVS fail share. CVV fails ÷ auth attempts: CVV-fail share. AVS-driven retries ÷ all retries: AVS retry share. AVS and CVV mismatches are a cash trade further down: Trade AVS/CVV approval for fraud dollars.
First-try vs net vs unique billing
CalculatorFirst-try is attempt 1. Net is the same orders after retries. Unique billing keeps those retries in the attempt count. Type your counts. No 80% default.
Type CRM unique declines and the gateway message count for the same bill set. We invent no approval target.
Type unique orders, gateway attempts, and CRM unique declines.
Type ACH approvals and card approvals. We invent no mix %.
Type ACH and card approvals.
Routing
CalculatorWhich MID/gateway sees which traffic
Type network-token and PAN-only vault counts. We invent no coverage %.
Type network-token and PAN-only counts.
Type primary, fallback, and fee delta $. We invent no share %.
Type primary, fallback, and fee delta $.
Type gateway attempts, total attempts, and MID plan %. We invent no skew %.
Type attempts and MID plan %.
Type outage attempts and total attempts. We invent no outage %.
Type outage and total attempts.
Type condition misses and routes. We invent no miss %.
Type condition misses and routes.
Type p95 route ms and timeout ms. We invent no over-threshold %.
Type p95 route ms and timeout ms.
Cascade
CalculatorAuths per recovered order. Extra chargebacks on hops. Hard fails do not leave this account.
Type first-try declines, recovered orders, and extra auths. Extra chargebacks blank is zero. We do not fill a hop count.
Type first-try declines, recovered orders, and extra auths. Extra chargebacks can stay blank. Tick hard-fail hops only if those codes left this account.
Type unique orders and failover auths. We invent no hop limit.
Type unique orders and failover auths.
Type CRM Initial / Recycle columns. Extra gateway hops are optional. We invent no recovery %.
Type Initial attempts from the CRM billing report.
Type attempts, fee per attempt, and net approvals. We invent no approval %.
Type attempts, fee $/attempt, and approvals.
Type hops, latency ms, abandon %, and AOV $. We invent no lost $.
Type hops, ms, abandon %, and AOV $.
Type cascade fails and cascade attempts. We invent no fail %.
Type cascade fails and cascade attempts.
Retries
CalculatorWritten window headroom. Soft only. Hard stops. Do not stack CBs or burn caps.
Type retries already counted in this window, the written limit from your processor / TPE notice, and how many hard fails are in that set. We do not fill Mastercard’s number.
Type used count, written limit, and hard fails. Soft only. Hard fails kill the token.
Adding 3DS on a soft retry is still a retry attempt unless your notice says otherwise. Filter the claim. Get the count rule in writing.
| Claim | Reality | Get in writing | Do not |
|---|---|---|---|
| Step-up 3DS does not count as a retry | Usually still an auth attempt on this MID — TPE / processor windows count messages, not “feel” | Does this notice exclude step-up challenges from the retry count? | Assume a challenge is free of the window |
| Failed step-up still gets liability shift | No. Shift needs a successful authentication — abandoned challenges are not shifts | What this gateway logs as authenticated vs attempted on the retry | Count failed challenges as shift wins |
| Step-up fixes soft NSF | No. NSF is money. 3DS does not create funds | N/A — wrong tool for NSF | Step-up every soft decline hoping for cash |
| Step-up is free of the cascade pollution count | Extra auths and issuer messages still burn. Net lift can hide the cost | Whether step-up hops sit in unique-billing attempts here | Ignore auth burn because the order finally paid |
| Hard fail → step-up on another MID | No. Hard fails kill the token. Hopping is how you buy chargebacks | N/A — stop, do not step-up | Open a spare MID to challenge a dead card |
| Checkout 3DS placement rules apply unchanged on retry | Retry step-up is a different path — still measure drop and fraud save, still respect the window | Who owns step-up rules vs first-try 3DS on this gateway | Copy first-try placement blindly onto every recycle |
A vaulted token sometimes needs a new card entry. That is not account updater. Filter the claim before you spray the token.
| Claim | Reality | Get in writing | Do not |
|---|---|---|---|
| The vaulted token always retries forever | Some declines mark the credential non-reusable — silent posts will keep failing | Which families on this gateway force a new card entry vs token retry | Spray the same token until the window burns |
| Clear-PAN retry is the same as account updater | No. Updater refreshes the token from the network. Clear-PAN is a new card entry | N/A — different jobs; enroll updater separately | Wait on updater when the gateway already said re-enter card |
| CS can pull clear PAN from CRM notes | Most vaults never store clear PAN. Token-only means ask the shopper | Whether any PCI-scoped key-in path exists here — usually it does not | Invent digits from a last-four or a ticket note |
| Clear-PAN retry fixes soft NSF | No. NSF is money. Re-keying the same empty account does not create funds | N/A — wrong tool for NSF | Ask for a new card entry to “fix” insufficient funds |
| After clear-PAN, keep the old MIT chain | New card entry is a new original — later rebills must point at that sale | How this gateway stores the new original ID after a keyed card | Bill the old MIT token as if the PAN never changed |
| Hard fail → clear-PAN on a spare MID | No. Hard fails kill the token. Hopping buys chargebacks | N/A — stop; ask a new card on a clean path if the shopper is still there | Open a spare MID to force a dead credential |
Tick a row when it is true in writing. Unchecked means re-collect. We invent no portability chip.
Holes: Credential type named per stored card, Written vault export from the leaving gateway, Receiving gateway confirmed ingest in writing, Live test bill on a migrated token, Re-collect plan for tokens that will not move, New card starts a new original-sale chain, PCI / SAQ change named if PAN moves.
Type token attempts, PAN fallbacks, and fee delta $/fallback. We invent no fail %.
Type attempts, fallbacks, and fee delta.
Type timeouts, AOV, and retry fee. We invent no timeout rate.
Type timeouts, AOV, and retry fee.
Type outage fails and later successes. We invent no recover %.
Type outage fails and later successes.
Type AVS-driven retries and all retries. We invent no share %.
Type AVS-driven retries and all retries.
Type retries that succeed and retries attempted. We invent no success %.
Type retries that succeed and retries attempted.
3DS placement
GuideConversion tax vs fraud dollars. Place on amount, BIN, or risk.
First-try challenge vs step-up after soft decline. Filter the claim. Distinct from 3DS-lift dollars and step-up-retry windows.
| Claim | Reality | Measure / ask | Do not |
|---|---|---|---|
| One 3DS drop % covers first-try and step-up | No. Different who pays friction; different sample | First-try drop and step-up abandon separately | Paste one slide onto both paths |
| Step-up is free of the retry / TPE count | Usually no — still an auth attempt unless notice excludes it | Written count rule on this MID | Assume step-up is invisible to the window |
| Pre-auth on every cart because liability shift | No. Shift needs success. Clean shoppers still pay the tax | Amount / BIN / risk placement on the lift page | Challenge every landing for shift theater |
| Step-up fixes soft NSF | No. NSF is money. A challenge does not create balance | NSF on the soft/hard playbook — not 3DS | Step-up NSF days like expired-card updater |
| This map is the 3DS-lift calculator | No. Lift types tax vs fraud $. This map is pre vs post fork | N/A — open three-ds-lift for dollars | Skip measuring because you named the fork |
| This map is the step-up retry claim map | No. Step-up-retry is count / shift / hop rules. This map is placement fork | N/A — open step-up-retry for the window | Confuse fork naming with retry writing |
Type weekly orders, settled AOV, conversion drop, and fraud chargeback dollars saved. We do not fill a drop percent.
Type all four fields. We do not fill orders, AOV, drop, or fraud dollars. Place 3DS on amount, BIN, or risk — not on every shopper.
Declines
GuideAVS/CVV cash trade. Soft retries on this MID. Hard kills the token.
Wallet fail → one card path. Not a MID cascade. Filter the claim. Soft/hard card playbook is a different page.
| Claim | Reality | Do | Do not |
|---|---|---|---|
| Wallet decline = cascade the token to another MID | No. Offer a card (or alternate wallet) path once | Show card form; keep the cart | Hop the same wallet credential across spares |
| Wallet fail is the same as card NSF | No. Often device, bank-app, or network path — not an empty card balance signal | One alternate path; then read any card decline family | Run the NSF day list on a wallet token |
| Auto-retry the wallet five times | No. Burn and friction without a new path | Fail once clearly; offer card | Silent wallet loops |
| Soft/hard card playbook applies before any card auth | No. That map needs a card issuer response. Wallet fail is earlier | Use decline playbook only after a card attempt returns a family | Map wallet errors onto pick-up / NSF rows blindly |
| 3DS on the wallet retry fixes everything | No. Wallet path and 3DS placement are different jobs | Card path first; place 3DS per your rule on that auth | Stack challenges on a dead wallet session |
| There is a good wallet approval benchmark here | No. We do not invent one. Measure your first-try wallet vs card fallback | Type your own rates on first-try / net pages | Paste a slide “wallet should be 95%” |
Required fields cost converts before auth. Filter the claim. Distinct from AVS/CVV cash trade after the card is typed.
| Claim | Reality | Measure | Do not |
|---|---|---|---|
| Require phone to cut fraud — free win | No. Phone friction drops carts before any auth | Abandon with phone required vs optional | Add phone with no funnel measure |
| Force account create raises LTV enough | Maybe — only after typed convert hole vs later cash | Guest vs forced-account completion | Invent LTV lift from a slide |
| This is the same as strict AVS | No. AVS is a mismatch rule after the card is typed | N/A — open AVS/CVV for that dial | Confuse pre-auth fields with AVS |
| Marketing opt-in required is harmless | No. Forced opt-in is friction and often a compliance mess | Completion with optional vs required | Hide the toggle as a required checkbox |
| More fields always mean fewer chargebacks | No universal rule. Type fraud dollars saved if any | Fraud $ in a clean on/off window | Invent a field-count benchmark |
| Wallet path fixes field friction | No. Wallet fails are a different recover job | N/A — open wallet decline recovery | Stack wallet retries instead of cutting fields |
Hard-fail kill vs updater enrollment vs soft retry. Filter the claim. Distinct from clear-PAN, involuntary-churn rate, and updater-lift cash.
| Claim | Reality | Do | Do not |
|---|---|---|---|
| Every hard fail should hit account updater | No. Pick-up / lost-stolen / fraud kill the token | Kill stop-list shapes; enroll only expiry / account-change | Updater a dead stop-list card |
| NSF means kill the token or updater will fix it | No. NSF is money. Dunning calendar — not kill, not updater | Soft NSF on the family retry path | Enroll updater hoping for balance |
| Hop the killed token to a spare MID | No. Dead tokens stay dead. Hops buy chargebacks | Stop; ask shopper for a new instrument if needed | Cascade pick-up across backups |
| This map is clear-PAN retry | No. Clear-PAN is when the vault cannot retry and you may ask the shopper | N/A — open clear-pan-retry for that path | Confuse shopper re-entry with updater enrollment |
| This map is involuntary-churn rate | No. That page measures the hard-fail hole. This map is kill vs enroll | N/A — open involuntary-churn to type the rate | Skip measuring because you named the fork |
| Vendor recover % proves updater for every fail | No. Recover is after enrollment from your extract — and only for updater shapes | Your extract after enroll — updater-lift page | Invent a recover chip for kill codes |
Guest checkout vs forced account. Filter the claim. Distinct from checkout-field friction and wallet decline recovery. We invent no guest-fraud chip.
| Claim | Reality | Do | Do not |
|---|---|---|---|
| Kill guest checkout to cut chargebacks | Not a public constant — often kills converts first | Measure abandon and CB mix on vs off | Invent a guest-fraud rate chip |
| Forced account replaces 3DS / AVS | No. Those are auth / mismatch doors | Keep real fraud stack; treat account as convert choice | Hide guest and call signup “prevention” |
| This map is checkout field friction | Related. Field friction is which inputs. This map is guest vs forced account | N/A — open checkout-field-friction for field list | Skip measuring account force because phone is optional |
| This map is wallet decline recovery | No. That page is after a wallet fail at pay | N/A — open wallet-decline-recovery for wallet fails | Force account create as the wallet recovery path |
| Subscriptions require forced account at first pay | Vaulted credential ≠ account wall before every one-shot | Name continuity needs separately from guest one-shots | Block all guest because MIT needs a token later |
| Amazon account rules are my DTC checkout | No. Amazon’s door is different. This is your guest toggle | N/A — open amazon-a-to-z for marketplace claims | Paste Seller Central onto DTC guest checkout |
Soft can retry on this merchant account. Hard kills the token. We do not invent an issuer code table.
| Family | Soft or hard | Next action | Do not |
|---|---|---|---|
| Do not honor | Soft | One retry on this MID, then stop | Do not cascade five times. Do not open a new MID. |
| Insufficient funds | Soft | Retry later on this same MID | Do not burn a new MID cap |
| CVV / AVS fail | Soft (data) | Retry once with correct data or 3DS | Do not strip CVV to force an auth |
| 3DS failed | Soft (auth) | Fall back only if this MID is enrolled and the rule says so | Do not send the same shopper around every 3DS MID |
| Pick up card | Hard | Kill the token. Do not retry. | Never hop to another MID |
| Invalid / no account | Hard | Ask a new card. Do not retry this PAN. | Do not hop the dead PAN |
| Fraud / security | Hard | Stop. Log the BIN. | Do not retry for conversion |
Type fraud-blocked $ and issuer decline $ for the same window. We invent no block percent.
Type fraud-blocked $ and issuer decline $.
Type FE approvals, upsell attempts, approvals, and upsell AOV. We invent no attach rate.
Type FE approvals, upsell attempts, approvals, and AOV.
Type measured approval under both rules, attempts, AOV, and extra fraud dollars from the loose period. We do not fill 81% or a sample fraud bill.
Type all five fields. Approval points are not free if they land as fraud chargebacks on a watched MID. Keep CVV on continuity.
Type challenged, abandon %, and AOV. We invent no abandon %.
Type challenged, abandon %, and AOV.
Type bump offers, takes, and bump AOV. We invent no take %.
Type bump offers, takes, and bump AOV.
Type 3DS-routed count, abandon %, and AOV. We invent no abandon %.
Type 3DS routed, abandon %, and AOV.
Type timer views, exits, and AOV $. We invent no exit %.
Type timer views, exits, and AOV.
Type wallet, card, and approvals. We invent no mix %.
Type wallet, card, and approvals.
Type step shown and taken. We invent no drop %.
Type shown and taken.
Type blocks and reviews. We invent no mix %.
Type blocks and reviews.
Type attempts and declines for one method. We invent no drop %.
Type attempts and declines.
Type timeouts and sessions. We invent no drop %.
Type timeouts and sessions.
Type soft, hard, and attempts. We invent no bucket %.
Type soft, hard, and attempts.
Type step-ups and blocks. We invent no mix %.
Type step-ups and blocks.
Type bucket count, total responses, and expected mix %. We invent no skew %.
Type bucket count, total responses, and expected mix %.
Type AVS fails and auths. We invent no fail %.
Type AVS fails and auths.
Type cvv fails and auth attempts. We invent no fail %.
Type cvv fails and auth attempts.
Type soft declines and all declines. We invent no soft %.
Type soft declines and all declines.
Type 3DS abandons and 3DS challenges. We invent no abandon %.
Type 3DS abandons and 3DS challenges.
Affinity
Not on this page yetBIN / source / campaign → MID
No calculator on this section yet.
On Payment orchestration: Cascade pollution, 3DS placement, affinity — +1pt net without blowing thresholds.