Your merchants already process with another provider, and you want to switch processors, add a second one, or bring an acquired book of merchants onto your platform. You might call this a processor migration, a cutover, or switching processors. Preczn groups this work under Migrate. The parts you want to keep are the merchant records, the cards and bank accounts customers have already saved, and the transaction history.

Without a layer in between, each switch means integrating the new processor's API and moving stored cards directly from one processor to the other.

In Preczn, a migration has four parts: importing merchants, linking existing credentials, importing tokens, and importing transactions. The cutover is a routing change. You move merchants to a plan that sends their transactions to the new processor.

Who this is for

---

• Platforms with merchants already processing at a processor or payment facilitator, moving some or all of them to a new provider.
• Platforms adding Preczn in front of the processor they already use, so they can add a second processor later.

You don't need this page in these cases:

• You have no existing merchants or stored payment methods. Start with Merchant Onboarding.
• You want to board existing merchants to an additional provider without moving anything. See Board one merchant to several providers with one form.

When to use this

---

How it works

---

Preczn keeps merchant data in the merchant vault and payment credentials in the Make Payment Methods Portable, apart from any processor. A migration fills both vaults, from your own records and from your current provider. Once a merchant has an active connection to the new processor and a plan that routes to it, transactions that use the imported tokens go to the new processor.

The diagram shows each kind of data moving into Preczn, and the plan that sends transactions to the new processor at cutover.

flowchart LR
    OLD["Current processor"] -->|"merchant import or<br/>linked credentials"| MV["Merchant vault"]
    OLD -->|"token export file"| TV["Token vault"]
    OLD -->|"transaction import"| TH["Transaction history"]
    MV -->|"merchants assigned to"| PLAN["Routing plan"]
    PLAN -->|"cutover"| NEW["New processor"]
    TV -.->|"token migration (optional)"| NEW

Token import and token migration move data in opposite directions:

• Token import brings tokens from your current provider into the Preczn token vault. Your current provider exports the file, and Preczn Support coordinates the transfer. Token Import lists the accepted file formats.
• Token migration creates matching tokens at a destination processor from payment methods already in the Preczn token vault. Use it when the destination should hold its own tokens. The Token Migration table on Supported Connections lists the destinations.

After a token import, each imported payment method has a Preczn token. Your system still stores the old processor's tokens, so you replace those references with the Preczn tokens before you charge through Preczn.

If your transaction requests name a processor, the plan doesn't apply to them. At cutover, change the processor on those requests, or stop naming one so the plan decides. See Transaction Routing.

Prerequisites

---

• The new processor is configured as a connection. See Connection Configuration.
• For connection import, transaction import, or linked credentials, the current processor is also a Preczn connection and supports that capability. Check Supported Connections.
• For token import, your current provider agrees to export your tokens.
• You have test mode set up, so you can rehearse the migration before you run it in live mode. See Live vs Test Mode.

Outline

---

1. Check capabilities. Confirm which import and boarding capabilities your current and new processors support in Supported Connections.
2. Import merchants. Load merchant records from a CSV file or pull them from a connected processor. Then send any data you hold in other systems with the Merchant API. See Creating Merchants.
3. Connect merchants to processors. Link credentials for merchants already boarded at a processor with Linking Existing Credentials. Board merchants to the new processor with Merchant Onboarding, or to several providers at once with Board one merchant to several providers with one form.
4. Import stored payment methods. Ask your current provider for a token export and send it to Preczn Support. See Token Import.
5. Update your stored token references. Replace each processor token stored in your system with its Preczn token. Preczn Support provides the import results. See Token Import.
6. Import transaction history (optional). Tell your Preczn account manager before you turn it on, then turn on one-time or continuous transaction import for the old connection. See Transaction Import.
7. Cut over. Assign merchants to a plan that routes to the new processor, now or on a scheduled date. If the new processor should hold its own tokens, contact Preczn Support about a token migration. See Assigning Merchants to Plans.

📘

Rehearse in test mode

Test and live modes are fully separate, including merchants, connections, and plans. Run the whole sequence in test mode with sandbox credentials, then repeat it in live mode.

Example

---

A scheduling platform for fitness studios has 300 studios on its current processor, and many studio members pay recurring dues with saved cards. The platform wants to move every studio to a new processor without asking members for their cards again.

1. The platform configures connections for both processors, then imports the studios from its own records with a CSV file.
2. It links each studio's existing credentials for the current processor, so each studio has an active connection to that processor in Preczn.
3. The current processor sends a token export to Preczn, and Preczn Support imports it into the token vault.
4. Preczn Support provides the import results. The platform replaces the processor tokens stored on its member records with the matching Preczn tokens.
5. The platform boards each studio to the new processor with a boarding form.
6. The platform schedules a bulk move of all 300 studios to a plan that routes to the new processor. From that date, dues are charged to the saved cards through the new processor.

Related

---

How-to guides

• Creating Merchants
• Linking Existing Credentials
• Token Import
• Transaction Import
• Assigning Merchants to Plans

Concepts and use cases

• Tokenization
• Merchants Overview
• Routing Plans
• Route Payments Across Providers

Reference

• Supported Connections
• Create Merchant
• Update Merchant