Stripe payment_action_required: What It Means and the Email to Send

You see invoice.payment_action_required in your webhook logs, and a subscription renewal is sitting unpaid. Nothing is wrong with the card. The customer's bank wants them to approve the payment, and until they do, the money does not move.

Disclosure: we run Renewvane, a failed payment recovery service on Stripe. Stripe details below were checked against Stripe's documentation on October 15, 2026.

What the event means

Stripe describes invoice.payment_action_required as "Sent when the invoice requires customer authentication" (Stripe docs: subscription webhooks).

Behind it, the payment needs 3D Secure. Stripe explains that "Some payment methods require customer authentication with 3D Secure (3DS)", and whether it is required "depends on your Radar rules and the issuing bank for the card" (Stripe docs: how subscriptions work). When that happens, the PaymentIntent status is requires_action and the invoice stays open.

This is common for cards issued in Europe, where Strong Customer Authentication rules apply, but it can happen anywhere a bank decides to ask.

Why waiting for retries does not help

authentication_required is on Stripe's list of hard decline codes. For those, Stripe says "the scheduled retries continue but the payment only executes if you obtain a new payment method" (Stripe docs: Smart Retries).

So the retry schedule ticks along, and nothing gets collected unless the customer acts. Every day without a message is a day closer to the end of your retry window.

Your options, from least to most work

1. Turn on Stripe's confirmation emails. In your billing settings, enable the setting that sends a Stripe hosted link for customers to confirm their payments when required. The email includes a link to a Stripe hosted page where the customer can confirm the payment. You can also enable reminders until the customer confirms or the payment expires (Stripe docs: customer emails).

2. Send your own email with the hosted invoice page. The invoice's hosted_invoice_url works well here, because when 3D Secure is needed "the hosted invoice page displays the payment confirmation modal to your customer" (Stripe docs: hosted invoice page).

3. Handle it inside your app. If the customer is logged in, Stripe's guidance is to retrieve the PaymentIntent's client secret and pass it to stripe.handleNextAction, which "guides the customer through any required steps" (Stripe docs: how subscriptions work). This only helps customers who come back to your app, so pair it with an email.

Whichever you choose, use one, not two. Two confirmation emails for one payment looks like phishing.

The email to send

The single most important thing: do not say the card was declined. It was not. Customers who read "declined" go looking for a new card, which is not what the bank asked for.

Email 1, as soon as the event arrives

Subject: Your bank needs you to confirm a [Product] payment

Hi [First name],

Your bank asked you to confirm your [amount] payment to [Product] for [period]. It is a routine security check, and your card was not declined.

You can confirm it here, it usually takes a few seconds in your banking app: [link]

If you were not expecting this charge, just reply and I will look into it.

[Your name], [Product]

Email 2, about 2 days later, only if still open

Subject: Reminder: confirm your [Product] payment

Hi [First name],

The confirmation for your [Product] payment is still waiting. Here is the link again: [link]

If your bank's app did not show a request, opening the link will trigger a new one.

[Your name]

Email 3, the day before access changes, only if still open

Subject: Your [Product] access changes on [date]

Hi [First name],

We still need the bank confirmation for your [Product] payment. On [date] your account will [what really happens]. Confirm here to keep everything as it is: [link]

[Your name]

Why these work, in our opinion: the subject names the bank, not a failure; the body tells the customer the card is fine; and the "were you expecting this?" line gives worried customers a human to talk to instead of a dispute button.

Checklist for developers

• Listen for invoice.payment_action_required and send the confirmation email, not your "card failed" email.
• Listen for invoice.paid and stop the sequence immediately. Check the invoice status again right before each send.
• Use a fresh hosted_invoice_url from the invoice. Stripe says invoice URLs "expire 30 days after the due date" (Stripe docs).
• Keep the email strictly about the payment. No promotions.
• Before provisioning access, confirm the subscription is active, as Stripe recommends (Stripe docs).

How we handle it

Our recovery emails have a separate track for bank confirmation, using the hosted invoice page. And because Stripe and your own settings keep working in the background, our monthly proof report only credits us with recovery above a random holdout group that gets no emails from us, after a safety margin for chance, and only on invoices where the subscriber clicked our link and, within 7 days, completed the confirmation or added a new card on the page we opened. See how attribution works.

Sources

• Stripe docs, Using webhooks with subscriptions: https://docs.stripe.com/billing/subscriptions/webhooks
• Stripe docs, How subscriptions work: https://docs.stripe.com/billing/subscriptions/overview
• Stripe docs, Automate payment retries (hard decline codes): https://docs.stripe.com/billing/revenue-recovery/smart-retries
• Stripe docs, Automate customer emails: https://docs.stripe.com/billing/revenue-recovery/customer-emails
• Stripe docs, Hosted invoice page: https://docs.stripe.com/invoicing/hosted-invoice-page