🔀 Omnichannel payments

From multichannel to unified commerce

For 20 years, retailers kept adding channels: POS terminals in stores run on a legacy card-processing setup, an e-commerce PSP for the website, and sometimes a third provider for the mobile app. The result is silos. Each channel has its own contract, its own back office, and its own transaction database, and no shared identifier lets the retailer recognize the same customer from one channel to the next. Omnichannel, and later unified commerce, take the opposite approach: process every payment on a single platform and keep one customer and transaction database, whatever the touchpoint.

Cross-channel tokenization

Tokenization replaces the card PAN with a token that stays stable over time and is shared across channels. It is the technical foundation of omnichannel. When a customer pays at the POS terminal, the platform derives the token for that card and matches it against the token stored from the customer's online purchases. A match shows that the same card was used for both. This approach, sometimes called payment as an identifier, enables invisible loyalty, receipt-free returns, and hybrid journeys while staying fully PCI DSS compliant, since the PAN never travels in the clear.

• PSP token (acquirer token): generated by the payment platform and stable across every channel it processes. It is the backbone of unified commerce.
• Network token (scheme token): generated by Visa or Mastercard and updated automatically when a card is reissued (lifecycle management). It is valuable for subscriptions and card-on-file payments.
• Combining the two: mature platforms pair the PSP token (a cross-channel view of the customer) with the network token (higher online authorization rates).
• The in-store constraint: at the POS terminal, the token must be derived from the transaction without storing the PAN, which is why an end-to-end PCI-certified chain (P2PE) matters.

Hybrid journeys: click and collect, endless aisle, and more

• Authorization validity: about seven days for a standard authorization (varies by scheme and MCC). After that, the merchant must reauthorize or switch to immediate capture with a refund if an item turns out to be unavailable.
• Partial and multiple captures: essential for orders shipped in several parts. Confirm that the acquirer and the contract support them.
• Incremental authorization: useful when the final amount may exceed the estimate (rentals, restaurants, hotels).

Cross-channel refunds and exchanges

Returns of items bought on another channel are the real test of a unified database. A customer buys online and returns the item in store (BORIS, buy online, return in store), or the other way around. To issue the refund, the store must find the original transaction, whichever channel recorded it. This is called a referenced refund. The credit goes back to the original card, identified by its token, and the customer does not need to show the card or a receipt. Unreferenced refunds (a “standalone” credit to a card, such as an OCT or payout) are kept for edge cases, because they cost more, carry more risk (refund fraud), and are sometimes restricted by the schemes.

• Refund to the original payment method by default: the schemes require it, and regulators expect it (anti-money laundering).
• Omnichannel store credit (gift card or customer credit) is an excellent buffer: it is instant, works everywhere, and keeps the revenue in the business.
• Record the original channel in the refund's accounting entry, or margin by channel becomes impossible to read.

Unified reconciliation

Reconciliation matches every sale, payment, bank payout, and fee across all channels. It is the financial side of omnichannel. In a siloed organization, the back office handles end-of-day batch files from POS terminals, e-commerce PSP reports, and bank statements in different formats, with no shared identifier to tie them together. In unified commerce, the platform produces a single settlement feed, in which each bank payout is broken down transaction by transaction, with the channel, store, fee, refunds, and chargebacks.

• Three reconciliations: sales ↔ payment transactions (completeness), transactions ↔ payouts (settlement), payouts ↔ bank statement (cash).
• Transaction-level detail: require a line-by-line settlement report from the provider that includes the order ID, because that is what makes automatic matching possible.
• Typical discrepancies: timing gaps (sale on D, payout on D+2), refunds that straddle two periods, chargebacks deducted from payouts, and bundled fees.
• KPIs: automatic matching rate (more than 98% is achievable), time to close, and discrepancies unresolved after more than 30 days.

{
  "settlement_batch": "2026-07-09-EUR-001",
  "payout_iban": "FR76XXXXXXXXXXXX",
  "gross": 74.00,
  "fees": -0.62,
  "net": 73.38,
  "transaction": {
    "order_ref": "ORD-84512",
    "channel": "ecommerce",
    "fulfillment": "click_and_collect",
    "store_id": "PAR-011",
    "method": "visa_token",
    "type": "partial_capture"
  }
}

Retailer examples and best practices

Large international retailers led the first programs of this kind. The typical model, popularized by Adyen with Decathlon and Sephora across several regions, replaces a patchwork of local card-processing contracts and e-commerce PSPs with a single platform, rolled out country by country. These programs report three results: a unified customer view through the token, cross-channel returns everywhere, and centralized multi-country reconciliation. They also let retailers launch new journeys, such as mobile checkout on the sales floor, kiosks, and line-free stores, with no new payment integration.

Leading unified commerce platformsAdyenStripeWorldlineNexi

• Start with the token: without a cross-channel customer identifier, omnichannel is only cosmetic.
• A single order ID carried through every transaction, on every channel.
• Tackle returns first: they are the most visible journey for customers and the most painful one in a siloed setup.
• Bring finance in from day one: unified reconciliation drives the accounting close. It is not an “IT” project.
• Migrate country by country or brand by brand, never in a big bang: in-store payments cannot tolerate any downtime.