Trigger Klaviyo payment recovery when Stripe charges fail

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.