Implementing Dynamics 365 POS payments means wiring together the Payment SDK, Hardware Station, and a payment connector that implements IPaymentProcessor, then validating tokenization and merchant properties before you go live. Start with the Adyen connector if your terminal and instrument needs fit its compatibility tables; build a custom connector against Microsoft’s interfaces if they don’t. Either path, package for LCS, run sandbox tests against edge cases, and confirm PCI hygiene before processing a single live transaction.

---

TL;DR:

• Compatibility between Terminal firmware versions and your Dynamics 365 release is critical; mismatches cause disconnections and support issues.
• Merchant property parity between authorization and capture connectors is essential to avoid outright transaction failures and reconciliation errors.
• Building a connector requires implementing specific interfaces, placing assemblies in correct folders, and thorough testing of all payment flows, especially cross-channel captures.
• Supporting a broad range of payment methods, including wallets and BNPL services, becomes easier with a processor-agnostic connector that maintains token ownership.
• Using a pre-built connector like Sensepass accelerates deployment, supports over 50 processors, and simplifies future upgrades or processor switches without reengineering.

---

Table of Contents

• How Does the Dynamics 365 Payment Architecture Work?
• How Do You Build a Payment Connector and Processor?
• Which Terminals and Payment Methods Does Dynamics 365 Support?
• How Do You Package, Deploy, and Test a Payment Connector?
• How Do Tokenization and ERP Reconciliation Work Together?
• What Operational Rules Prevent Payment Outages?
• Where Does a Processor-Agnostic Connector Fit In?
• An Integrator’s View on Sequencing Payment Work
• Get Dynamics 365 Payments Live Faster With a Connector That Already Speaks 50+ Processors
• Where to Go Next for Developer Reference
• Sources

How Does the Dynamics 365 Payment Architecture Work?

Every transaction moves through four layers, and knowing who owns each step saves you hours of debugging later. The POS client sends a payment request to the Hardware Station, a Windows service that manages terminal communication so the POS itself never talks directly to card hardware. The Hardware Station passes that request to your payment connector, which implements the interfaces Microsoft’s runtime expects and forwards the transaction to the actual processor or gateway. Tokenization happens at this connector layer, where a card number gets swapped for a token before it ever touches your database.

Merchant properties, the configuration values tied to a specific payment connector instance, determine which connector handles a given transaction. This matters enormously for capture: capture must use the same connector and merchant properties that created the original authorization, or the transaction fails outright. That single rule causes more production incidents than any other omnichannel design decision.

Card-present flows (in-store swipe or tap) and card-not-present flows (online, phone orders) route through the same connector logic but carry different data payloads, documented in detail by Microsoft. Buy-online-pickup-in-store scenarios sit at the intersection of both, which is exactly where merchant property mismatches tend to surface.

How Do You Build a Payment Connector and Processor?

Building a connector for Dynamics 365 POS payments comes down to implementing a defined set of interfaces correctly, in the right order. Skip a step and the runtime either rejects the package or silently fails at capture time.

1. Implement INamedRequestHandler. Your connector class, following Microsoft’s PaymentDeviceSample pattern, must handle named request types including authorize, capture, refund, and void. The end-to-end payment extension guide provides the sample code and the Execute method structure this depends on.
2. Implement IPaymentProcessor. This interface exposes GetMerchantAccountPropertyMetadata (which properties your connector needs configured) and ValidateMerchantAccount (which checks those properties before a transaction runs). Get this wrong and merchant onboarding breaks silently.
3. Override the specific POS extension handlers you need, such as PaymentTerminalAuthorizePaymentRequestHandler, plus corresponding capture, refund, void, and ExecuteTask handlers. POS already runs the standard workflow, so your extension code only supplies the custom logic and response mapping. Register these in manifest.json with the correct extension points.
4. Place assemblies in the correct runtime folders. Hardware Station, CSU, MPOS, and web connector assemblies each live in distinct locations under the Retail SDK’s PaymentExternals structure. Mixing these up is a common reason a working connector fails to load in one channel but not another.

If your instrument and terminal needs already fit a supported gateway, building custom code here is often wasted effort, worth weighing against an off-the-shelf connector before you write a line.

Which Terminals and Payment Methods Does Dynamics 365 Support?

Before you write a single line of connector code, check compatibility. This is the step most implementers rush, and it’s the one that generates the most support tickets later.

• Cross-reference your Commerce release version against the connector’s firmware compatibility table. The Adyen connector documentation lists specific ranges, such as terminal firmware v1.117 through v1.120 paired with Commerce 10.0.47. Running mismatched versions causes intermittent terminal disconnects that look like network problems but aren’t.
• Verify your physical terminals carry current PCI PTS POI certification. Devices that fall out of certification create compliance exposure even if they still process transactions fine.
• Cross-check supported card brands against your target markets. Coverage varies by connector version and country.
• Confirm wallet support explicitly. Some BNPL providers and region-specific digital wallets carry tokenization limitations that only show up in the connector’s own instrument tables, not in general marketing copy.

Pro Tip: Pull the compatibility table for your exact Commerce release before ordering hardware, not after. Firmware mismatches between terminal and connector version are the single most common cause of “the terminal just stopped working” tickets during rollout.

How Do You Package, Deploy, and Test a Payment Connector?

Packaging mistakes are almost always folder mistakes. Microsoft’s deployment documentation is explicit about where each artifact belongs, and skipping that structure is the fastest way to produce a package that uploads to LCS but fails at install.

1. Place your IPaymentProcessor assemblies, IPaymentDevice assemblies, and payment web files into the correct PaymentExternals subfolders, since CSU, HWS, MPOS, and e-commerce host folders each expect different artifacts.
2. Run msbuild from the Retail SDK root to generate RetailDeployablePackage.zip. Running it from any other directory produces an incomplete package.
3. Upload that package to the LCS asset library, then deploy to a sandbox environment first. Never push straight to production.
4. Open a service request if a sandbox deployment fails validation. It’s usually faster than debugging blind.
5. Run your test plan: standard authorize/capture flows, then refunds, voids, partial authorizations, simulated network timeouts with retry behavior, and cross-channel captures where the order originates on one channel and completes on another.

Pro Tip: Test the cross-channel capture scenario last, after every other flow passes. It’s the one most likely to expose a merchant property mismatch, and you want a clean baseline before you chase that bug.

How Do Tokenization and ERP Reconciliation Work Together?

A token created at authorization has to survive intact through capture, settlement, and ERP posting. Break that chain anywhere and your finance team ends up reconciling by hand.

• The authorization reference generated at the point of sale must be reused for capture, even when capture happens on a different channel or days later, as with buy-online-pickup-in-store orders.
• Merchant property parity between the authorizing connector and the capturing connector is not optional. Microsoft’s omnichannel payments documentation confirms the system tries to reuse the original connector for capture, and when properties don’t match, the capture fails outright rather than degrading gracefully.
• Build a fallback path that detects connector unavailability and prompts the operator with a clear message, instead of letting the failure surface as a generic error.
• For ERP posting, track ProviderTransactionId and the approval code alongside your standard capture references, since these are the fields Microsoft’s payment connector data schema uses to tie a POS transaction back to a processor record during audits.

Teams that document merchant property parity requirements before writing code tend to skip an entire category of production incidents. It’s cheap insurance.

What Operational Rules Prevent Payment Outages?

Timeout and retry configuration is a reliability lever most teams undertune. A timeout window that’s too short converts a slow but ultimately successful transaction into a permanent failure. A generous window with two to three retries absorbs the transient network hiccups that are common on retail floors without materially slowing checkout.

Logging discipline matters just as much. Never log full PAN or CVV data under any circumstance; Microsoft’s own PCI implementation guidance flags this as a compliance violation, not just a bad habit. Run quarterly log audits and restrict access to payment logs by role.

Pro Tip: Build a runbook that checks terminal health, confirms fallback flows still trigger correctly, and reconciles capture counts against authorizations daily, not weekly. Daily catches drift before it becomes a finance escalation.

Where Does a Processor-Agnostic Connector Fit In?

Everything above assumes you’re building or configuring a single connector path. Sensepass operates as a payment connector, the integration layer linking a business’s ERP, POS, and eCommerce systems to over 100 payment methods and more than 50 card processors through one integration, connecting natively with Dynamics 365 Business Central, Finance & Operations, and Commerce alongside platforms like NetSuite, Oracle Xstore, and Shopify POS.

Because the architecture is processor-agnostic and merchants retain ownership of their own tokens, several of the traps covered above shrink considerably:

• Adding a BNPL provider like Klarna or Afterpay doesn’t require reissuing tokens or rebuilding merchant property mappings.
• Switching processors later doesn’t force a re-integration project, since the token layer stays constant.
• Wallet support, including Apple Pay, Google Pay, and PayPal, extends without a separate connector build for each one.

An Integrator’s View on Sequencing Payment Work

Payments aren’t a set-and-forget module. Sequence tokenization parity and merchant property mapping before writing capture logic, then stage rollouts channel by channel. Your go/no-go checklist should hinge on whether cross-channel capture actually works, not whether the demo does.

— Vlad

Get Dynamics 365 Payments Live Faster With a Connector That Already Speaks 50+ Processors

Building a custom connector from scratch means owning every interface, every firmware compatibility check, and every merchant property edge case covered above. Sensepass gives integrators a faster starting point: a processor-agnostic payment connector already wired to Dynamics 365 Business Central, Finance & Operations, and Commerce, plus NetSuite, Oracle Xstore, and Shopify POS, supporting digital wallets like Apple Pay and Google Pay, BNPL options including Klarna and Afterpay, pay-by-bank methods, and crypto through BitPay and Coinbase.

Because token ownership stays with the merchant, adding a new payment method or switching processors later doesn’t trigger the rework cycle a single-connector build often creates. If surcharge recovery is on your roadmap alongside the core payment build, the Dynamics 365 surcharging setup guide walks through configuration at the POS level. For a broader view of how the connector layer fits your architecture, the how it works overview is the right next stop before you scope your build.

Where to Go Next for Developer Reference

The sections above map to specific Microsoft Learn pages worth bookmarking before your build starts:

• End-to-end payment extension — developer code samples covering INamedRequestHandler implementation and the PaymentDeviceSample pattern for connectors and device handlers, available on Microsoft Learn.
• Adyen connector documentation — firmware compatibility tables, supported card brands, and wallet support status, detailed here.
• Payment connector data fields — the exact request and response schemas for card-present and card-not-present scenarios, documented by Microsoft.
• Deploy a payment connector — packaging folder structure, msbuild steps, and LCS deployment guidance, covered in full here.

If you’re also weighing a third-party gateway integration against a custom Adyen build, the difference between gateways and processors is worth reviewing before you commit engineering time either direction.

Sources

• Implementing a payment connector and payment device (end-to-end payment extension) — Microsoft Learn
• Dynamics 365 Payment Connector for Adyen — Microsoft Learn
• Deploy a payment connector — Microsoft Learn
• Payment connector data fields — Microsoft Learn

Recommended

• The Easiest Way to Integrate FreedomPay and Microsoft Dynamics 365
• Migrate Payment Processors in Dynamics 365 Without Re-Integration
• How to Accept ACH Payments in Dynamics 365 F&O