Most Dynamics 365 projects treat payment processing like a checkbox. It shows up as a single line item in the SOW, gets a quick nod in a meeting, and is mentally filed under “we’ll deal with that later.” Someone usually says, “We’ll use what we already have,” or “Microsoft recommends Adyen,” and the team moves on.
That assumption works—right up until UAT.
This is where missing features, connector limitations, card-present hardware questions, and finance vetoes start to surface. What felt like a small, contained decision suddenly turns into a blocker that threatens timelines and go-live. For teams implementing Dynamics 365 Commerce, Business Central, or Finance, payment processing isn’t an add-on. It’s infrastructure that touches revenue, reconciliation, customer experience, and delivery risk.
This article explains why Dynamics 365 payment processing is not plug-and-play, and how teams can reduce risk before payments become a late-stage surprise.
Why Payment Processing Keeps Derailing Dynamics 365 Projects
When people search for Dynamics 365 payment processing issues or Dynamics 365 payments problems, they’re rarely looking for a definition. They’re usually in the middle of a project that feels off-track and are trying to understand why something that sounded “simple” is suddenly complicated.
A common reason is timing. Payment processing is often scoped late or left vague on purpose. Partners may mark it as “TBD,” assuming the client will decide. Clients may assume the partner already has a standard answer. Finance assumes they’ll weigh in later. By the time everyone realizes no one actually owns the decision, the project is already moving fast.
Another recurring issue is the assumption that an existing processor automatically fits a new Dynamics 365 environment. Many organizations do have a processor, but that doesn’t mean it aligns with their new module, channel mix, compliance requirements, or reconciliation workflows. What worked in a legacy system doesn’t always map cleanly to Commerce, POS, ecommerce, or modern ERP flows.
The real damage happens when these mismatches are discovered late. Connector gaps, missing omnichannel features, or card-present requirements that weren’t planned can quickly turn into expensive rework. At that point, teams aren’t selecting a solution anymore; they’re firefighting.
Continue reading: Why Payment Processing Is the #1 Hidden Risk in D365 Implementations →
What Actually Happens When You Take a Payment in Dynamics 365
One reason Dynamics 365 payment processing is underestimated is terminology. Teams use words like “gateway,” “processor,” “connector,” and “payment provider” interchangeably, even though they describe very different parts of the transaction flow.
At a high level, a payment typically moves from the ERP through a connector or custom integration, optionally through a gateway, then to a processor or acquiring bank, through the card networks, and finally to the customer’s bank. On paper, that sounds straightforward. In reality, each layer introduces decisions that affect cost, security, flexibility, and long-term lock-in.
Here’s a plain-English way to think about the flow:
Dynamics 365 (ERP) → connector or custom integration → gateway (sometimes) → processor/acquirer → card networks → customer’s bank
The distinction between a payment gateway and a payment processor matters more in ERP environments than most people expect. A gateway moves and encrypts data. A processor routes transactions and settles funds. Some vendors do both. Some do one or the other. Some behave differently depending on the Dynamics module and connector being used. Understanding which role a vendor is playing helps teams avoid paying for unnecessary layers or discovering missing functionality late.
Continue reading: Payment Gateway vs Payment Processor: Complete Guide for ERP →
Card-present vs card-not-present changes everything
Transaction method also plays a major role. Card-present and card-not-present transactions carry different risk profiles and different interchange costs. That difference becomes material at scale, even for organizations that don’t think of themselves as retailers.
Devices aren’t an afterthought— they’re part of the architecture
Hardware and device strategy also isn’t a footnote—once terminals are deployed, switching processors later can become expensive very quickly.
Built-In and “Out-of-the-Box” Payment Options in Dynamics 365
Many teams default to built-in or commonly recommended payment options because they feel safer. Fewer vendors, fewer integrations, and a sense that the solution is “supported” all reduce perceived risk. In some cases, that instinct is correct.
However, “out of the box” in Dynamics 365 often means connector-based, module-specific, and limited to particular workflows. The capabilities shown in vendor demos don’t always reflect what the Dynamics integration actually exposes in real implementations. Supported does not automatically mean sufficient.
These default paths can work well when requirements are simple, channels are limited, transaction volume is modest, and finance is aligned on both the provider and the contract model. They tend to struggle when projects introduce omnichannel complexity, regulatory constraints, specialized device needs, or finance-driven mandates. The goal isn’t to avoid defaults. It’s to validate fit early, in the context of how payments will actually flow through Dynamics 365.
Why “Just Use Adyen” (or Any Single Processor) Isn’t a Strategy
Adyen frequently appears in Dynamics 365 Commerce conversations, and for good reason. It’s a well-known, enterprise-grade platform and is often positioned as a straightforward answer that reduces vendor sprawl.
The problem isn’t Adyen itself. The problem is treating any single processor as the strategy.
Teams often select Adyen early because it feels aligned, familiar, and easier to explain. What’s less visible is the difference between what the platform can do and what the Dynamics 365 connector actually supports for a given workflow. That gap is where many projects encounter friction.
Adyen can be an excellent fit when requirements are validated early, channels and devices are planned explicitly, and finance is aligned on settlement and contract structure. It becomes a constraint when those assumptions change late—such as when POS and ecommerce requirements expand, a CFO mandates a different acquirer, or regulatory rules force a specific setup. The lesson isn’t “don’t use Adyen.” It’s that no processor choice should substitute for a real selection process.
The Hidden Cost of “We Already Have a Payment Processor”
“We already have a processor” is one of the most common ways payment decisions get deferred, and one of the most expensive assumptions teams make during ERP projects.
Interchange vs headline rate
Quoted rates are usually blended averages that obscure how costs are actually calculated. Interchange fees vary based on card type and transaction method, and ERP migrations often change customer behavior in ways that shift the card mix. A move to more ecommerce or card-not-present transactions can materially increase costs, even if the processor hasn’t changed.
If you’re not sure which pricing model you’re on, this is the simplest place to start: Interchange Plus vs Flat Rate: Which Fits Your D365 Implementation? →
Device replacement and hardware lock-in
If your processor relationship is tied to leased or proprietary terminals, “keeping the same processor” can quietly become “keeping the same hardware ecosystem.” If you later need to switch, you’re buying your way out.
Future re-platforming costs are real
Tokenization and data portability matter too without clarity, switching processors in the future can require significant rework.
What a Real Payment Processing Selection Should Decide
A real Dynamics 365 payment processing selection isn’t about choosing a recognizable logo. It’s about aligning four areas before contracts and integrations are locked in.
1) Requirements (Commerce, BC, F&O, POS, ecommerce)
Be specific:
- Where are payments taken?
- What channels exist now, and what’s planned?
- What’s card-present vs card-not-present?
- What’s the mix of card vs ACH vs other methods?
2) Solution fit
Selection should map to your Dynamics architecture:
- which module(s) you’re implementing
- which connector patterns are available
- what features are required in real workflows
3) Commercial terms
This is where real money hides:
- pricing model (flat vs interchange plus)
- markup and fees
- device costs and leases
- early termination and auto-renewal
- incentives, subsidies, implementation credits
4) Implementation feasibility
Even the “best” provider is a bad choice if:
- the connector doesn’t support your workflows
- you discover gaps during UAT
- the device plan wasn’t validated
- responsibilities aren’t clear across partner/vendor/client
This is the gap where neutral, Dynamics-literate payment advisory creates the most value.
How to De-Risk Payments Before They Derail Your Go-Live
Whether you’re a Microsoft Partner or a Dynamics customer, these questions are the fastest way to uncover hidden risk early.
1) What module(s) are in scope, and where do payments happen?
Commerce, Customer Engagement (Field Services & Customer Service), Business Central, and Finance have very different payment realities.
2) Are we dealing with POS payments, ecommerce payments, or back-office only?
Don’t assume. Map actual flows.
3) What does the connector specifically support in our workflow?
Not “the platform.” The connector. In your use case.
4) Who owns the payment processor decision?
If finance isn’t in the room early, you’re setting yourself up for a veto later.
5) Are we card-present where we should be?
If high-value transactions are being run card-not-present when they could be swiped, that cost adds up fast.
6) What pricing model are we on and can we verify with a sample statement?
If a processor can’t show you “what you would have paid last month,” you’re flying blind.
7) What happens if we switch processors later?
Ask about:
- token portability
- device lock-in
- contract exit terms
- rework scope
If you can answer these seven questions early, you’ll prevent most Dynamics 365 payment processing issues before they surface.
Read next (Clients): Payment strategy and selection for Microsoft Dynamics 365 clients →
Read next (Partners): Dynamics 365 payment processor advisor for Microsoft Partners →
Payments Aren’t Plug-and-Play. Planning Is.
Payment processing in Dynamics 365 can absolutely be implemented cleanly. It just rarely happens when teams treat it as a checkbox, default to the first recommendation they hear, or postpone decisions until UAT.
If you’re navigating payments in a Dynamics 365 project and want a neutral, Dynamics-literate second set of eyes, Pathfynder helps teams validate requirements, compare options, and reduce delivery risk—without adding complexity to the project.
Evaluating payment processors for your D365 implementation?
Let’s compare options based on your actual transaction profile. Get started →