If you're running a SaaS in Europe or the UK, failed payments are a different problem than they are in the US. Strong Customer Authentication, the PSD2 rules, and the 3D Secure layer sitting on top of most EU card transactions turn "just retry the card" into a multi-step dance with the customer's bank. Stripe Smart Retries helps, but it only helps inside the boundaries that SCA sets.
This guide walks through how Stripe Smart Retries actually works under SCA constraints, why EU and UK SaaS almost always need a dedicated dunning layer on top, and the tactical playbook we've seen work.
The SCA constraint in one minute
Strong Customer Authentication is a PSD2 rule that requires two-factor authentication for most card payments initiated by EU or UK customers. The second factor is usually a bank app prompt, an SMS code, or a biometric check. In Stripe's world this shows up as 3D Secure (3DS), specifically 3DS2.
SCA splits your payments into two buckets:
On-session payments. The customer is actively present at checkout. Stripe can trigger a 3DS challenge, the customer approves it in their banking app, and the payment goes through. This is your initial subscription signup.
Off-session payments. The customer isn't present. This is every recurring charge after the first one. Stripe can attempt the charge using the authenticated card on file, but if the issuer decides the charge needs a fresh challenge, you're stuck. The issuer returns a authentication_required decline and Stripe can't do anything without the customer physically being there.
That second case is where dunning gets hard.
How Stripe Smart Retries behaves under SCA
Stripe Smart Retries is an algorithm that picks the optimal time to re-attempt a failed charge based on machine learning across Stripe's transaction data. On US cards with no SCA, it recovers roughly 30% of failed payments on its own. The details are documented in the Stripe dashboard under Revenue Recovery.
Under SCA, the calculus changes.
Soft declines can still retry. Insufficient funds, temporary holds, and generic issuer declines are fair game. Smart Retries will pick the right time and try again.
Authentication-required declines cannot retry silently. If the issuer came back with authentication_required, retrying off-session will just hit the same wall. You need the customer to come back on-session, authenticate, and then you can charge the card.
Smart Retries doesn't pull the customer back. It's a backend retry engine. It can't send an email, surface a banner in your app, or prompt the customer to authenticate. That's on you.
So on SCA-affected cards, Smart Retries recovers a smaller slice, probably closer to 15 to 20% instead of the 30% you'd see on a US portfolio. The rest of the recovery has to come from a customer-facing flow that brings the user back on-session.
Why the dunning layer matters more in the EU
In the US, a well-configured Stripe account can recover 40 to 50% of failed payments with card updater plus Smart Retries alone, no dunning emails needed. Add email sequences and you're at 55 to 65%. Add SMS and you're at 65 to 80%.
In the EU and UK, that stack is weaker at the base. Card updater coverage is thinner because VAU and ABU have weaker participation outside the US. Smart Retries loses ground on SCA-gated cards. So the recovery burden shifts further onto customer-facing sequences that actually bring the user back to authenticate.
Put differently: in the US, dunning emails are the last mile. In Europe, they're often the middle 60%.
What a working EU dunning sequence looks like
The core job of an EU-focused dunning sequence is to get the customer on-session on a page where they can authenticate. That page is usually a hosted payment method update form where the customer confirms (or replaces) the card and passes the 3DS challenge as part of the confirmation.
Here's a reasonable schedule:
| Day | Channel | Message goal |
|---|---|---|
| 0 | Heads-up, link to update payment method | |
| 1 | Smart Retries attempt | Stripe internal |
| 2 | Second nudge, explain authentication may be needed | |
| 3 | SMS | Short link to update page |
| 5 | Third touch, urgency, specific deadline | |
| 7 | SMS | Final reminder before pause |
| 8 | Account paused notification |
Two things make or break this sequence in Europe:
The update page must trigger 3DS as part of confirmation. If your customer updates their card but Stripe doesn't run a setup intent with SCA-compliant authentication, the next charge will just fail again for the same reason. Rekko and other SCA-aware dunning tools handle this automatically. If you're building it yourself, you need a setup intent with payment_method_options.card.request_three_d_secure set to automatic or any.
SMS matters more in Europe. European customers, especially in the UK, France, Germany, and the Nordics, check SMS regularly and trust it more than US customers often assume. SMS recovery rates in our EU customer data are higher than in US cohorts, sometimes by 5 to 10 percentage points.
Copy for SCA-aware dunning emails
The copy has to explain, without sounding technical, why the customer might see a bank prompt when they update their card. A short sample:
Hi {{customer_name}},
Your payment of {{amount}} for {{account_name}} was declined by your bank this morning. This is usually an expired card or a temporary hold, and your bank may ask you to approve the update in your banking app when you enter new card details.
Update here: {{payment_link}}
If you see a prompt from your bank, go ahead and approve it. The whole thing takes about a minute.
Thanks, The {{account_name}} team
Notice what's not in the copy: the words "SCA," "PSD2," "3DS," or "Strong Customer Authentication." Your customer doesn't know or care. They just need to know a bank prompt is expected, so they don't bail when it appears.
Tactical advice for EU SaaS
A few things we've seen move recovery for European SaaS specifically:
Send the first email faster. In the US, a 6-hour delay on the first dunning email is fine. In the EU, because Smart Retries recovers less at the base, the first email is a bigger chunk of your recovery. Send it within 30 minutes of the failure.
Use SMS earlier in the sequence. US playbooks often introduce SMS on day 4 or 5. In Europe, day 2 or day 3 works better because of how receptive the channel is.
Explicitly prepare customers for the bank prompt. A single sentence in your email reduces bail-outs on the 3DS challenge significantly. We've seen 10 to 15 point lifts on update-page conversion just from that sentence.
Localize templates by language, not just currency. A French customer is more likely to update their card from a French-language email. Most EU-focused dunning tools support this, but plenty of teams don't take the time to set it up.
Watch for bank-specific patterns. Some EU banks are stricter than others on off-session authentication. If you see a disproportionate share of failures from one issuer, that's a signal to test different retry timing for that issuer.
Where Rekko fits for European SaaS
Rekko handles SCA-aware payment method updates out of the box. The hosted update page runs a setup intent with authentication, so when the customer replaces their card the next charge goes through without hitting the same wall. Email plus SMS sequences are built in, templates support multiple languages, and SMS is included at every tier.
If you're in the EU or UK and your recovery rate is stuck below 60%, SCA handling is usually part of the reason. A focused tool fixes it faster than building the flow yourself.
Start your 14-day free trial, no credit card required. Or see how Rekko compares to Stripe Billing's built-in dunning for European accounts.