Retailers who sell both online and in physical stores are increasingly confronting a structural problem with their payment setup: two separate worlds that do not talk to each other.

Online, they have a PSP with a payment page, a 3DS flow, digital wallets, and iDEAL. In-store, they have a separate POS terminal contract, different settlement, different reporting, and often a different provider entirely. When a customer wants to buy online and return in-store, or start a transaction on a mobile app and complete it at a kiosk, the seams show.

Unified commerce is the strategy that removes those seams. And for most retailers, payment is the hardest seam to remove.

What unified commerce means for payments

Unified commerce is not simply omnichannel rebranded. Omnichannel means multiple channels exist and are coordinated. Unified commerce means those channels share a single underlying commerce and payment infrastructure, so the customer experience is genuinely seamless rather than stitched together.

The payment implications are significant. A unified commerce payment setup requires a single PSP or payment orchestration layer capable of handling online transactions, card-present POS transactions, and intermediate scenarios such as endless aisle, click-and-collect, ship-from-store, and in-app purchase. Settlement, reconciliation, and reporting need to work across all of these from a single ledger.

That is a materially different requirement from a standard online payment setup, and it changes the PSP selection criteria considerably.

The commercial opportunity

Getting the unified commerce payment layer right creates measurable commercial value in several ways.

A single customer view across channels enables better loyalty programme execution, more accurate attribution, and more effective retention. When a customer’s purchase history is unified regardless of channel, the data becomes actionable in ways that siloed channel data never can be.

Flexible fulfilment options, buy online pay in-store, pay online collect in-store, reserve and pay, all require a payment infrastructure that can handle partial authorisation, delayed capture, and cross-channel settlement correctly. Retailers who cannot support these flows lose sales to competitors who can.

Returns and refunds across channels are a persistent pain point for retailers without a unified payment layer. Accepting an in-store return for an online purchase requires the payment infrastructure to process a cross-channel refund cleanly. Without it, the workaround is a manual credit, which creates reconciliation problems and a poor customer experience.

The challenges

The challenges are real and should not be underestimated.

PSP selection

Most PSPs are strong in one environment and weaker in the other. Online-first PSPs have typically built POS capability through acquisition or partnership, and the integration quality varies. POS-first acquirers have added online capability but often lack the depth needed for a high-volume e-commerce operation. A small number of providers can genuinely handle both at the required level of performance.

Selecting the right PSP for unified commerce requires a structured RFP process that evaluates both environments with equal rigour, tests integration capability against your specific tech stack, and negotiates commercial terms that reflect the combined volume rather than treating online and POS as separate contracts.

Payment method coverage

The payment method requirements for a unified commerce setup are more complex than for a purely online operation. In the Netherlands, iDEAL dominates online but is not available at POS. Card schemes need to cover both card-present and card-not-present scenarios. Contactless, mobile wallets, and QR-based payments each have different acceptance infrastructure requirements. The payment method matrix needs to be mapped carefully against your channel mix and customer base.

Integration complexity

Connecting a unified commerce payment layer to your commerce platform, OMS, ERP, and loyalty system is a significant integration project. The payment provider’s API quality, webhook reliability, and reporting granularity all become important considerations. This is an area where the technical evaluation during PSP selection needs to be thorough, not just the commercial evaluation.

Cost structure

Unified commerce payment costs are more complex than online-only costs. Card-present interchange rates differ from card-not-present rates. POS terminal fees, acquirer fees, and scheme fees for in-store transactions follow different structures from online processing fees. Blended contracts that combine online and POS volumes can obscure cost inefficiencies in one channel. Understanding and negotiating the full cost structure across both environments requires specific expertise.

How to approach the payment layer

The starting point is clarity on your current situation. What does your online payment setup cost per transaction, and what does your POS setup cost? Are they with the same provider or different providers? What are the contract terms and renewal dates for each?

From that baseline, the unified commerce payment strategy becomes a commercial and technical project: evaluating whether your current providers can support the unified scenario, what alternatives exist, and what the commercial terms look like when online and POS volumes are combined in a single negotiation.

The retailers who navigate this well tend to approach it as a structured procurement exercise rather than a technology project. The technology question, which platform and which PSP, is secondary to the commercial question: what are we actually paying, what should we be paying, and which provider can deliver the capability we need at the right cost?

Talk to us about your unified commerce payment setup

EcomStream helps retailers optimise payment costs and performance across online and POS channels. Independent, no-cure-no-pay, and exclusively on the merchant side.