How to Switch Merchant Account Providers Without Interrupting Payment Processing

Review the current agreement before setting a termination date.  Often there will be an early termination fee associated with the merchant account. Additionally, there may be requirements regarding the processing gateway, software and equipment that is required to continue to exist even after the merchant is no longer processing payments for the company.

Review the following elements of the current agreement:

• expiration date of the contract
• requirements to cancel the agreement
• eligibility for early termination of the agreement
• ownership of the hardware
• lease agreements for the hardware
• procedures to cancel the processing gateway
• options to export the software
• release of any reserves
• access to the final customer statements
• how any open customer disputes will be handled
• how to be eligible for a refund after the canceled date
• responsibility for the annual and monthly fees for the agreement

Any rolling reserve may remain with the merchant’s old provider even after the merchant terminates the account with the company. The account provider is often contractually required to retain these funds and any potential losses related to the accounts that are closed.

Finally, the hardware that is used by the merchant must also be reviewed. Most hardware can be reprogrammed to work with another card processing company; however, some hardware is proprietary and encrypted to the old company, in which case the merchant will be required to purchase new hardware to continue using their current systems.

Often, the most difficult migration will be the stored payment credentials. Unlike a simple number, a token is a piece of data created by a specific payment module and may only work within that specific account.

Authorize.net allows for payments to be migrated into its Customer Information Manager. The documentation for the system makes clear that imported customers will receive new profile and payment-profile IDs. The merchant will have to update the records for each customer that was imported into the system. Additionally, the data will have to be transferred through the provider’s encrypted process rather than being downloaded into a spreadsheet application.

NMI distinguishes between a gateway move and a data transfer. In a gateway move, the customer retains their account and all of their transaction and vault data. In a data transfer, the customer’s data is copied into a new account that may not have the same data as the old provider’s account.

Ask both providers:

1. Who owns the tokens?
2. Can the old provider export them?
3. Can the new provider import them?
4. Who initiates the token transfer?
5. Will customers have new profile identifiers?
6. Will their recurring transactions be able to use their old provider’s transactions?
7. Will their transaction history show up in the new provider’s system?
8. Will customers have to reauthorize their transactions?
9. What will happen to transaction records that fail to export?
10. What is the transaction validation process?

Do not ask an employee or developer to export the customer’s card numbers to an unencrypted file. If there is no way to perform a direct token transfer from the old provider to the new provider, the customer will have to enter their payment method into a secure hosted form.

Subscription merchants need to preserve more than a list of customer cards. The system needs to know which subscription plans are active and what payment information each customer provides.

Create a file of the subscription information that does not contain sensitive data such as payment cards. Such a file can include information like:

• internal customer ID
• subscription plan
• billing amount
• billing frequency
• next charge date
• trial or promotional plan status
• cancellation date
• invoice balance
• customer communication preference
• migrated token

Do not allow both providers to offer the same subscription plans with the same billing schedules to customers. This would result in duplicate charges to customers and potentially refunds.

Tokenization is another feature that can significantly impact system security and customer payment performance. According to Visa, over half of electronic commerce transactions on their network were tokenized in fiscal year 2025. Companies that use tokenized transactions see a 5% increase in transaction authorizations and a 35% reduction in fraudulent transactions compared to those that use primary account numbers for transactions.

Run a group of subscription payments through the new system before migrating all subscriptions. This will allow merchants to investigate any issues with subscription renewals before migrating all subscriptions to the new system.

Parallel processing means the old account is always available while the new account is tested. It does not mean the same purchase is submitted to both accounts at the same time.

During the period of running in parallel, the company may:

• process test transactions into the new account
• send only one location to the new provider
• leave the old account open for any refunds
• compare authorization results
• compare deposits to sales batches
• validate accounting exports
• test void transactions
• test fraud rules
• ensure customers correctly receive receipts
• monitor billing descriptors

Start with the transactions with the least risk to the company. Rather than testing all sales and products at once, test each channel individually. These channels might include ecommerce websites, point-of-sale (POS) systems, virtual terminals and mobile sales.

Make sure that both accounts are properly disclosed and used for business purposes. Do not move disputed sales from one account to the next. Do not hide sales from the merchants and do not use the new account to avoid close scrutiny by the processor or credit card network.

A successful authorization does not mean that the migration is complete. Testing should continue beyond authorization to the settlement of the transaction.

Run each of the following transaction types:

• Approved sale
• Issuer decline
• Void prior to settlement
• Full refund
• Partial refund
• Recurring transaction
• Card-on-file transaction
• Ecommerce transaction
• In-person terminal transaction
• Payment link or virtual terminal transaction
• Chargeback-alert transaction
• Accounting system reconciliation

Ensure that the customer’s receipts and statements reflect the correct business name. Incorrect business names can lead to charge and credit card disputes.

Perform a test to ensure that the transactions are funding the business account. Check the deposit amount, fees, and the settlement date and destination bank account for the business.

Avoid a migration period during a major sale, holiday weekend, subscription-billing run, or peak business period when technical and customer service staff must be on-site.

The migration process should include the following elements:

• testing deadline
• deployment time
• activation schedule
• training date
• recurring-billing transition date
• technical contact
• provider contact
• rollback elements
• communication elements with customers
• monitoring period

Plan for the ability to roll back to the existing checkout system in the case of configuration failures.

While NMI offers tools to reprogram the checkout and payment systems for compatible processors, each merchant will be required to test the processor’s settings and credentials in their own systems prior to going live with the changes.

Turning off new sales for a provider does not mean that their responsibilities towards customers and their transactions end. Responsibilities like issuing refunds, responding to chargebacks and retrieval requests, and performing actions related to the release of reserves and fees still occur after the cutover of sales to the new provider.

The old provider’s account should be maintained long enough to:

• Issue refunds against the original sales transactions
• Respond to chargebacks and disputes from customers
• Download final sales and transaction statements
• Reconcile the balances of sales batches that have not yet been settled
• Monitor sales and release reserves
• Export any historical sales reports
• Resolve any negative sales balances
• Cancel the customer contract
• Remove access for the former employee
• Document the date of the final and complete closure of the old provider’s sales account

Refund processing against the original sales transaction is generally better than attempting to charge or credit the customer through a different and unrelated sales system. Ensure that the old provider is aware of how to process refunds after the new sales system begins accepting orders from the customers.

Finally, ensure that the old provider’s sales and transaction records are exported from their system before their access to the sales software expires. The types of data that should be exported include transaction reports, chargeback records, payout records, and records of any communications with the old provider.

While the provider switch will temporarily increase the exposure of payment data, the provider should restrict access to those involved in the switch.

The PCI DSS security responsibilities do not end with outsourcing checkout or payment data storage to a third-party provider. According to the PCI Security Standard Council (PCI SSC), merchants are responsible for ensuring that their providers are PCI compliant and that there is a written agreement between the parties regarding the responsibilities of each organization regarding security.

During the provider switch, implement the following recommendations to maintain PCI compliance:

• Use the provider’s approved methods to transfer data between the current and new providers
• Ensure that any files containing sensitive customer data are encrypted
• Never move payment data through email or messaging chat functions
• Create an individual account for each administrator of the website
• Enable multifactor authentication for website administrators’ accounts
• Rotate the API keys and passwords used to authorize transactions
• Remove the old API keys and passwords after the cutover to the new provider
• Review all website plugins and webhooks to ensure that they do not contain vulnerabilities that could expose payment data
• Document the PCI DSS responsibilities of each third-party vendor
• Update the PCI DSS scope of validation to include the provider

Do not delete the old website integration until it has been determined that no processes or functions of the website depend upon the old provider.

Monitor the new account after the switch. Compare the new account’s results to those of the business’s former account.

Review the following metrics for both the old and new accounts:

• authorization rate
• decline reasons
• funding
• effective processing cost
• refunds
• chargebacks
• fraud-screening decisions
• subscription failures
• gateway errors
• duplicate transactions
• customer complaints
• reconciliation

The new processor does not erase the history of chargebacks or improve the merchant’s standing with the card brands automatically. The Visa Acquirer Monitoring Program (VAMP) tracks the number of qualifying, card-not-present, Visa fraud reports and non-fraud disputes that are settled by merchants. By changing payment processors without fixing the cause of charge and chargeback disputes on the account, merchants may find themselves in the same spot after the switch.

High-risk merchants should report any changes in sales volume, ticket size, products sold, or sales channels to the new payment processor. Sales reported by the merchant should remain in line with what the acquiring bank approved for the account.

The most common mistake when migrating payment accounts is closing the old account as soon as the new application is submitted. There is always a chance that the approval you received will be denied or delayed.

Other mistakes that can be made include:

• assuming that all tokens will automatically transfer with the new account
• not remembering that there are automatic payments that must be set up for the new account
• purchasing any necessary hardware prior to determining compatibility with the new account
• canceling any software or gateway contracts for the old account
• not exporting the transaction history from the old account
• not testing the ability to process refunds and void transactions
• attempting to change the checkout process during a sales event
• migrating all sales to a new account that has not been tested for accuracy or ability to receive the sales
• using the wrong billing descriptor for the new account
• losing access to any disputes that are associated with the old account
• failing to train employees how to use the new account
• failing to create a rollback plan in case the new account fails
• hiding the true reason for the account change from the new underwriter

Assigning each task on the payment account migration checklist to a specific employee will ensure that no task is skipped and that each aspect of the change is properly accounted for. It is easy for each provider to think that another provider is responsible for a particular task, even if that provider may also be responsible for that same task themselves.