Can I export my customers' saved card numbers myself?

No, and every processor says so in its own words. The transfer runs processor to processor under PCI rules, encrypted to the receiving side's public key, and you are never a hop on that route. What you can pull yourself is the masked version. Authorize.net's article on downloading Customer Information Manager profiles (article 000001270) lists the fields in that self-serve download and marks three of them: CardNumber is described as "Only the last four digits will be provided," CardExpirationDate as "Will be completely masked," and BankAccountNumber the same way as the card number (checked 10 September 2026). That file is useful for reconciliation and useless for billing anybody. The same article says the route to full card numbers is a support request that starts an export review on your account, which is the point: even leaving, you are asking rather than downloading.

Do my subscriptions come across with the cards?

No. Braintree's data migration overview states plainly that it cannot migrate subscription or transaction information, and that on an import you have to recreate your plans in the Control Panel and create your subscriptions again. Square's import article excludes gift cards, subscriptions and appointments from the process. Stripe's export page says it does not export payment history, subscriptions or other objects. The card migration gives you a payment instrument attached to a customer; the schedule that charges it is a separate build, and every renewal date, trial end and billing anchor in it is something you re-enter or script (all checked 10 September 2026).

What happens to card updates customers make while the migration is in flight?

They are lost, and two processors document it in the same words. Stripe's import page warns that if customers update their payment information with the previous processor in the window between transferring the data and completing the import, those changes are lost, and tells you to change your own update flow to cope. Authorize.net describes the same gap and adds that changes cannot be made on its side either, because the profile ID does not exist yet — though it can run a delta import if required, for records created or changed after the first pass. Braintree caps you at two imports and two exports in total, so the catch-up run is not an unlimited budget: one bulk pass, one delta, and that is the allocation (checked 10 September 2026).

Switching Payment Processors: What Happens to Stored Cards

Q: Do customers have to re-authorise ACH payments when I switch processors?

Treat it as a live question rather than a settled one, because the two sides of it sit at different altitudes rather than contradicting each other. Nacha's Rules put the authorisation between the Originator and the Receiver — that is you and your customer, with the processor a party to neither — and Nacha's consulting blog describes it as defining when you may debit, how much, and how the customer revokes. Braintree's migration overview is a term of its own product rather than a network rule: it takes the position that a customer storing an ACH payment method enters an explicit agreement to be charged only by that processor, and requires merchants to agree to additional legal terms before an ACH migration. Stripe says you and Stripe share responsibility for maintaining proof of authorisation to debit. Neither layer answers the merchant's actual question, which is whether the authorisation you already hold covers a debit originated somewhere else. What all versions do require is that you can still produce the original authorisation and its date, so build that first and confirm the re-consent question with your ODFI and your own adviser before the file moves.

Week two of the migration plan usually says move the saved cards. One line, sitting between two other lines, and it reads like the small one.

It is not a task. It is a request, made by you, performed entirely by two other companies. Card numbers do not move the way records move: no export button, no ZIP in your downloads folder, no CSV to open in a spreadsheet and count rows against the customer list. The file is assembled by the processor you are leaving, encrypted to a key belonging to the one you are joining, and delivered over a route that deliberately excludes you. You request it, and afterwards you repair everything downstream of it. In between, you never see it.

Which is why the usual migration instinct — export, inspect, fix, import — has nowhere to attach here, and why planning as though it does turns a two-week job into a quarter. The first real question is not about your data at all. It is whether the processor you are joining is PCI DSS Level 1, and where it publishes its public key.

The receiving processor has to qualify before anything moves

Stripe's page on requesting a payment data export is the clearest statement of the gate. To meet PCI compliance obligations, it says, Stripe can only transfer card data to another PCI DSS Level 1-compliant payment processor, and it wants two specific things about the receiving side: a current PCI Attestation of Compliance, or a listing on Visa's Global Registry of Service Providers, plus a PGP public key that "must be 4096 bits or greater in length" and "must be hosted over HTTPS on one of the processor's domain names referenced in their AOC or Visa Registry listing" (Stripe docs, checked 10 September 2026).

Read that key requirement again, because it is doing more work than it looks. The key has to live on a domain that appears in the compliance paperwork. A key pasted into a support ticket does not satisfy it. Neither does one sitting on a marketing site. That is the mechanism preventing the file from being routed to whoever happens to be answering the migration email thread.

Every processor states the same gate in its own dialect. Braintree wants an attestation of the receiving service's PCI compliance from a qualified provider before it will request their public key, then encrypts and transmits over SFTP, SCP or FTP over SSL, and adds that protecting the private key afterwards is the receiving provider's responsibility under PCI DSS (Braintree data migration, checked 10 September 2026). Square's help centre says it can only migrate data from another PCI DSS Level 1-compliant processor, that the process "can only be done with the Square account owner and not with any other authorized individuals," and asks you not to email Square "(or anyone) with payment card details or sensitive customer information" (Square support, checked 10 September 2026). Authorize.net publishes its migration key openly, fingerprint printed on the page, and states that it cannot accept data that is unencrypted or encrypted by any method other than PGP (Authorize.net KB, checked 10 September 2026). Leaving Authorize.net runs on the same principle from the other side. The profile download you can run yourself returns masked card data, and the article describing it says that for exporting full PAN data from CIM, account owners need to contact customer support to request the start of the export review and process for their account (Authorize.net article 000001270, checked 10 September 2026). There is a route out; it is a support case, not a button.

So the first task in a processor switch is not technical. It is confirming that the two vendors will talk to each other at all, and doing that before you sign anything with the new one.

What is in the file, column by column

The receiving processor can only import what the sending processor put in the file, and the files are not the same width.

Square, on the way out, sends a five-field CSV. Its export article prints the header row — card_id,pan,expiration,postal_code,customer_id — with sample rows underneath (Square support, checked 10 September 2026). Cardholder name is not in it. Street address is not in it. Postal code is the only address element that travels, which is enough for a partial AVS check and not enough for a full one. Square's own answer to that is a second step: export the customer directory from the Dashboard as a separate CSV so the new processor has something to map names and emails against.

Braintree's export is wider. The documented header list runs from customer identity fields through a full billing address that carries the country four separate ways — name, ISO 3166-1 numeric, alpha-2 and alpha-3 — and includes two columns most merchants have never thought about: credit_card.network_transaction_identifier.identifier, described as a key component for merchant-initiated transaction exemptions under PSD2 and Australian SCA rules, and credit_card.network_transaction_identifier.status, whose documented example value is grandfathered. The format is a GPG-encrypted CSV named MERCHANT_ID_export_DATE.csv.gpg, one row per card, and the page says flatly that no modifications to this format can be made.

Stripe's is an encrypted JSON document with customers nested above their cards, carrying email, description, the default source token and any metadata you attached.

The consequence is asymmetry. Coming out of Braintree you hand the new processor enough to rebuild AVS behaviour and the network transaction history sitting behind your recurring charges. Coming out of Square you hand them a PAN, an expiry and a postal code, and everything else is joined from a second file on your side. Work out which of those two situations you are in before you promise anyone that billing will look identical afterwards.

The bar on the receiving end is lower than people expect, incidentally. Braintree's import page says the minimum fields it needs to import a credit card are the number and the expiration. Import succeeds on very little. Charging successfully afterwards is a different matter, and that gap is why the width of the file matters more than whether the import reported success.

Wallets do not come at all

Two categories are excluded outright, and they are the ones customers use most on phones.

Braintree's overview states that Apple Pay and Google Pay payment methods are excluded from its exports, because those network transactions carry secure tokens that are not transferable between providers. Stripe's export page carries the same exclusion for Link: you cannot transfer payment credentials saved with Link between processors, and Stripe excludes any credentials saved through Link from its exports.

There is no workaround at file level. Those customers enrol again on the new processor, which means the migration is not silent for them — it is a checkout-time event. If a meaningful share of your recurring revenue sits on wallet credentials, that share needs a re-consent message scheduled before cutover rather than discovered after it. Same class of problem as moving an email list and leaving the suppression file behind, which the Mailchimp to Klaviyo write-up covers at field level: the instrument moves, the permission attached to it does not.

The subscription schedule is a second project

Every processor here says the same thing, and each says it somewhere different, which is how it keeps surprising people.

Braintree: it can import and export customer and credit card records, but cannot migrate subscription or transaction information, and on an import you must recreate your plans in the Control Panel and create your subscriptions once the migration is complete (Braintree overview, checked 10 September 2026). Square: the migration of gift cards, subscriptions or appointments data is not supported through this process. Stripe: it does not export your account's payment history, subscriptions or other objects, and points you at the API or Dashboard instead — with a separate Billing migration toolkit for subscription data on the inbound side (Stripe billing docs, checked 10 September 2026). Authorize.net: the article on downloading Customer Information Manager profiles opens by noting that this method will not include Automated Recurring Billing subscription details (Authorize.net article 000001270, checked 10 September 2026).

The card migration gives you an instrument attached to a customer. It does not give you the next charge date, the amount, the trial end, the discount that expires in March, the quantity on a metered plan, or the anniversary that decides proration. Those you reconstruct, and the reconstruction is where the money is — a wrong billing anchor charges someone twice, a missing one charges them never. Pull the schedule out of the old system as its own dated export well before the card file moves, then reconcile afterwards on customer count and total monthly value rather than on whether the import reported success.

Two identifiers change, and everything downstream holds the old ones

After the import, every customer has a new ID and every stored card has a new token. Your database, your invoicing tool, your CRM and your support macros all hold the previous pair.

Each processor hands back a mapping artefact, and they are shaped differently. Stripe sends a choice of CSV or JSON showing the mapped relationship between the old processor's IDs and the imported Stripe object IDs, and its import guide gives the worked example: a customer might be ID 42 in your own database, 1893 at the previous processor, and cus_12345 in Stripe (Stripe docs, checked 10 September 2026). Braintree returns a logfile of the customer IDs and payment method tokens it created, one row per customer with each card on its own row beneath. Authorize.net supplies a mapping file containing the old Customer, Payment and Shipping IDs alongside the new ones, and is direct about the work that follows: you reconfigure your customer records to correspond with the new Profile and Payment Profile IDs. Square creates new customer records for every customer in the file, so if you already had a Square directory, the mapping problem includes deduplicating against records that were there before.

Braintree offers the one escape hatch worth asking about. It can either generate new customer IDs and payment method tokens, or use values supplied by you or your former processor — with a warning to check the existing vault for collisions first. If your own database ID can be carried through as the customer ID, a whole class of remapping disappears. Ask before the export is built, not after.

Anything storing a processor ID outside the processor needs a pass too. Accounting connectors are the usual casualty, because they key on identifiers you never chose; the accounting sync write-up covers what that looks like when it surfaces at reconciliation time instead of at cutover.

The gap in the middle, where updates go to die

Between the moment the old processor builds the file and the moment the new one finishes importing, your customers keep living. Some of them update a card.

Stripe's import guide is explicit: if customers update their payment information with the previous processor in that window, those changes are lost, and it advises changing your site's update process beforehand to prevent errors or billing issues. Authorize.net describes the identical gap and adds the detail that makes it worse — changes cannot be made on the new side either, because the data has not been imported and the new profile ID does not exist yet. It can run a delta import if required, updating information modified since the first pass and bringing in records generated after it. Note the conditional: the catch-up is something you ask for, not something that happens.

Braintree puts a number on the same idea from the other end. You must migrate with no more than two exports: one for the bulk of your customers, one for anyone created while processing switched over. It will not run periodic exports for backup or failover. Two is the entire allocation, which means the catch-up run has to be spent on the real cutover rather than on a rehearsal.

The version of this that costs the most is quiet: leaving the update-your-card page pointed at the old processor during the window, so every customer who dutifully replaces an expiring card writes it into a system that is about to be switched off. Point that page at the new processor first, even while the new processor has nothing in it, and let those customers land as fresh records to reconcile later. A duplicate is cheap. A silently discarded update is a failed charge you hear about from the customer.

ACH is a different object, and the object is the authorisation

Bank debits look like cards with different numbers on them. They are not. What moves is not an account number, it is an authorisation, and the authorisation has law attached.

Regulation E is the floor for consumer accounts. Preauthorised electronic fund transfers from a consumer's account "may be authorized only by a writing signed or similarly authenticated by the consumer," and the person that obtains the authorisation must provide a copy to the consumer (12 CFR 1005.10(b), eCFR, title 12 as of the 8 September 2026 issue, read 10 September 2026). The same section gives the consumer a stop-payment right that is exercised at their bank rather than with you: notice to the financial institution, orally or in writing, at least three business days before the scheduled date of the transfer. It also requires the designated payee or the institution to send the consumer written notice of the amount and date at least ten days ahead whenever a preauthorised transfer will vary from the previous one under the same authorisation.

Nacha's consulting team sets out what a compliant authorisation contains and who it binds: a consumer debit authorisation needs seven essential pieces of information, the Originator must be able to produce proof of authorisation to its ODFI on request, and the authorisation "defines the terms of the agreement between the Originator and the Receiver," including how the Receiver revokes it (Nacha, 3 November 2025, read 10 September 2026). The same article prices the failure: a breach of warranty related to proper authorisation can result in extended returns of up to two years for consumers, plus the first 95 calendar days, and one year for non-consumers — the 95 days counting from the first entry under that authorisation that produced the error.

Now hold that against what the processors say. Braintree's position is that when a customer stores an ACH payment method with a processor, the customer "enters an explicit agreement to be charged only by that processor," and it requires merchants to accept additional legal terms — a Data Protection Agreement addendum, plus a privacy policy naming PayPal as an independent Controller — before it will move ACH data. Stripe says you and Stripe share responsibility for maintaining proof of authorisation to debit as well as verification of the bank account, and that if you migrate accounts yourself it will temporarily allow you to bypass bank account verification only after support has heard how you collect authorisations and how you verify accounts. Its sample call is the detail to notice: the SetupIntent carries mandate_data[customer_acceptance][type]=offline alongside an accepted_at timestamp documented as the date of your customer's original authorisation (Stripe ACH docs, checked 10 September 2026).

Braintree's sentence and Nacha's look like a contradiction. They are better read as two altitudes. Nacha and Regulation E describe what an authorisation must contain, who holds proof of it, and who the two parties are — the Originator and the Receiver, meaning you and your customer. The processor is not a party to it in either text. Braintree's sentence is a term of its own product: a description of what it considers a customer to have agreed to when storing a bank account in its vault, and a condition it attaches to moving that data out. One is a network rule, one is a commercial position, and neither of them answers the question a merchant actually has, which is whether the authorisation you already hold covers a debit originated through a different processor. That is why the answer here is a referral rather than a ruling.

What is not ambiguous is the timestamp. The new processor is not asking whether an authorisation exists. It is asking for its date, per customer, in a field. If your authorisation records are PDFs in a shared drive with no machine-readable date column, build that column before you book the migration — and take the survival question to your ODFI and your own adviser rather than inferring it from a help page.

One more ACH item is new enough to catch a migration mid-flight. Stripe's compliance page states that effective 20 March 2026, Nacha requires e-commerce purchases made through ACH debits to carry PURCHASE in the Company Entry Description, for consumer-authorised online purchases of physical or digital goods using the WEB or TEL SEC codes — and not for services, donations or bill payments (Stripe docs, checked 10 September 2026). On Stripe it lands as a classification setting with three positions — classify automatically, classify everything as goods, or classify nothing as goods — with a per-transaction transaction_purpose override in the Payment Intents API for anyone who sells both. Leave it untouched on a fresh account and Stripe classifies automatically from signals such as your business information: a reasonable guess, made on your behalf, about whether what you sell counts as goods. If you only sell goods, or only services, that is a setting to choose during cutover rather than a guess to audit later.

Book the calendar backwards from the slowest number

Published timings are the constraint everything else has to fit inside, and they run longer than a typical software cutover.

Square says an import can take up to 15 business days from when the encrypted file is received, and that it cannot guarantee completion by a specific date; on the way out, the average export timeframe is up to two weeks, and the request begins with the account owner telephoning support for ownership verification. Braintree publishes no fixed timeline — it says timelines vary with the complexity of your integration and the completeness of your intake materials — and charges no fees for migrations. Stripe runs the process through migrations teams on both sides, starting from an intake form, and puts two numbers around it: your previous processor might take anywhere from a few days to several weeks to hand over the final data, and Stripe then typically imports within 10 business days of receiving correct data (Stripe docs, checked 10 September 2026). Both of those sit before the first successful charge, not after it.

Which gives an order that holds regardless of which pair of processors you are between. Confirm the receiving processor's PCI standing and published key. Ask whether your own customer IDs can be reused as import keys. Export the subscription schedule separately, dated. Repoint the update-your-card page. Book the file transfer with the second export left unspent. Rebuild plans and schedules while the file is in flight. Reconcile against the mapping file rather than the success message. Re-enrol the wallet customers. Only then look at the old account's cancellation date, which has a notice period of its own and belongs on the pre-cancel checklist next to everything else that has to come off the old system before the account closes.

Verified against Stripe, Braintree, Square, Authorize.net, Nacha and eCFR documentation on 10 September 2026, at the pages linked above. Three cautions on reading it. Vendor migration pages are operational documents that get rewritten without a changelog, so the date is the edge of what this page knows. The four processors are cited because they publish their migration mechanics in public, which is a point about their documentation rather than a ranking of their products — nothing above recommends a processor. And the ACH section describes what the Nacha Rules and Regulation E require of an authorisation, not whether yours survives a particular change; that one is for your ODFI and your own adviser. A claim that no longer matches its source can go to the contact form, and the about page sets out why every page carries a date.