Home / Migration guide

Moving from an Authorize.Net plugin to native NMI.

A sequence that keeps the store taking money throughout. The card path is easy. Stored cards and active subscriptions are the part that needs a decision before you touch anything.

Start in sandbox Have us review your plan

Before you start

Three things to establish, in this order.

Confirm you are on NMI

If your account is behind the emulator, the platform underneath is already NMI. Ask your processor for native API credentials for the same merchant account.

Count your stored cards

How many customers have a saved card, and how many have an active subscription? These two numbers decide how much planning the migration needs.

Pick a quiet window

Not month end, not during a sale. You need a day where you can watch the first live transactions closely.

Keep the old plugin

Installed but inactive. Historical refunds must route through the gateway that took the original payment.

The sequence

Roughly a week end to end, most of it waiting and watching rather than working.

Request native credentialsA security key and the direct API endpoint for your existing merchant account. Routine request, usually answered same day.
Set up in sandboxInstall this plugin on staging with sandbox credentials. Run every flow that matters to you: sale, partial refund, void, saved card, and a subscription renewal if you have them.
Decide the stored card questionTokens created through the emulator may not map to native vault records. Either ask subscribers to re-enter a card, or run both gateways in parallel until each subscriber renews once.
Enable the new gateway on productionAdd live credentials, enable this gateway, and disable the old one for new orders. Do not uninstall anything.
Watch the first twenty ordersCheck auth codes land on orders, refunds work, and the log is clean. Most problems appear inside the first hour if they appear at all.
Migrate subscribersSend the payment method update email in batches rather than all at once, so support can absorb the replies.
Retire the old pluginOnce historical orders are outside your refund window and every subscription has renewed successfully, deactivate and remove it.

The subscriber email is the whole job

If you have active subscriptions, the migration succeeds or fails on how well you ask people to update their card. Send it from a person, explain that nothing about their plan or price is changing, link straight to the payment method page, and send it before the renewal rather than after a failure.

Questions

Enterprise and Agency customers get help planning this directly.

Contact support

Can this be done with no downtime?

Yes. Both gateways can be active at once, so checkout never stops. The switch is enabling one and disabling the other for new orders.

Will old orders still be refundable?

Through the old plugin, yes, which is why it stays installed. New orders refund through the new gateway.

What if a subscriber never updates their card?

Their renewal fails and the standard dunning emails go out. Migrate before the renewal date rather than relying on the failure to prompt them.

How long should I run both?

Long enough for every active subscription to have renewed once, plus your refund window on historical orders. For monthly billing that is usually five to six weeks.

Can you do the migration for me?

We will review your plan and be on hand during the switch for Enterprise and Agency customers. The changes themselves stay in your hands, since it is your merchant account.

Start free, upgrade when the store needs it.

Install from WordPress.org, connect your gateway, take a real order today.

Download from WordPress.org See pricing