Stripe failed payment to Klaviyo recovery flow with Slack alerts

Build a code workflow that turns failed Stripe charges into a Klaviyo payment recovery flow and a Slack alert for ops. Every step is a known operation against a structured webhook payload, so do it as a deterministic node-by-node pipeline with no LLM judgement step.

Trigger: incoming webhook from Stripe on the charge.failed event. The webhook payload is a Stripe Charge object and includes the customer ID, amount, currency, and failure_code / failure_message.

Step 1, Stripe Retrieve Customer: take the customer ID from the webhook and fetch the full customer record so we have email, name, and metadata. If the charge has no customer attached (guest checkout), short-circuit and only run the Slack alert with whatever billing details Stripe gave us.

Step 2, Klaviyo Create or Update Profile (Upsert): upsert by email using the customer's email from Stripe. Pass first_name, last_name, and any useful Stripe metadata as profile properties so the profile always reflects the latest customer info.

Step 3, Klaviyo Create Event: log a Payment Failed event on that profile. Set the metric name to Payment Failed. Event properties should include amount (converted from Stripe's smallest currency unit to a decimal), currency, failure_code, failure_message, charge_id, and the Stripe customer ID. This is the event your Klaviyo dunning flow will key off.

Step 4, Klaviyo Add Profiles to List: add the profile to a Payment Recovery list. The list ID should be a configurable input so the user can point this at whichever list gates their dunning flow.

Step 5, Slack Send a Message: post to a configurable ops channel with the customer email, customer name, amount in the human-readable currency, failure reason (failure_message), and the charge ID. Keep it one short message a human can scan, not a long block.

Inputs the user should be able to configure: the Klaviyo Payment Recovery list ID, the Slack channel, and an optional minimum amount threshold below which the Slack step is skipped (the Klaviyo steps always run).

Make the workflow idempotent: re-running on a duplicate Stripe event should be safe. Upsert and Add to List are already safe; tag the Klaviyo event with the charge_id so downstream filtering can dedupe if needed.

Additional information

What does this prompt do?

Listens for failed Stripe charges and pulls the customer's email, name, and account details.
Updates the matching Klaviyo profile so it always reflects the latest customer info.
Logs a Payment Failed event on the profile with the amount, currency, and decline reason so your Klaviyo flow can use those values in the email.
Adds the customer to a dedicated Payment Recovery list that gates your Klaviyo dunning flow.
Posts a one-line alert in your ops Slack channel with the email, amount, and reason so a human can step in on big or repeat failures.

What do I need to use this?

A Stripe account where you can turn on the failed charge webhook.
A Klaviyo account with a Payment Recovery list and a dunning flow you want to trigger.
A Slack workspace and the channel you want alerts to land in.

How can I customize it?

Swap the Klaviyo list ID if you want recovery to feed a different audience or A/B test two flows.
Change the Slack channel, or only alert when the failed amount is above a dollar threshold so small failures stay quiet.
Add extra event properties (plan name, retry count, customer lifetime value) so your Klaviyo email can personalize the recovery message.

Frequently asked questions

Why do I need this if Klaviyo already integrates with Stripe?

Klaviyo's native ecommerce integrations only listen to platforms like Shopify and BigCommerce. If you run a SaaS or subscription business on Stripe directly, failed payment events never reach Klaviyo unless you wire them in. This workflow does that.

Will this work with Stripe subscriptions and one-off charges?

Yes. It listens for failed charges, which covers both subscription renewal failures and one-time payment failures. If you want to listen for invoice payment failures specifically, you can switch the trigger event in the workflow.

Do I have to build the recovery email here?

No. The email itself stays in Klaviyo. This workflow's job is to keep the profile fresh, log the failure as an event, and put the customer on the right list. Your existing Klaviyo flow handles the send.

How do I stop sending alerts for every small failed charge?

You can add a minimum amount filter in the Slack step. Only failures above your threshold post to Slack, while every failure still flows into Klaviyo.

What if Stripe sends a duplicate failed charge event?

Klaviyo's upsert and add to list operations are safe to call twice. The profile gets updated, the list membership stays the same, and a new Payment Failed event is logged so your flow can count retries.