Omnichannel payments: how to reconcile card-present and online payments in one ledger
To reconcile omnichannel payments in one place, every channel sends the same order reference, every acquirer's settlement file goes into one ledger, and each payment is matched to its order and payout.
A business tracks and reconciles omnichannel payments in one place by doing three things. Every payment, in store, online, in app or by phone, carries the same order reference into the gateway. Each acquirer's settlement file is loaded into one double-entry ledger. Each payment is then matched three ways: to its order, to its line in the settlement file, and to the bank payout that included it, with refunds booked against the original sale whatever channel they happen in.
What omnichannel payments are
An omnichannel business sells to the same customer through several channels: a terminal in a shop, a website, an app, a call centre taking card details by phone. Each accepts cards differently, often through a different acquirer, the bank that signs the merchant and pays it.
Selling everywhere is the easy part. Afterwards, two or three acquirers send back their own files on their own schedules, and finance has to prove that every sale became money in the bank.
How a business tracks and reconciles omnichannel payments in one place
The method is the same whatever the number of channels:
One order reference. Created before the payment and sent with it from every channel, so the acquirer's file carries it back.
One ledger. Every capture, fee, refund, chargeback and payout is booked in a double-entry ledger, with one receivable account per acquirer.
Every acquirer's file, every day, loaded as it arrives.
Three-way matching. Order to settlement line, settlement line to payout, payout to the bank statement.
An exceptions queue for whatever does not match, with its age and amount.
Reconciliation is that daily comparison. The rest of this guide shows each piece.
One customer, one card, several numbers
Customer C saves a card on the website, then taps a phone at the shop's till with the same card in a wallet. To the merchant's systems, that one card can be three different numbers.
The card number (PAN) is what the website collected the first time, or what the shop's terminal read from the chip.
A network or device token replaces the PAN when the card sits in a phone wallet or on file with a merchant. EMVCo, which writes the standard, says a token is limited to a specific merchant, device or payment scenario (EMV Payment Tokenisation).
A gateway token is the merchant's own reference for a stored card, so its systems never hold the PAN.
The thread that ties them together is the Payment Account Reference (PAR), which EMVCo's framework defines to link payments made with tokens to the PAN they were issued for. Visa's rules give every Visa account one, require acquirers to be able to pass it to the merchant, and limit its use to customer service, fraud and risk control, services the cardholder opted into, and legal compliance (Visa Core Rules, sections 1.5.1.6, 4.1.1.14 and 7.8.1.1).
Payment tokenisation keeps the card number out of the merchant's systems; the PAR keeps the customer recognisable across them.
Card-present and card-not-present: different rules, liability and fees
The schemes split every card payment into two worlds. Visa defines a card-present transaction as one where the card and the cardholder are physically at the merchant and the payment goes through an acceptance device, and adds that it must not use a stored credential. Everything else, including a saved card charged at the till, is card-absent (Visa Core Rules, glossary). Mastercard's rules list e-commerce, mail order, phone order and credential-on-file as card-not-present (Mastercard Transaction Processing Rules, 3.2).
The split changes who pays for fraud. In store, Visa's EMV liability shift lets an issuer dispute counterfeit fraud on a chip card when the payment did not use the chip, for example at a terminal that cannot read one. Online, an issuer can dispute any payment the cardholder denies, unless, among other cases, it was authenticated with Visa Secure on EMV 3-D Secure and sent with ECI 5 and the authentication value (Visa Core Rules, dispute conditions 10.1 and 10.4).
It also changes the price. Visa's published US table, effective 24 October 2026, sets interchange on an exempt Visa debit card at 0.80% + $0.15 at a retailer in person, against 1.65% + $0.15 for the same card not present (Visa USA Interchange Reimbursement Fees). In the EU, the Interchange Fee Regulation caps interchange on consumer debit cards at 0.2% and on consumer credit cards at 0.3% of the transaction's value (Regulation (EU) 2015/751, Articles 3 and 4).
So one ledger holds fees that differ by channel and card type, and disputes whose liability depends on how each payment was taken.
What each acquirer sends back
Each acquirer reports in its own format and on its own timetable, but the content is similar. In the EU, after each card payment the merchant's payment provider must give it a reference to identify the payment, the amount credited, and the charges, "indicating separately the merchant service charge and the amount of the interchange fee". Contracts may allow this to be provided periodically, at least once a month (Regulation (EU) 2015/751, Article 12).
A settlement file line usually holds the acquirer's reference, the merchant's order reference if it was sent, the channel or terminal, the card brand and type, the gross amount, the fees and the payout batch. Refunds, chargebacks and reserves are lines of their own.
The payout is never the day's sales: Visa's rules require an acquirer to pay the merchant the transaction totals less refunds, discounts, disputes, agreed fees and any reserve (Visa Core Rules, 1.5.6.2). Each acquirer also has its own cut-off time, so a payment taken late in the evening can land in the next day's file.
Matching a payment to an order and a payout: a worked example
With illustrative numbers, a retailer's shops use acquirer S, and its website, app and call centre use acquirer W. Fees are set in each acquirer's contract; these are made up.
On Monday, acquirer W's file has three lines:
Line | Order | Channel | Gross | Fees | Net |
|---|---|---|---|---|---|
1 | 1001 | Website | 120.00 | 1.80 | 118.20 |
2 | 1003 | App | 60.00 | 0.90 | 59.10 |
3 | 0990 | Refund, last week's order | −30.00 | 0.00 | −30.00 |
Payout batch W-1 | 147.30 |
Order 1001 is matched three ways. The order system says 120.00; the file's line 1 carries reference 1001, 120.00 gross and 1.80 of fees, of which 0.36 is interchange on a consumer credit card. On Wednesday the bank statement shows 147.30 from acquirer W with batch W-1, the sum of the three net lines.
In the ledger, that is three entries against one receivable account for acquirer W:
At capture: debit receivable from W 180.00 for orders 1001 and 1003, credit sales 180.00. Last week's refund was already booked when it was made, as a credit of 30.00 to the same account, so the receivable now stands at 150.00.
When the file arrives: debit card fees 2.70, credit receivable from W 2.70.
When the payout lands: debit bank 147.30, credit receivable from W 147.30.
After the payout, the receivable for W is back to zero, which is the test. The shops' file matches the same way: orders 1002 (80.00) and 1004 (200.00), fees of 0.80 and 2.00, and a payout of 277.20 from acquirer S.
One order breaks the pattern. Order 1005, 95.00 on the website, was captured at 23:10, after acquirer W's cut-off. It is in Monday's orders but in Tuesday's file, so it stays open in the receivable for a day and clears by itself. An item still open after that goes to the exceptions queue with its age.
Refunds across channels: buy online, return in store
Customer C bought order 1001 online and brings one item, worth 40.00, back to a shop. The schemes' rules set the limits.
Visa says a merchant must, "to the extent possible", refund to the same payment credential used for the purchase, with cash or store credit allowed only in listed cases, such as no proof of purchase (Visa Core Rules, 1.5.4.14). Mastercard's rule is a credit to the same card account, in the same currency and no more than the purchase, with the refund submitted to the acquirer within 15 days; for payments within Europe its rules allow a refund by any means (Mastercard Transaction Processing Rules, 3.14 and 3.15).
The shop has two ways to do it:
A referenced refund. The clerk finds order 1001 and refunds 40.00 to the original payment through the gateway. It goes back through acquirer W to the same credential, as a card-not-present refund.
A refund at the terminal. The customer taps a card or phone and the shop's terminal refunds 40.00 through acquirer S. Mastercard notes that when a phone or other device was used, the card number may not match the receipt even for the same account; the PAR shows whether it is.
Either way, the ledger books it against order 1001: debit sales returns 40.00, credit the receivable of the acquirer that paid it out. On the second route, acquirer S's next payout is 40.00 lower for a sale it never processed, and only the link to order 1001 explains why.
The reporting an enterprise needs
With every channel in one ledger, the reports follow:
Cash position by acquirer: what each one owes, what is paid, and what is expected tomorrow.
Exceptions with ageing: unmatched items by amount and days open.
Fees by channel and card type: EU acquirers must quote merchant service charges per card category and brand, unless the merchant asks for blended pricing in writing (Regulation (EU) 2015/751, Article 9).
Refunds by channel of sale and channel of refund, so cross-channel returns are visible.
Chargebacks by channel, with the liability each one carried.
Authorisation rates by channel and acquirer.
Security scope follows the channels too. PCI DSS applies to every entity that stores, processes or transmits cardholder data, merchants included (PCI SSC), and PCI SSC says merchants using its listed point-to-point encryption solutions at their terminals have fewer PCI DSS requirements (PCI SSC, P2PE). The PCI DSS guide covers what a gateway has to meet.
What to look for in enterprise omnichannel payment solutions
Test each solution against the method above. Does every channel carry the order reference to the acquirer? Does it load every acquirer's files, keep fees unblended, receive the PAR and book refunds against the original sale across channels? Is the ledger double entry?
Paynoramic's payment gateway books every payment, fee, refund and payout in a double-entry ledger, reconciled daily with processors and banks, with refunds and receipts in one place.
Frequently asked questions
Is a saved card charged at the till a card-present payment? Not under Visa's definitions. A payment completed with a stored credential counts as card-absent, even with the customer standing in the shop.
Do all channels need the same acquirer? No. Several acquirers work, as long as each one sends the order reference back and its files are loaded into the same ledger, with one receivable account each.
Why does the payout not match the day's sales? Because the acquirer pays sales less refunds, fees, disputes and reserves, and its cut-off time moves late payments into the next file.
See it in one place
Reconciliation across channels starts with the payment flow's design, not the month-end spreadsheet. See how our white-label payment gateway brings checkout, routing, the merchant dashboard, the ledger and payouts together, or start your project at paynoramic.com.
