Stripe's Bancontact Can Now Save Itself for Off-Session Billing in Checkout. What Gets Saved Isn't a Bancontact Payment Method.
Stripe's Sept 30 release lets Checkout save Bancontact for recurring billing — by converting it into a SEPA Direct Debit mandate your dunning stack won't recognize.
Bancontact has been single-use on Stripe for as long as it's existed: a customer picks it at checkout, gets redirected to their banking app or Bancontact card reader, authorises the one payment in front of them, and that's the end of the relationship. Stripe's own payment method reference still lists Bancontact's "Recurring payments" property as a flat No. The September 30 Endive release changed what Checkout can do with it anyway — Checkout can now save a Bancontact payment and charge it again later, off-session, the same shape as a stored card. What it's actually saving is where this gets interesting.
That's not a niche payment rail. If you bill customers in Belgium at all, Bancontact is probably already on your checkout page, and until last week there was exactly one way to collect from a Bancontact subscriber on an ongoing basis: send them an invoice and wait for them to pay it by hand, every cycle, forever. Stripe's own product-support footnote spells this out — Invoicing and Subscriptions only support Bancontact through the send_invoice collection method. No auto-charge, no retry, no dunning in the normal sense, because nothing was ever saved to retry against.
The mechanism: a token charge, a refund, and a different payment method entirely
Bancontact doesn't gain a native recurring mode. Stripe routes around the limitation by converting the first Bancontact payment into something else. The clearest documentation of exactly how is written for Bancontact's closest sibling, iDEAL, and Stripe is explicit that it's the same family of mechanism: Stripe charges the customer a small token amount through the redirect method to collect their bank details, refunds that charge the instant the customer authenticates, and stores the resulting IBAN as a reusable SEPA Direct Debit PaymentMethod. For iDEAL, Stripe's docs put that token charge at €0.01. Bancontact has carried the equivalent fields — generated_sepa_debit and generated_sepa_debit_mandate — on its Charge object for years; what shipped on September 30 is the ability to reach that conversion through a Checkout session in setup mode, instead of only through a hand-rolled PaymentIntents and Elements integration.
Retrieve the SetupIntent afterward, expand latest_attempt, and the response looks almost identical to what iDEAL returns: a bank, a bic, an iban_last4 — and the two IDs that matter, a generated SEPA Direct Debit PaymentMethod and its mandate. From that point forward, a renewal isn't a Bancontact charge at all. It's a PaymentIntent against a SEPA Direct Debit PaymentMethod, confirmed off-session, using an IBAN the customer never typed in and a mandate they never saw described as a mandate.
| First payment (Bancontact) | Every renewal after | |
|---|---|---|
| Payment method | Bancontact | SEPA Direct Debit |
| Customer action | Redirect + authenticate in banking app | None — off-session |
| Authentication | Customer-authenticated per payment | Standing mandate, no per-charge auth |
| Dispute / chargeback risk | None — no dispute mechanism exists | 8-week no-questions-asked refund right (SEPA Core) |
| Decline vocabulary | Bancontact's own success/fail redirect result | SEPA R-transaction codes (AM04, MD01, AC04, etc.) |
| Default auto-retry | N/A — single use | Off by default; must be enabled, and only retries insufficient-funds failures |
Every row in that second column is a behavior we've already written about in detail for SEPA Direct Debit dunning generally. The difference here is that nobody signing up through a button labeled "Bancontact" has any reason to expect it.
Why Bancontact can't just bill itself directly
Bancontact's payment method family is "authenticated bank-debit" — every charge requires the customer to actively authenticate in the moment, which is exactly why it has no dispute exposure at all. There's no chargeback network sitting behind a Bancontact payment, because the bank already confirmed the customer approved it before the money moved. That's a genuine advantage for one-time purchases: no fraud risk, no disputed-charge losses, full stop.
It's also precisely why Bancontact can't be billed off-session on its own. An off-session charge means nobody is there to authenticate it. SEPA Direct Debit solves that by running on a standing mandate instead of per-transaction authentication — you bill against a signed authorization the customer already gave, rather than asking them to approve each charge. Converting Bancontact into SEPA Direct Debit isn't a workaround Stripe invented; it's the only rail in the EU that actually supports the thing you're trying to do, which is also exactly why iDEAL — Netherlands' equivalent bank-redirect method — has used the same conversion for years.
Source: Stripe Bancontact and SEPA Direct Debit payment method documentation; SEPA Core Direct Debit Rulebook, European Payments Council.
What this actually changes for a SaaS billing Belgian customers
Your dunning routing needs a second branch for the same checkout button
If your billing logic routes dunning by payment method type, a subscriber who signed up with Bancontact needs to be rerouted into your SEPA Direct Debit path the moment their first renewal happens — not left in a Bancontact bucket that doesn't actually get charged that way anymore. The decline vocabulary changes completely: there's no such thing as a Bancontact decline on a renewal, only AM04, MD01, AC04, and the rest of the R-transaction codes we've catalogued for SEPA. A dunning rule written for "Bancontact failures" will simply never fire, because the thing that can fail post-conversion isn't Bancontact at all.
The reversal window is new exposure, not a hidden cost of the old flow
Before this release, a Belgian subscriber paying you repeatedly through Bancontact meant repeated one-time payments, each with zero dispute risk, full stop. After this release, a Belgian subscriber who converts to off-session billing takes on the SEPA Core scheme's 8-week no-questions-asked refund right on every renewal — the same reversal window we've detailed in our SEPA Direct Debit guide. That's not a defect in Stripe's implementation; it's the actual tradeoff of gaining automatic billing on a rail that was never built to auto-bill. Teams that currently treat "paid" as final the moment a Bancontact-originated renewal clears are the ones most likely to get surprised by a reversal weeks later with no warning in their dashboard that distinguishes it from any other refund.
Enabling it isn't a single toggle
Turning on recurring Bancontact billing means SEPA Direct Debit itself has to be active in your Dashboard payment settings — it's a separate activation from enabling Bancontact — and you need to agree to both the Bancontact and SEPA Direct Debit terms of service, since the charge you're actually running is governed by the latter. The Checkout Session that collects the mandate has to run in setup mode rather than payment mode, which is a different integration shape than a typical "enable a payment method and let Stripe pick it automatically" rollout. If you're used to dynamic payment methods just working without code changes, this one specifically isn't that.
Pre-notification is a new compliance step for a method that never needed one
A single Bancontact payment needs no advance notice — the customer authenticates it live. A SEPA Direct Debit collection does: the scheme requires a pre-notification of the amount and date at least 14 calendar days before the debit, which a single annual notice can cover for a year of identical recurring charges. If your Bancontact checkout flow was built assuming Bancontact's own rules, that notice requirement doesn't exist yet in your billing calendar, and it needs to before the first off-session renewal runs.
Where this fits next to BLIK and Klarna's September changes
This is the third payment method in the same Endive release to move from single-use toward something that can bill itself again without the customer present — alongside BLIK gaining a true recurring mandate in Poland and Klarna's existing off-session renewal support running into new UK authentication rules. The pattern across all three is the same shape, with a different catch each time: BLIK caps you at 2,000 PLN per off-session charge, Klarna can silently reroute a UK renewal to a full-amount charge instead of an installment plan, and Bancontact doesn't cap or reroute anything — it just quietly hands the renewal to a completely different payment rail with its own reversal rights, decline codes, and compliance obligations. None of the three let you treat "the customer picked payment method X at signup" as a safe assumption about how the next charge actually behaves.
If Belgium or wider Benelux is a meaningful part of your subscriber base, it's worth modeling the SEPA-conversion reversal window as its own line in your involuntary churn reporting rather than folding it into a generic refunds bucket — our churn calculator is a quick way to see how much that segment is worth isolating before you build dunning rules around it. And separately from any renewal that fails or reverses on its own: a subscriber who's decided they're actually done is still better served finding a real cancel button than discovering, eight weeks after a quiet renewal, that reversing a SEPA Direct Debit collection was the only exit they knew how to find — which is exactly the gap a proper cancellation flow like CancelFlow is built to close before it ever gets that far.
Frequently asked questions
Does Bancontact support recurring subscription payments?+
Not as a Bancontact charge. Stripe's own payment method reference lists Bancontact's 'Recurring payments' property as No, and says Invoicing and Subscriptions only support Bancontact through the send_invoice collection method — meaning Stripe doesn't auto-charge it on a schedule. What Stripe ships instead, now including Checkout as of the September 30, 2026 Endive release, is a conversion: the first Bancontact payment generates a reusable SEPA Direct Debit PaymentMethod and mandate, and every renewal after that is a SEPA Direct Debit collection, not a Bancontact one.
How does Stripe turn a Bancontact payment into a SEPA Direct Debit mandate?+
Stripe documents the identical mechanism for iDEAL, Bancontact's closest sibling: it charges the customer a small token amount through the redirect method to collect their bank details, refunds it the moment the customer authenticates, and stores the resulting IBAN as a SEPA Direct Debit PaymentMethod. For iDEAL, Stripe's docs put that token charge at €0.01. The generated PaymentMethod ID and mandate ID land under payment_method_details.generated_sepa_debit and generated_sepa_debit_mandate on the SetupIntent's latest attempt — fields that have existed on Stripe's Charge object for Bancontact for years, now reachable through a Checkout setup-mode session instead of only through the raw PaymentIntents API.
Does the SEPA Direct Debit 8-week refund right apply to a subscriber who signed up with Bancontact?+
Yes, once their first payment converts to a SEPA Direct Debit mandate. Under the SEPA Core scheme, a customer can reverse an authorised Direct Debit collection with no reason given, within 8 weeks of the debit date, and their bank must refund it within 10 working days — the same right we've covered for any SEPA Direct Debit collection. A subscriber who thinks of themselves as a 'Bancontact customer' gets this right on every renewal after the first, even though Bancontact itself carries no comparable reversal risk and no dispute exposure at all.
What do I need to turn on to accept recurring Bancontact payments through Checkout?+
You need SEPA Direct Debit activated in your Stripe Dashboard payment settings, not just Bancontact — the recurring charge is a SEPA Direct Debit charge under the hood. You also need to agree to both the Bancontact and SEPA Direct Debit terms of service, and run the Checkout Session in setup mode (mode: 'setup') rather than payment mode to collect the mandate before you ever bill anything.
Stop losing subscribers today
One script tag. One function call. A live cancellation flow in under 10 minutes.
Start free trial →