You can migrate or add payment processors in Dynamics 365 Commerce without re-integrating your POS or eCommerce stack. The mechanism is a processor-agnostic payment connector layer, built on Microsoft’s own Payments SDK, that sits between your Commerce Scale Unit and whichever processor you choose next.

• Preserve or re-tokenize stored cards through coordinated token migration instead of forcing customers to re-enter payment data.
• Implement standard interfaces: IPaymentProcessor and IPaymentDevice, per Microsoft.Dynamics.Retail.PaymentSDK.
• Configure merchant properties once, in the POS hardware profile and the Commerce Scale Unit (CSU), so every channel reads from the same source.

Connectors like Sensepass already speak these interfaces and link Dynamics 365 to 100+ payment methods and 50+ processors, which is why PCI DSS scope and integration effort stay flat even as the processor behind the scenes changes.

Key Takeaways

A connector-first architecture, built on Dynamics 365’s IPaymentProcessor and IPaymentDevice interfaces, lets teams migrate payment processors without re-integrating POS or eCommerce systems.

Point	Details
Use a connector layer	Implement IPaymentProcessor and IPaymentDevice once, then treat processor swaps as configuration changes.
Plan token migration early	Start re-tokenization planning alongside connector configuration, not after, to avoid failed recurring payments.
Package AOS and CSU separately	In 10.0.10+, build distinct Visual Studio and Commerce SDK packages with portable DLLs only.
Test across five dimensions	Validate channel, transaction type, token flow, payment method, and merchant account before cutover.
Sensepass as the connector option	Sensepass links Dynamics 365, NetSuite, and other platforms to 100+ payment methods and 50+ processors while keeping token ownership with the merchant.

Table of Contents

• What Is the Right Approach to Dynamics 365 Processor Migration?
• How Do You Plan a Dynamics 365 Processor Migration Step by Step?
• How Do You Package and Deploy a Payment Connector?
• How Does Tokenization Affect Omnichannel Capture and SCA?
• What Should You Test Before and After Cutover?
• What Do Developers Need to Implement a Payment Connector?
• Why Connector-First Migrations Beat Processor-by-Processor Rebuilds
• Get Your Migration Scoped With Sensepass
• Frequently Asked Questions
• Sources

What Is the Right Approach to Dynamics 365 Processor Migration?

The right approach treats the connector, not the processor, as your integration contract. Build or configure one adapter layer that speaks Dynamics 365’s IPaymentProcessor and IPaymentDevice interfaces, and every processor swap afterward becomes a configuration change rather than a development project.

The payoff shows up fast:

• One integration point across POS, CSU, and eCommerce instead of three separate builds.
• Faster processor onboarding, since new processors slot into an existing adapter pattern.
• Centralized token handling, so authorization references don’t fragment across channels.
• Consistent merchant properties, which keeps reconciliation into Dynamics 365 clean.

The tradeoff is upfront effort. Someone has to build or configure the connector, and you inherit a dependency on how that connector handles tokens. Licensing or migration-service costs can apply too. Microsoft’s Payments SDK actually expects this split: IPaymentDevice and iNamedRequestHandler handle the physical terminal connection, while IPaymentProcessor governs merchant account properties, according to Microsoft’s own architecture. Treating those as one job is a common design mistake.

Pro Tip: Start token migration planning the same week you begin connector configuration. Running them sequentially is the single biggest cause of blown cutover windows and failed recurring charges.

How Do You Plan a Dynamics 365 Processor Migration Step by Step?

A processor migration breaks into six phases. Treat each as a gate, not a suggestion, because skipping discovery or testing is where most cutovers go sideways.

1. Discovery (2 to 4 weeks). Inventory every stored token, every merchant account by legal entity, and every payment method in use, cards, wallets, BNPL. Map which channel, POS/CSU, eCommerce, or call center, owns each token today.
2. Design (1 to 2 weeks). Choose your connector architecture: a processor-agnostic adapter factory you build, or a connector vendor like Sensepass. Decide your token strategy, export and transfer, re-tokenize, or customer re-entry, and map settlement postings to your Dynamics 365 ledger and posting profiles.
3. Build and configure (2 to 6 weeks, depending on processor count). Implement IPaymentProcessor’s GetMerchantAccountPropertyMetadata and ValidateMerchantAccount methods. Where physical terminals are involved, implement iNamedRequestHandler or IPaymentDevice.
4. Package. Build deployable packages for AOS and CSU following your Dynamics 365 version’s rules, with all portable DLLs and resource files included (covered in detail below).
5. Test (2 to 4 weeks). Run unit tests, sandbox integrations against each processor, and full token tests, authorize, capture, refund. Validate omnichannel recall (capturing against an original authorization) and SCA flows for regulated regions.
6. Cutover (1 to 3 days per legal entity, or phased by channel). Run parallel processing where feasible. Route customers who need it through a re-tokenization portal. Watch declines and reconciliation closely for the first 48 to 72 hours.

Acceptance criteria before you call it done: authorizations, captures, and refunds succeed end to end across every channel; tokens recall correctly; settlement files reconcile against CustTrans and AR; POS latency shows no regression; and your PCI DSS scope stays at or below plan.

Timeline expectations vary by scale:

• Small retailers (1 to 3 processors): 6 to 10 weeks.
• Mid-market, multisite (3 to 10 processors): 10 to 16 weeks.
• Large multi-entity, global (10+ processors): 16+ weeks, phased rollout by entity or region.

Token migration deserves its own attention here. Tokens belong to the processor that issued them, and they’re often not directly portable between processors, which is why re-tokenization and coordinated cutover testing show up in almost every timeline above, not just the large ones.

How Do You Package and Deploy a Payment Connector?

Packaging rules split sharply depending on your Dynamics 365 version, and integrators who miss this split are the number one source of failed sandbox deployments.

In releases 10.0.10 and later, you build two separate packages: an AOS package through Visual Studio for Application Explorer, and a Commerce channel or CSU package through the Commerce SDK or Visual Studio’s own packaging rules. Earlier versions handle this differently, so confirm your build against your actual environment version before assuming either path.

A few naming and content rules apply regardless of version:

• The model name must start with the RetailPaymentConnectors prefix, or it won’t surface as a connector option in Commerce.
• Package contents need IPaymentProcessor and IPaymentDevice assemblies plus any payment web files (HTML/CSS), and every DLL must be portable, non-portable assemblies cause loading failures at runtime.
• Web resources need to be added as project resources so they land correctly under AosService\WebRoot\Resources\Html or Styles, with URLs the connector can actually resolve.

Component	Deploy target
Payment processor DLLs	Commerce Scale Unit
Payment device DLLs	Hardware Station / Local Hardware Station
Web resources (HTML/CSS)	Store Commerce web root
Deployable package	LCS Asset Library

Once built, the package uploads to the LCS Asset Library, gets applied to a sandbox for validation, and only then goes to production through a formal service request.

How Does Tokenization Affect Omnichannel Capture and SCA?

Token references are tied to a specific merchant, connector, and processor combination, all three, not just one. When an order gets recalled for capture, Dynamics 365 preserves the original connector name on the tender line and tries to capture through that same connector. If your connector layer doesn’t present identical merchant properties across channels, cross-channel capture breaks silently.

Three token migration paths exist, and each carries different tradeoffs:

• Processor export, when the outgoing processor supports it, is fastest but rare.
• Secure re-tokenization through the new processor is the most common path and the most testing-intensive.
• Customer re-entry via a payment portal is the fallback when neither of the above works, and it costs you customer friction.

For eCommerce, enhanced SCA changes the checkout mechanics: it combines tokenization and authorization into a single request instead of two separate calls. Adyen’s V002 and V003 connector versions are the documented example of this newer flow. If your new connector doesn’t support the enhanced pattern, expect checkout friction in any region with SCA requirements.

Build your test cases around tokenized recurring billing, single-swipe tokenization for deposit-then-capture flows, SCA redirect behavior in storefront checkout, and what happens when a stored authorization has expired by the time of pickup.

What Should You Test Before and After Cutover?

Your test matrix needs to cover five dimensions at once, not sequentially: channel (POS/CSU, eCommerce, call center), transaction type (authorize, capture, refund, void), token flow (create, recall, reuse), payment method (card, wallet, BNPL), and merchant account variation by legal entity or geography.

Metric	What to watch
Success rate	Authorization and capture rates versus pre-migration baseline
Latency	POS transaction time, no regression versus legacy processor
Reconciliation	Settlement files matching ledger entries in Dynamics 365
First-attempt token success	Percentage of re-tokenized methods succeeding without retry

Set explicit rollback triggers before cutover, not during it: a meaningful jump in failed captures against baseline, reconciliation mismatches beyond your tolerance, token mapping errors you can’t resolve quickly, or a processor SLA violation mid cutover.

If any trigger fires, the rollback sequence is: revert connector configuration to the previous merchant properties, redirect transaction calls to the legacy processor adapter, re-run reconciliation for any captures still pending, and brief customer support with a hotfix playbook so front-line staff aren’t improvising. Snapshot your posting tables and pending authorizations before cutover begins. That snapshot is what makes a clean backout possible instead of a manual reconstruction under pressure.

What Do Developers Need to Implement a Payment Connector?

The interfaces are narrower than most teams expect. IPaymentProcessor needs GetMerchantAccountPropertyMetadata and ValidateMerchantAccount implemented; for physical terminals, add iNamedRequestHandler or IPaymentDevice. Methods you don’t use can throw FeatureNotSupportedException rather than requiring a stub implementation.

Your merchant property metadata needs to expose, at minimum:

• PortableAssemblyName
• ServiceAccountId
• SupportedCurrencies
• SupportedTenderTypes

These fields have to match exactly what GetMerchantAccountPropertyMetadata returns, or validation fails downstream in ways that are painful to trace.

Beyond the interfaces themselves, a short checklist saves real debugging time: portable DLLs only, HTML/CSS resources registered as project resources, the RetailPaymentConnectors model prefix, and your adapter registered in a connector factory so calling code never branches on processor identity. That factory pattern, documented in gateway hub architectures, is what keeps future processor additions from turning into another migration project.

On credentials: store API keys and merchant secrets in Azure Key Vault or an equivalent encrypted store. Never persist card numbers in Dynamics tables, tokens only, always.

Why Connector-First Migrations Beat Processor-by-Processor Rebuilds

The teams that get processor migration right stop thinking of it as a payments project and start treating it as an integration architecture decision. Every processor you add through custom point-to-point code is technical debt with an expiration date, because that processor will eventually be renegotiated, replaced, or supplemented.

A connector built once, correctly, against IPaymentProcessor and IPaymentDevice turns future processor changes into configuration work instead of development work. That matters most when a business is expanding into new legal entities or new countries, where processor requirements shift by jurisdiction. The catch is that the connector has to be architected properly from day one: real token ownership, secure credential storage, and per-entity posting profiles. Skip those, and your “flexible” connector becomes just as rigid as what it replaced.

Get Your Migration Scoped With Sensepass

If you’re weighing a build-your-own adapter against a connector vendor, the calculation usually comes down to how many processors and platforms you actually need to support long term. Sensepass is a payment connector, the integration layer linking Dynamics 365 (Commerce, Finance & Operations, and Business Central), NetSuite, Oracle Xstore, Shopify POS, and more to 100+ payment methods and 50+ card processors through a single integration, so you’re not rebuilding this work the next time a processor relationship changes.

Because Sensepass is processor-agnostic, your team keeps ownership of payment tokens rather than handing that control to whichever processor you’re on this year. On top of the connector layer, Sensepass runs a payment gateway, surcharging, tap-and-pay, and pay-by-link, all reconciling back into your Dynamics 365 ledgers automatically, alongside support for digital wallets, BNPL options like Klarna and Afterpay, ACH, and crypto through BitPay and Coinbase. For merchants also juggling recurring billing through the migration, Sensepass’s subscription payment tools handle tokenized recurring charges without a separate integration.

If your team is scoping a processor switch or consolidation right now, request a technical scoping call to walk through your specific processor count, token strategy, and Dynamics 365 version before you commit to a build.

Frequently Asked Questions

Do I have to re-integrate my POS and eCommerce systems to switch payment processors in Dynamics 365?
No. A processor-agnostic payment connector that implements IPaymentProcessor and IPaymentDevice lets you swap the processor behind the scenes while your POS, CSU, and eCommerce integrations stay untouched.

How long does a Dynamics 365 processor migration usually take?
Small retailers with one to three processors typically finish in 6 to 10 weeks. Mid-market multisite operations run 10 to 16 weeks, and large multi-entity global rollouts should plan for 16 or more weeks in phases.

What happens to stored payment tokens during a processor migration?
Tokens belong to the issuing processor and usually aren’t directly portable. Migration typically requires secure re-tokenization through the new processor or, in some cases, customer re-entry through a payment portal.

Do I need separate packages for AOS and Commerce Scale Unit?
Yes, in releases 10.0.10 and later. Build an AOS package through Visual Studio and a separate Commerce channel or CSU package using the Commerce SDK, each with portable DLLs only.

Does switching processors affect PCI DSS compliance scope?
It can, depending on how tokens are handled. Keeping card data as tokens only, never persisting PANs in Dynamics tables, and storing credentials in a service like Azure Key Vault keeps your compliance scope stable through the migration.

Sources

• End-to-end payment extension (Microsoft Docs)

Recommended

• The Easiest Way to Integrate FreedomPay and Microsoft Dynamics 365
• What Is a Point of Sale Machine for ERP Teams? – Omnichannel payments at the Point Of Sale | Sensepass
• Processor-Agnostic Payment Setup: A Retailer’s Guide – Omnichannel payments at the Point Of Sale | Sensepass