Your best flow never fires.

06 Jul 2026 · Stam · 6 min read

You built the post-purchase flow. The trigger is Placed Order, the emails are written, the flow is live. Three weeks later the analytics show zero recipients. The store is taking orders every day.

I see this in audits more often than any copy problem, and it almost always traces back to the same place: the payment gateway.

The event chain nobody looks at

Klaviyo doesn’t watch your store. It watches events your store platform sends it. For a Placed Order flow to fire, this whole chain has to hold:

1. The customer pays.
2. The gateway tells your store platform the payment succeeded.
3. The platform changes the order status to something it considers “placed.”
4. The platform’s Klaviyo integration fires the Placed Order event.
5. The flow trigger catches it.

Steps 1 and 5 get all the attention. The break is usually in steps 2–3.

Standard card gateways (Stripe, Shopify Payments, PayPal Express) confirm payment synchronously — the order lands as processing immediately and the event fires. But a whole class of payment methods doesn’t work that way: bank e-transfers, manual invoice payment, cash on delivery, buy-now-pay-later providers with delayed capture, crypto with confirmation windows. These create the order in a pending or on-hold state and only move it forward when a human or a delayed callback confirms the money.

On WooCommerce, most Klaviyo event firing hangs off the processing/completed status transitions. An order that sits in on-hold and then gets bulk-updated by a fulfilment plugin can skip the transition hook entirely. Result: real revenue, no Placed Order event, silent flow.

I spent a week inside exactly this on a client whose regional payment method settles by manual bank transfer. Orders came in on-hold, staff confirmed payments in batches, a custom plugin flipped statuses directly in the database — and the status-change hook Klaviyo’s integration listens for never ran. Every downstream flow starved.

How to diagnose it in ten minutes

1. In Klaviyo, open Analytics → Metrics → Placed Order and check the activity feed. Compare event volume against actual order volume in your store admin for the same day. A gap here ends the investigation — the problem is upstream of Klaviyo.
2. Filter your store’s orders by payment method. If card orders appear in the metric feed and e-transfer/COD/BNPL orders don’t, you’ve found it.
3. Check how the missing orders had their status changed. Manual admin edits and direct database updates by plugins are the classic hook-skippers.

The fixes, in order of preference

Fix the status transition. If a plugin is updating statuses directly, replace that with the platform’s proper status API ($order->update_status() in WooCommerce terms) so hooks fire. This repairs Klaviyo and everything else listening — inventory, accounting, fulfilment.

Fire the event yourself. When you can’t touch the offending plugin, send the event server-side via Klaviyo’s Events API on the transition you can observe. A small snippet hooked to the right action, posting the order payload with the same metric name and structure the native integration uses, keeps your historical data continuous. Match the payload shape exactly — $value, item array, the works — or your flow filters and revenue attribution drift.

Change the trigger. Sometimes the honest answer is that Placed Order is the wrong trigger for this payment path. A flow triggered on a custom Order Confirmed event you control is more robust than fighting a gateway’s timing.

What I’d avoid: switching the trigger to a segment condition as a workaround. Segment-triggered flows re-evaluate on profile changes, not order events, and you lose per-order data in the flow context. It looks fixed and breaks differently.

The wider lesson

Flows are only as reliable as the events feeding them, and events are only as reliable as your store’s least disciplined plugin. When I audit an account, event integrity comes before anything creative — because a perfect email in a flow that never fires is worth exactly nothing.

If your store takes any payment method that isn’t instant card capture, assume this problem exists until you’ve checked the metric feed yourself.