Call customers with Bland AI when a Stripe payment fails

Build me a code workflow (deterministic pipeline, no agent branching) that runs a voice-first payment recovery flow the moment a Stripe invoice payment fails.

Trigger: a Stripe webhook on the invoice.payment_failed event. Treat the incoming event body as the source of truth for the customer id and invoice id.

Pipeline, in order:

1) Parse the Stripe event payload to extract the customer id and invoice id.

2) Call Stripe Retrieve Customer to fetch the customer's name, email, and phone.

3) If phone is missing or empty, skip the call and jump to the ledger step, logging "skipped: no phone on file" as the call status. This is the only branching allowed and it is a simple null guard.

4) Call Stripe Retrieve Invoice to get the amount due and hosted invoice URL.

5) Call Bland AI Send Call to dispatch an outbound AI phone call to the customer's phone number, using a scripted task that greets the customer by name, references the failed invoice amount in the customer's currency, offers to update their card via a link that will be texted after the call, and asks if they need a payment plan. Wait for the call to complete.

6) Call Bland AI Get Call Details for the call id to fetch the transcript, duration, and completion status.

7) Call Google Sheets Append Values to add one row to the recovery ledger tab with these columns in order: timestamp, customer name, customer email, customer phone, invoice id, amount due, call status, call duration in seconds, and a short transcript snippet (first ~500 chars). For skipped customers, still append a row with the skip reason in the call status column and blanks for the call-only fields.

Config knobs the user should be able to edit without touching code: the Bland AI call script text, the Google Sheets spreadsheet id and tab name, and the caller phone number Bland AI dials from.

This is code, not agent: every step maps to a documented op and there is no reasoning between them. Do not add retries, escalation branches, or LLM decisions beyond the null-phone guard.