Merchants that move stored cards between Authorize.Net’s Customer Information Manager (CIM) and NMI’s Customer Vault can carry card numbers and billing details across, but not the subscription schedules or card-on-file history built on top of them. Support documents from both gateways show the transfer runs through encrypted files and support tickets, and Authorize.Net warns that its export alone can take up to three weeks. For autoship supplement, CBD, and telehealth programs, the gap between the old gateway’s last rebill and the new gateway’s first one is where renewals quietly fail.
Both products work the same basic way. A vault stores the card number on the gateway’s servers and gives the merchant a reference ID, so the store’s own database never holds the full number. That reference ID only works on the gateway that issued it. Moving to a new gateway means moving the underlying card data, not the token.
Getting cards out of Authorize.Net
The download button in the Authorize.Net Merchant Interface will not do it. Authorize.Net’s support article on downloading CIM profiles says the file shows only the last four digits of each card number and masks the expiration date completely. Full card data requires a data extraction request through Authorize.Net Customer Support.
Authorize.Net’s data export article sets the terms. The extraction includes CIM profiles and Automated Recurring Billing (ARB) subscription information, the account owner must approve it, there is a fee, and the export “may take up to 3 weeks.” Authorize.Net copies the data rather than moving it, so the profiles stay on the original account, which should remain open until the process finishes. It also delivers every profile on file at the time of extraction, with no partial exports, and states that the merchant is responsible for PCI compliance and data security once the file leaves.
Getting cards into NMI
NMI’s Data Import, Export, and Transfer article, updated July 2, 2026, says every import, export, or transfer must be started by the NMI affiliate partner that manages the merchant’s gateway and authorized by that affiliate’s primary contact. In practice, the request goes through the merchant’s reseller or independent sales organization rather than a ticket the merchant opens alone.
Incoming card files must be encrypted with NMI’s public PGP key and sent to NMI support, or uploaded by secure file transfer. NMI says it does not audit or filter the file, so the merchant and the sending gateway are responsible for including only the records that should be imported. Each imported record costs the merchant its normal Customer Vault per-transaction fee. The import section mentions only the Customer Vault, and the section on gateway transfers says only cardholder data moves and that NMI “cannot import to Recurring.” Subscription plans have to be recreated, either in NMI’s recurring module or in the store’s own billing engine.
The reverse trip costs more
Merchants leaving NMI for Authorize.Net face a fixed price. NMI charges a non-negotiable $0.50 per record or $500, whichever is higher, to export Customer Vault or recurring subscription data, with a 25-record minimum. The receiving gateway must be Level 1 PCI DSS compliant and provide its Attestation of Compliance, and when the file goes by email, the recipient’s domain must match the one on that attestation. NMI will export a subset if the merchant supplies a CSV of vault or subscription IDs, which helps a brand that wants to leave dormant customers behind.
On the receiving end, Authorize.Net’s import article accepts only a PGP-encrypted CSV sent directly from the old provider using Authorize.Net’s migration key. It imports the file within three to five business days of receipt, then returns a mapping file that pairs each old profile, payment profile, and shipping ID with its new Authorize.Net ID, plus a Remarks column naming rows that failed. Subscription details cannot be imported, so the merchant recreates them from the new customer profiles through the API. If customers change cards while the file is in transit, Authorize.Net can run a delta import to catch up.
Card-on-file history does not ride along
The quieter risk is the network transaction ID. Card networks expect a merchant-initiated charge, such as a monthly rebill, to reference the original customer-authorized transaction that set up the stored credential. Authorize.Net’s card-on-file guide says Visa requires that ID for recurring, unscheduled, resubmission, and reauthorization charges, among others. Customer profiles send it automatically from the first transaction on each payment profile, and the guide lets merchants submit an ID generated by a third-party system, with the warning that Authorize.Net does not validate it.
NMI’s credential-on-file guide asks for an initial_transaction_id on every subsequent stored-card charge and lists a missing one as a common cause of declines. NMI’s API reference describes that field as the original payment gateway transaction ID, and its transfer FAQ says recurring and card-on-file chains are not carried over when card data is copied between gateway accounts. NMI’s public documents do not explain how to reference a transaction that ran on another gateway, so merchants should get an answer from NMI and their acquirer before the first rebill. Mastercard’s Transaction Link ID rules for recurring charges add one more identifier that should survive the move.
Planning the cutover
The documents point to a sequence rather than a single switch date. A practical plan looks like this:
- Book the timeline backward from a billing date. Allow up to three weeks for an Authorize.Net export or the 7 to 10 business days NMI asks for ahead of a transfer, plus import time, before the first renewal that must run on the new gateway.
- Freeze card changes or plan a delta. Card updates made on the old gateway after the export starts will not be in the file. Authorize.Net offers a delta import when it is the receiver. On NMI, plan a second, smaller file or ask customers to update cards after cutover.
- Load the ID map before rebills resume. Every subscription, order, and customer record in the store must point to the new vault ID. Authorize.Net’s mapping file and its Remarks column are the checklist for rows that need customer outreach.
- Run both gateways for a cycle. Authorize.Net already asks that the old account stay active during an export. Keeping it open through one more billing cycle lets a small cohort renew on the new vault first, and pausing automated dunning for that cohort can stop a mapping error from turning into a wave of retry declines.
- Compare decline reasons, not totals. A jump in declines tied to missing vault records or stored-credential flags after cutover points to a mapping or card-on-file problem, while a steady rate of insufficient-funds declines does not.
A supplement brand may change gateways because the acquirer behind its merchant account changed. A new merchant account through a specialty provider such as Organic Payment Gateways, for supplement processing, still leaves the stored cards on the old gateway until the export and import are finished, so the vault timeline has to be built into the switch date. EC4IM’s earlier explainers on Authorize.Net Account Updater settings and NMI’s move from transact.php to its JSON Payments API cover related settings worth checking at the same time.
What a vault move really involves
Moving stored cards between Authorize.Net CIM and NMI Customer Vault is a support-desk project measured in weeks. Authorize.Net exports full card data only through a fee-based request approved by the account owner and may take up to three weeks, while NMI imports only through an affiliate-initiated, PGP-encrypted file and charges at least $500 to send data the other way. Neither gateway imports subscription schedules, and the card-on-file links behind recurring charges need a plan of their own. Recurring merchants that schedule the move around a billing date, map every new ID, run both gateways for a cycle, and watch decline reasons closely can keep a gateway change from showing up as lost subscribers.
Sources
- Authorize.Net Support, Does Authorize.net support data exports and imports? (KA-07571)
- Authorize.Net Support, Downloading CIM profiles in the new Merchant Interface (KA-07614)
- Authorize.Net Support, Importing customer data to Authorize.net (KA-04061)
- Authorize.Net Developer Center, Customer Profiles
- Authorize.Net Developer Center, Card-On-File Transactions
- NMI Support, Data Import, Export, and Transfer Information (updated July 2, 2026)
- NMI Support, Customer Vault
- NMI Docs, Credential on File Best Practices
- NMI Docs, Transaction Processing reference
- Organic Payment Gateways