Stripe's Standalone 3D Secure Can Authenticate a Renewal With Nobody There to Approve It. Most SaaS Teams Still Can't Turn It On.

We've written twice now about the same hard limit in how 3D Secure works: it authenticates a cardholder who's present to tap a prompt or type a code, and a subscription renewal almost never has one. The fix the industry built for that gap is the merchant-initiated transaction exemption — authenticate once at signup, and every renewal after that inherits the mandate without a fresh challenge, as long as the charge doesn't drift too far from what was originally authorized. On September 30, 2026, Stripe shipped an API that attacks the same problem from a different angle: instead of leaning harder on an exemption, it lets you run a fresh 3D Secure authentication on a renewal with nobody there, by referencing the authentication you already have on file.

That 57% is the reason Standalone 3DS exists at all. If every business ran 100% of its volume through Stripe, Stripe's existing bundled 3DS — authenticate and charge in one PaymentIntent — would cover nearly every case worth covering. The moment a meaningful share of merchants split volume across multiple processors, authentication becomes a second thing to solve for independently of which processor actually moves the money, and nothing in Stripe's API used to let you do that. Standalone 3DS is Stripe explicitly building for the 57%, not the single-processor majority of its own SaaS customer base.

What actually shipped on September 30

Before this release, every 3D Secure challenge Stripe ran lived inside a PaymentIntent or SetupIntent — authentication and the charge were the same object, confirmed together. Standalone 3DS pulls authentication out into its own resource. You create a 3DS Authentication object with the transaction amount, currency, card details, and the cardholder's browser information, Stripe submits it to the card network's directory server and the issuer's access control server, and — if the issuer requires a challenge rather than approving frictionlessly — you present that challenge through an iframe or Stripe.js. On success, you get back a cryptogram, an Electronic Commerce Indicator, and a Directory Server Transaction ID. That proof of authentication is portable: present it to Stripe for the actual charge, or hand it to any other PSP that accepts a 3DS cryptogram.

Three details matter more than the mechanics for a subscription business specifically:

• 3DS Requestor Initiated (3RI) authentication — a flow built explicitly for transactions where the cardholder isn't present, by referencing a previous authentication to get a new cryptogram for a later charge. Stripe's own example use cases are a travel booking authenticated at fulfillment time and a split shipment authenticated per shipment — both cardholder-not-present scenarios with the same shape as a subscription renewal.
• A declared reason for each authentication — you can tell Stripe why you're running 3DS on a given transaction (liability shift, processing-cost reduction, or regulatory compliance) and let it pick the optimal flow, or request a specific one: frictionless for low-risk traffic, a full challenge when you want stronger verification, or a data-share-only flow that exchanges risk signals with the issuer with no cardholder friction at all.
• Full observability into the issuer's response — the complete 3DS protocol output, not just a pass/fail, which is what lets you build your own authorization logic instead of trusting a black box.

Why this is a different fix than the MIT exemption

Our piece on SCA and European renewals covers the mechanism most Stripe subscriptions already lean on: authenticate once as a customer-initiated transaction, and every renewal that follows qualifies as merchant-initiated and skips the challenge — until a renewal drifts enough from the original pattern that an issuer stops honoring the exemption and asks for a fresh authentication nobody's there to give. That failure mode is structural. The exemption is a bet that this charge looks enough like the last one; when a trial converts to a real price, a plan upgrades mid-cycle, or a subscription resumes after a long pause, the bet can lose, and today there's no way to proactively re-authenticate the one specific charge that's about to trip it.

3RI authentication is a mechanism built for exactly that gap. Instead of hoping an issuer extends the exemption to an off-pattern charge, you request a new authentication for that specific renewal, referencing the cardholder-present authentication already on file. You're not asking the customer to do anything — the reference to the prior authentication substitutes for their presence — but you are giving the issuer a fresh, transaction-specific signal to evaluate instead of leaning entirely on pattern-matching against the original mandate. It doesn't replace the exemption for the renewals that already sail through fine; it's a tool for the subset that the exemption was never going to cover reliably.

The multiprocessor case this was really built for

Standalone 3DS sits in the same part of Stripe's product line as the multiprocessor Radar signals we've covered before — the Payment Records API for reconciling a charge that ran outside Stripe, and the new predictive early fraud warning signal for scoring one. All three assume the same thing: you don't run 100% of your volume through Stripe, and you still want Stripe's fraud and authentication infrastructure on the slice that doesn't. Standalone 3DS is the authentication piece of that pattern. A business settling charges through a regional acquirer for cost or coverage reasons can still get a Visa- or Mastercard-recognized 3DS authentication from Stripe, then hand the resulting cryptogram to that acquirer to authorize the charge — getting the liability-shift benefit of 3DS without moving the money through Stripe at all.

That chart isn't about Standalone 3DS directly — Stripe hasn't published success-rate numbers for it yet, since it's weeks old and still preview. It's the existing evidence for why the feature's two biggest selling points, full issuer-response observability and device fingerprinting through Stripe.js, aren't cosmetic. Visa's own data shows merchants who send richer data into a 3DS request get measurably better authentication outcomes on exactly the same transaction; Standalone 3DS is a bet that giving businesses the raw protocol output back, instead of a bundled pass/fail, lets them tune that same lever for themselves.

Who actually qualifies right now

This is the part most coverage of a new Stripe feature skips, and it's the part that decides whether anything above matters to you this quarter. Standalone 3DS supports Visa, Mastercard, American Express, Discover, and Cartes Bancaires, and it's available in every country where Stripe supports card payments except Malaysia and Thailand — on paper, broad coverage. In practice, three gates sit in front of it: it's restricted to businesses on Interchange Plus pricing, a negotiated, cost-plus pricing model that's a volume-based upgrade from Stripe's standard blended rate rather than something you flip on in the dashboard; it requires contacting your Stripe account executive or registering interest rather than a self-serve API key; and Stripe hasn't given a general-availability date.

Interchange Plus pricing specifically tends to track with processing volume high enough that Stripe negotiates it directly, which means the businesses who can turn this on today skew toward larger, often multiprocessor merchants — the same 57% from the hero stat — rather than the single-processor SaaS business running a few hundred thousand dollars a month through standard Stripe pricing. If that's you, Standalone 3DS isn't something to implement this sprint. It's something to watch for a GA announcement and a pricing-tier change, and to flag now if your own payments setup is multiprocessor enough that the eventual access would matter.

What this doesn't fix yet

None of this changes the underlying math on what a successful authentication actually buys you. Stripe is explicit, in its documentation on the bundled version of 3DS it's run for years, that a successful challenge generally supports a liability shift on a fraud-coded dispute but doesn't guarantee the outcome of any specific dispute — card network rules decide that case by case, and an account enrolled in a network fraud-monitoring program can lose the protection even on an authenticated charge. A fresh 3RI authentication on a renewal is a stronger signal to hand an issuer than nothing. It is not a guarantee the charge gets approved, and it's not a substitute for fixing the underlying regional gap in mandated 3DS adoption we've covered before, where an unauthenticated card capture at signup — in a market with no 3DS mandate — leaves every renewal on that subscription exposed for as long as the customer stays subscribed, long before any 3RI authentication could intervene.

It's also, for now, a preview product most of this blog's readers can't touch. The honest read is that Standalone 3DS matters as a signal about where Stripe is headed — decoupling authentication from the money movement itself, treating it as infrastructure any processor can plug into — more than as something to budget engineering time against this quarter, unless you're already multiprocessor and already on negotiated pricing.

A renewal that fails on authentication, with or without this API, never shows up as a customer deciding to leave. It shows up as a payment that silently didn't go through, on a subscriber who may not notice until they try to log back in. That's a different problem than the one a cancellation flow solves, and it's worth knowing how much of your blended involuntary churn is actually this mechanism before assuming a better save offer would have caught it — run the split through our churn calculator with your multiprocessor or EEA/UK segment isolated, and you'll usually find the fix was always upstream of anything CancelFlow shows at the cancel button.

Frequently asked questions

Stop losing subscribers today

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