PayPal migrations are unlike every other provider migration, because there are no card tokens to move. What you hold is a book of billing agreements— standing authorizations to charge a PayPal account — and agreements move by transfer or by re-consent, never by export. I have migrated subscription bases moving $100M+ in recurring revenue; the PayPal cohort is always its own project, and this guide is that project's playbook.
The two paths, and how to choose
Path one: agreement transfer. Where Stripe supports PayPal as a native payment method (Europe is the main case), existing agreements can often be carried across so billing continues without the customer doing anything. This is the renewal-boundary takeover pattern applied to agreements: Stripe takes over at the next cycle, the customer notices nothing.
Path two: re-consent. Where transfer is unavailable — most US-centric setups — the honest answer is that you are asking every PayPal subscriber to approve a new payment method. That word "asking" is why this path is a retention project wearing a migration's clothes.
Most real subscriber bases need both paths at once, split by region and account setup. Size each cohort before you commit to a timeline, because the two paths have completely different durations: transfer is measured in weeks, re-consent in renewal cycles.
Running re-consent like dunning
- Sequence around renewal dates, not campaign dates. A subscriber renewing in three weeks gets a different cadence than one renewing tomorrow.
- One-click update inside the product. Every extra step costs real percentage points of your subscriber base. The email links straight into a prefilled payment update.
- Never retire the old agreement before the new method is confirmed. The old rail keeps billing until the new one demonstrably works. Revenue gaps come from optimistic cutoffs.
- Measure conversion per cohort and per email step, and expect the tail to take months. The subscribers who never respond convert at their renewal moment or not at all — plan the final ask accordingly.
You do not need to become an expert in any of this. Everything on this page is my day job: I run fixed-scope migrations off PayPal end to end — eligibility analysis, the credential transfer, cutover sequencing, reconciliation — while your team keeps shipping product. If you want your plan pressure-tested first, that is a 90-minute clarity call. If you want it done, start with the migration service.
The framework every migration shares
Whatever provider you are leaving, the platform you build is the same five layers: a snapshot mirror so selection never touches production; a selector that is the single source of truth for eligibility; batching with a migration lock and one correlation ID stamped everywhere; the credential transfer covered above; and cutover pinned to each subscription's renewal boundary— the old provider bills the last cycle it owns, Stripe bills the next one, and no customer is ever billed twice or skipped. Reconciliation runs the whole time, counting row states rather than log events, with Stripe's warehouse as the authority for "ever migrated."
I wrote the full treatment — sequencing, reconciliation formulas, the long-tail playbook, and ten field lessons — in the complete migration guide. This page covers what is different about your starting point.
PayPal-specific gotchas
- Agreements have their own failure modes. Cancelled agreements, closed PayPal accounts, and funding-source failures inside PayPal all look identical from outside until you classify them. Bucket them before the campaign, not during.
- Braintree-vaulted PayPal is its own case. If your PayPal runs through Braintree, read the Braintree guide — the agreement portability question has a different starting point there.
- Watch the dispute asymmetry. PayPal buyers dispute inside PayPal; Stripe-processed payments dispute through card rails or Stripe's PayPal integration. Your support playbooks need updating on cutover day, not after the first confused chargeback.
Frequently asked questions
Can PayPal subscriptions be moved to Stripe?
Sometimes directly, always eventually. Where Stripe processes PayPal natively (notably in Europe), existing billing agreements can often be carried over so the customer never re-approves anything. Where that path is unavailable, you run a re-consent campaign: subscribers approve a new payment method before their agreement is retired. The split between those two paths is the first thing to establish.
Does PayPal export card data like other providers?
No, because there is nothing to export: a PayPal payer is identified by a billing agreement, not a card number in a vault. That is why a PayPal migration is a different project from a card migration — the asset being moved is an authorization, and authorizations are moved either by transfer or by asking again.
How do I run a re-consent campaign without losing subscribers?
Treat it like dunning, not like a announcement. Sequence emails around each subscriber's renewal date, offer the payment update inside the product with one click, keep the old agreement billing until the new method is confirmed, and measure conversion per cohort. Rushed re-consent campaigns are where PayPal migrations lose revenue; patient ones lose almost none.
Written by Andrej Dragojevic, Stripe Certified Professional Billing Architect.