Subscription Import

Bring active recurring subscriptions from Tebex, CraftingStore, or any other store across to FluxStore without making your customers re-subscribe. Subscription Import attaches an existing Stripe or PayPal subscription that’s already billing on your gateway directly to a FluxStore package, so the next renewal lands in your new dashboard with delivery commands, receipts, and analytics wired up exactly as if the customer had subscribed on FluxStore from day one.

This is the recurring-subscription counterpart to the Tebex and CraftingStore CSV imports, which cover one time purchases. If your old platform had subscribers paying you every month, this is the page you want.

Read this first

In practice this means the first renewal cycle after import is when the customer notices anything has changed. Up until then, your gateway keeps charging on the existing schedule and FluxStore tracks each renewal as it lands.

Where to find it

Open Dashboard > Subscriptions and click Import subscription at the top right of the page. The wizard runs as a dialog over the subscriptions list. The button is gated on the same permission as cancelling subscriptions, so your store owner or admin role can see it.

What the wizard asks for

Import is a two step wizard.

Step 1: identify. Pick a gateway (Stripe or PayPal) and paste the gateway side subscription ID.

• Stripe. Find this under Customers > Subscriptions in your Stripe dashboard. IDs look like sub_1234abcd….
• PayPal. Find this under Activity > Subscriptions in your PayPal dashboard, or on the buyer’s email receipt. IDs look like I-ABCD1234WXYZ.

FluxStore calls the gateway, reads the subscription, and refuses to continue if the subscription has already ended on the gateway side, has no price attached, or has already been imported into this FluxStore store.

PayPal imports also require you to have a PayPal webhook ID configured under Payment Gateways > PayPal first. Without it FluxStore cannot trust incoming renewal notifications, so the import is blocked at the preview step rather than silently leaving you with a subscription that never updates.

Step 2: confirm. The wizard shows a read only summary of the gateway side subscription: plan name, per cycle amount and currency, billing interval, status, customer email, original start date, and how many renewals have already completed on the gateway. Then it asks you to map three things:

• Package. Pick the FluxStore subscription package this should map to. Only packages marked Is subscription and Active appear in the dropdown, because non subscription packages have no billing interval for renewal commands to anchor to.
• Server. The server renewal commands deliver to. Must respect the package’s server allowlist if one is set.
• Player username. The Minecraft username renewals deliver to. The wizard prefills this from the local part of the customer’s gateway email as a suggestion, but you should override it whenever the email local part isn’t the player’s actual username (it usually isn’t).

The wizard also tells you which historical month the import will count toward. The import is backdated to the gateway’s original subscription start date, so a sub that started in March 2025 will count as a March 2025 sale in your analytics rather than landing in the current month.

What gets recorded

On import, FluxStore creates an Order, an OrderItem, an Entitlement, and a Subscription, all marked IsImported = true with ImportSource set to stripe-subscription or paypal-subscription. Specifically:

• Subscription record with the gateway IDs, current period start and end pulled from the gateway, the renewal count carried over from the gateway, and the package, server, and player username you mapped.
• Backdated Order with the original gateway start date as CreatedAt, the per cycle amount, the gateway currency, and the customer email. This is what makes historical analytics line up.
• Customer record. If a customer doesn’t already exist for this email, one is created and the import’s revenue is rolled into their lifetime totals.
• Gateway side metadata. Best effort: FluxStore writes a flux_imported_at marker plus the FluxStore order and package IDs into the Stripe subscription metadata (or the PayPal equivalent) so the link is observable from both sides. If this best effort step fails, the import itself still succeeds and is logged.

No welcome email is sent. The customer already subscribed on the old platform and received their welcome email there; firing a second one from an identity they’ve never seen would read as spam. The first contact from FluxStore is the natural renewal receipt the next time the subscription bills.

The first renewal cycle

When the gateway next attempts to charge:

• If it succeeds. FluxStore receives the renewal webhook, runs delivery commands on the server you mapped, sends the renewal receipt, and increments RenewalCount. The customer notices nothing.
• If it fails (expired card, declined transaction, lapsed PayPal agreement, etc.), the gateway marks the subscription past_due, FluxStore mirrors that status, and a subscription_payment_failed dunning email goes out to the customer asking them to update their payment method. The email points them at your storefront so they can pay the outstanding invoice and re enter a card or relink PayPal. The dunning email is deduped to one per six hours so retries don’t spam them.

Some subscriptions imported from old platforms will renew fine for many cycles because the original card is still valid. Others will fail on the first attempt because the customer changed cards months ago. Plan messaging accordingly.

Verifying the import worked

After committing, the wizard redirects you to the subscription’s detail page. From there:

• Subscriptions list. The imported subscription appears in Dashboard > Subscriptions alongside native ones with the player, package, status, and next renewal date all populated from gateway data.
• Activity timeline. The “Subscription started” entry on the detail page is backdated to the original gateway start, with each prior renewal recorded if the gateway exposed them.
• Sales analytics. Revenue is attributed to the historical month the subscription originated in, not the day you ran the import.

Common pitfalls

• No matching subscription package. The package dropdown is filtered to active subscription packages. If it’s empty, you haven’t created one for this billing tier yet; set it up first under Products, then re run the wizard.
• Package interval mismatch. Nothing stops you from mapping a monthly Stripe subscription to a yearly FluxStore package, but renewal commands will then run on a yearly cadence that doesn’t match the customer’s actual billing. Match the billing interval to the gateway’s reported interval when picking the package.
• Importing the same subscription twice. Both the preview and commit steps reject a gateway subscription that’s already been imported into this store, so the worst case is a clear error message rather than a duplicate record.
• Customers who can’t update their payment method in time. The dunning email gives them a route, but a small fraction will let the subscription expire. Consider an out of band heads up from your old platform’s mailing list a week before cutover telling subscribers a payment update prompt is coming.
• Ended subscriptions. The wizard refuses to import subscriptions the gateway reports as ended (canceled on Stripe, CANCELLED or EXPIRED on PayPal). There’s nothing to take over there. PayPal SUSPENDED is allowed and maps to past_due so you can take over an in flight dunning cycle if you want.
• PayPal without a webhook ID. PayPal imports require the store’s PayPal webhook ID to be configured first. Without it, renewals would never reach FluxStore and the imported subscription would silently stop updating. The wizard blocks this case at the preview step.