A candle subscriber in Manchester has been on the same monthly plan for a year. Her card hasn't expired, hasn't been reissued, and has more than enough headroom for a £22 charge. This month's renewal fails anyway, with a decline code that reads nothing like the usual insufficient-funds or expired-card messages support is used to triaging. The automated dunning email goes out regardless, telling her to update her payment method. She logs into her bank app, confirms the same card is fine, checks her balance, and updates nothing - because there's nothing wrong with the card. Two more scheduled retries fail the exact same way, and on the third the subscription cancels itself, having never once been a payment problem in the first place.
The decline was real, and so was the bank's reason for issuing it. Under PSD2, European and UK-issued cards are subject to Strong Customer Authentication - a rule requiring two-factor verification (something the cardholder knows and something they hold, typically a 3D Secure prompt on their phone) before certain card transactions are allowed to complete. A subscription renewal is what the card networks call a merchant-initiated transaction: the store triggers it, on schedule, with no cardholder present to approve anything. Recurring charges can qualify for an SCA exemption if the very first payment in that series was properly authenticated as the start of a stored-credential agreement - but that exemption isn't automatic or guaranteed, and an issuing bank can still choose to challenge a renewal anyway, based on its own fraud scoring. When it does, there is no phone in anyone's hand to complete the challenge, so the charge simply fails.
The mistake isn't selling subscriptions to UK or EU customers, and it isn't a gap in Shopify's checkout - SCA is a banking regulation the platform and every gateway on it have to work within. The mistake is routing an authentication-required decline into the same automatic retry-and-dunning queue built for a plain card decline, when retrying a merchant-initiated charge changes nothing about whether a cardholder is there to authenticate it. It will fail the same way every time, for a reason a generic "update your card" email doesn't describe and a subscriber has no way to act on.
Why a funded, valid card still gets challenged
- SCA applies per-transaction, not per-card - a card that authenticates fine at checkout can still be flagged for a challenge on a later renewal, because the bank is scoring that specific charge, not vouching for the card generally
- A recurring-payment exemption depends on the first transaction in the series being correctly flagged as the start of a stored-credential agreement - if that flag was set incorrectly, or the issuing bank simply doesn't honor the exemption, every renewal after it is a candidate for a challenge
- A merchant-initiated transaction has no cardholder in the loop to complete a 3D Secure prompt - unlike a checkout, where the shopper is staring at their phone waiting for the code, a renewal fires in the background with nobody available to approve it
- Issuing banks vary in how aggressively they apply SCA to recurring charges - the same subscriber's card can sail through five renewals and get challenged on the sixth, based on the bank's own risk model rather than anything that changed on the merchant's side
- The decline code itself usually says "authentication required" or similar, distinct from an ordinary decline - but only if someone downstream is actually reading that code instead of routing every failed renewal into one generic "payment failed" bucket
What treating it like a normal decline costs
An ordinary failed renewal has a real chance of clearing on retry - a temporary hold lifts, a paycheck lands, a limit resets. An authentication-required decline has none of that variance. Retrying it on the same schedule as a normal decline burns through the dunning sequence without ever addressing what actually blocked the charge, and every one of those retries reaches a subscriber holding a perfectly good card who's just been told, repeatedly and incorrectly, that something's wrong with it. By the time the subscription cancels itself, she hasn't churned because she wanted out - she's churned because the recovery flow diagnosed the wrong problem three times in a row and never gave her anything she could actually fix.
The card was never declined for being bad. It was declined because no one was there to approve a charge the bank decided needed a second look.
Recovering a renewal that needs a cardholder present
- Treat an authentication-required decline as its own category from the moment it happens - it isn't the same failure as insufficient funds or an expired card, and folding it into one dunning sequence guarantees the same outcome on every retry
- Don't schedule a blind automatic retry for this decline type the way you would for a normal one - a merchant-initiated retry can't complete a 3D Secure challenge any better the second time than the first, so retrying without change is just delay
- Message the subscriber specifically, not generically - "we need you to confirm this payment" with a direct path to do so reads very differently from "update your card," and it's the difference between a subscriber who can act and one who checks her bank app and gives up confused
- Give her a way to complete the authentication herself, through a checkout-style flow where she's present to approve the charge - that's the one thing a background retry structurally cannot provide, and it's the only step that actually satisfies what the bank asked for
- Watch decline reason codes as their own metric, separate from your overall failed-payment rate - a rising share of authentication-required declines points at an SCA or exemption-flagging issue, not a sudden wave of bad cards, and the fix for one doesn't touch the other
Where this lives in AppFox Subscription
Card authentication itself is handled by Shopify's checkout and the payment gateway underneath it, not by AppFox Subscription directly - that boundary isn't something AppFox reaches past, since the bank's SCA decision happens outside the app on every platform it applies to. Where AppFox helps is in what happens next: the customer portal is where a subscriber can be pointed to resolve a stalled renewal on her own, through Shopify's own checkout, rather than support trying to talk her through a decline code over email. That's a materially different conversation than "please update your card" - it's "please confirm this specific charge," and it's the version of the message that actually matches what her bank is waiting on.
The Manchester subscriber's cancellation wasn't a payment failure in any sense her dunning emails described. Her bank asked for a cardholder who wasn't in the room, three renewals in a row got treated as if a different problem had occurred, and the subscription ended before anyone told her what was actually being asked of her. The fix isn't a better retry schedule - it's recognizing the decline for what it is and giving her the one thing an automatic retry can never supply: the chance to show up and approve the charge herself.