When interchange fees come up in a Dynamics 365 payment processing conversation, most teams focus on the rate itself. What they often miss is that the rate isn’t fixed; it changes based on how the card is taken.
That distinction has real dollar consequences, and in a D365 environment, it’s also an integration question.
Card-Present vs. Card-Not-Present: What the Terms Mean
A card-present transaction is one where the physical card, or a device holding the card, is used at the point of sale. A swipe, a tap, a chip read. The card is there.
A card-not-present transaction is everything else. Phone orders. Online checkouts. Back-office invoicing where someone reads a number and enters it manually. The card never touches a terminal.
Processors treat these differently because the fraud risk profile is different. Card-present transactions are harder to fake. Card-not-present transactions carry more exposure, so processors charge more to process them.
The rate difference is typically in the range of 0.2% to 0.3% per transaction, which sounds small until you apply it across meaningful monthly volume.
Card-Present Rates in D365: The Cost of Getting It Wrong
Dynamics 365 supports a wide range of transaction scenarios across businesses: back-office invoice payments, POS terminals on the floor, phone orders processed by staff, field sales, last-mile delivery, and more.
Each of those scenarios may be processed differently, and not all of them qualify as card-present even when a physical card is involved. The qualification depends on the device, the integration, and whether the processor receives the right data signals to classify it correctly.
This is where D365 payment processing architecture matters. A team that doesn’t map transaction types to interchange classifications during implementation may be paying card-not-present rates on transactions that should qualify as card-present — and never know it.
For a grounding on how interchange fees work before getting into the D365 specifics, see What Are Interchange Fees? (And Why They Matter for D365).
Card Present Classification Happens at the Integration Layer
Whether a transaction is classified as card-present or card-not-present depends on data, not the device alone. The processor makes that classification based on signals passed through the connector.
When a customer taps or swipes at a terminal, that transaction data doesn’t travel directly to the processor; it passes through the connector first. The connector is responsible for passing the signal that tells the processor the card was physically present. If it doesn’t, the processor has no way to know. It defaults to card-not-present and charges accordingly.
No error. No alert. Just a higher rate on every affected transaction until someone looks closely enough to notice.
That’s why payment architecture in Dynamics 365 means mapping how data moves from the terminal through the connector to the processor, because that determines what rate you actually pay.
For a broader look at how the gateway, connector, and processor fit together, see Payment Gateway vs Payment Processor: Complete Guide for D365.
Card-Present Rates and D365 Payment Pricing Models
The card-present vs. card-not-present distinction also affects which payment pricing model makes the most sense for your D365 environment. If a significant share of your volume qualifies as card-present, you have more to gain from interchange-plus pricing, where that rate advantage flows directly to you, than from flat-rate pricing, which averages everything together.
Interchange Plus vs Flat Rate: Which Fits Your D365 Implementation? covers that decision in full. The card-present rate difference is one of the key inputs.
What to Ask Before D365 Go-Live
Before a D365 payment processing implementation goes live, these are worth confirming:
- Which transaction scenarios in your environment qualify as card-present?
- Is the connector passing the data signals the processor needs to classify them correctly?
- Are you on a pricing model that lets you benefit from the rate difference?
These aren’t questions most implementation partners raise. Payment processing is typically treated as something to get working, not something to optimize. That’s the gap independent payment architecture advisory fills and why getting these details right before development starts matters more than revisiting them after go-live.
For the full picture on why Dynamics 365 payment processing decisions need to happen early, see Why D365 Payment Processing Isn’t Plug-and-Play.
If card-present classification hasn’t been part of your D365 payment processing conversation yet, let’s talk.