Stripe Customer Data Copy: Capabilities and Limits
Last updated:
Direct answer: Stripe can copy eligible Customer records and supported saved payment methods from one Stripe account to another. It does not copy Subscription objects, invoices, plans, coupons, events, or logs. Subscription migration is a separate recreation and cutover process.
Stripe calls this a copy, not a move. Source data remains available in the original account.
Current Copy Matrix
Stripe’s current support documentation lists the following:
| Data | Copy status | Important detail |
|---|---|---|
| Customer name, email, phone, and address | Supported | Customer-level fields |
| Customer default payment method | Supported when the underlying method is eligible | Verify the destination default after the copy |
| Customer metadata | Supported | Subscription metadata is a separate object |
| Cards | Supported | Card, Source, and PaymentMethod representations are listed |
| ACH | Supported | Bank-account and PaymentMethod representations are listed |
| SEPA PaymentMethod | Supported | Legacy SEPA Source objects are excluded |
| Subscription | Not copied | Recreate or import in the destination |
| Invoice and charge history | Not copied | Retain appropriate source-account access |
| Product, plan, and Price configuration | Not copied through Customer Data Copy | Prepare destination catalog separately |
| Coupons | Not copied | Recreate and map where supported |
| Events and logs | Not copied | Keep source records for audit and support |
| Bacs PaymentMethod | Not copied between Stripe accounts | Plan customer remediation |
| Connected accounts and guest customers | Not copied | Requires a separate account-specific plan |
Primary source: Data that can be copied between Stripe accounts.
What Happens to Stripe IDs?
Stripe currently states that copied Customer objects keep the same Customer ID in the destination account. Payment-method IDs change even though the copied objects refer to the same eligible payment credentials.
Do not extrapolate this to every object:
- destination subscriptions get new
sub_…IDs; - destination payment methods get new IDs;
- Products, Prices, Coupons, Tax objects, and webhooks are account-specific;
- historical invoices, charges, events, and logs remain source-account objects.
Reconcile the result of the actual copy and migration. Do not make an application cutover depend solely on the expected ID behaviour.
Why Customer Data Copy Is Not Subscription Migration
Customer Data Copy prepares the billing relationship at the Customer and payment-method layer. A destination subscription still needs:
- a destination Customer with a valid default payment method;
- a destination Product and recurring Price;
- quantity and multiple-item configuration;
- billing date, trial, and collection method;
- discount and tax treatment;
- metadata needed by the application;
- a coordinated source-deactivation decision.
Stripe now provides a Billing migration toolkit for importing this subscription configuration from a CSV, including Stripe-to-Stripe use cases. MoveMRR provides an alternative workflow that coordinates mappings, rehearsal, source deactivation, reconciliation, and the buyer/seller audit record.
Can the Copy Avoid Customer Action?
Stripe says customers are not informed when eligible data is copied in the background. That means a migration can often avoid asking every customer to register again or re-enter a card.
It does not guarantee that every future renewal succeeds without customer action:
- the payment method might be excluded from copying;
- the destination Customer might not have a usable default;
- the method might expire or be declined;
- an issuer can require SCA or 3DS authentication;
- legal consent or mandate requirements can differ by payment method and transaction.
Use the customer-action decision table to classify the migration population before cutover.
Operational Checklist
Before the Copy
- Confirm source and destination account ownership with Stripe.
- Identify every payment-method type in scope.
- Separate unsupported methods and guest customers.
- Preserve source account access for history and disputes.
- Prepare the destination account’s business, statement, invoice, tax, and dunning settings.
After the Copy
- Compare Customer counts and actual destination IDs.
- Verify intended default payment methods.
- Sample cards, ACH, and SEPA PaymentMethod cases.
- Export explicit remediation lists for missing or unsupported methods.
- Test the destination payment-update and authentication flow.
- Only then schedule or create destination subscriptions.
Using the Copy with MoveMRR
MoveMRR does not receive raw card numbers and does not replace Stripe’s credential-copy process. It uses the destination Customer state and project mappings to prepare subscription recreation.
A MoveMRR project can then:
- scan and validate the source data;
- map destination catalog objects;
- rehearse and run a dry run;
- create destination subscription objects;
- apply the selected source-deactivation strategy;
- reconcile per-item results and export destination IDs.
Any unsupported payment method remains an explicit follow-up rather than being hidden behind a “no customer action” claim.