How to switch from Stripe without losing customers' cards

The hardest part of leaving any payment processor is not the code. It is the saved cards: a stored payment method is a token that only works with the processor that issued it. Lose those and every subscriber has to re-enter a card, which some of them will not do. The good news is that Stripe has a formal process for handing card data to another processor, and it works.

What transfers, and what does not

The migration, step by step

1. Get approved with the new processor

   Apply and complete underwriting first. Card imports go into an approved merchant account, and you will want production keys ready before the data arrives.

2. Request the export from Stripe

   Contact Stripe support, name the new processor, and send its PCI Attestation of Compliance and PGP public key. For Paydude, email support@paydude.io for the current AOC. Do this early: the queue on Stripe's side is usually the slowest part of the whole migration.

3. Build the new integration in sandbox

   While you wait, swap the payment calls behind your checkout. If you abstract the processor behind one internal interface, the cutover becomes a configuration change rather than a deploy.

4. Export your subscriptions and mapping

   Pull plans, prices, billing intervals and next billing dates from Stripe's API, keyed by Stripe customer ID. Ask the new processor for a mapping from old Stripe IDs to the imported ones; it is how you reattach each subscription to the right card.

5. Import the cards

   Stripe sends the encrypted file to the new processor. Paydude imports it at no cost, usually within 3–5 business days of receiving it.

6. Recreate subscriptions

   Create each subscription on the new platform against its imported card, anchored to the existing next billing date so nobody is charged twice or skipped.

7. Run in parallel

   Send new customers through the new processor first while renewals stay on Stripe. Watch authorisation rates, webhooks and payouts for a week or two before moving anything else.

8. Cut over and keep Stripe open

   Move renewals, then turn off Stripe for new payments. Leave the account open so refunds and disputes on old payments can still be handled — they can arrive for months.

The mistakes that hurt

• Cancelling Stripe subscriptions before the new ones exist. Recreate first, then cancel, or customers are skipped for a cycle.
• Double-charging during the overlap. Make sure a renewal can only fire on one processor. Guard writes with idempotency on your side.
• Forgetting webhooks. Every place your app listens for a Stripe event needs an equivalent. See handling webhooks reliably.
• An unrecognisable descriptor. A new name on a statement causes "I don't recognise this" disputes. Set your billing descriptor clearly and tell subscribers about the change.
• Closing Stripe too early. Old disputes and refunds need somewhere to land.

Is it worth switching?

Work out the annual saving before committing engineering time. The cheaper Stripe alternatives guide prices the gap at different volumes, and the best Stripe alternatives guide helps you pick where to go. If the saving is a few hundred dollars a year, it may not be worth the migration. At tens of thousands, it almost always is.