What the integration actually does
Recharge holds the subscription: the plan, the frequency, the next charge date, and every charge attempt against it. Klaviyo holds the customer relationship and sends the messages. The integration is the bridge, and it runs in one direction — Recharge publishes events and properties into Klaviyo, and Klaviyo does not write anything back.
Once it is on, Klaviyo gains a set of subscription metrics it cannot see through the Shopify integration alone: a subscription being created, activated or cancelled, a charge upcoming, a charge failing, a charge recovering. Those are the triggers for the flows that actually move subscription revenue — the dunning sequence, the renewal reminder, the pre-cancellation save, the win-back.
It is worth being precise about what this changes, because the common assumption is wrong. Turning this on does not give you subscription flows. It gives you the triggers for subscription flows, and it simultaneously creates three new ways for your existing flows to misbehave. The setup below takes about an hour. The section after it is the part that takes a fortnight if you skip it.
Before you start
- Know which Recharge model you are on. Legacy Recharge Checkout and Shopify Checkout Integration (SCI) create the order record in different places, which decides whether your renewal orders arrive in Klaviyo as ordinary Shopify orders. If you are unsure, Recharge vs Skio explains how to tell them apart, and the same test applies here.
- Have the Klaviyo–Shopify integration already live and settled. This integration sits on top of it. Connecting both at once makes it impossible to tell which system produced which profile when something looks wrong.
- Write down every transactional message a customer currently receives, and which system sends it. You will need this list at step 4, and it is much harder to reconstruct afterwards.
Setting it up, step by step
- Create a dedicated Klaviyo API key. In Klaviyo, open the account settings and generate a private API key named for Recharge, alongside your public API key (the site ID). A key named for one integration can be revoked without taking anything else down — a shared key cannot.
- Enable the integration in Recharge. In the Recharge admin, open the integrations list and select Klaviyo, then paste both keys. The exact menu label has moved between Recharge admin versions, so navigate by search rather than by a screenshot. Menu path to confirm against the current admin
- Choose which events to send. Enable the subscription lifecycle events and the charge events at minimum. Send everything you might plausibly want later — an event you are not using costs nothing, and an event you did not enable did not happen and cannot be recovered.
- Decide who owns each notification, before you build a single flow. Recharge sends its own transactional emails: upcoming charge, charge failed, card expiring, subscription cancelled. Klaviyo can now send all of the same things. Go through the list you wrote down and name exactly one owner per message, then switch the others off in the system that sends them. Suppressing a Klaviyo flow does not stop a Recharge notification.
- Confirm events are arriving. Place a real test subscription, then open Klaviyo’s metrics view and look for the Recharge metrics. Nothing appears before an event actually fires — the integration does not import history, so an empty metric on day one is expected and an empty metric on day three is a problem.
- Build each flow on the correct trigger. The dunning flow triggers on Recharge’s charge-failure metric, not on anything from Shopify. The renewal reminder triggers on the upcoming-charge metric — and see failure three below before you add a time delay to it.
- Exclude renewals from your acquisition flows. Every renewal creates an order. Any flow triggered on a placed-order event will fire for every subscriber, every cycle, unless you add a filter that excludes orders carrying the subscription selling plan or tag. Do this before you turn the integration on, not after the first billing day.
The three things that break
The profile splits in two
- Symptom
- A subscriber gets the dunning email at one address and the newsletter at another. Consent looks wrong. A flow filter says the profile has no orders while Shopify shows eleven. Unsubscribes do not seem to stick.
- Cause
- Two systems create profiles. Klaviyo’s Shopify integration builds one from the Shopify customer; Recharge sends events keyed to the email on the subscription. When those diverge — a customer changes their email in the subscription portal but not in their Shopify account, checkout used a different address than the account, an agent edits one side inside the helpdesk — you get two profiles, each holding half the history. Consent and suppression live on only one of them, which is why the unsubscribe appears to fail.
- Fix
- Name one system as the identity source, and in practice that is Shopify. Make the subscription portal write email changes back to the Shopify customer record, not just to the subscription. Add a scheduled check for profiles that share a phone number or a Shopify customer ID under different emails, and merge them on a rule rather than when somebody complains. And never key a flow filter on a property that only one of the two systems writes.
Everyone gets everything twice
- Symptom
- Two failed-payment emails an hour apart. A welcome series firing at a subscriber on their ninth month. A cancellation confirmation from one system and a win-back from another in the same afternoon. Support tickets that open with “why do you keep emailing me”.
- Cause
- Two things compounding. First, three senders can now send the same message — Recharge’s own notifications, Shopify’s, and your new Klaviyo flows — and enabling the flow does not disable the others. Second, a renewal is an order, so every flow keyed to a first-purchase event re-fires on every billing cycle for every active subscriber.
- Fix
- Keep a written owner map of every transactional message and treat it as part of the build, not documentation. Turn the duplicates off at source, in the sending system’s settings. Then audit every flow with a placed-order trigger and add an explicit filter excluding subscription renewals. The renewal filter is five minutes of work and it is the single most common thing missing from a Klaviyo account we are asked to look at.
Events do not backfill, and the timing is not what you think
- Symptom
- Flows behave strangely for the first month. A segment built on subscription history is empty on day one and half-full on day thirty. The renewal reminder lands at the wrong time — sometimes days early, sometimes after the charge has already gone through.
- Cause
- The integration starts producing events at the moment you switch it on and imports nothing from before. Every segment or flow filter that depends on subscription history is therefore wrong until a full billing cycle has passed. Separately, the upcoming-charge event fires on Recharge’s own notification schedule rather than at a fixed offset you chose in Klaviyo — so a delay added inside the flow stacks on top of an offset that already exists, and the message lands at the sum of the two.
- Fix
- Hold the offset in one place. Either set the notification window in Recharge and send immediately from Klaviyo, or set the window as early as Recharge allows and hold the delay in the flow — never both, and write down which you chose where the next person will find it. For history, backfill what you need through the Recharge API into a Klaviyo profile property before you launch anything that depends on it, or wait a complete billing cycle before you trust a subscription segment.
What syncs, and what doesn’t
| Data | Direction | Notes |
|---|---|---|
| Subscription created, activated, cancelled | Recharge → Klaviyo | Carries the product and frequency as event properties |
| Upcoming charge | Recharge → Klaviyo | Fires on Recharge’s notification schedule, not a fixed offset |
| Charge failed and charge recovered | Recharge → Klaviyo | The correct trigger for a dunning flow |
| Order processed | Recharge → Klaviyo | Overlaps with Shopify’s order event — pick one per flow |
| Subscription properties | Recharge → Klaviyo | Status, next charge date, plan |
| Cancellation reason | Recharge → Klaviyo | Depends on your cancellation-flow configuration; verify in your own account |
| History from before go-live | Neither | No backfill. Use the API if you need it |
| Klaviyo consent and unsubscribes | Not written back | Unsubscribing in Klaviyo does not stop Recharge’s transactional email |
| Klaviyo profile edits | Not written back | Klaviyo is a consumer here, never the source of truth |
| Bundle and box contents | Partial | Line items arrive as event properties; anything deeper comes from Shopify |
| Retry attempt number and decline code | Not exposed | The reason dunning flows are usually blunter than they should be |
Event names and property availability differ between Recharge’s checkout models and have changed across versions. Confirm the exact list against your own Klaviyo metrics view before you build a flow that depends on one. Event list to confirm per account
Advanced: when the native integration isn’t enough
The native integration is built for the average merchant, and the average merchant is not billing thousands of subscribers on a schedule. Four things we build on top of it.
A webhook receiver we own. A self-hosted n8n instance subscribes to Recharge’s webhooks directly, with a queue, a retry policy and a dead-letter path, then posts events into Klaviyo’s API under our own naming. A five-minute outage at either end becomes a delayed event rather than a permanently missing one.
The properties the native events don’t carry. Retry attempt number, decline-code family, days since the last successful charge, subscriber tenure in cycles, projected next reorder date. Once those exist on the profile, flows you could not previously build become ordinary — starting with the one below.
Decline-code-aware dunning. An insufficient-funds decline and a do-not-honour decline are different customer problems with different resolution rates, and they should not receive the same email on the same schedule. That branch does not exist in any native integration, and it is usually the largest single improvement available in a payment-recovery build. The payment recovery page covers what that looks like end to end.
A reconciliation job. A scheduled comparison of Recharge’s charge list against the events Klaviyo actually received, alerting on the difference. A dropped event is silent by definition; the only way to find one is to go looking on a schedule.
All of it is built in your own accounts, documented, and yours if we part ways. If you would rather find out what the current setup is costing before rebuilding anything, that is what the audit is for — or run the arithmetic yourself with the failed-payment calculator.