Skio Subscriptions: Why Payment Tokens Make Migration Hard

What to check before you evaluate Skio subscriptions

Skio subscriptions come up in this evaluation because a merchant is already running a subscription programme on Shopify and is either starting fresh or moving off a platform they’ve outgrown. Before you look at any specific app, get three facts from your current setup: how many active subscribers you have, which payment processor issues their stored payment method, and what percentage of your monthly recurring revenue those subscriptions represent. Those three numbers decide whether a migration is a weekend project or a quarter-long one.

This article is written for operators at roughly $3M to $30M in revenue on Shopify Plus or a comparable paid subscription platform, evaluating or migrating to Skio as one option among several. If you’re pre-revenue or running under a few hundred thousand dollars a year in subscription volume, the migration risk described here doesn’t apply at your scale yet, and a simpler tool will serve you better. If you’re already deep into a custom checkout build with a payments team on staff, this is also not written for you: you have more control, and more to lose, than the general case covered here.

Don’t take vendor claims about setup time or migration effort at face value from a sales call. Ask specifically how the vendor handles token migration for your processor, and ask for a reference merchant who moved from your current platform, not a generic one.

Where Skio subscriptions sit on Shopify checkout

The category Skio competes in is built around one architectural choice: sell subscriptions through Shopify’s own checkout rather than routing the subscriber to an app-hosted page. That distinction matters more than it sounds. A hosted checkout page, the older pattern in this space, takes the subscriber off Shopify’s checkout entirely, which means it can’t inherit Shopify’s fraud tools, saved payment methods, or any checkout customisation you’ve already built. Selling through native checkout keeps the subscriber inside the flow you’ve already paid to optimise, and it’s the direction the subscription app category has moved as Shopify’s checkout extensibility has opened up.

Confirm the specifics of how this works today directly with Skio rather than from an old blog post or app-store screenshot, because checkout extensibility itself has been a moving target on Shopify and any specific mechanism (a checkout UI extension, a cart transform, a subscription-specific line item) can change between what a vendor built two years ago and what they ship now.

What this buys you operationally: one checkout to maintain instead of two, one place to test a discount code or a shipping rule, and one set of checkout analytics instead of a split between “subscription checkout” and “one-time checkout.” What it doesn’t buy you automatically is control over the checkout’s appearance beyond what Shopify’s checkout extensibility framework allows — if your brand relies on a highly custom checkout experience, verify what’s actually editable before assuming parity with a fully hosted page.

How to set up passwordless subscriber management

A passwordless portal is now close to table stakes in this category: instead of asking a subscriber to remember a password, the platform sends a link by email or SMS that logs them straight into their account. The subscriber clicks, lands on a page showing their upcoming order, payment method and plan, and can pause, skip, swap or cancel from there without a support ticket.

Set this up in order:

1. Decide the primary contact channel. Email is the default for most merchants; SMS is faster but costs more per send and needs a separate opt-in. Pick the channel your subscriber base actually checks, not the one that’s cheapest to send.
2. Set the portal’s self-service permissions. Most platforms let you choose, independently, whether a subscriber can skip a shipment, swap a product, change frequency, or cancel outright from the portal, versus routing that action to your support team. Cancel-anywhere is the setting that most affects your retention numbers, and it’s worth deciding deliberately rather than accepting the default.
3. Configure the link’s expiry window. A magic link that never expires is a security problem; one that expires too fast generates support tickets from subscribers who didn’t click it in time. There’s no universal correct value here — it depends on your send frequency and support capacity, so test a window and watch the “expired link” complaints before locking it in.
4. Brand the portal and the transactional emails. An unbranded portal reads as a third-party page to a subscriber who doesn’t recognise it, which increases the odds they treat a legitimate billing email as spam or phishing.

The step teams skip here is testing the portal from a subscriber’s actual inbox, not an admin preview. A magic-link email that renders fine in a testing tool can still get clipped, delayed or filtered differently depending on the subscriber’s email provider.

What self-service does to your cancellation rate

The portal actions matter individually, not just as a bundle called “self-service.” Skip, swap and pause each interrupt a different reason a subscriber was about to cancel, and a portal that only offers cancel treats all three the same.

• Skip a shipment. A subscriber who’s overstocked, going on holiday, or just doesn’t need the next box yet will cancel outright if skipping isn’t available, because cancel is the only button that stops the charge. Skip gives that same subscriber a way to stay subscribed while doing nothing this cycle, and it’s the single action most likely to convert what would otherwise be a permanent loss into a temporary pause in shipments.
• Swap the product. A subscriber whose preferences changed, a flavour they’re tired of, a size that no longer fits, a formulation they’ve outgrown, cancels if the only options are “keep getting the same thing” or “stop.” Letting them swap inside the same subscription keeps the relationship and the billing relationship intact, instead of forcing them to cancel and start a new one-time order elsewhere.
• Pause without a hard end date. Distinct from skipping a single shipment, a pause suspends billing and shipping entirely for a subscriber who isn’t ready to commit to “resume next month” but also isn’t ready to cancel. Not every platform in this category offers pause as separate from skip and cancel; confirm which of the three Skio supports before assuming a subscriber has the option a competitor’s portal gives them.

The common thread is that each of these keeps a subscriber inside the subscription rather than pushing them to the only alternative a limited portal offers, which is cancel. A support team handling these requests manually can, in principle, offer the same flexibility a phone call at a time, but that only works at the volume a person can handle; past a few hundred subscribers, the requests that don’t reach a human become cancellations that a self-service option would have caught. Whichever combination you enable, the setting is also a support-load setting: every action a subscriber can complete alone is a ticket your team doesn’t get, and a portal that’s too restrictive shows up as ticket volume before it shows up in the churn number.

How to configure dunning and failed-payment handling

Dunning is the retry-and-recovery sequence that runs when a subscriber’s card is declined, and it’s the single highest-leverage setting in a subscription platform, because failed payments are a bigger source of churn than most teams assume. Stripe reports that roughly 25% of lapsed subscriptions trace back to a payment failure rather than a deliberate cancellation, and Baremetrics puts the revenue impact at ~9% of monthly recurring revenue lost to failed payments industry-wide. Paddle and ProfitWell’s estimate that 20–40% of subscription churn is involuntary, meaning the subscriber didn’t choose to leave, points the same direction: the retry logic you configure is doing real retention work, not a background technical detail.

A dunning sequence generally has three parts, each of which is a setting, not a fixed behaviour:

• The retry schedule. When and how many times the platform re-attempts the charge after a decline. Retrying too soon repeats the same decline (many card declines resolve only after a day or two, when a subscriber has topped up a debit account or a temporary hold clears); retrying too late loses more subscribers to a lapsed subscription before recovery.
• The subscriber notification. An email or SMS asking the subscriber to update their card, sent alongside the retries rather than only after they’re exhausted. This is the step that turns a silent decline into a recovered payment, because a subscriber often doesn’t know their card failed until you tell them.
• The grace period before cancellation. How long the subscription stays active while retries run, versus auto-cancelling on the first decline. A grace period protects revenue but has to be balanced against the cost of shipping product to a subscriber who ultimately doesn’t pay.

The setting most teams leave on the vendor’s default, without ever opening the configuration screen, is the retry schedule’s timing. The default is built for an average merchant, not yours, and your card mix (debit-heavy versus credit-heavy, prepaid versus standard) changes which retry timing actually recovers payments. Check the current default and the adjustable range directly in the platform, since specific retry counts and intervals vary by vendor and change over time.

How to plan the payment token migration

The token migration is the part of a subscription platform switch that gets underestimated, and it’s the proprietary element of this article: the app itself is rarely the hard part of moving to Skio or any comparable platform. The hard part is the subscriber base you’re bringing with you, specifically the payment tokens attached to each active subscription.

A subscription platform never stores a raw card number. It stores a token, issued by a payment processor, that represents a specific card on file for a specific merchant account. That token is typically scoped to the pairing of processor and platform that created it. When you change subscription platforms, the new platform usually can’t simply read the old platform’s tokens and start charging against them, because the token was never issued to the new platform in the first place.

There are three broad outcomes when you migrate, and which one applies to you depends on your specific processor and both platforms’ migration tooling, not on anything general you can assume in advance:

• A processor-level migration path exists. If both the old and new platform sit on the same underlying payment processor, and that processor offers a merchant-of-record or token-portability path, tokens can sometimes move without the subscriber doing anything. This is the best case and the one to ask about first.
• A re-authorisation flow is required. Where a direct transfer isn’t available, subscribers are prompted, typically by email, to click through and confirm or re-enter their payment method on the new platform. This works, but it’s an action the subscriber has to take, and not every subscriber takes it before their next scheduled charge.
• No automated path exists. In the least favourable case, subscribers who don’t re-authorise before a cutoff date simply fail to bill on their next cycle, which shows up as involuntary churn with no obvious cause in your reporting unless you specifically tag it as migration-related.

Before committing to a migration date, get a written answer from Skio (or whichever platform you’re evaluating) about which of these three paths applies to your specific processor, and ask what percentage of tokens they’ve seen transfer automatically in past migrations from your current platform. If they can’t or won’t give you a number, treat that as a signal to migrate a small cohort first and measure it yourself rather than the whole base at once.

Prepaid and gift subscriptions are the edge case a token-migration plan built around recurring billing usually misses. A prepaid subscription, three boxes paid up front, delivered monthly, isn’t charged again until the prepaid term runs out, so it may not touch the payment token at all during a migration window, which makes it easy to assume it “just carries over” along with the token-based subscriptions. What actually has to move is the fulfilment schedule: how many boxes are still owed, on what cadence, tied to an order that was paid in full on the old platform. If the new platform doesn’t import that remaining-boxes count correctly, a subscriber either gets billed again for boxes they already paid for, or stops receiving boxes they’re still owed, and both look like a data error to the subscriber even though the token was never the problem. A gift subscription compounds it: the payment method on file belongs to the gift-giver, not the recipient managing the account, so a re-authorisation email meant for “the subscriber” may reach someone who has no card to update and no reason to. Pull a list of active prepaid and gift subscriptions before cutover and verify each one’s remaining-shipment count and correct billing party separately from the standard token-migration check, since neither shows up in a token-transfer-rate number that’s only counting recurring charges.

The step most teams get wrong

The step that causes the most damage in a subscription platform migration is running the full subscriber base through the switch on a single cutover date, instead of migrating a cohort first and watching what happens over a full billing cycle before moving everyone else.

The logic behind the mistake is understandable: a full cutover feels cleaner, and it avoids running two platforms at once. But a subscription base’s payment tokens don’t fail predictably. The failure rate you’ll see depends on your card mix, your processor, and how your specific re-authorisation emails perform, none of which you know with confidence until you’ve actually run subscribers through the new platform. Migrating a small cohort first, an illustrative slice such as one-tenth of your active subscribers chosen at random rather than your most engaged customers, gives you a real failure rate before you’ve put your whole subscriber base at risk.

Watch specifically for: the percentage of tokens that transferred automatically versus needed re-authorisation, the percentage of re-authorisation emails that got opened and completed, and whether the dunning sequence you configured on the new platform actually fired correctly on the first billing cycle. If any of those numbers look worse than you’d tolerate at full scale, you’ve found the problem while it only affected a cohort, not your entire recurring revenue base.

How to verify the migration before cutover

Before you move the remaining subscribers, confirm four things against the pilot cohort’s results:

1. Token transfer or re-authorisation rate. What share of the pilot cohort billed successfully on the new platform’s first attempt, without any manual intervention from your support team.
2. Dunning behaviour on a real decline. If any pilot subscriber’s card was declined during the test window, confirm the retry schedule and notification actually fired as configured, not just that the setting exists in the admin panel.
3. Portal access. Confirm a sample of pilot subscribers can log into the passwordless portal, see the correct upcoming order and payment method, and successfully skip, swap or cancel — each of those is a separate code path, and one working doesn’t confirm the others do.
4. Revenue reconciliation. Match the subscription revenue recognised on the new platform against what your old platform would have billed the same cohort, so a silent under-charge or duplicate charge shows up before it’s happened at scale.

Only after those four checks come back clean is it reasonable to schedule the full migration, and even then, keep the old platform’s data accessible for at least one full billing cycle after cutover in case you need to reconcile a dispute.

How subscription data reaches the rest of your stack

A subscription platform isn’t the end of the data’s journey. A skip, a swap, a failed charge or a cancellation is only useful to the rest of the business if it reaches the email or SMS platform, the helpdesk, and whatever you use for revenue reporting, and that connection is usually built once, at setup, and then never checked again until something looks wrong.

• The ESP. A subscriber who skips a shipment or updates a failing card shouldn’t keep receiving a “your card failed” nudge after they’ve fixed it, and a subscriber who cancels shouldn’t stay in a winback flow meant for someone who’s still active. That depends on the subscription platform firing an event (or updating a customer property) the ESP is actually listening for, not just logging the change on its own side. Confirm which events sync automatically and which need a workflow or a Zapier-style connector built on top, because “the app integrates with your ESP” and “every subscriber action reaches your ESP in real time” are different claims, and vendors are more careful about the second than marketing pages usually are.
• The helpdesk. A support agent looking at a subscriber’s ticket needs to see their subscription status, next billing date and recent portal actions without opening a second tab. If that sync breaks or was never built, agents answer billing questions from memory or by logging into the subscription platform separately mid-conversation, which is slower for the subscriber and more error-prone for the agent. This is also where a failed token migration surfaces fastest: a spike in “why was I charged” or “why didn’t I get my box” tickets is often the first signal that a data sync gap exists, before it shows up in any dashboard.
• Analytics and revenue reporting. Whatever you use to track MRR, churn and LTV needs subscription events to reconcile against actual bank deposits, not just against what the subscription platform’s own dashboard reports. A subscriber marked “active” in the platform but not actually billing successfully (a dunning sequence stuck mid-retry, for instance) can inflate an MRR figure that isn’t backed by real revenue, if your analytics tool is only reading subscription status rather than confirmed payment events.

What breaks when this sync is incomplete isn’t usually visible in the subscription platform’s own reporting, since the ESP, the helpdesk and the analytics tool each only show their own side of the subscriber’s status. A subscriber can look fully cancelled in the subscription app and still be getting billed reminders from the ESP, or look active in the helpdesk and be three failed charges from auto-cancellation with nobody on the team aware. Test each of the three connections with a real subscriber action, not a sample record, before trusting any of them as a source of truth on their own.

The cutover runbook: what runs in parallel

A responsible cutover doesn’t switch billing over on a single date with the old platform turned off at the same moment. It runs both platforms in parallel for a defined window, moves a small share of subscribers first, and only decommissions the old platform once the new one has been billing correctly, unattended, for a full cycle.

1. Freeze new sign-ups on the old platform, but keep it running for existing subscribers, before you move anyone. This stops the subscriber count you’re migrating from growing while the migration is in progress.
2. Run the pilot cohort (see above) on the new platform while everyone else stays on the old one. Both platforms are live and billing simultaneously during this window; nothing about the rest of your subscriber base changes yet.
3. Reconcile the pilot cohort’s first full billing cycle against what the old platform would have charged the same subscribers, matching subscriber-by-subscriber rather than checking only the total, since a duplicate charge on one subscriber and a missed charge on another can net out to a total that looks correct while being wrong for two individual people.
4. Move the remaining subscribers in waves, not in one batch, sized to whatever your support team can absorb in ticket volume if a wave’s token-transfer rate comes in worse than the pilot’s. A wave size chosen for engineering convenience rather than support capacity is how a bad batch turns into a support-queue backlog instead of a contained problem.
5. Keep the old platform’s billing engine live, but not sending new charges, for at least one full cycle after the last wave moves, so a subscriber who disputes a charge or reports a missing shipment can be checked against the record that actually billed them.
6. Only decommission the old platform once every wave has billed correctly for a full cycle on the new one and the data sync to your ESP, helpdesk and analytics has been confirmed, not just configured. Turning off the old platform before that point removes your only record for resolving a dispute about a charge it made.

Subscription platform migrations are, underneath the app choice, a subscription retention problem: every subscriber lost to a failed token transfer or a missed re-authorisation email is retention you’re giving up for reasons that have nothing to do with whether they still want the product. Treating the migration itself as a retention event, worth measuring and worth piloting, is what separates a platform switch that holds revenue flat from one that quietly erodes it. Pointerflow’s subscription retention work starts from that same premise: the platform is a tool, but the churn it causes or prevents is the actual scoreboard. Model what a percentage-point change in involuntary churn is worth to your business with the subscription churn calculator, check where your current churn sits against the DTC consumables churn benchmark, and if you’re past the point where a manual migration checklist is enough, see how this fits the broader operating model for scaling brands.