At a glance
The percentage of Recharge charges that triggered a 3DS challenge and were abandoned by the customer (not declined by the issuer). On Recharge specifically, 3DS abandonment is overwhelmingly a Recharge Checkout first-order problem, not a rebill problem, recurring rebills should qualify for MIT (Merchant Initiated Transaction) exemption and not face 3DS at all. If you see meaningful abandonment on rebills, your MIT exemption flag is misconfigured. UK and EU first-order traffic typically runs 8, 15% abandon on a 3DS challenge; US traffic doesn’t see this card materially.
Calculation
Calculated automatically from your Recharge data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
“Daily Greens Co” UK customers, 7-day window 26 Apr 26 to 02 May 26.- The 22 rebill challenges (18+4) shouldn’t exist. Recurring rebills on saved tokens qualify for MIT (Merchant Initiated Transaction) exemption under PSD2 SCA. If this card shows non-zero rebill challenges, the MIT flag is missing in the Recharge → processor API call. This is a config bug; open a Recharge support ticket.
- First-order abandon at 11.7% is normal range for UK 3DS friction. Below 8% is excellent (clean challenge UX, fast issuer pages); above 15% suggests a UX problem in the challenge popup (mobile blocking, language mismatch).
- Annual prepaid challenges abandoned 25% because the customer was challenged by the issuer for a high-value (USD 790) transaction; they were unsure if they really wanted to commit and abandoned. High-value transactions intentionally face higher abandonment. Mitigate with clear pre-challenge UX (“you’re about to be authenticated for your annual subscription, please complete the bank prompt”).
- US customers don’t appear here because PSD2 SCA doesn’t apply outside EEA. A US customer never sees a 3DS prompt unless the issuer chose to step-up authenticate (rare, and not Recharge-driven).
- Issuer-rejected (19 total) is NOT abandonment, it’s decline. The customer attempted, the issuer said no. They’re tracked in
rec_decline_rateasAUTHENTICATION_REQUIREDorAUTHENTICATION_FAILED.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in the Recharge merchant portal: admin.rechargepayments.com. Recharge admin doesn’t expose a dedicated 3DS abandon view; the better source is the underlying processor’s dashboard (Stripe Radar → 3DS, Shopify Payments → Authentication) for the same window. Recharge’s Charges → Failed → AUTHENTICATION_REQUIRED lists the issuer-rejected slice, which is the cousin to abandons. Why our number may legitimately differ from the underlying processor:
Cross-connector reconciliation: