Dynamics 365 Commerce handles payments through a connector architecture, with Adyen and PayPal shipping as the built-in options that cover most online, POS, and call center scenarios through the Payments SDK’s iPaymentProcessor and INamedRequestHandler interfaces. Use those connectors for standard omnichannel flows. When you need broader payment method coverage, faster processor migrations, or token ownership outside Microsoft’s default stack, a processor-agnostic connector like Sensepass is the more practical next step.

---

TL;DR:

• Only specific Adyen connector versions (V002 and V003) support the streamlined single-authorization checkout flow with Enhanced SCA, affecting user experience.
• Proper configuration of merchant properties, connector order, and channel-specific capabilities is critical to prevent transaction failures, especially during a multi-channel deployment.
• Deployment must ensure assemblies and web files are placed in the correct component directories to avoid connector and payment flow failures.
• Refunds and voids depend heavily on using the same connector and merchant context as the original transaction; mismatches can cause failures or reconciliation issues.
• Using a processor-agnostic connector like Sensepass enables easier processor migrations and broader payment method coverage without extensive re-integration.

---

Table of Contents

• What Is a Payment Connector in Dynamics 365 Commerce?
• Which Connectors and Payment Methods Does Commerce Support?
• How Do the Payment SDK Interfaces Work?
• How Do You Configure Payment Modules and Enable SCA?
• How Do You Package and Deploy Payment Connector Files?
• Common Integration Pitfalls and How to Fix Them
• Handling Refunds, Voids, and Cancellations
• Security and Compliance Considerations for Payments
• Best Practices for Testing Payment Integrations
• Performance and Scalability for High-Transaction Volumes
• Logging and Monitoring for Payment Transactions
• Author perspective: recommended approach for enterprise Dynamics 365 payment projects
• Sensepass: A Processor-Agnostic Connector Built for Dynamics 365 Commerce
• Sources

What Is a Payment Connector in Dynamics 365 Commerce?

A payment connector is the code layer that sits between Commerce and a payment processor. It translates a transaction request from POS, e-commerce, or call center into whatever format the processor expects, then hands back an authorization, token, or decline. Without one, Dynamics 365 Commerce has no native way to talk to a card network or wallet provider.

The connector model exists because Commerce is genuinely omnichannel, and a shopper’s payment details often need to move between systems that were never designed to share state. Microsoft’s own documentation frames this as preserving payment details across the transaction lifecycle, not just at the moment of purchase.

That matters most in a handful of recurring scenarios:

• Online checkout, where a shopper enters card details on the storefront and the connector processes a card-not-present authorization.
• POS card-present transactions, where a physical terminal reads a chip or tap and the connector routes through a card-present flow instead.
• Call center orders, where an agent keys in payment details on behalf of a customer who never touches a device.
• Buy online, pick up in store (BOPIS), where authorization happens online but capture and fulfillment happen at a different location, often days later.
• Cross-store fulfillment, where an order placed at one location ships or gets picked up from another.

The mechanism that makes all of this work is the authorization token. A token created during checkout carries enough context that a different channel, at a different time, can complete the capture. Get the token handling wrong and cross-channel fulfillment breaks quietly, often weeks after go-live.

Which Connectors and Payment Methods Does Commerce Support?

Microsoft ships two connectors out of the box, and each has a distinct job. The Adyen connector handles both card-present and card-not-present transactions, making it the connector most retailers configure for POS. The PayPal connector is online-only, built for storefront checkout rather than in-store terminals.

Coverage looks like this in practice:

• Adyen: POS terminals (card-present), online checkout (card-not-present), specific card brands and countries listed in Microsoft’s connector tables, and firmware/version compatibility requirements you need to check against your Commerce release.
• PayPal: online checkout only, including PayPal wallet and standard card processing through the hosted checkout flow.
• Digital wallets: availability differs by channel. A wallet that works cleanly online may not have a POS equivalent through the same connector, so don’t assume parity across channels without checking the connector’s own capability tables.

Here’s a caveat worth building into your project timeline early: only specific Adyen connector versions (V002 and V003) support Enhanced SCA’s single-authorization checkout flow. Earlier versions still work, but they don’t get the streamlined authorization behavior, and upgrading mid-project changes how checkout behaves for shoppers.

A few operations simply aren’t supported without customization. Cash back at POS is one, according to Microsoft’s own payments FAQ. Recurring token support also varies by card scheme, so subscription and recurring billing scenarios need explicit testing rather than an assumption that “tokenization” means the same thing everywhere.

How Do the Payment SDK Interfaces Work?

Connector code doesn’t run in one place. It runs across four components, each handling a different part of the transaction: the Commerce Scale Unit (CSU) for online and headless transactions, Hardware Station for POS terminal communication, the Store Commerce app for in-store cashier flows, and the e-commerce web root for storefront checkout scripts.

The Payments SDK splits responsibility by transaction type, and this is where a lot of custom connector projects go sideways. iPaymentProcessor handles card-not-present transactions, the kind that happen online or through a call center. INamedRequestHandler handles card-present transactions at a physical terminal. A connector meant to work across both online and in-store channels has to implement both interfaces properly. Assuming one implementation covers both is a common and expensive mistake.

The typical transaction lifecycle follows a consistent pattern:

• BeginTransaction initializes the payment session and establishes context.
• Authorize sends the payment details to the processor and, on success, returns a token along with an authorization reference tied to the merchant and connector that created it.
• Capture completes the charge, sometimes immediately, sometimes hours or days later through a different channel.
• EndTransaction closes out the session and finalizes state.

Consistency in tender type IDs and card type IDs across every channel is not optional. Microsoft notes that an authorization reference is bound to the merchant and connector context that created it, which means a capture attempt from a different channel needs that same context available, or the capture fails silently.

How Do You Configure Payment Modules and Enable SCA?

Getting checkout to behave correctly with multiple connectors configured comes down to a short list of settings, and getting the order wrong is the single most common cause of checkout errors reported against Commerce sites.

1. Enable single payment authorization (SCA) in site builder if you’re running a supported Adyen connector version. This refactors checkout into a single authorization flow rather than a multi-step one, and it requires an explicit setting change, not just a version upgrade.
2. Set core module properties correctly. Supported tender types, the Is primary payment flag, and Use connector ID all need to match your actual processor setup, and iframe content security policy (CSP) settings need to allow the connector’s hosted fields to render without being blocked by browser security rules.
3. Order your connectors deliberately in Payment accounts. The order there, combined with the Is primary payment flag, determines which connector checkout defaults to. Mis-ordering is a recurring, avoidable source of failed transactions.
4. Test Adyen and PayPal side by side before assuming they coexist safely. Each occupies a distinct role (Adyen for POS and online, PayPal for online only), and running both means verifying that neither module’s iframe or tender configuration interferes with the other at checkout.

Pro Tip: Before you touch production, stand up a sandbox checkout with every connector you plan to use enabled simultaneously. Half of the “it worked in isolation” bugs in Dynamics 365 Commerce payments only surface when two payment modules compete for the same checkout step.

How Do You Package and Deploy Payment Connector Files?

Deployment is where a technically sound connector implementation can still fail, because the files have to land in the right place on the right component.

Microsoft packages connector code and assets into a RetailDeployablePackage, which gets uploaded to Lifecycle Services (LCS) for staged rollout across environments. That package contains assemblies and web files that don’t all belong in the same folder.

• IPaymentProcessor assemblies go into the Commerce Scale Unit’s bin directory, since card-not-present processing runs there.
• IPaymentDevice assemblies belong in Hardware Station’s ClientBroker bin, where POS terminal communication happens.
• Payment web files get copied into the e-commerce web root’s Connectors folder so storefront checkout scripts can load them.
• Store Commerce app needs its own matching connector files for in-store cashier flows to function.

For developer sandbox testing, a manual deployment checklist beats trusting the automated package every time until you’ve validated the flow once. Confirm every assembly landed in its expected directory, confirm version numbers match across components, and run a full transaction (authorize through capture) before promoting anything toward production.

Common Integration Pitfalls and How to Fix Them

Most payment integration failures in Dynamics 365 Commerce trace back to a small set of repeatable mistakes, and most of them are boring in a good way. They’re fixable once you know where to look.

1. File misplacement and version mismatches. Deploying assemblies to the wrong component web root is, by a wide margin, the most frequent root cause of connector failures. If a payment method works in one channel but not another, check file placement before you check code.
2. Merchant property and connector availability mismatches. If a connector isn’t marked available for capture on a given merchant, orders authorized online will fail to fulfill in store, or vice versa. This shows up as a fulfillment failure, not an obvious payment error, which makes it harder to diagnose.
3. Use the TestConnector for safe experimentation. Microsoft’s payments FAQ documents the TestConnector as a way to trial transaction flows without touching a live processor, which is the right first stop before blaming your production connector.
4. Decide build-versus-buy deliberately. Custom connectors make sense for scenarios Microsoft’s connectors don’t cover, such as linked refunds or region-specific payment types. For everything else, a prebuilt connector, whether Microsoft’s own or a processor-agnostic option built for faster POS deployment, gets you to production faster with less custom code to maintain.

Pro Tip: When a transaction fails in one channel but not another, pull the logs from both the CSU and Hardware Station before you touch code. Most “connector bugs” turn out to be a merchant property that was never enabled for the channel that’s failing.

Handling Refunds, Voids, and Cancellations

Refund logic in Dynamics 365 Commerce depends heavily on which connector authorized the original transaction, because a refund isn’t a new payment. It’s a reversal tied to the original authorization reference and the merchant/connector context that created it.

A void cancels an authorization before capture, typically same-day, and most connectors handle this cleanly since no funds have actually moved yet. A refund reverses a captured transaction, which means the connector has to route the reversal back through the same processor and merchant account that processed the original capture. Try to refund through a different connector than the one that captured the original payment, and you’ll get a rejection or, worse, an orphaned transaction that reconciliation can’t match.

Cancellations get more complicated in BOPIS and cross-store fulfillment scenarios. An order authorized online and canceled before in-store pickup needs the void or refund to route back through the original online connector context, not through whatever connector the pickup location uses for its own POS traffic. This is exactly the kind of edge case Microsoft points to when it discusses linked refunds as a reason to consider a custom connector: out-of-the-box connectors don’t always handle multi-location refund chains gracefully.

Build your reconciliation reporting to flag any refund attempt where the requesting channel’s connector doesn’t match the original capture’s connector. That single check catches a disproportionate share of refund failures before they reach a customer service ticket.

Security and Compliance Considerations for Payments

Payment connectors in Dynamics 365 Commerce need to keep raw card data out of Microsoft’s systems entirely, which is the core principle behind PCI DSS scope reduction. A well-built connector tokenizes card details at the point of entry, whether that’s a hosted iframe field online or a terminal at POS, so Commerce itself never stores or transmits a raw card number.

That tokenization boundary is what determines your PCI DSS scope. If your connector properly hands off sensitive data capture to the processor’s hosted fields or terminal firmware, your Commerce environment carries a much lighter compliance burden than if card data ever touches your own servers unencrypted.

Encryption matters at two points: in transit, where TLS between the connector, Commerce, and the processor is non-negotiable, and at rest, for any authorization reference or token stored for later capture. Tokens themselves should be treated as sensitive, even though they aren’t raw card numbers, because a leaked token can sometimes be replayed against the merchant account that issued it.

Enhanced SCA support adds a compliance dimension beyond PCI DSS. Strong customer authentication requirements, common in European card scheme rules, push more of the authentication burden onto the connector and processor rather than the merchant, which is part of why only specific connector versions support the single-authorization flow that satisfies those rules cleanly.

Audit your connector vendor’s own PCI DSS attestation before go-live. A connector that claims card-present and card-not-present support without a current attestation on file is a compliance gap you’ll inherit, not one they’ll own.

Best Practices for Testing Payment Integrations

Testing payment connectors properly means testing every channel combination, not just the one your team happens to be working on that week. A connector that passes online checkout tests can still fail at POS if the card-present interface was never exercised.

Start in a sandbox using the TestConnector Microsoft provides for exactly this purpose, since it lets you replicate authorize, capture, void, and refund flows without touching a live processor account. Once basic flows pass, move to a staging environment configured with the actual connector version you intend to run in production, matching firmware and assembly versions exactly.

Test the full lifecycle deliberately: authorize online, capture in store (BOPIS), then attempt a refund from a third channel. This sequence exposes merchant property and connector availability mismatches faster than any single-channel test ever will. Also test failure paths on purpose. Declined cards, expired tokens, and network timeouts all need defined behavior, not just the happy path where everything works.

Run at least one full regression pass after any connector version upgrade, since Enhanced SCA and similar feature changes alter checkout behavior in ways that don’t always show up in a quick smoke test. Keep a staging environment that mirrors production connector versions permanently, rather than rebuilding it ad hoc before each release, so regression testing is a five-minute exercise instead of a two-day setup project.

Performance and Scalability for High-Transaction Volumes

Payment connector performance becomes visible fastest during peak load, when authorization latency and connector timeout settings that seemed fine in testing suddenly cause checkout abandonment at scale. The Commerce Scale Unit processes card-not-present authorizations, so its scaling configuration directly affects how much online checkout volume it can absorb without queuing delays.

Hardware Station handles POS card-present traffic separately, which means online and in-store performance bottlenecks rarely show up at the same time or for the same reason. A retailer running a major online sale won’t necessarily see POS slow down, and vice versa, because the two paths run through different components entirely.

Token-based capture flows help scalability by decoupling authorization from capture. Authorizing a payment doesn’t require the fulfillment system to be immediately available, which matters when BOPIS or cross-store orders spike faster than warehouse or store systems can process pickups.

Connector timeout and retry configuration deserves explicit tuning for high-volume periods rather than relying on default values. A connector that retries too aggressively during a processor slowdown can multiply load on an already struggling payment gateway, turning a minor latency issue into a cascading failure. Load-test your connector configuration at expected peak volume, not average volume, before any high-traffic event, and confirm your processor’s own rate limits align with what your Commerce environment can actually push through.

Logging and Monitoring for Payment Transactions

Every authorization, capture, void, and refund needs a log entry that ties back to the transaction’s merchant, connector, and channel context, because that’s the only way to reconstruct what happened when a customer disputes a charge weeks later.

Log at each lifecycle stage separately: BeginTransaction, Authorize, Capture, and EndTransaction each generate distinct log events, and losing visibility into any one of them makes root-cause debugging far slower. Include the connector version and assembly version in every log entry, since a surprising number of payment discrepancies trace back to a version mismatch between what staging validated and what production actually deployed.

Monitor connector availability and merchant property configuration as ongoing health checks, not just at initial setup. A merchant property that gets accidentally disabled during an unrelated configuration change can silently break capture for an entire location, and without active monitoring, that failure often surfaces only when a customer complains about an order that never fulfilled.

Set up alerting on authorization failure rate spikes by channel and by connector, since a sudden increase isolated to one connector usually points to a processor-side issue, while a spike across all connectors simultaneously usually points to something on your own Commerce environment. Retain transaction logs long enough to support chargeback disputes and audit requests, which for most processors and card schemes means keeping records well beyond the transaction date itself.

Author perspective: recommended approach for enterprise Dynamics 365 payment projects

Start with Microsoft’s built-in connectors for anything standard. They’re supported, documented, and don’t add custom code to maintain. Reach for a processor-agnostic connector like Sensepass when you need method coverage Adyen and PayPal don’t offer, or token portability for a future processor switch. Either way, validate merchant properties and capture availability during design, not after go-live.

— Vlad

Sensepass: A Processor-Agnostic Connector Built for Dynamics 365 Commerce

Once you’ve mapped out where Adyen and PayPal’s coverage ends, the question becomes how to add the rest without building and maintaining a second custom connector from scratch.

Sensepass is a payment connector, not an orchestration platform: it’s the integration layer that links Dynamics 365 Commerce (Business Central, Finance & Operations, and Commerce itself), along with NetSuite, SuiteCommerce, Oracle Xstore, Aptos, Shopify POS, BigCommerce, STORIS, and NCR, to more than 100 payment methods and 50 card processors through one integration. Because it’s processor-agnostic, you keep ownership of your payment tokens, which means switching or adding a processor later doesn’t force a re-integration project. That coverage spans digital wallets (Apple Pay, Google Pay, PayPal, Venmo, Amazon Pay, Alipay, WeChat Pay), BNPL and financing methods (Klarna, Affirm, Afterpay, Sezzle, Zip, Splitit, WeGetFinancing), pay-by-bank and ACH (Trustly, LinkMoney), and crypto (BitPay, Coinbase). On top of the connector, Sensepass runs a payment gateway, surcharging, tap-and-pay, and pay-by-link as add-on products your team can turn on without a separate vendor relationship.

If you’re evaluating options for migrating processors without re-integration work, or adding a method like Klarna in-store and online, start with a sandbox evaluation against your current Commerce environment to see how the connector maps against your existing merchant and channel setup.

Sources

• Omnichannel payments – Commerce | Dynamics 365 | Microsoft Learn
• Payment module – Commerce | Dynamics 365
• Enhanced payments in storefront checkout – Commerce | Dynamics 365 | Microsoft Learn
• Deploy payment connectors – Commerce | Dynamics 365 | Microsoft Learn

Recommended

• Integrators: Ship Dynamics 365 POS Payments Faster With a 50+ Connector
• How to integrate multiple payment gateways for retail
• Migrate Payment Processors in Dynamics 365 Without Re-Integration
• Integrate online payments for retail: omnichannel guide