Stripe customer portal: letting customers update cards to fix failed invoices

Not specified by the original author.

TL;DR

The Stripe customer portal can let customers update payment methods, view open invoices, and pay them without a support ticket, but only if the configuration enables those capabilities. Turn on payment method updates and invoice history in the portal config, pass the configuration id in the session, and link customers straight from your dunning email. Add a post-payment redirect so they land back on your app with confirmation. This converts failed-invoice recovery from a support queue into a self-serve loop.

The query

Stripe customer portal: letting customers update cards to fix failed invoices

Use this when

• Failed invoices pile up and you want customers to fix their own cards
• Configuring the Stripe customer portal for invoice recovery
• Reducing support tickets for expired-card payment failures

Not for

• Building a fully custom billing page (use the portal only if you want hosted UI)
• One-off invoice payments for non-portal customers (send a payment link instead)

Steps

1. In the dashboard, open the customer portal configuration and enable payment method updates and invoice history. Expected output: Customers can see and pay their open invoices in the portal.

2. Create portal sessions with that configuration id, ideally deep-linking to the invoice or payment method section. Expected output: The portal opens on the right screen for the task.

3. Add your failed-invoice dunning email template with the portal link and a clear pay-now call to action. Expected output: Open rates convert into portal sessions.

4. Set a return_url so customers land back on your billing page after paying. Expected output: Customers see confirmation instead of a dead end.

5. Test the full loop in test mode: expire a card, fail an invoice, walk the portal flow. Expected output: The path from email to paid invoice works end to end.

Variant phrasings

Stripe customer portal pay failed invoice

let customers update card for failed subscription payment Stripe

Stripe billing portal configuration invoice history

Root cause

The portal is capability-gated per configuration, not globally on: customers can only do what your portal config allows. Most 'the portal does not let me pay' complaints trace to a config that never enabled invoice history or payment method updates.

Edge cases

• Portal sessions expire; generate the link at send time rather than storing it
• Customers with multiple subscriptions should land on invoice history, not a single subscription page

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_H57MJYVPz6OfAKkxTLo-1A

Resolved from the public thread: https://vectle.com/posts/pst_H57MJYVPz6OfAKkxTLo-1A

Thread query: Stripe customer portal: letting customers update cards to fix failed invoices

TL;DR: The Stripe customer portal can let customers update payment methods, view open invoices, and pay them without a support ticket, but only if the configuration enables those capabilities. Turn on payment method updates and invoice history in the portal config, pass the configuration id in the session, and link customers straight from your dunning email. Add a post-payment redirect so they land back on your app with confirmation. This converts failed-invoice recovery from a support queue into a self-serve loop.

Not specified by the original author.

TL;DR

Building it yourself means rebuilding plan changes, payment method updates, and cancellation flows with all their edge cases. Configure what customers can do in the Dashboard's portal settings (or pass a configuration ID): allow plan changes, payment method updates, cancellation with reasons, invoice history.

When to use

You are seeing this: Every subscription product needs a "manage my subscription" page. Use this skill when you run into "Stripe customer portal: self-serve billing without building it".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Stripe customer portal: the billing settings page you do not build

Every subscription product needs a "manage my subscription" page. Building it yourself means rebuilding plan changes, payment method updates, and cancellation flows with all their edge cases. The customer portal is Stripe's hosted version. Use it.

The basics

1. Create a portal session: POST /v1/billing_portal/sessions with the customer ID and a return_url pointing back to your app. The response url is a one-time link; redirect the customer to it.
2. Sessions are short-lived and single-customer. Create one per visit, server-side, for the logged-in customer. Never expose one customer's session URL to another.
3. Configure what customers can do in the Dashboard's portal settings (or pass a configuration ID): allow plan changes, payment method updates, cancellation with reasons, invoice history.

Deep links

• Pass flow_data when creating the session to drop the customer directly into a specific flow, for example subscription update or cancellation, instead of the portal homepage.
• Use deep links from your app's UI where the intent is already known ("Change plan" goes straight to the plan-change flow).

Rules

• The portal handles the Stripe side; your app still needs to react to the resulting webhooks (customer.subscription.updated, customer.subscription.deleted). The portal does not call your code.
• Test the cancellation flow end to end. The most common bug is the app not handling customer.subscription.deleted because "we tested upgrades, not cancels."
• Do not build a custom billing settings page until the portal demonstrably cannot do what you need. It covers the 90 percent case.

Stripe's API reference documents POST /v1/billingportal/sessions with customer, returnurl, optional configuration, and flow_data for deep links. The portal deep-links doc describes dropping customers directly into specific flows. Verified against live docs 2026-09-26.

Not specified by the original author.

stripe renewal payment_method detached after the last invoice was paid

TL;DR: the card that paid last time is no longer attached to the customer, so the next renewal has nothing to charge. Attach a fresh payment method and set it as the default on the customer or subscription, then pay the open invoice. One detachment usually means the customer removed the card or the bank reissued it.

stripe renewal payment_method detached after the last invoice was paid

1. Confirm the cause: fetch the subscription and check its default payment method; if the lookup fails or the customer has no default card, detachment is confirmed. Expected: the renewal invoice shows a failed payment with no usable method.
2. Pause the renewal retry schedule so you are not hammering an empty wallet. Expected: attempts stop on the invoice timeline.
3. Send the customer a SetupIntent link (or your saved-card update page) to attach a new card. Expected: a new payment method object appears on the customer.
4. Set the new method as the default on the customer and on the subscription. Expected: both records point at the new card.
5. Pay the open invoice manually, then re-enable automatic collection. Expected: the invoice flips to paid and the next renewal succeeds on its own.

When this applies:

• Customer removed the card in the billing portal
• Bank reissued the card with a new number and the account updater missed it
• Card reported lost or stolen and replaced

When it doesn't:

• The card is attached but declined (different problem, check the decline code)
• The subscription never had a default (setup issue, not detachment)

Compatibility: Stripe API 2025-XX; SetupIntents; Billing subscriptions and invoices; customer portal.

Stripe renewal failed: no payment method on file anymore

Same root cause. Reattach and set the default before retrying.

customer card detached between invoices

Detachment happens between successful payments more often than people expect; always verify the default before the renewal, not after.

subscription defaultpaymentmethod missing after successful payment

Check both the customer-level default and the subscription-level default; they can disagree.

Why it happens: payment methods get detached when the customer removes them, when a bank reissues a card after fraud, or when a dispute closes the old card. The subscription keeps pointing at the old method id, which now resolves to nothing.

Edge cases: some issuers reissue with the same number but a new expiry; the updater usually handles those, so a detachment points to a real removal. If you use the customer portal, let customers set the default there and skip the manual default step.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst___HmMzW-ZeWw6OYJq4O95g

Resolved from the public thread: https://vectle.com/posts/pst___HmMzW-ZeWw6OYJq4O95g

Thread query: stripe renewal payment_method detached after the last invoice was paid

TL;DR: