Stripe's last_payment_error Can Now Name the Payment Method That Failed. Most Dunning Routers Still Join to Find Out.

Every dunning handler we've ever reviewed starts the same way: a webhook fires on invoice.payment_failed or payment_intent.payment_failed, and the first thing the code needs to decide is what kind of failure this actually is. Not just the decline reason — the payment method itself. A card failure gets a retry schedule and a "update your card" email. A SEPA Direct Debit failure gets a mandate check. A BNPL failure gets neither, because retrying it does nothing. Until September 30, 2026, Stripe's failure payload didn't actually tell you which of those you were looking at. You had to go get it.

This is a small release by changelog standards — one bullet in a list of two dozen things Stripe shipped that day. But it closes a gap that's been getting more expensive every quarter your subscriber base spreads across more rails, which for most SaaS businesses now selling outside the US is exactly what's happening.

What actually shipped on September 30

Stripe added a payment_method_type property inside the last_payment_error hash on the PaymentIntent object. It returns the type of payment method involved in a failed attempt — card, ideal, sepa_debit, and so on — and it covers failures during capture and multicapture, not just the initial authorization. The same value shows up in the payment_intent.payment_failed event body, so you don't need a second API call after the webhook lands to find out what you're looking at.

Two details matter for how you plan the rollout. First, it's additive and forward-only: existing failure records aren't backfilled, so any historical reporting you run against old failures still won't have this field. Second, it ships under API version 2026-09-30.endive, and your webhook endpoint's pinned version is configured separately from your API request version in the Dashboard — upgrading one does not upgrade the other, and it's an easy step to miss.

The join this replaces

Before this release, if you wanted to know the payment method type behind a failure at the moment your webhook fired, you had one of three options, and all three cost you something. You could expand payment_method on the PaymentIntent in the same request — an extra nested object Stripe doesn't include by default, which means an extra round trip if your webhook handler wasn't already requesting it. You could look the payment method up separately by ID after the fact, which works until the method itself gets detached or the lookup races a cleanup job. Or you could maintain your own mapping back to whatever Checkout Session or Payment Element configuration originated the attempt, which works until you have more than one place in your codebase creating PaymentIntents and the mapping drifts.

None of those are exotic engineering problems. But they're exactly the kind of incidental complexity that accumulates in a dunning stack that started as "handle card failures" and grew into "handle fourteen payment methods" one region at a time. Each new rail you turn on — SEPA, iDEAL, BLIK, Bancontact, a BNPL method — added another branch to the webhook handler, and every one of those branches needed the same piece of information that now just arrives for free.

Why this stopped being a cards-only problem

The reason this field matters more now than it would have two years ago is that card is no longer the default way most of the world pays for anything online, subscriptions included.

That data is about wallets specifically, but the pattern holds across every non-card rail Stripe has added recurring billing support for this year: the markets growing fastest for SaaS adoption are often the ones where card was never the dominant payment method to begin with. A failure payload that only distinguishes "card declined" from "something else declined" is increasingly describing a minority of your failures, not the majority.

What changes in a routing handler

The point of the table isn't the specific actions — we've covered most of those in depth elsewhere, including the SEPA reversal mechanics and the core Stripe dunning setup. The point is that the dispatch decision at the top of every one of those playbooks — which row of this table am I even in — used to require a lookup. Now it's a field you already have in hand when the webhook lands.

How this interacts with the August error codes

If you read our piece on the unified error codes Stripe shipped on August 26, 2026, you already know Stripe added codes like payment_method_restricted and authentication_failure that describe the same failure the same way across rails. That release and this one solve adjacent but different problems. The August codes tell you what kind of failure this is, independent of payment method. This release tells you which payment method you're looking at, independent of what kind of failure it is. Put together, a well-built handler now checks both off one event: the unified code decides whether to retry at all, and payment_method_type decides which playbook to retry with. Before September 30, you had the first signal and had to go fetch the second one separately — or skip the distinction and run one blended retry schedule across every rail, which is how debit-style timing problems and SEPA-style mandate problems end up getting the same generic "please update your payment method" email.

Rolling it out without breaking webhooks

• Upgrade the API version on your webhook endpoint specifically. This is configured separately from the version your outbound API calls use. Check both in the Dashboard before assuming you're receiving the new field.
• Upgrade your SDK alongside the API version. Stripe's own upgrade guidance ties the two together; an old SDK parsing a new API version is a common source of silently-missing fields.
• Don't backfill-test against historical failures. The field is forward-only. Validate it against a fresh test failure on each payment method type you support, not against last month's data.
• Drop the expand-or-join workaround once the field is confirmed live. If your handler currently expands payment_method just to get the type, that extra round trip is now redundant — remove it rather than running both in parallel indefinitely.

Where the real win is

On its own, knowing the payment method type faster doesn't recover a single additional dollar. The value shows up one step downstream, in how fast and how correctly you can branch. A webhook handler that has to make three API calls and check a locally-maintained mapping table before it can decide whether to retry, re-prompt, or give up entirely is a handler that's slow to write, slower to extend to the next payment method you turn on, and prone to the exact kind of silent misrouting that shows up months later as unexplained involuntary churn nobody can quite trace back to a cause. Collapsing that decision into a field you already have removes one specific, recurring source of that drift.

If you're trying to work out how much of your current involuntary churn is sitting in payment methods your retry logic was never built to treat differently, our churn calculator will turn a specific failure segment into an MRR number in a couple of minutes. And for the subscribers whose payment method is working just fine and who are leaving on purpose, that's a separate decision a proper cancellation flow is built to catch — no amount of better failure routing will save someone who never had a failed payment to begin with.

Frequently asked questions

Stop losing subscribers today

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