Stripe Now Requires a Billing Address on UK and Swiss SEPA Debits. The Deadline Is on Mandates You Already Have.

Stripe shipped a routine-looking line in its September 30 changelog: non-EEA IBANs on SEPA Direct Debit now need a city and postal code, not just a street address and country. Easy to skip past. It isn't routine. The requirement reaches every SEPA Direct Debit mandate you already have on file for a UK or Swiss customer, it isn't gated behind an API version upgrade the way most breaking changes are, and the enforcement date — November 15, 2026 — is the point where renewals on unfixed mandates simply start failing.

What actually changed, in plain terms

SEPA Direct Debit has always asked for a billing address: a street line and a country. Stripe's September 30 "endive" release adds two more required fields — city and postal_code under billing_details.address — whenever the IBAN behind the payment method belongs to a country in the SEPA scheme but outside the European Economic Area. Stripe ties the change directly to the European Payments Council's structured address requirement, which is the same body that writes the SEPA rulebook we've covered before in our guide to SEPA Direct Debit dunning.

The requirement attaches to three API operations: creating or updating a PaymentMethod, creating, updating, or confirming a PaymentIntent, and creating or confirming a SetupIntent — any time a non-EEA IBAN is involved. Miss either field on a fresh API call today, right now, and the request fails outright with a validation error. That part is simple enough. The part that should get your attention is what happens to the mandates you collected before this requirement existed.

The part most breaking-change playbooks don't cover: no version escape hatch

Stripe's API versioning normally works like a seatbelt for exactly this kind of change. A breaking change ships under a new version string, your account stays pinned to whatever version you're running, and nothing in your integration changes until you deliberately upgrade and test against the new behavior. We've relied on that pattern ourselves when writing about other pieces of the same September 30 release, like classic billing mode's new credited-items field.

This one skips the seatbelt. Stripe's own changelog entry says the address requirement "affects all API versions" — language that doesn't show up on most of the breaking changes in the same release. Practically, that means pinning your account to an older API version buys you nothing here. The enforcement date is the enforcement date, for every integration, regardless of what version string sits in your Stripe-Version header.

Where the November 15 deadline actually bites

Not every surface is equally exposed. Stripe's support documentation draws a clear line between new transactions and the mandates you already collected, and the risk is almost entirely on the second group.

Checkout, Payment Element, and Hosted Invoices now surface city and postal code as required fields on their own for any new SEPA Direct Debit collection — Stripe handles it client-side, no code change needed. A direct API integration creating a brand-new PaymentMethod has to add the two fields itself, but at least that failure is immediate and loud: the create call just errors. The dangerous bucket is every SEPA Direct Debit PaymentMethod you collected before this requirement existed. Those records are sitting in your Stripe account today without a city or postal code, attached to live mandates, waiting for their next scheduled charge.

What "waiting for their next scheduled charge" means for a subscription

A SEPA Direct Debit mandate doesn't get checked against this new rule until Stripe actually tries to confirm a PaymentIntent against it. For a subscription, that's your next renewal. Nothing about the account looks wrong between now and then — the mandate is valid, the customer hasn't done anything, your dashboard shows an active subscription with a healthy payment method on file. Then the renewal date hits, Stripe tries to confirm the charge, the address validation fails, and you get a failed invoice that looks identical to any other decline, except the customer did nothing to cause it and can't fix it by updating their card, because there's no card involved.

This is exactly the kind of failure that doesn't show up until it's already churn. Stripe told affected merchants it emailed a list of the specific payment methods at risk — worth digging up if you run SEPA Direct Debit in the UK or Switzerland and haven't seen it, since you can also pull the full list yourself with the List PaymentMethods endpoint, filtered to SEPA Direct Debit and the affected countries.

Two ways to fix an existing mandate

Stripe's support guidance gives you exactly two paths for a payment method you already have on file, and they're not equivalent.

• Update the PaymentMethod directly. Call Update a PaymentMethod and set billing_details.address.city and billing_details.address.postal_code. This keeps the existing mandate intact — no re-authorization, no new signature from the customer, just a data patch. It's the only option that doesn't touch the mandate itself, and it's the one worth automating against your List PaymentMethods results if you have more than a handful of affected customers.
• Delete the payment method and recollect it. Available from the Dashboard. This throws away the existing mandate and asks the customer to go through SEPA Direct Debit setup again, which means you're depending on them to actually do it. For a B2B subscriber who signed up eighteen months ago, that's a live reactivation campaign, not a backend fix.

If you have the city and postal code on file anywhere in your own system — a CRM, an onboarding form, an invoice billing address — the first path is almost always cheaper than the second, because it doesn't put a task on the customer's plate at all.

Why this is landing on UK and Swiss accounts specifically

SEPA Direct Debit's geographic reach extends past the euro area by design — it's built to let 34 countries bill through one rail, which we covered when we wrote about the scheme's 8-week reversal right. The EEA boundary that matters here is a regulatory one, not a currency one: Switzerland and the UK both sit inside SEPA's reachability list but outside the EEA, and both are large enough B2B SaaS markets that SEPA Direct Debit shows up constantly as a lower-fee alternative to cards for recurring billing. Albania, Andorra, and Vatican City are in the same non-EEA bucket on paper, but they're not where this actually costs anyone real MRR.

If your SEPA book skews European-mainland, this change is mostly a non-event — EEA IBANs were never affected. If it includes any meaningful share of UK or Swiss customers, specifically ones who converted to SEPA Direct Debit through a flow like Bancontact's off-session conversion or who were set up on SEPA Direct Debit directly years before this requirement existed, that's exactly the segment sitting on an unfixed mandate right now.

Put it on the calendar, not the backlog

Most of what we write about involuntary churn is about catching a failure after it happens — a smarter retry, a better dunning email, a faster recovery flow. This one is rarer: a failure you can see coming on a fixed date, for a payment method you can identify today, with a fix that takes one API call per record. The cost of ignoring it isn't abstract risk. It's a known subset of your SEPA Direct Debit renewals that will fail starting November 15, 2026, for a reason that has nothing to do with the customer's intent to keep paying you.

Run the audit this week, not the week of the 14th. Pull every non-EEA SEPA Direct Debit PaymentMethod you have, check it against the city and postal code fields, and patch what's missing before it becomes a support ticket that reads like a cancellation. And separately: a customer who's actually decided to leave deserves a real way to do it, rather than discovering weeks from now that their bank quietly stopped letting a renewal go through. If you want to see what a cluster of compliance-driven failures like this is worth in lost revenue before you prioritize the fix, our churn calculator is a fast way to model it — and a proper cancellation flow, the kind CancelFlow builds, is still the right tool for the subscribers who were never going to renew either way.

Frequently asked questions

Stop losing subscribers today

One script tag. One function call. A live cancellation flow in under 10 minutes.