At a glance
The percentage of customers who abandoned at the 3DS challenge (Cardinal-Cardinal-Commerce-issued bank popup) without completing it. Different from 3DS-failed (issuer rejected). Indicates UX friction: customers can’t or won’t complete bank verification.
| What it counts | COUNT(3DS-attempted but not completed) / COUNT(3DS-attempted) * 100. Numerator: customers who initiated 3DS but neither passed nor failed within the cardinal-session timeout. |
| API source | Cardinal Commerce session events (bundled with Authorize.Net for 3DS handling) plus transactionStatus = expired rows from the Transaction Reporting API. |
| 3DS-passed | Excluded (success). |
| 3DS-failed | Excluded (counted as decline in aut_decline_rate, reason 200). |
| 3DS-not-required | Excluded (no challenge displayed, no abandon possible). |
| Currency | Currency-neutral. |
| Channel | Web checkout only (POS / MOTO / B2B-CIM-tokens don’t trigger 3DS). |
| Healthy baseline | 8 to 15% of challenged customers abandon. Above 25% suggests language localisation issue, mobile UX issue, or unclear merchant branding on the bank page. |
| Time window | 7D vsP. |
| Alert trigger | >30% absolute OR +15pp vsP. |
| Sentiment key | gauge_inverse: good<=15, warn>30 |
| Roles | owner, operations |
Calculation
Calculated automatically from your Authorize.net data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
“Heartland Hardware Co.” web checkout, 7 days ending 02 May 26.| Outcome | Count | % of challenged |
|---|---|---|
| 3DS-frictionless (no challenge needed) | 312 | - |
| 3DS-challenge displayed | 96 | 100% |
| … 3DS-passed | 71 | 74.0% |
| … 3DS-failed | 8 | 8.3% |
| … 3DS-abandoned | 17 | 17.7% |
- 17.7% abandon rate is just above the healthy 15% line. Watch for trend movement. Above 25% triggers investigation.
- The challenge frequency itself matters. 96 challenges out of 408 total 3DS-attempted (96 + 312) is 23.5%. Issuers send to challenge when their device-fingerprint risk score is high. Better risk-data signalling reduces challenge frequency.
- The most common UX causes of abandon. (a) Customer doesn’t recognise the merchant on the bank page (Cardinal-Cardinal-Commerce-rendered popup may show the acquirer name, not the merchant). (b) The OTP / push notification is delayed and the session times out. (c) Mobile customer hits a non-mobile-optimised bank page.
- Per-issuer split is the real diagnostic. A 30% abandon on one BIN range while others sit at 12% means that issuer’s 3DS challenge UX is broken; raise with the acquirer.
- Cart-recovery email for abandoned-3DS customers recovers 8 to 15% of the dropouts. Lower than abandoned-cart recovery (which can hit 25 to 35%) because customers may have already re-attempted with a different card.
Sibling cards merchants should reference together
| Card | Why pair it with 3DS Abandon |
|---|---|
aut_decline_rate | 3DS-failed (issuer rejected) is in here, not the abandon card. |
aut_success_rate | Compound view; success = 100% - decline - abandon. |
aut_top_decline_reasons | Reason 200 (3DS_FAILED) is the cousin metric. |
aut_volume_trend | Drops in volume often correlate with 3DS friction. |
Stripe stripe_threedsecure_abandon_rate | Cross-PSP 3DS comparison. |
Reconciling against the vendor’s own dashboard
Where to look in the Authorize.Net Dashboard: account.authorize.net does not natively show 3DS abandon as a single metric. Closest views: Reports → Transaction Statistics (filter forexpired status which is the abandoned-session marker), and the Cardinal Cardinal Commerce console (separate login at cardinalcommerce.com) for 3DS-flow detail.
Why our number may differ:
| Reason | Direction | Why |
|---|---|---|
| Cardinal session events | Either | Cardinal events arrive on a separate feed; if the engine processes them on a 5-minute lag, a customer who completed late can flip from “abandoned” to “passed”. |
| Time zone | Boundary days off | Pacific batch cut-off vs UTC. |
| Per-issuer split | Not in Dashboard | The Authorize.Net Dashboard does not natively split by issuer BIN. |
| Comparison | Expected | Why |
|---|---|---|
aut_threedsecure_abandon_rate ↔ stripe.stripe_threedsecure_abandon_rate | Differ by 3DS Server vendor | Stripe uses its own 3DS Server; Authorize.Net uses Cardinal. UX layouts differ; abandon rates can differ by 3 to 8pp. |
Known limitations / merchant FAQs
Why is my 3DS abandon rate so high? Three common causes: (1) The bank’s challenge page is poorly mobile-optimised and customers on phones bounce. (2) OTP / push notification arrives slowly and the session times out (typically 10 minutes for Cardinal). (3) Customers don’t recognise the merchant name on the bank page. Fix: ensure your acquirer is sending the correctmerchantName field; A/B-test mobile vs desktop; instrument cart-recovery for abandon-3DS customers.
Is the US even using 3DS materially?
Patchy. EU PSD2 mandates 3DS for card-not-present above EUR 30; the US has no equivalent mandate. Most US merchants use 3DS for higher-value transactions (USD 1,000+) or as a chargeback liability shift, but it’s optional. B2B Authorize.Net merchants typically have 3DS off by default; consumer-facing merchants on aggressive fraud-prevention enable it.
3DS-failed vs 3DS-abandoned, the difference?
- Failed: customer attempted, the issuer rejected (wrong OTP, biometric failure).
- Abandoned: customer didn’t attempt (closed the popup, didn’t get the OTP, session timed out).