Plan your payment-provider exit before entry
The cheapest time to understand provider dependence is before customers, tokens, subscription schedules, and reporting history accumulate inside it.
The short version.
- Customer export does not imply that payment credentials, active mandates, subscriptions, or tax evidence are portable.
- Keep your own stable customer, product, entitlement, and order identifiers alongside provider IDs.
- A credible exit includes dual-running, reconciliation, rollback, customer communication, and a plan for records that cannot move.
Inventory the provider-owned state
List customers, legal entities, products, prices, coupons, subscriptions, invoices, payment methods, mandates, balances, payouts, disputes, tax evidence, receipts, webhooks, and reports. Mark which records are authoritative for product access and accounting.
Export access can differ from migration access. A dashboard CSV may help reporting without being sufficient to recreate active billing elsewhere.
Payment credentials need a controlled transfer
Raw card data should not pass through your ordinary systems. Processor-to-processor transfers can require provider cooperation, destination approval, secure channels, and matching customer records. Wallets and local payment mandates may not transfer in the same way.
Ask about token portability, export eligibility, fees, lead time, supported destinations, and what happens if the account is restricted or the relationship has ended.
Subscriptions are schedules plus promises
An active subscription includes price, currency, interval, quantity, billing anchor, trial, discount, tax behavior, collection method, payment credential, cancellation state, and sometimes usage or future phases. Recreating only the customer and plan name is not enough.
Preserve legacy pricing and promised terms. Decide whether the migration transfers credentials and schedules, keeps existing subscribers on the old provider, or asks customers to re-enter payment details.
Own the product state
Use internal IDs that remain stable when providers change. Keep a provider mapping layer and derive entitlements from a durable internal policy rather than scattering provider-specific plan IDs throughout application code.
Store webhook events or normalized business events with idempotency and processing status. During migration, compare old and new systems without granting duplicate access or charging twice.
Design the cutover and rollback
A migration plan needs freeze points, delta exports, mapping validation, test customers, canary traffic, monitoring, reconciliation, customer communication, support scripts, rollback criteria, and cleanup timing. Do not cancel the source system before the destination state is verified.
Some records will remain in the source for statutory, accounting, dispute, or support reasons. Define read-only retention and access before closing the account.
Decision checklist.
- Obtain sample exports for every critical record type before signing.
- Confirm payment-token and mandate transfer rules in writing.
- Keep stable internal customer, product, order, and entitlement IDs.
- Test a representative subscription mapping including legacy edge cases.
- Write cutover, reconciliation, rollback, and record-retention procedures.
How this shows up in real businesses.
These are anecdotes and first-party accounts, not policy evidence. Use them to discover questions worth verifying.
The account holder reports that funds entered a reserve after a creditor action, illustrating that payment availability can be affected by legal and account events beyond ordinary processing risk.
The facts are self-reported and unusually specific; the story should not be generalized into a claim about typical Stripe reserves.reddit · first personA founder reports an unexpected Paddle account blockA founder describes an account restriction after deliberately choosing an MoR, reinforcing the need to understand product eligibility, review processes, cash exposure, escalation paths, and exit options.
This is one disputed account with only the poster's version available; it is a risk prompt, not evidence of provider-wide behavior.founder blog · first personA solo founder recounts two weeks migrating from Stripe to PaddleThe founder describes the implementation and operational differences encountered while replacing a direct Stripe integration with Paddle's Merchant of Record model.
This personal account has not been independently verified and may omit product-specific constraints or later platform changes.engineering blog · provider authoredPaddle describes migrating more than a million subscriptionsPaddle's engineering team explains how an initially manual migration process evolved into self-service workflows across incompatible billing architectures and a large subscription population.
This is provider-authored engineering material about Paddle's own migration and highlights its chosen framing and success metrics.company blog · provider authoredChargebee outlines a staged Stripe Billing migration frameworkThe vendor describes discovery, schema mapping, sandbox migration, delta syncs, phased or cold cutover, validation, reconciliation, and rollback safety as distinct migration workstreams.
The framework is useful operationally but is also vendor marketing and includes customer outcomes that were not independently checked here.engineering blog · provider authoredPaddle explains rebuilding its billing platform around new primitivesThe engineering narrative shows how platform object models, APIs, subscriptions, developer experience, and legacy compatibility can become long-term architectural constraints for both provider and customer.
This is Paddle's account of its own product evolution and should be read alongside current documentation and customer experience.Review the evidence.
- Stripe subscription migration stagesReviewed 2026-07-27
- Stripe API subscription migrationReviewed 2026-07-27
- Paddle migration overviewReviewed 2026-07-27