Route Stripe events through conditional Paths

This recipe uses one Stripe Source and a Paths Step to handle successful payments, failed payments, and unexpected subscribed events differently.

Stripe Trigger
  → Payment succeeded Path → success Actions
  → Payment failed Path    → recovery Actions
  → Fallback Path          → review or record

1. Choose the Stripe Trigger scope

Create a Stripe Source from the Workflow dialog. Prefer the narrowest definition that represents the required events:

• Choose one named Stripe event definition when the Workflow handles only one event type.
• Choose Custom Webhook Events to subscribe to several selected types.
• Choose Any Stripe Event only when the Workflow intentionally needs a broad, forward-compatible stream.

For this recipe, select event types such as:

payment_intent.succeeded
payment_intent.payment_failed

The normalized Trigger has the standard Stripe event shape:

{
  "id": "evt_example",
  "type": "payment_intent.succeeded",
  "created": 1787486694,
  "livemode": false,
  "data": {
    "object": {
      "id": "pi_example",
      "amount": 1000,
      "currency": "usd"
    }
  }
}

2. Add a Paths Step

Add Paths immediately after the Trigger. Rename the default routes so Audit reads as an operational decision instead of “Path A” and “Path B.”

Payment succeeded

Use a Custom rules Path:

trigger.type exactly matches payment_intent.succeeded

Add Actions that should occur after confirmed success, such as notifying a fulfillment channel or updating a business record.

Payment failed

Use another Custom rules Path:

trigger.type exactly matches payment_intent.payment_failed

Add recovery Actions, such as alerting support or recording the failed PaymentIntent ID and failure context.

Fallback

Set the last Path to Fallback. It runs only when no earlier Path ran. Record or alert on the event type so newly added subscriptions do not disappear silently.

3. Map Stripe data

Map provider fields with the picker. Common values include:

• trigger.id — Stripe event ID.
• trigger.type — event type used by Paths.
• trigger.livemode — test or live mode indicator.
• trigger.data.object.id — the affected Stripe object.
• trigger.data.object.amount and currency when present for that object type.

Stripe event objects differ by type. A field present on a PaymentIntent may not exist on an Invoice, Checkout Session, dispute, or subscription. Put event-type checks before type-specific mappings.

4. Test every route

Use Stripe test mode to produce one success event and one failure event. Verify in Workflow Audit that:

• The Trigger type matches the intended test.
• Exactly the intended custom Path ran.
• Steps on the other custom Path were skipped.
• The fallback did not run for known events.
• Mapped IDs, amounts, and currency match the Stripe test object.

Then temporarily include or send a third subscribed event and confirm the Fallback route runs.

Avoid duplicate side effects

Stripe can retry webhook deliveries. Workflow Actions can also retry temporary failures. Include the Stripe event ID or object ID in downstream records and make side-effecting receivers idempotent.

Before manually replaying or repeating a failed Action, verify whether the downstream provider completed the operation but the response was lost.

Test mode and live mode

Use trigger.livemode as an additional condition when one connected account or broad Source can expose both contexts. Keep destructive live Actions behind explicit conditions and test the same graph with controlled events before enabling them.

Error handling

Connect one error route from each critical Action to an alert or durable record. Filter the normalized error code when retry exhaustion, permissions, invalid mappings, and provider validation failures need different operator responses.

Continue with Paths and conditions, Error handling, and Runs and errors.