Card-on-file PCI + dunning flow for failed renewals?
Subscription billing means you’re storing payment methods. The compliance + technical requirements:
- PCI DSS scope, you must NEVER store card numbers on your Magento DB. Tokens only. The card lives at the gateway (Stripe / Adyen / Braintree); you store a token reference per customer. This is the “card-on-file” standard pattern and reduces PCI scope to SAQ-A (the simplest level).
- SCA / 3DS2 for EU + UK, Mandatory for subscription renewals to EU + UK cards since 2021. The first transaction triggers 3DS2 challenge; subsequent renewals use the merchant-initiated transaction (MIT) flag with the saved authentication. Stripe + Adyen handle this; Braintree partial; Bold V2 has rough edges here. Get this wrong and ~15-30% of EU renewals decline.
- Dunning flow for failed renewals, the recovery sequence I build:
- Day 0: card declines → retry next day at same time.
- Day 1: retry → if still declined, send “your card declined, update it here” email + SMS with one-click portal link.
- Day 3: second retry. Send second “your box won’t ship without updated payment” email.
- Day 7: third retry. Send “final attempt” email + SMS. If still declined, cancel sub.
- Day 14: win-back email, “Come back for 20% off your next box”.
- Account-updater services, Stripe Adaptive Acceptance, Adyen RealTime Account Updater. Auto-update expired/replaced cards before retry. Recovers 4-8% of would-be churned subs.
Tech: ReCharge / Smartrr have dunning built-in; you tune the retry timing + email/SMS content. Magento integrates via the sub provider’s webhook → Klaviyo flow trigger. Recovered subs are typically 30-50% of all initial declines, massive impact on net retention.