Every Dynamics partner eventually takes this call. A client's processor has raised rates, or approval performance has slipped, or an outage took the checkout down for an afternoon. The client wants to move. So they ask what it would take.
The honest answer is usually uncomfortable. Moving is possible. However, it is far harder than anyone expected when they signed, and the hardest part has nothing to do with the ERP.
This is a practical guide to scoping a payment processor migration in Dynamics 365. It covers what acquirer lock-in actually costs, why stored payment credentials are the real obstacle, and how to avoid the problem architecturally.
Why lock-in stays invisible until you try to leave
In practice, payment integrations rarely feel restrictive at go-live. The processor works. Transactions post. Everyone moves on to the next workstream.
The constraint only appears later, when circumstances change. By then the client has years of transaction history, a base of returning customers, and — critically — a vault full of stored payment credentials that they do not control.
Most native connectors bind you to a single acquiring bank. Therefore your rates, approval performance, uptime, geographic reach and available all depend on one relationship. That is fine while the relationship works. It is a genuine business risk when it stops.
The stored-card problem
Here is the detail that turns a commercial decision into a technical one.
When a customer saves a card, the real card number is replaced by a token. That token is usually issued and held by the processor. Consequently it is meaningless to anyone else. Move to a new processor and the tokens do not travel, so every stored card becomes unusable.
For a business with saved cards, that is not a migration inconvenience. It is a customer-facing event. Subscription billing fails. Repeat purchases require re-entry, which hits and cash flow directly. Some customers simply do not come back to finish the form.
Still, vault migrations between processors do exist. In practice they require the losing processor's cooperation, PCI-compliant transfer arrangements, and a timeline that suits a vendor with no interest in helping you leave. Some cooperate professionally. Others do not, and the project stalls.
So the practical outcome is predictable. The client runs the numbers, sees the churn risk, and stays with a processor they have already decided is not serving them.
What acquirer lock-in costs beyond the headline rate
Most conversations about processor choice focus on the rate. However, the rate is the smallest part of the cost.
First, you lose renewal leverage. A processor that knows you cannot realistically leave has little reason to sharpen a renewal quote. Therefore the switching cost shows up as a worse rate every year, not as a one-off project. Merchants looking to reduce acceptance cost also lose access to other levers, such as steering volume to cheaper rails or running where the rules permit it.
Second, you have no failover. One acquirer means one point of failure. When it goes down, your checkout goes down, and nothing reroutes.
Third, you inherit a geographic ceiling. Expanding into a market your acquirer does not serve well means either poor approval rates or a second integration. For clients with international plans, this constraint arrives faster than expected.
Fourth, you inherit a method ceiling. Local rails, depend on what your acquirer supports. Consequently the client's payment roadmap is set by a vendor rather than by the business.
Finally, the migration cost grows. Every additional stored card makes leaving more expensive. So delay makes the problem worse, which is exactly why lock-in persists.
Four questions worth asking before any payment integration
Fortunately, partners can prevent most of this at scoping. These four questions surface lock-in before it exists.
- Who owns the payment tokens? If the answer is the processor, plan the exit now.
- What happens to stored cards if we change processors? Ask for the specific mechanism, not reassurance.
- Can we run more than one processor at once? This matters for regional coverage and failover, not just negotiation.
- What does adding a new payment method require? If it means a development project each time, the roadmap belongs to the vendor.
A client who cannot get clear answers is being sold a constraint alongside the integration.
How to scope the migration itself
When a migration is genuinely needed, the sequence below keeps it predictable.
First, inventory the stored credentials. Establish how many active tokens exist, how many customers they represent, and how much recurring revenue depends on them. This number decides whether the project is straightforward or delicate.
Second, establish token portability. Confirm in writing whether the tokens can move, under what arrangement, and on what timeline. Everything else in the plan depends on this answer, so do not defer it.
Third, identify recurring and subscription exposure. These fail silently and painfully. Therefore map every recurring schedule and decide how each will be re-established before cutover, not after.
Then plan a parallel run. Route a portion of traffic through the new processor while the incumbent still handles the rest. Consequently you validate approval rates, settlement files and reconciliation postings with real transactions rather than test data.
Next, test reconciliation explicitly. New processor, new settlement format. So confirm that transactions post correctly into Dynamics 365, that fees post separately, and that bank reconciliation still matches cleanly. In addition, deferred methods need their own check, because settlement batches and clawbacks post differently from card transactions.
Finally, agree a rollback position. Decide in advance what triggers a return to the incumbent, and keep that path open through the parallel run.
Communicate to customers only if you must. After all, if tokens migrate cleanly, most customers never notice. If they do not, the communication plan becomes the most important part of the project.
The architectural alternative
The migration above is worth doing well. However, it is worth noting that the whole problem is architectural, and it is avoidable.
A processor-agnostic connector sits between Dynamics 365 and the payment ecosystem. Rather than integrating directly with one acquirer, the ERP integrates once with the connector. The connector then holds the processor relationships. That is the same pattern used for generally.
works this way. It connects , and to and 112 payment methods through a single integration.
Two properties matter for this discussion specifically.
Token ownership sits with the merchant. Because stored credentials are held in a portable vault rather than by an acquirer, changing processor does not mean re-collecting card details. Therefore the decision becomes commercial again rather than technical.
Multiple processors can run simultaneously. You can route by region, by cost, or by availability, and fail over when one processor has problems. Consequently a single acquirer outage stops being a checkout outage.
The same layer also removes the method ceiling. Wallets, BNPL providers, and bank rails are enabled at the connector rather than negotiated with an acquirer. So are the channels themselves: at the register and for invoices and phone orders both run through the same connection. Whether that matters depends on the client's roadmap, but it usually does eventually.
Running several processors deliberately
Once processor choice is not binary, some useful patterns open up.
Regional routing. Domestic acquirers frequently approve local cards at higher rates than a foreign acquirer does. So routing by geography can improve acceptance measurably, particularly where you also need local methods in that market.
Least-cost routing. Send each transaction to the with the best economics for that card type and amount.
Failover. Reroute automatically when a processor degrades, rather than waiting for it to recover.
Negotiating position. A client who can move volume between processors has a materially different renewal conversation.
For multi-entity groups, this also interacts with legal-entity structure and currency handling. covers that in more detail.
What this means for partners
In most projects, payment architecture is rarely on the critical path, so it tends to get decided quickly and revisited painfully. Yet the decision constrains the client for years.
The most useful thing a partner can do is ask the token ownership question early. It takes one sentence at scoping. Meanwhile it prevents the far longer conversation that starts with "our processor raised rates again, but we cannot really leave."
Frequently asked questions
How do you migrate payment processors without losing saved cards? It depends on whether the tokens are portable and whether the incumbent processor cooperates with a vault migration. Where tokens belong to the merchant rather than the processor, migration is straightforward. See for how a portable vault works.
What is payment token migration? It is the process of transferring stored payment credentials from one processor's vault to another, so customers do not have to re-enter card details.
Why is acquirer lock-in a problem if the rate is good? Because the rate is only one cost. Lock-in also removes failover, caps your geographic and payment-method reach, and weakens your position at every renewal.
Can Dynamics 365 use more than one payment processor? Not through most native connectors, which bind to a single acquirer. A allows several processors at once, with routing by region, cost or availability.
How long does a processor migration take? It depends almost entirely on token portability and recurring-billing exposure. Confirm both before estimating anything else.
What should partners ask at scoping? Who owns the tokens, what happens to stored cards on a switch, whether multiple processors can run concurrently, and what adding a new requires.
Does changing processors affect reconciliation? Yes. Settlement formats differ, so confirm that transactions post correctly into Dynamics 365 and that fees post separately during a parallel run.
Which Dynamics 365 modules does this apply to? , and . A connector sits alongside the environment rather than inside it.
SensePass is a payment gateway and connector for Microsoft Dynamics 365. It links Business Central, Finance & Operations, and Commerce to 112 payment methods and through a single integration, with merchant-owned tokens and multi-processor routing. or .