Stripe Now Shows the Network's Final Verdict on Every Card Charge. It Can Overrule a Successful 3D Secure Check.

A European subscriber signs up, completes a 3D Secure challenge on their bank's app, and your integration logs the authentication as a success. Eight months later that subscriber disputes a renewal charge as fraud, and you assume you're covered — the customer authenticated, liability shifts to the issuer, case closed. Except Stripe shipped a field on September 30, 2026 that exposes a fact most teams never had visibility into: the card network can quietly overrule that authentication on its own, and until now you had no way to see it happen.

What actually shipped, and why the old field wasn't enough

Stripe already exposed an ECI value before this release, at payment_method_details.card.three_d_secure.electronic_commerce_indicator. The problem is what that field actually represents: the ECI your 3D Secure provider sent in the authorization request — in other words, what you asked the network to believe about the authentication that just happened. It's a provisional value. The network doesn't have to agree with it.

The new field, payment_method_details.card.electronic_commerce_indicator, sits directly on the charge and carries the network's final answer, returned in the authorization response. Stripe's own documentation gives a worked example of why the distinction matters: a Visa charge where the request carried ECI 05 — fully authenticated — and the response came back 07, not authenticated. Same transaction, same successful customer authentication on your side, and the network downgraded it anyway. "An authenticated ECI alone doesn't determine liability shift," Stripe's guide states flatly. The request value tells you what you tried to claim. The response value tells you what the network actually granted.

That gap is invisible unless you're pulling both fields and comparing them, which is precisely why most teams have never caught it. A three_d_secure.result of authenticated reads as a clean success in your logs. The response ECI sitting one level up in the same payload can tell a completely different story, and until September 30 there was no first-class way to see it on the charge at all.

Notice the codes don't line up across networks — Visa's 02 isn't Mastercard's 02, and treating one network's table as a universal key will hand you a confidently wrong read on the other network's charges. Stripe's guide is blunt about this: "don't use an ECI meaning from one network to interpret a transaction processed on another network."

The line that matters most: Mastercard code 07

Buried in that table is the single most important row for a subscription business. Mastercard reserves ECI 07 for "partial shipment or recurring transaction" — a category that has nothing to do with whether 3D Secure ran at all. A renewal charge processed under the merchant-initiated transaction exemption, the same mechanism that lets your off-session SCA-exempt renewals skip a fresh authentication challenge, can come back from Mastercard's network simply tagged as a recurring transaction. Not authenticated. Not unauthenticated. A different bucket entirely, with its own liability rules that most merchants have never read because they never had a reason to look.

This is the mechanism most teams miss when they think about liability shift as a one-time event that happens at signup and then persists forever. It doesn't. Each individual charge gets its own ECI, decided by the network at authorization time, and a subscription that authenticated perfectly in month one can be running on a completely different liability basis by month eight — not because anything about the customer changed, but because the charge itself is now classified differently by the network processing it.

Card-not-present fraud wasn't just the dominant category in Europe — it kept growing its share every time the ECB measured it. Every subscription renewal you process is card-not-present by definition; there's no terminal, no chip, no swipe. That makes the ECI on a recurring charge one of the only network-level signals that directly addresses the fraud category your entire billing model lives inside, and until this release it was a field most SaaS teams didn't know to ask for.

Why "authenticated" was never the whole answer

Liability shift has always had more conditions attached than the one everyone remembers. Stripe's own limitations section spells out three separately: the response ECI has to indicate authentication, the transaction needs a valid cryptogram, and the merchant category has to be eligible in the first place. A fourth condition that trips up more subscription businesses than any of those — enrollment in a card network's own fraud monitoring program, or certain SCA exemption paths, can downgrade or exclude liability shift even when every other box is checked.

Put plainly: authentication is necessary for liability shift, but it was never sufficient, and most dispute-response workflows have been written as if it were. A chargeback team that pulls three_d_secure.result: authenticated and assumes that alone wins a fraud dispute is reading the wrong field for the claim they're trying to make. The response ECI is the field that was actually built to answer the liability question, and before September 30 there wasn't a direct way to pull it off a Stripe charge at all — you'd have had to go to your acquirer or the network directly, which almost nobody does per-dispute.

What to actually do with the new field

• Query it across your volume, not just per-dispute. Stripe exposes card_electronic_commerce_indicator as a column in Sigma. Pull the distribution across your recurring charges and find out what share are landing as Mastercard 07 or Visa 07 before a dispute ever forces you to look one at a time.
• Compare the request and response values, not just the response. When three_d_secure.electronic_commerce_indicator and the new top-level field disagree, the network downgraded what you sent. That gap is the signal worth building an alert on — it tells you liability protection you thought you had quietly isn't there.
• Mind the start date. Response ECI data is only populated for charges from June 10, 2026 onward in the API, and from July 22, 2026 in Sigma and Data Pipeline, with no backfill. Anything disputed from before those dates has no response ECI to pull, no matter how recently the dispute itself was filed.
• Treat it as one input to a dispute, not the case. Stripe auto-attaches an authenticated response ECI to fraud-dispute evidence for you. It still sits alongside everything else that actually moves a digital-goods dispute — refund records and usage logs carry more weight on their own, as we've covered in our breakdown of what Stripe's million-dispute study found actually wins these cases.

None of this changes what a card network ultimately decides — Stripe doesn't guarantee liability shift outcomes, and neither does this field. What it changes is whether you find out before a dispute lands or after. A business running recurring EEA or UK cards already has to reckon with how often SCA exemptions quietly reshape what "authenticated" means on an off-session renewal; the response ECI is the first place that reshaping shows up in a format you can actually query. And broadly, this sits in the same category as every other dispute mechanic we've covered under chargebacks and disputes — the charge that triggers a cancellation and the charge that triggers a dispute often start from the exact same renewal, and knowing which liability bucket it fell into before the bank calls is worth more than any evidence you assemble afterward.

It's also a reminder that a dispute a customer never has to file is cheaper than one you win. A subscriber who can find your cancel button settles things through a refund, not a chargeback claim that drags a liability-shift argument into it at all — which is most of what a well-built cancellation flow is actually protecting you from. If you're trying to size how much involuntary churn and dispute exposure is costing you against the cost of fixing the renewal mechanics directly, our churn calculator is worth running before you invest engineering time in a Sigma query most teams have never needed until now.

Frequently asked questions

Stop losing subscribers today

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