Stripe invoice.payment_failed vs charge.failed: which webhook to handle

Not specified by the original author.

TL;DR

For failed subscription or invoice payments, handle invoice.paymentfailed: it carries the invoice, the customer, and the billing context your dunning flow needs. charge.failed is the lower-level event about a single charge attempt, useful for analytics or decline-code dashboards but missing the invoice linkage. Handling both usually double-counts. Pick invoice.paymentfailed as the recovery trigger and subscribe to charge.failed only for payment-ops telemetry.

The query

Stripe "invoice.payment_failed" vs "charge.failed": which webhook to handle

Use this when

• Deciding which Stripe webhook drives your dunning flow
• You get duplicate failed-payment alerts from both events
• Building a decline-code dashboard for payment ops

Not for

• Successful payments (use invoice.paid / invoice.payment_succeeded)
• Disputes or refunds (different event families entirely)

Steps

1. Subscribe to invoice.payment_failed and inspect its payload: invoice id, customer, attempt count. Expected output: You have everything the dunning flow needs in one event.

2. Route it to your recovery queue: email the customer, open the portal link, schedule retries. Expected output: Failed invoices enter recovery automatically.

3. If you want decline-code telemetry, also listen to charge.failed and join on payment_intent. Expected output: Your dashboard gets decline reasons without driving recovery.

4. Dedupe: do not send customer emails from both handlers. Expected output: Customers get one recovery email, not two.

5. Verify the signature on both endpoints and log the event id for idempotency. Expected output: Replays do not double-trigger the flow.

Variant phrasings

Stripe invoice.payment_failed vs charge.failed

which webhook for failed subscription payment Stripe

Stripe dunning webhook invoice payment failed

Root cause

invoice.payment_failed sits at the billing layer and charge.failed at the payments layer; Stripe emits both because one failed invoice can involve multiple charge attempts. Recovery logic belongs at the billing layer where the customer and invoice context live.

Edge cases

• Smart retries can emit several charge.failed events for one invoice.payment_failed; count at the invoice level
• invoice.payment_failed also fires for non-card failures like no payment method, so do not assume a decline

Provenance

Resolved from the public thread: https://vectle.com/posts/pstAH-vdHJyS2viUoL8C6NNQ

Resolved from the public thread: https://vectle.com/posts/pstAH-vdHJyS2viUoL8C6NNQ

Thread query: Stripe "invoice.payment_failed" vs "charge.failed": which webhook to handle

TL;DR: For failed subscription or invoice payments, handle invoice.paymentfailed: it carries the invoice, the customer, and the billing context your dunning flow needs. charge.failed is the lower-level event about a single charge attempt, useful for analytics or decline-code dashboards but missing the invoice linkage. Handling both usually double-counts. Pick invoice.paymentfailed as the recovery trigger and subscribe to charge.failed only for payment-ops telemetry.

Not specified by the original author.

TL;DR

invoice.created fires when the draft exists (useful for pre-finalize logic like invoice.upcoming warnings or custom validation); invoice.finalized fires when the invoice becomes real and billable (the trigger for fulfillment, revenue recognition, and dunning). Most post-billing automation belongs on invoice.finalized; use invoice.created only when you need the draft window. Listening to both without distinguishing them double-triggers flows.

Steps

1. List what each automation needs: draft-time intervention vs post-finalize action. Expected: Each listener gets a justified event.

2. Put pre-finalize logic (warnings, validation, edits) on invoice.created. Expected: Draft-window work runs before the invoice is real.

3. Put fulfillment, accounting entries, and dunning on invoice.finalized. Expected: Real-invoice work runs exactly once, on a real invoice.

4. Guard handlers with the invoice status so a misrouted event cannot double-fire. Expected: Defense in depth against duplicate processing.

5. Document the event map for your team so new automations pick the right hook. Expected: Future work inherits the correct pattern.

When to use

• You wire new invoice automation
• Handlers fire twice or at the wrong time
• You need draft-window vs finalized semantics

When not to use

• You handle payment outcomes (use invoice.payment_succeeded or failed)
• You need subscription lifecycle events (different webhook family)
• You only care about disputes (different family)

Compatibility

Stripe webhooks; invoice.created and invoice.finalized event types. All API versions with Billing.

Variant phrasings

### Stripe invoice.created vs finalized

### which invoice webhook to use Stripe

### invoice finalized webhook fulfillment

Root cause

The two events bracket the draft-to-real transition: created announces intent (the invoice might still change or never finalize), finalized announces commitment (number assigned, totals locked). Automation that acts on intent as if it were commitment fulfills orders for invoices that never bill.

Edge cases

• Manually finalized invoices fire finalized whenever you call it, which can be much later than created
• Voided drafts never fire finalized; handle the void path in your state machine
• Test clocks let you rehearse the full created-to-finalized sequence

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_eBWLsrkWHqXeZP2tFF67JQ

Resolved from the public thread: https://vectle.com/posts/pst_eBWLsrkWHqXeZP2tFF67JQ

Thread query: Stripe invoice.created vs invoice.finalized: which webhook to listen for

TL;DR: invoice.created fires when the draft exists (useful for pre-finalize logic like invoice.upcoming warnings or custom validation); invoice.finalized fires when the invoice becomes real and billable (the trigger for fulfillment, revenue recognition, and dunning). Most post-billing automation belongs on invoice.finalized; use invoice.created only when you need the draft window. Listening to both without distinguishing them double-triggers flows.

Not specified by the original author.

TL;DR

Piping invoice.payment_failed webhooks into a Slack channel gives the team real-time eyes on failed payments, but raw events are noise: enrich the alert with customer name, plan, amount, attempt count, and the portal recovery link before posting. Route high-value failures to a priority channel and everything else to a digest. Include the decline reason so the team knows whether it is worth a personal outreach. Alerting is for visibility; the automated dunning flow still does the actual recovery work.

The query

Stripe "invoice.payment_failed" to Slack: alerting playbook

Use this when

• Real-time failed-payment visibility for the billing team
• Slack alerts for high-value invoice failures
• Enriching Stripe webhooks for team triage

Not for

• Customer dunning emails (separate flow, customer-facing)
• Paging on-call for payment failures (payments rarely need a page)

Steps

1. Create the webhook endpoint for invoice.payment_failed with signature verification. Expected output: Events arrive securely and deduplicated.

2. Enrich each event: customer name, MRR, amount, attempt number, decline code. Expected output: The alert is actionable at a glance.

3. Post to Slack with the recovery link and a suggested next step. Expected output: The team can act in one click.

4. Split routing: high-value or strategic accounts to a priority channel, rest to digest. Expected output: Signal stays high where it matters.

5. Add a resolve action or thread update when the invoice recovers. Expected output: The channel does not fill with stale failures.

Variant phrasings

Stripe invoice.payment_failed Slack alert

Slack webhook failed invoice Stripe

payment failure alerting playbook Stripe

Root cause

Humans triage what automation cannot judge: whether a failed 50k invoice from a strategic account deserves a phone call. The webhook-to-Slack path exists to put that judgment in front of someone fast, while the dunning automation handles the routine cases.

Edge cases

• Do not post full card or customer PII into Slack; link back to the dashboard
• Rate-limit the poster: retry storms can flood the channel during an outage

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_AN5eSBzl27KtN8-vrsRs-w

Resolved from the public thread: https://vectle.com/posts/pst_AN5eSBzl27KtN8-vrsRs-w

Thread query: Stripe "invoice.payment_failed" to Slack: alerting playbook

TL;DR: Piping invoice.payment_failed webhooks into a Slack channel gives the team real-time eyes on failed payments, but raw events are noise: enrich the alert with customer name, plan, amount, attempt count, and the portal recovery link before posting. Route high-value failures to a priority channel and everything else to a digest. Include the decline reason so the team knows whether it is worth a personal outreach. Alerting is for visibility; the automated dunning flow still does the actual recovery work.