There’s a version of Dynamics 365 payment processing planning that feels responsible. You choose a connector, something like Retail Realm, Red Maple, or New West — specifically because it abstracts away the processor underneath. If you ever need to switch processors, you swap the back end. No rip-and-replace. No disruption.
Reasonable strategy. But the POS terminals don’t move.
Why Your D365 Payment Connector Doesn’t Free Your Hardware
When D365 implementation teams evaluate payment architecture, focus naturally lands on the processor-to-ERP integration layer — tokenization, pre-authorizations, settlement timing, PCI exposure. The connector is what makes Dynamics 365 payment processing work end to end.
Hardware gets treated as a line item. Someone picks a Verifone or Ingenico credit card terminal, procurement buys them, they get deployed at go-live.
The problem: POS terminals are certified to work with specific processors, specific connectors, and specific integration stacks. When you switch processors — even through a flexible connector — you replace the devices. For a mid-market retailer with 50 locations, that’s a terminal swap across every register in every store.
If the gateway and processor layer is still fuzzy, Payment Gateway vs Payment Processor: Complete Guide for D365 breaks down how those pieces fit together before you get to the hardware question.
Payment Terminal Negotiations: A Lever Most D365 Teams Don’t Use
Processors want your business. When volume is large enough (hundreds of locations, millions in annual card volume), they have real budget to compete. That budget doesn’t always show up as a lower rate. Sometimes it shows up as hardware.
In one D365 payment processing implementation involving a national restaurant chain, the winning processor contributed over a million dollars toward implementation costs in exchange for a multi-year contract. POS terminals across every location, hardware that would otherwise have been a capital expense, were included.
The customer didn’t know to ask. The partner didn’t negotiate for it. It took someone who understood both the D365 implementation landscape and how processors structure deals to put that offer on the table.
The D365 Payment Feature Gap That Surfaces at Go-Live
Terminal decisions affect capability, and capability gaps in payment devices are some of the most expensive surprises in a Dynamics 365 payment processing go-live.
A large specialty retailer running Dynamics 365 retail operations migrated to a new payment processor. Connector in place. Credit card terminals deployed. Testing is going well. Two weeks before rollout, the CIO said: turn on marketing.
The processor had demoed the ability to display loyalty prompts, collect email addresses, and surface promotional content directly on the POS terminal screen now of transaction. The customer had seen it, wanted it, and assumed it was included. However, that capability existed in the processor’s standalone environment, not in the D365 integration, and not with that connector. Getting it working required custom development that nobody had scoped, budgeted, or scheduled. Six-figure change order. Nearly missed the go-live window before the busy season.
This is one of the most common patterns we document in Top 3 Payment Delays in Dynamics 365 Projects.
Card-Present Rates and D365: Why Terminal Selection Has a Dollar Value
How a card is taken: swiped or tapped on a POS terminal versus entered remotely, directly affects your interchange rate. For high-volume industries like equipment rental, wholesale distribution, and last-mile delivery, that difference across thousands of monthly transactions adds up materially. Getting card-present capability right in a D365 payment processing environment depends on device selection, integration, and knowing which transaction scenarios actually qualify.
For a refresher on how interchange rates work, see What Are Interchange Fees? (And Why They Matter for D365). For the card-present vs. card-not-present rate distinction specifically, see Interchange Fees in D365: How Card-Present vs. Card-Not-Present Affects What You Pay.
The Right Sequence for D365 Payment Terminal Strategy
Most D365 projects handle terminals after processor and connector decisions are already made. The sequence that prevents late surprises:
- Map full requirements up front: transaction processing, loyalty, marketing, omnichannel, text-to-pay, card-on-file, pre-auth flows
- Identify which requirements touch the terminal directly, not just the connector or processor
- Select processor and connector based on that complete map
- Negotiate terminal costs, lease terms, and replacement provisions as part of the processor agreement
- Validate terminal capability against every requirement before D365 implementation development begins
When terminal strategy enters the conversation at architecture, the loyalty prompt problem gets caught in requirements. When it enters at procurement, it gets caught two weeks before go-live.
What Happens at Processor Renewal
Renewal is when rates quietly increase, like being framed as moving from introductory to standard terms and when POS terminal upgrade requirements surface. The 50% hardware discount at renewal sounds like a concession. For customers with real volume, it shouldn’t be a discount at all.
Renewal is a negotiation, and going in without independent context on what processors will actually give up is expensive.
In D365 Payment Processing, Terminal Strategy Is Architecture
The partners running your D365 implementation are focused on getting you live. Payment processing is, as one longtime Dynamics 365 practitioner put it, “a cost of doing business” — something to resolve, not optimize.
When terminal strategy, processor negotiation, and integration scoping happen together before development starts, the surprises that cost six figures and push go-live dates don’t materialize. That’s the work Pathfynder does.
For a broader look at why Dynamics 365 payment processing is more complex than most teams expect, see Why D365 Payment Processing Isn’t Plug-and-Play.