Zapier Stripe: Which Payment Events Actually Need a Zap

What “Zapier Stripe” automation is actually for

Zapier Stripe integrations get built for two very different reasons, and mixing them up is where most setups go wrong. One reason is moving money data into other systems: payouts into a ledger, charges into a spreadsheet. The other is reacting to something that happened to a specific payment: it failed, it was disputed, or the subscription behind it lapsed. This article covers the second kind. If you came here for the general workflow-building mechanics, the pricing model, or reconciling Stripe payouts against QuickBooks, that’s a different piece of ground and this isn’t it.

The reason this matters enough to write down: a failed payment or an opened dispute is time-sensitive in a way most Zapier triggers aren’t. A new order landing in your CRM a few minutes late is a shrug. A failed payment sitting unnoticed for three days is a subscription you didn’t try to save, and a dispute you didn’t respond to inside its evidence window is a chargeback you couldn’t contest. The lag matters, and so does not double-reacting when Stripe redelivers the same event.

Operators running $3M–$30M in revenue on Shopify Plus or a comparable subscription platform are this article’s audience, since payment failures and disputes happen often enough to need a process, but not so often that a bespoke payments engineering team already owns this. If you’re processing a handful of subscription charges a month, a person checking the Stripe dashboard weekly probably beats another Zap to maintain. If you’re well past that volume and disputes are a daily occurrence, you’ve likely outgrown Zapier for this specific job and need a payments-side webhook consumer with proper queuing, and that’s worth naming honestly rather than selling you a Zap that will fall over.

Which Stripe events are worth wiring into a Zap

Stripe emits an event for nearly everything that happens to money in your account. Wiring all of them into Zapier is how a team burns through its task allowance reacting to events nobody reads. Three categories earn their own Zap because a specific person is waiting on the other end of each one.

The failed payment event

A payment failure on a one-off charge is usually self-resolving: the customer retries checkout or abandons it, and either way the order record reflects what happened. A payment failure on a subscription is different: no one is sitting at a browser to retry it, so unless something intervenes, the charge just fails again on the platform’s own retry schedule and eventually the subscription lapses. Stripe’s dashboard and its event catalogue distinguish a charge failure from an invoice payment failure on recurring billing, so check the current event names in Stripe’s documentation before you build the trigger, because the exact identifiers have shifted across API versions and a stale name in a tutorial is a Zap that never fires.

Baremetrics puts the figure at ~9% of MRR lost to failed payments across the subscription businesses it tracks (a vendor-reported figure, but a useful sense of scale for why this event gets its own Zap rather than a shrug).

The dispute opened event

A dispute is the customer’s bank telling Stripe the charge is being contested, not a request routed through your support inbox. It carries a clock: Stripe gives you a defined window to submit evidence before the dispute defaults against you. A Zap that fires the moment a dispute opens, and drops the charge ID, the order reference and the evidence deadline in front of whoever owns chargeback response, buys back the days that would otherwise get lost while the notification sits unread in a Stripe dashboard nobody checks daily.

The subscription lapsed event

The subscription lapsed event is the one most teams forget to wire up at all, because it’s downstream of the failed payment, not the payment itself. A subscription doesn’t usually cancel on the first failed charge; it typically moves through a retry sequence first, and only reaches a lapsed or canceled state once those retries are exhausted. Stripe attributes about 25% of lapsed subscriptions to payment failure rather than a deliberate cancellation, and Paddle’s ProfitWell research puts 20–40% of churn as involuntary. That gap between “customer decided to leave” and “customer’s card just stopped working” is exactly where a retention team can still win the account back, but only if something tells them the subscription lapsed before the customer’s mental model of your brand has moved on.

Before you build anything: what you need

• A Stripe account with the events you’re reacting to actually enabled for the connected mode. Test mode and live mode fire different events, and a Zap built against test-mode data will look correct in the editor and do nothing in production.
• A Zapier plan that supports the number of steps your Zap needs. A single trigger-to-action Zap runs on any paid tier; a Zap with a filter step and more than one downstream action needs multi-step support, which is a plan-tier question you should check against Zapier’s current pricing page rather than assume from an older plan name.
• A destination that can hold a “have we already handled this charge” flag. A CRM field, a spreadsheet row or a support ticket property all work. Without somewhere to check that state, the dedupe check in Step 2 can’t run, and every retry becomes a duplicate.
• Someone named to own each event category. A failed-payment Zap that emails a shared inbox nobody is accountable for is worse than no Zap: it creates the appearance of a process without the substance of one.

Step 1: Choose the trigger event and skip “New Charge”

The temptation is to build one Zap off a broad trigger and filter everything downstream. Resist it. Zapier’s Stripe integration exposes specific trigger events for failed payments, disputes and subscription state changes; pick the one that matches the category you’re reacting to, not the generic “new charge” or “updated customer” trigger. A narrow trigger only fires when the thing you care about happens, which means fewer wasted tasks and a Zap history that’s actually readable when you’re debugging it at 6pm on a Friday.

Step 2: Add a filter step so Zapier reacts once, not per retry

Adding this filter is the step most tutorials skip, and it’s the one that decides whether your Zap is trustworthy. Stripe redelivers a webhook event if it doesn’t receive a timely acknowledgement, which means the same event can reach Zapier more than once for the same underlying charge. Add a filter or a lookup step immediately after the trigger that checks whether the charge ID, invoice ID or dispute ID has already been recorded in your destination system. If it has, stop the Zap there. If it hasn’t, continue and write the record. The filter condition is simple to describe and easy to skip building: “continue only if this ID is not already present.” Skipping it is how a support inbox ends up with three identical failed-payment tickets for one charge.

Step 3: Set the idempotency key before the action runs

Idempotency is the property that lets the same input run through a process any number of times and produce the same result as running it once. In a Zapier Stripe workflow, that property doesn’t come from Zapier itself. It comes from the destination action being written to check for an existing record keyed on the Stripe object ID before it creates a new one. If your CRM or spreadsheet action is a plain “create record” step, run it twice and you get two records. If it’s a “create or update” or “find or create” step keyed on the charge or invoice ID, running it twice produces one record, updated. Use the latter for anything reacting to a Stripe event. This is a setting choice inside the action step, not a separate Zap. Look for the field that lets you search on an existing value before writing, and set it to the Stripe object ID every time.

Step 4: Route each event type to a different action

A failed payment, a dispute and a lapsed subscription need different people and different urgency, so route them to different actions rather than one shared notification. A failed payment on a subscription might go to a retention queue with the customer’s plan and retry count attached. A dispute goes to whoever manages chargeback response, tagged with the evidence deadline. A lapsed subscription goes to a win-back sequence or a CRM stage change, not a real-time alert. By the time it’s lapsed, minutes don’t matter the way they do for a dispute clock. Building three Zaps instead of one branched Zap is usually easier to maintain: each one is short enough to read start to finish, and a failure in one doesn’t take the others down with it.

Step 5: Verify the Zap against Zapier’s own history, not your inbox

Once it’s live, don’t verify a Stripe Zap by waiting for a real failed payment to happen. Use Stripe’s test mode to trigger a test event, or use Zapier’s own “test trigger” against a recent real event, and then check Zapier’s task history, not your inbox, for what actually ran. The task history shows you the exact payload the Zap received and the exact output each step produced, which catches a mismatched field or a filter condition that’s slightly wrong before it costs you a missed dispute window. Checking your inbox only tells you the Zap ran; it doesn’t tell you whether the data it wrote was correct.

The step most teams get wrong

Skipping Step 2, the dedupe filter, is the single most common mistake in a Stripe reaction Zap, and it’s rarely caught until volume increases enough for retries to become common. At low volume, a duplicate ticket or a doubled record is an annoyance someone quietly deletes. At the volume where this pattern starts to matter, meaning more failed payments, more disputes and more Stripe retries in absolute terms, that duplicate record shows up in a churn report as two lost customers instead of one, or in a support queue as three open tickets that all need closing individually. The fix costs one extra step at build time. Retrofitting it after a quarter of duplicated data means reconciling which records are real, which is a much worse afternoon.

What a missed dedupe check looks like on a Tuesday

A support lead opens the queue Tuesday morning and finds three tickets for the same customer, all titled some version of “payment failed”, all created within four minutes of each other overnight. Nothing is wrong with the customer’s card beyond the original failure. Stripe redelivered the webhook twice after the first delivery didn’t get acknowledged quickly enough, and the Zap had no step checking whether it had already created a ticket for that invoice. The support lead closes two tickets as duplicates, which costs a few minutes, but the real cost is upstream: whoever reads the weekly failed-payment report now sees three events instead of one, and the retention team’s sense of how often this happens is wrong by a factor of three until someone notices the pattern. None of this shows up as an error anywhere. The Zap ran successfully each time. That’s exactly the problem. A Zap with a dedupe filter in Step 2 produces one ticket, closed once, counted once.

Naming the notification instead of routing to a shared inbox

A Stripe event Zap that ends in “send an email to billing@” is a Zap that will be ignored within a month, because a shared inbox has no single owner and a notification with no owner gets read only when someone happens to be bored. Name the destination as specifically as the event: a failed-payment Zap writes to a field on the customer’s record that a retention workflow already watches, or opens a task assigned to a named role, not a person’s individual inbox that breaks the moment they’re on leave. A dispute Zap should land somewhere with the evidence deadline visible without opening a second system, because the whole value of reacting fast is lost if the deadline is buried in a Stripe dashboard nobody checks until it’s too late. This is a small setting choice: which field, which assignee, which channel. But it’s the difference between a Zap that changes behaviour and a Zap that just generates traffic nobody reads.

Why the payout deposited to your bank never matches the order total

The mismatch between a Stripe payout and an order total generates the most confused Slack messages between finance and whoever owns the Zapier setup, and it isn’t a bug in your Zap. A Stripe payout is a net cash movement, not a running total of gross order values, and three things separate the two.

Processing fees are deducted per charge, before the payout is calculated. Every charge that settles has Stripe’s processing fee subtracted from it, and that fee comes off before the money ever reaches the payout figure. The rate itself varies by card type, currency and your account’s specific pricing, so check Stripe’s current pricing page for your account rather than assume a flat number, since it differs by region and by negotiated volume.

Refunds and disputes are netted against the payout, not tracked separately. A refund issued today reduces a future payout by the refunded amount; it doesn’t create a matching negative line item that’s easy to eyeball against today’s order total. A disputed charge can be held out of a payout entirely while the dispute is open, and reappear, or not, once it resolves.

Payouts batch across a schedule that rarely lines up with a calendar day of orders. Depending on your account’s payout schedule, a single payout can include charges from more than one day, and a single day’s charges can be split across more than one payout. Comparing “yesterday’s orders” to “yesterday’s payout” is comparing two different sets almost by construction.

Here’s an illustrative example, with invented figures purely to show the mechanism; check your own account for actual rates. Say an illustrative order total comes to $100.00. An illustrative Stripe processing fee on that charge might run $3.20, leaving an illustrative $96.80 destined for that day’s payout. If a separate illustrative order of $50.00 is refunded before the payout batches, that charge nets down to an illustrative $46.80, lower still if fees on refunds aren’t returned in full, so confirm the exact refund-fee treatment on Stripe’s current pricing page rather than assume it from this example. The payout that actually lands in your bank account is the sum of every net charge amount in that batch, minus every refund and hold, not a subtotal drawn from Shopify’s order list. Reconciling the two means matching each charge in the payout to its underlying order, deducting the fee, and accounting for anything that moved between order date and payout date: a finance workflow, not something a single Zap step can shortcut.

How to check a payout against a batch of orders

Start from the payout, not the orders. Stripe’s dashboard shows you exactly which charges, refunds and adjustments make up a given payout; pull that list first. Then match each charge back to its order using the charge ID or the payment intent ID, which should already be stored against the order if your checkout flow is wired up correctly. What’s left over after matching is your actual variance: fees, timing differences, and anything genuinely wrong. Trying to work in the other direction, starting from a day of orders and asking why the payout doesn’t match, means fighting the batching logic instead of using it, and it’s the reason “the payout is wrong” tickets take longer to close than they should.

Who this isn’t for

If you’re processing a low number of subscription charges a month, the overhead of building and maintaining three separate event-reaction Zaps likely costs more attention than a person glancing at the Stripe dashboard twice a week. And if disputes and failed payments are already a daily, high-volume occurrence, Zapier’s per-task pricing and its single-threaded Zap execution become a genuine constraint. That’s the point where a dedicated webhook consumer with its own queue and retry logic, built and owned by engineering, is the honest answer rather than a heavier Zap.

Reacting correctly to what Stripe is telling you (without double-firing on a retry, without losing the evidence window on a dispute, without mistaking a payout figure for an order total) is exactly the kind of narrow, rules-based decision that belongs to an automation layer rather than a person’s memory of what to check today. That’s the problem Pointerflow’s AI agents and automation work is built around: not replacing the judgement calls, but making sure the events that need a fast, consistent reaction get one every time, not just on the days someone remembers to look.