What each one actually is
Recharge is the incumbent subscription platform on Shopify and has the largest installed base in the category. That history matters more than any feature, because it means two different Recharge products are live in the wild at the same time.
Older stores run Recharge Checkout, where Recharge hosted the subscription checkout and the payment relationship sat with Recharge’s processing setup rather than with Shopify. Current installs run Shopify Checkout Integration (SCI), where the subscription is a native Shopify subscription contract, the customer checks out on Shopify’s own checkout, and Shopify creates the renewal order.
Work out which one you are on before you read any further, because it changes almost everything downstream: which system creates the order record, which “placed order” event your Klaviyo flows should be listening to, whether Shopify Flow can see a renewal at all, and — most of all — what a migration costs.
Skio was built on Shopify’s native checkout and subscription contracts from the start, so there is no legacy checkout underneath it. It leads on the operational side of subscriptions: a passwordless magic-link customer portal, cancel flows with offers and SMS that a marketer can edit, and a smaller, newer surface area generally. The trade-off is ecosystem depth — materially more third-party apps advertise a native Recharge integration than a native Skio one, so the apps you already depend on are a real part of this decision rather than a footnote.
Both are serious products. Neither of them will fix a retry schedule you have never looked at.
Recharge vs Skio, line by line
| Axis | Recharge | Skio |
|---|---|---|
| Checkout model | SCI on current installs; legacy Recharge Checkout still live on older stores | Shopify’s native checkout and subscription contracts only |
| Where the subscription record lives | In Recharge, mirrored to a Shopify subscription contract under SCI | Shopify subscription contract, with Skio’s layer on top |
| Customer portal | Hosted portal, plus a themed portal for deeper work — usually a developer job | Passwordless magic-link portal, configured rather than coded |
| Cancel flow | Offers and reasons are configurable; anything past that needs the API | Built-in cancel flow with offers and SMS, editable by the team |
| Retries and dunning | Configurable retry schedule and dunning emails, and exposed to your own flows | Configurable retries and dunning — confirm the depth against your retry policy |
| Klaviyo events | Native integration with subscription, charge and cancellation metrics | Native integration; confirm the exact event list against flows you have built |
| API and webhooks | Large documented API, wide webhook coverage, big partner ecosystem | Public API and webhooks; smaller ecosystem, so check each app you depend on |
| Prepaid, bundles, gifting | Broad support including prepaid terms and bundle models | Supported — confirm the specific model you sell before you commit |
| Migration in | Supported, and routinely done from other platforms | Migration from Recharge is a named, well-rehearsed motion |
| Platform fee | — per month | — per month |
| Percentage of subscription revenue | — | — |
| Per-transaction fee | — | — |
| Best-fit signal | Complex catalogue, prepaid, heavy app dependencies, an existing custom portal | Straightforward catalogue, and a team that wants to change things itself |
Every cell marked — is a price we have not re-verified this quarter. Subscription-platform pricing changes without announcement and a stale figure would make the rest of this page worth less, so we would rather print nothing. Check both vendors’ live pricing pages before you build a business case on them. Pricing to confirm before publish
Pricing reality and hidden costs
Both vendors charge in the same shape: a platform fee, a percentage of subscription revenue, and a per-transaction fee. Comparing those three numbers is the easy part, and it is also the part least likely to decide the outcome. Five costs sit underneath them.
Payment processing does not move. Whichever platform you pick, you are still paying Shopify Payments or your gateway on every renewal. A lower platform percentage does not reduce that line, and it is the larger of the two.
The portal is developer time, twice. Anything you do not get out of the box is a build, and then it is a re-build the next time you touch the theme. Price the portal you actually want, not the one in the demo.
The app tax is real. Every app in your stack that integrates natively with one platform and not the other becomes either a custom build or a capability you quietly stop having. Make that list before you take a call with either vendor, not after.
Migration is one-off, but it is not small. See the next section. It is the single largest number in this comparison and it is the one neither pricing page mentions.
And the failed payments dwarf all of it. Around 9% of recurring revenue is lost to failed payments, and 20–40% of all churn is involuntary rather than a decision anyone made (sources: Baremetrics, Paddle / ProfitWell). Against those figures, the gap between two vendors’ percentage fees is a rounding error. Decide on retry behaviour and event surface, then negotiate the percentage — not the other way round.
If you want that arithmetic against your own numbers first, the failed-payment calculator does it in the browser.
Migration: what it actually takes
Migration between subscription platforms is a solved problem in the sense that it happens every week and vendors have teams for it. It is not a solved problem in the sense of being cheap. Six steps, in the order they bite.
- Establish which Recharge model you are on. On SCI, the subscription contracts and the vaulted payment methods already live with Shopify, and the migration is largely a re-platform of the layer above. On legacy Recharge Checkout, the payment credentials sit inside Recharge’s processing relationship, and moving them is a token migration coordinated between both vendors and the gateway. It is done routinely, and it sets your timeline.
- Rebuild selling plans and product mapping. Every plan, frequency, discount and prepaid term is re-created on the other side. SKUs either map one-to-one or somebody spends a week deciding what happens to the ones that don’t.
- Rebuild the portal and the cancel flow. Anything custom is rebuilt, not exported. If you have a themed Recharge portal with bespoke logic in it, this is the largest engineering line in the project and it is worth scoping in detail before you sign anything.
- Re-point every event consumer. Klaviyo flows, SMS, helpdesk macros, analytics, the warehouse feed, and every n8n or Zapier workflow listening for a webhook from the old platform. This is the step that quietly fails after go-live, because nothing errors — flows simply stop firing, and you find out when a subscriber emails to ask why nobody told them their card was declined. Budget a fortnight of actively watching the event stream, not a checklist tick.
- Reconcile what is in flight. Queued charges, scheduled skips, pauses, one-time add-ons and gift subscriptions all exist in the old system on cut-over day. Decide in advance what happens to each.
- Run a full billing cycle before you relax. A subscription platform only reveals itself on renewal day. Compare a complete cycle against the old system’s numbers before you decommission anything.
The vendor’s migration team does the heavy lifting on steps 1 and 2. Steps 3, 4 and 5 land on you, and how big they are depends entirely on how much of your current setup is custom. Scope those three specifically — not the migration as a whole — before you commit to a date.
Who each one is genuinely better for
Recharge is the better answer when
- You sell prepaid terms, bundles, build-a-box or gifting, and the model is load-bearing rather than a side product.
- Your stack depends on several apps whose native integration is with Recharge, and re-building those connections would cost more than the platform difference.
- You already have a customised portal that works, and the people who built it are still reachable.
- You are on SCI, your subscriber base is large, and nobody has yet audited the retry schedule — in which case the platform is not your problem and a migration would be an expensive way to avoid finding that out.
Skio is the better answer when
- Your catalogue is straightforward and your subscription model is simple frequency plus quantity.
- The bottleneck is operational: your team cannot change a cancel-flow offer, a portal string or a swap rule without a developer, and that is slowing down everything you want to test.
- You are still on legacy Recharge Checkout, want to be on Shopify’s native checkout, and have concluded that if you are paying for a migration anyway you should choose the destination on merit.
- SMS is central to your retention plan and you want the cancel path and the SMS in the same product.
Our take
Start by proving the platform is the constraint, because most of the time it isn’t. Failed payments, a retry schedule nobody has revisited, a dunning sequence with one email in it and a cancel flow that offers nothing — all four are fixable where you are, in weeks, for less than a migration costs. Changing platform to change a retry setting is the most expensive way to change a retry setting.
If you have done that work and the platform is still the constraint, the decision is usually operational rather than technical. A platform your marketing team can change without a ticket gets tested more often, and what gets tested is what improves. That is the strongest argument for Skio, and it is a real one.
If you sell prepaid or bundles, or if a handful of Recharge-native apps are doing real work in your stack, stay on Recharge and put the migration budget into the dunning sequence and the cancel flow instead. That is the trade almost nobody regrets.
Whichever way it goes, the expensive part is step 4 above — re-pointing everything that listened to the old system. Plan the migration around that step, not around the data.
Disclosure: Pointerflow takes no affiliate revenue, referral fee or partner commission from Recharge, Skio or any other tool named on this site. We build on both.
Next: n8n vs Zapier for the automation layer underneath, or how to connect Klaviyo to Recharge — including the three things that break when you do.