Migrations and data moves

3 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

How do I move subscribers from one Stripe account to another?

You cannot do it self-serve — card PAN data belongs to the account that tokenized it. The official path: contact Stripe support and request a PAN data transfer between accounts (both accounts must be verified and in good standing; there are restrictions on cross-merchant moves). Stripe securely copies customer records and card details to the new account. What does NOT transfer: subscriptions, invoices, payment history, coupons, webhook configs, Radar data. You must recreate subscriptions in the new account (typically via API import with backdate_start_to / trial_end tricks to avoid recharging), remap every customer id (they change or must be re-mapped), and run both integrations in parallel during cutover. Plan weeks, not days, and keep the old account alive for refunds and disputes.

Migrating from Chargebee/Recurly/paddle to Stripe Billing — what's the plan?

Standard sequence: (1) export customers + payment method tokens from the old provider — most providers coordinate a PAN/tokens export to Stripe via their support, similar to account-to-account transfer; (2) import customers and payment methods into Stripe, building an old_id → new_customer_id mapping table; (3) recreate subscriptions with billing_cycle_anchor / backdate_start_to set to the NEXT already-paid renewal date so nobody gets double-billed, and proration_behavior none; (4) cut over webhooks and disable subscription creation in the old system; (5) run parallel read-only reconciliation for one billing cycle. The classic bug: importing with the anchor = now, charging everyone a second time. Cancel old-platform subscriptions only after confirming the Stripe invoice schedule.

Why do my local subscription records drift from Stripe over time?

Because you mirror state from webhooks, and webhooks are lossy in practice: endpoint outages, disabled endpoints, missed event types after you add a feature (e.g. you never handled customer.updated), and ordering bugs all accumulate drift. The fix is periodic reconciliation, not more webhook handling. Nightly or weekly job: list active/trialing/past_due subscriptions from the API (paginated, created filters), diff against your database on status, price, quantity, period end, and repair or alert on mismatches. Use Stripe as the source of truth — never the other way around. Also reconcile money separately: match payout amounts to balance transactions (see reconciliation note) so accounting catches what subscription-state checks miss.

Give your agent this brain