Stripe Automation

n8n is the default because payment workflows tend to branch: the same subscription event means different things depending on its status, plan, or metadata, and handling duplicates means looking up whether an event was already processed. n8n's branching, Code node, and direct Stripe API calls handle that without workarounds, and self-hosted it has no per-run cost however many payments come through. Zapier is the fastest way to send a receipt or a Slack alert for each payment, but it bills per action step, which adds up at payment volume. Make sits in between on both flexibility and cost. The Pricing section has the plan figures.

It depends on how they pay. For a one-off Checkout purchase, use checkout.session.completed, but check its payment status: bank debits and some other methods complete the session before the money arrives, and those need checkout.session.async_payment_succeeded instead. For subscriptions, grant or extend access on invoice.paid, which fires for the first payment and every renewal, and use customer.subscription.updated and customer.subscription.deleted for plan changes and cancellations. Avoid building access on charge.succeeded for subscriptions; it doesn't tell you which subscription or period the payment covers.

Assume both will happen. Stripe retries a failed delivery for up to three days in live mode, and it can deliver the same event twice or a later event before an earlier one. Two habits cover it. First, record each processed event ID (in a database table, a spreadsheet, or n8n's own data store) and skip IDs you have already seen. Second, treat the event as a signal rather than the truth: when order matters, fetch the current subscription or invoice from the Stripe API inside the workflow and act on that, so a late-arriving older event can't undo a newer state.

The connection to Stripe. Test and live mode have separate API keys and separate webhook endpoints, so a workflow that worked perfectly against test events receives nothing in production until the live endpoint and live key are configured too. In n8n that means a second credential and re-activating the Stripe Trigger against it; in Zapier and Make, reconnecting the Stripe account in live mode. Before launch, run the full subscription lifecycle in test mode with test clocks (which fast-forward a subscription through trials, renewals, and failed payments), then send one real low-value payment through the live setup and refund it.

From Stripe, mostly. Stripe Billing already retries failed card payments on its own schedule (Smart Retries) and can email customers about failed payments and expiring cards, and it handles card updater services your workflow can't reach. Rebuilding that in an automation platform duplicates it and risks double emails. Use the workflow for what Stripe doesn't do: tell the account owner or a sales channel that a large customer's payment failed, update the customer's status in your CRM, and restrict access in your product when a subscription moves to past_due or is finally cancelled.