In most retail businesses, payment hardware is a cost nobody questions until someone adds it up. First, a terminal at every till. Then spares, plus the ones on the floor for line-busting. Then the maintenance contracts, the PCI scope each device carries, and the replacement cycle when a model reaches end of life.
For a fifty-store chain, that is a substantial capital line and a permanent operational one. Meanwhile the customer experience it buys is increasingly ordinary, because shoppers now expect the same payment options in store that they get online.
So this is a practical look at in-store payment options for Dynamics 365 Commerce, what each one costs you operationally, and the cross-channel returns problem most retailers discover after go-live.
What Dynamics 365 Commerce gives you natively
In practice, Commerce handles in-store payment through hardware profiles and EFT service connectors. Microsoft provides connectors including Adyen, which supports card-present and card-not-present transactions, and ISV partners can build custom ones.
That works. However, two constraints follow from it.
First, you are tied to whichever acquirer the connector represents. Therefore rate negotiation, failover and regional acquiring are all off the table. Microsoft's own documentation notes that merchants in some geographies need new connectors when the out-of-box options do not cover their region.
Second, card-present acceptance assumes certified hardware at the point of sale. So your payment capability scales with your device fleet, not with your business.
The four ways to accept payment in store
So retailers running Commerce generally choose between these four.
First, traditional countertop terminals. Reliable and familiar. Also capital-intensive, each device sits in PCI scope, and every new payment method depends on the terminal supporting it.
Second, mobile terminals for floor staff. Better for queue-busting and clienteling. Consequently you buy more devices, charge them, and manage them.
Third, tap to pay on a store-owned phone. Cheaper hardware, but your staff still handle a device per associate, and method coverage remains limited to what the card rails support.
Finally, a chargeless tag the customer taps with their own phone. The customer taps, a payment page opens on their device, and they pay with any enabled method. No terminal, no charging, no pairing, and nothing for your staff to hold.
The fourth option is worth understanding properly, because it changes the economics rather than shaving them.
Why the customer's phone is the better terminal
After all, every shopper already carries a payment device. It is charged, connected, biometrically secured, and loaded with their wallets, cards and financing accounts.
A tag uses it. The customer taps the tag, their phone opens a branded payment page, and they pay with whatever they prefer. Critically, they do not download an app, activate a virtual card, or scan a QR into a third-party wallet first.
That last point matters more than it sounds, and it is where most in-store method expansion fails.
For example, take BNPL. Every major provider's native in-store flow pushes the shopper into the provider's own app: Afterpay requires activating a wallet card inside the Afterpay app, Affirm issues a one-time virtual card, and Klarna uses a QR-to-app flow or a digital single-use card. So supporting four BNPL providers natively means four different counter procedures your staff must learn — and an app install happening at your till while a queue builds.
Through a connector, works like any other tender. One procedure, whatever the customer chooses.
The same applies to . For retailers operating internationally, a shopper in Brazil or Japan can pay with the rather than the card you hoped they carried.
The cross-channel returns problem
Meanwhile, here is the operational issue that catches omnichannel retailers, usually after launch.
Tokenisation normally binds a refund to the original card. So a customer who buys online and returns in store — or who wants the refund on a different card — hits a wall. Your associate then apologises for a limitation nobody chose, at the exact moment the customer is already mildly unhappy.
For a Commerce retailer whose entire premise is a unified experience across channels, that gap is visible precisely where it hurts most.
Solving it requires a payment layer that spans both channels rather than two systems stitched together. Where online and in-store run through the same connector, buy-online-return-in-store works, including refunds to a different card. Consequently the other omnichannel scenarios — BOPIS, endless aisle, cross-channel exchanges — behave consistently too.
This is the practical test worth applying: do your online and in-store payments run through the same layer? If not, you will reconcile them separately and your returns policy will carry an asterisk.
What this changes operationally
First, hardware footprint. Fewer terminals means less capital, fewer maintenance contracts and a smaller PCI surface. It also removes the end-of-life replacement cycle for devices you no longer own.
Second, store flexibility. Payment no longer depends on a fixed location. Therefore line-busting, curbside, kerbside pickup, pop-ups and events all work without provisioning devices first.
Method expansion. New payment methods arrive at the connector layer rather than through a hardware refresh. So adding a wallet or a financing provider becomes a configuration change.
Also, staff training. One payment procedure regardless of tender. That matters in retail, where turnover is high and training time is short.
Reconciliation. In-store and online transactions post back into through the same pipeline, so finance reconciles one system rather than matching two.
Still, you will want terminals in some contexts. High-volume grocery lanes, for instance, or markets where card-present regulation requires specific hardware. The point is not eliminating terminals everywhere. It is not needing one everywhere.
What to check before you commit
Questions worth putting to any in-store payment option for Commerce:
- Does it support the same payment methods online and in store?
- Can the customer pay without downloading anything?
- Does buy-online-return-in-store work, including refunds to a different card?
- Are you tied to one acquirer, or can you ?
- What does adding a new payment method require — a setting, or new hardware?
- How do in-store transactions reconcile back into Dynamics 365?
- Does it cover mobile, curbside and pop-up scenarios, or only the fixed till?
The first and third questions separate genuine omnichannel from two systems sharing a brand.
Where this fits alongside the rest of your payment stack
In practice, in-store rarely stands alone. Most Commerce retailers also invoice, take phone orders, and sell online.
Running those through one connector keeps the method list and the reconciliation consistent. links , and to 112 payment methods and 50+ processors through a single integration. That covers the register, the online checkout, and for phone orders and quotes.
Because it stays processor-agnostic, it also leaves the commercial decisions open — without re-integrating, and applying where the rules permit.
Frequently asked questions
Can Dynamics 365 Commerce accept payments without a payment terminal? Yes. With a tap-and-pay tag, the customer taps their own phone and pays on their device, so no terminal is required at the till.
Do customers need to download an app to pay in store? Not with a connector-based tap-and-pay flow. By contrast, most BNPL providers' native in-store methods require their app and a virtual or wallet card.
Does Dynamics 365 Commerce support multiple payment processors? Not through native connectors, which tie you to one acquirer. A processor-agnostic connector supports several at once.
Can we offer BNPL at the register? Yes, through a connector. Natively, each provider brings its own app-based flow, so supporting several means several counter procedures.
How do we handle buy-online-return-in-store refunds? You need online and in-store running through the same payment layer. Otherwise tokenisation binds the refund to the original card and cross-channel returns break.
Will in-store transactions reconcile in Dynamics 365? Through a connector, yes. In-store and online transactions post back through the same pipeline, so finance reconciles one system.
Is this suitable for pop-ups and events? Yes, and it is one of the clearest advantages. No device provisioning is required, so temporary retail works the same as a permanent store.
SensePass is a payment gateway and connector for Microsoft Dynamics 365. It links Commerce, Business Central and Finance & Operations to 112 payment methods and through a single integration, with chargeless for in-store, pay by link, and surcharging. or .