For the complete documentation index, see llms.txt. This page is also available as Markdown.

Migrating to FlyCode from Paddle Retain, Churnkey or Churn Buster

Migrate to FlyCode from Paddle Retain, Churnkey's recovery module or Churn Buster: what to turn off, the cutover order, and what to expect in week one.

TL;DR: Switching recovery tools is mostly a sequencing problem: measure your current baseline, install FlyCode in monitoring mode, align the platform settings (native retries and emails off), then turn off the old tool's retries and dunning on the same day FlyCode goes live so no customer is contacted twice and no card is retried by two systems. Cancel-flow features (Churnkey) can stay; only the failed-payment module moves. Expect measurable lift within one to two billing cycles.

By the FlyCode team. Last reviewed September 2026.

Before you start: the baseline

Export the last 90 days from your current tool and from your processor: failed invoices, recovered invoices, days to recovery, emails sent, and cancellations for non-payment. Compute recovery rate as recovered failed invoices divided by failed invoices, both by count and by amount. This is the number FlyCode is measured against, and the free payment audit during onboarding produces the same view from your processor data so the two can be reconciled.

The general order of operations

  1. Install FlyCode in monitoring mode. Stripe: install the app from the Stripe App Marketplace (guide). Shopify: connect through Recharge or Skio (guide). Braintree or PayPal: create the API user. FlyCode reads failures and builds your model while the old tool still runs.

  2. Prepare emails. Recreate your branded templates in FlyCode (from your domain, at customer local time). Copy wording that performed well; drop steps that duplicated retries.

  3. Align the processor. Turn off the processor's own automatic retries and failed-payment emails (Stripe Billing settings, Recharge payment settings, Skio dunning settings) so one engine owns the schedule.

  4. Cut over. On the chosen day: disable the old tool's retries and dunning, then switch FlyCode from monitoring to recovery. Do both within the same hour.

  5. Watch week one. Check the FlyCode dashboard daily for attempts per recovery, outreach volume and any invoice that received both an old-tool message and a FlyCode message (there should be none).

  6. Keep the old tool's account open read-only for 30 days for historical exports and comparison, then close it.

From Paddle Retain (formerly ProfitWell Retain)

What changes: Retain adds fixed-interval retries (typically three to five) on top of Stripe's native retries and runs an email-heavy dunning cadence. FlyCode replaces both layers with one adaptive schedule.

Step
Where
Note

Export recovery reports for 90 days

Retain dashboard

Baseline, including their reported recovery rate definition.

Recreate email templates

FlyCode

Retain's card-update page is replaced by FlyCode's login-free update link.

Disable Retain's recovery emails and retries

Retain settings

Do this at cutover, not before.

Remove the Retain snippet or integration if it is only used for recovery

Your app

Keep it if you use Retain's other features.

Turn off Stripe Smart Retries and Stripe failed-payment emails

Stripe Billing settings

Required for a single retry engine.

If you bill through Paddle as merchant of record rather than Stripe, recovery is controlled inside Paddle; contact FlyCode before planning a migration.

From Churnkey's recovery module

What changes: Churnkey's failed-payment module stacks retries on Stripe's schedule and adds payment walls, emails and in-app prompts. Its cancel flows, pause offers and exit surveys address voluntary churn and can stay.

Step
Where
Note

Export failed-payment recovery data

Churnkey

Separate their dunning-campaign metric from total involuntary churn detected; the second is the baseline.

Keep cancel flows, pause and discount offers running

Churnkey

Unaffected by the migration.

Disable the failed-payment module: retries, dunning emails, payment walls

Churnkey settings

At cutover. In-app payment walls can be replaced by FlyCode's outreach or kept if they do not send their own retries.

Turn off Stripe Smart Retries and Stripe emails

Stripe Billing settings

Same single-engine rule.

Many teams run Churnkey for cancellations and FlyCode for failed payments in parallel; the two layers do not conflict once the recovery module is off.

From Churn Buster

What changes: Churn Buster is a communications tool (email and SMS dunning) that relies on the processor or subscription app for retries. FlyCode adds the retry engine and backup payment methods and replaces the messaging.

Step
Where
Note

Export campaign and recovery data

Churn Buster

Their recovery figure is campaign-based; compute your overall failed-invoice recovery rate from the processor for the baseline.

Recreate email and SMS templates

FlyCode

Carry over SMS consent records; do not re-ask customers who have opted in.

Disable Churn Buster campaigns

Churn Buster

At cutover.

Turn off native retries and emails in Recharge, Skio or Stripe

Platform settings

See the platform guides for exact toggles.

Shopify merchants moving from Churn Buster typically see the largest change from retries and backup cards, which Churn Buster did not provide.

What to expect in week one

  • Retry volume per failed invoice goes down, not up; recovery comes from timing and backup methods rather than more attempts.

  • Email volume drops because soft declines are recovered silently before any message is sent.

  • Recoveries appear in your processor as normal paid invoices; the FlyCode dashboard attributes them by method (retry, backup card, outreach).

  • Lift becomes visible within one to two billing cycles once the pre-cutover cohort has aged out of the recovery window.

FAQ

Can I run the old tool and FlyCode side by side for an A/B test?

Only if the split is by customer, not by invoice, and each customer is touched by exactly one system. Most teams instead compare FlyCode's first 60 days with the 90-day baseline, which avoids the auth-rate risk of two engines.

Will customers notice the switch?

They should notice fewer emails. Templates come from your domain in your voice, and silently recovered payments show up as normal receipts.

What if my contract with the old tool has not ended?

Run FlyCode in monitoring mode until the contract allows the cutover; the model trains on your data in the meantime.

Was this helpful?