At a glance
Percentage of CyberSource transaction attempts that ended in AUTHORIZED. The cleanest single signal of “is the gateway doing its job today, yes or no” for enterprise merchants. The 35%-weight component of Payment Health Score. Healthy CyberSource merchants run 92, 96%; below 90% is unusual and almost always points to a Decision Manager rule-pack misfire, an issuer-side outage on a major BIN, or a 3DS 2.0 challenge-rate spike.
Calculation
Calculated automatically from your CyberSource data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A US-based subscription telecommunications merchant running CyberSource for monthly bill-pay across 8.4M active accounts. The 7-day window covers 06 Apr 26 to 12 Apr 26. Heavy tokenized-recurring book (94% of attempts are TMS-tokenized stored cards on file). The transaction outcome mix from/tss/v2/searches:
Drilling into the 86,400 DECLINED:
- 93.56% is healthy enterprise band. Comfortably above the 92% alert threshold. The carrier’s heavy TMS-tokenized recurring book is doing its work; if this were a fresh-card-heavy mix the auth rate would likely sit 87, 91% with the same issuer base.
do_not_honoris the largest decline bucket at 41%. This is typical for recurring-billing books: issuers responddo_not_honor(reason 203) when their internal risk models flag a recurring-MID transaction even though there’s nothing wrong. Recovery via single retry rarely works (the issuer’s risk position doesn’t change); recovery via Dunning Recovery Rate at +24h with messaging to the customer is more effective.insufficient_fundsis the second-largest at 27%. Higher than typical for a non-subscription merchant. This is an artifact of bill-pay timing: the merchant runs all monthly bills on the same day for some account cohorts, hitting customers who hadn’t yet been paid that month. Retry-on-payday-aligned schedules (typical+5 days,+10 days,+15 daysfor a SSI / pension cohort that paydays mid-month) recover ~32% of these.- AVS mismatch at 13% is meaningful. Fresh-card billing-address re-prompts in the customer self-service portal recover some of these (the customer typed the wrong zip; the actual zip on the bank record is different). For a recurring book, AVS mismatch on a previously-successful tokenized card usually means the customer moved house and the billing zip is now stale; account-update services from the card networks refresh this.
- Decision Manager
REJECTat 6.4%, with REVIEW at ~0.8% of total. A relatively healthy DM tuning. If REJECT climbed above 8%, ops should run a Decision Manager Replay against historical rule packs to confirm whether a recent rule change is responsible. See Decision Manager Score Mix.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in CyberSource Business Center (EBC2): Closest views in ebc2.cybersource.com:- Transactions → Search, filter by
Status = AUTHORIZEDfor numerator, all statuses for denominator. - Reports → Standard Reports → Conversion Detail Report, the daily transaction-level dump. Authoritative source for “what authorised yesterday”.
- Decisions → Decision Manager → Performance Reports for the DM
ACCEPT/REVIEW/REJECTdistribution.
Cross-connector reconciliation:
Known limitations / merchant FAQs
Why is CyberSource’s auth rate lower than Stripe’s for the same brand? Three structural reasons. (1) CS is positioned for enterprise and carries harder traffic mix: more international, corporate, recurring, all of which run lower issuer-side approval rates. (2) Multi-acquirer routing typically sends harder traffic to CS by design (Stripe handles the easy domestic-consumer flow). (3) CS’s Decision Manager rule packs are usually tuned more conservatively than Stripe’s Radar defaults, especially on enterprise merchants with chargeback monitoring exposure. A 2, 4pp gap is normal. My auth rate dropped 3pp overnight, where do I look first? In order: Top Decline Reasons (which bucket grew?), Top Declining Issuers (single-issuer outage?), Decision Manager Score Mix (recent DM rule-pack ship?), then 3DS Success Rate (challenge-rate spike from the issuer side?). 80% of overnight drops are either a single-issuer outage (Capital One, Chase, BoA) or a DM rule-pack rollout. My DM REVIEW rate climbed; should I expect this auth rate to fall? Yes, by definition. REVIEW outcomes are in the denominator but not the numerator. A 1pp climb in REVIEW rate without a compensating climb in ops manual-approval pulls auth rate down 1pp. The fix is either: tighten DM rules (so fewer transactions go to REVIEW), or speed up ops manual-clear so customers don’t abandon during the queue. How does 3DS 2.0 affect this card? 3DS 2.0 frictionless flow has minimal impact, frictionless authentications complete server-to-server and the auth proceeds normally. Challenge flow is the impact: customers seeing the issuer’s challenge screen and abandoning end asDECLINED (the auth never completes), which lowers this rate. EU PSD2 / SCA-mandated challenges add 5, 12% friction depending on customer device and issuer. See 3DS Challenge Abandon Rate.
Why is my recurring-billing auth rate lower than my one-time auth rate?
Two reasons. First, recurring transactions trigger issuer risk models more aggressively (they look like card-on-file fraud patterns to a naive risk engine). Second, recurring books accumulate stale tokens (cards that have expired since the last successful charge); the network’s Account Updater service refreshes some, but not all. Tokenized recurring on network tokens (VTS / MDES) is the highest-auth-rate slice of any enterprise book.
What’s the auth-rate uplift from network tokens specifically?
Materially significant. On the same merchant comparing fresh-card vs network-token (Visa VTS / Mastercard MDES) for the same customer cohort, expect 4, 8pp uplift. PAN-token via TMS gives less (1, 3pp). Network tokens carry stronger metadata to the issuer and trigger fewer risk-model false-positives.
Does multi-acquirer routing affect this card?
Yes. If the merchant uses an external router (Spreedly, Cashflow, internal logic) to distribute auth requests across multiple acquirers, this card shows only the slice routed to CyberSource. Healthy multi-acquirer setups send harder traffic to the lowest-cost acquirer; if CS is the failover, expect this card to read materially lower than a single-acquirer-CS setup would.
How fast does this card refresh?
Real-time via /tss/v2/searches for the most recent 7 days, with sync-cycle freshness (typically every 5, 15 minutes). Historical (>7 days back) uses Reporting v3 which runs overnight. Check last_synced_at in the card metadata for exact freshness.