Recover failed payments with webhook retries, customer alerts, and CRM updates

Quick overview

This workflow receives failed payment events via webhook, selects a customer-tier retry strategy in code, retries the charge through HTTP calls to a payment gateway, notifies the customer and updates a CRM endpoint, then returns a detailed recovery report to the webhook caller.

How it works

1. Receives a failed-payment event via a POST webhook.
2. Validates required fields (such as customerId, amount, and email) and selects a retry strategy based on the provided customer tier and failure code.
3. Waits briefly and sends the first HTTP POST retry request to the configured payment gateway endpoint.
4. Waits again and sends a second HTTP POST retry request to the payment gateway endpoint.
5. Waits briefly, then sends an HTTP POST to a notification endpoint to inform the customer and an HTTP POST to a CRM endpoint to update recovery status and optionally escalate.
6. Aggregates the HTTP response statuses into an audit-style recovery report and responds to the webhook with a 200 (recovered) or 402 (not recovered) status code.

Setup

1. Configure the source system (payment provider, billing system, or internal service) to send failed payment events to this workflow’s POST webhook URL.
2. Replace the placeholder httpbin.org URLs in the strategy/config section with your real payment gateway retry endpoint, customer notification endpoint (email/SMS service), and CRM/collections endpoint.
3. If your endpoints require authentication, add the necessary credentials (for example API keys or OAuth2) and update the HTTP request headers accordingly.
4. Ensure the webhook payload includes at minimum customerId, amount, and email (and optionally customerTier and failureCode) so strategy selection and reporting work correctly.