Stripe's New SeQura Payment Method Can't Touch Billing, the Portal, or Radar — Not Just Recurring Charges
Stripe added SeQura BNPL for Spain on Sept 30, 2026. It skips Billing, the Customer Portal, and Radar — not just recurring charges.
Stripe added SeQura, a Spanish buy-now-pay-later method, in its September 30, 2026 release. We've covered two other BNPL additions from Stripe this year — Billie, which can't be stored but at least slots into an invoicing workflow, and Klarna, which genuinely does renew like a card in most countries. SeQura isn't a variation on either story. Look at Stripe's own product-support table for it and the pattern is different in kind: Billing, the Customer Portal, Adaptive Pricing, and Radar are all marked unsupported. Not "supported with caveats." Not "available in preview." Unsupported, full stop. If you're running a subscription business and you add SeQura at checkout expecting it to behave like any other Stripe payment method once it's turned on, the gap between what it does at signup and what it does at renewal is wider than anything we've seen from a 2026 Stripe payment method addition so far.
What SeQura actually is
SeQura is a Spanish installment lender. A customer picks it at checkout, gets redirected to SeQura's own hosted page, chooses a repayment plan, and authorizes it there — Stripe never sees the installment schedule itself, only a pass/fail on the payment. The merchant gets paid on Stripe's standard payout schedule, not instantly the way Billie pays out; SeQura's value proposition is for the buyer, not for accelerating the seller's cash position. It's available only to Stripe accounts based in Spain, only to customers located in Spain, settles only in EUR, and Stripe's own eligibility table marks cross-border coverage as unsupported. If your business sells outside Spain, this entire payment method is irrelevant to you. If you sell inside Spain, it's worth understanding exactly how far "available" actually extends, because the answer is narrower than it looks on the payment methods settings page.
Why this isn't the "single-use" story again
Billie's limitation is about the payment method object: it can't be saved to a customer and reused, so every invoice needs its own credit check, but Billie is still wired into Stripe's product layer well enough to show up against an invoicing workflow. SeQura's limitation sits one level up, in which Stripe products are allowed to talk to it at all. Pull the capabilities table apart by surface area and the drop-off isn't even consistent — it gets worse the deeper you go into actual subscription infrastructure.
Source: Stripe, SeQura payment method reference (docs.stripe.com/payments/sequra)
At checkout, SeQura looks almost fully supported — it works in a full-page redirect, Payment Links, an embedded form, the Payment Element, and in-app payments, with only the Express Checkout Element left out. That's the layer most teams test and ship against, and it's the layer that will convince you SeQura is production-ready. Move to the API layer and support halves: Checkout Sessions and plain PaymentIntents work, but there's no setup_future_usage and no Setup Intents, meaning there's no way to capture a SeQura credential for later use even if you wanted to build something custom around it. Move to the product layer — the actual systems that run a subscription business — and only Invoicing and Connect show a checkmark. Billing, Customer Portal, Adaptive Pricing, and Radar are all out.
What that actually breaks for a subscription business
No Billing means no subscription object ever touches it
This is the part worth being blunt about: you cannot attach SeQura to a Stripe Subscription. Not as a saved method, not as a fallback, not at all — Billing isn't on the supported-products list. If you want to offer SeQura to a subscriber, every charge has to be its own manually triggered Invoicing transaction or Checkout Session, outside whatever automated billing logic runs your actual subscription base. That's a materially bigger lift than Billie's single-use limitation, which at least lets you reuse the same invoicing pattern Stripe already ships. With SeQura, you're building and maintaining a second, parallel charging path by hand for however many customers pick it.
| Payment method | Where it's available | Recurring on Stripe | Works with Stripe Billing | Renews without a redirect |
|---|---|---|---|---|
| SeQura | Spain only | Not supported | No — Invoicing/Checkout only | No — new session every charge |
| Billie | EU, Germany-led | Single-use per invoice | Via Invoicing, not auto-charge | No — fresh credit check each time |
| Klarna | 19–22 countries | Yes, storable | Yes | Mostly — UK off-session GBP is the exception |
| Card | Global | Yes, storable | Yes | Yes |
No Customer Portal support means your subscribers who paid with SeQura can't go to Stripe's hosted portal to view or manage that payment history the way a card-paying customer can — you'd need to surface it yourself if you want them to see it at all. No Radar support means Stripe's fraud scoring doesn't run against SeQura transactions; SeQura is doing its own fraud and credit decisioning on its hosted page, which is a reasonable trade for a method that runs its own underwriting, but it does mean you can't layer your existing Radar rules on top of it the way you can for cards. And no Adaptive Pricing means if you're using Stripe's FX-localized pricing for international customers, SeQura — being EUR-only and Spain-only anyway — was never going to be part of that picture, but it's worth knowing going in rather than discovering it mid-integration.
The amount band rules out most SaaS monthly plans
SeQura charges have to fall between €29 and €3,000. A monthly SaaS plan priced under €29 — which covers a large share of the SMB and prosumer tier — simply can't be charged through SeQura at all; the transaction would be rejected below the floor. An annual plan is far more likely to clear the minimum, but now you're running an annual-contract charge through a payment method that has no Billing integration, meaning the renewal a year later needs its own manually triggered checkout, not an automatic charge against anything on file. If you're positioning SeQura as a way to let Spanish customers pay for a subscription in installments, map your actual price points against that €29–€3,000 band before you build anything — it changes which of your plans this even applies to.
Disputes give you one shot, not several
SeQura's dispute process only allows a single round of evidence. Compare that to a standard card dispute, where you can sometimes get a second look if new evidence surfaces — with SeQura, you submit everything you have within 15 days of the dispute opening, SeQura decides within 25 days, and that's final. The 120-day window customers have to open a dispute in the first place is generous by card standards, and the refund mechanics are stricter than most teams expect too: once submitted, a SeQura refund can't be cancelled, and a full refund cancels the buyer's remaining installments outright while partial refunds recalculate what's left rather than simply returning a prorated amount. None of this is unusual for installment lending — it mirrors the single-round evidence model we've seen on other BNPL methods — but it's one more place where SeQura behaves like a credit product with its own rules, not a Stripe-native payment type with Stripe-native dispute handling.
What to actually do if you're turning SeQura on
1. Confirm it's actually solving a checkout problem, not a renewal one
SeQura is a genuinely strong fit if your Spanish customers are price-sensitive at the point of purchase and installments would convert a sale you'd otherwise lose. It is not a fit if what you actually need is a way to automatically rebill a subscriber — Billing being entirely unsupported makes that explicit rather than a limitation you'll discover later.
2. Build the renewal charge as its own manual workflow, and own that it's manual
Because there's no stored credential and no Billing integration, plan for a human or a scheduled job to trigger a fresh Checkout Session or Invoicing charge at renewal time, the same category of workaround we flagged for the Southeast Asian wallet methods that also can't be stored. Don't let this quietly become an ungoverned side process — someone needs to own the list of SeQura-paying customers and the calendar for when each one needs a new charge sent.
3. Keep a fallback payment method on file regardless
Since SeQura can't be attached to a subscription, you need a separate, storable payment method — a card, typically — on file for anything your billing system needs to retry automatically. Treat SeQura as an at-signup convenience layered on top of a conventional recurring method, not a replacement for one.
4. Segment SeQura-related involuntary churn apart from everything else
A failed SeQura checkout, a missed manual renewal, and a card decline are three different failure mechanisms that need three different fixes. Folding them into one involuntary churn number, the trap we keep flagging across every new Stripe payment method, will hide whether SeQura is actually working for the Spanish segment or quietly leaking renewals nobody is tracking.
SeQura is a reasonable checkout option for a Spain-only business that wants to offer installments on larger one-time or annual charges, and the underwriting and settlement mechanics behind it are sound for what they're built to do. What it isn't is a payment method you can treat the way you'd treat a card once it's turned on — the unsupported list in Stripe's own documentation is longer than the supported one, and Billing being on that unsupported list means the entire automated side of subscription billing doesn't apply to it. If SeQura ends up being more than a small slice of your Spanish revenue, run that segment through our churn calculator on its own rather than blended into your overall number — and whatever manual renewal process you build around it, a cancellation flow still needs to catch the subscribers who show up to leave on purpose, which a credit-financed installment plan does nothing to prevent on its own.
Frequently asked questions
Does SeQura support recurring or subscription billing on Stripe?+
No. Stripe's own capabilities table for SeQura lists recurring payments as not supported, with no exceptions. It can't be saved with setup_future_usage, it has no Setup Intents support, and it isn't available as a Stripe Billing payment method at all. Every SeQura payment, including a second or third charge to the same customer, has to go through its own one-time Checkout Session or Payment Intent.
Which countries and currencies does SeQura support on Stripe?+
Spain only, on both sides of the transaction. Stripe accounts have to be based in Spain to accept SeQura, and customers have to be located in Spain to use it. Payments settle in EUR, and Stripe's documentation explicitly marks cross-border coverage as unsupported — it's a domestic-only payment method with no path to serving customers elsewhere.
What are the minimum and maximum transaction amounts for SeQura?+
The minimum SeQura charge is €29 and the maximum is €3,000, per transaction. That band rules it out for most monthly SaaS plans outright and puts a hard ceiling on what any single SeQura-financed invoice — including an annual plan — can charge.
How do SeQura disputes and refunds work on Stripe?+
Customers have 120 calendar days to open a SeQura dispute, and a given payment can only be disputed once — there's no second round if you lose. Once a dispute opens, you get 15 calendar days to submit evidence and SeQura issues a final decision within 25 days, with only a single evidence submission allowed. Refunds are separate: you have 180 days to issue one, they take about 5 minutes to process, and they can't be cancelled once submitted. A full refund cancels the buyer's remaining installments; a partial refund recalculates them.
Stop losing subscribers today
One script tag. One function call. A live cancellation flow in under 10 minutes.
Start free trial →