How does Matcher™ match transactions automatically?
Through a cascade running from the most precise strategy to the most tolerant. First by reference, when the notification and the transaction share an exact payment identifier. Then by merchant order reference. Then by data, comparing amount, store, payment method and a date window. Then by pairing, when a transaction is offset by an opposite movement such as a sale and a refund of the same amount in the same store. A transaction becomes Matched once the full amount is covered, and stays Pending while part of it remains.
In detail
Matcher™ runs a cascade of strategies, from the most precise to the most tolerant, and stops at the first one that resolves the transaction.
The cascade
- By reference, when the provider notification and the transaction share an exact payment identifier.
- By merchant order reference.
- By data, comparing amount, store, payment method and a date window.
- By pairing, when a transaction is offset by an opposite movement, such as a sale and a refund of the same amount in the same store.
A transaction becomes Matched once its full amount is covered, and stays Pending while part of it remains.
The cases that do not match on their own
Real operations produce more of these than expected. One sale can generate several terminal notifications, which Matcher™ aggregates until their total equals the receipt. One ticket can be paid with two methods. An amount can arrive in several parts. A notification can arrive hours after the receipt because a terminal processed offline, which the date window absorbs. A ticket that never generates a payment, such as a cancelled sale, is matched with a dedicated reason so it does not surface as a false exception.
What remains unmatched goes to your merchants' finance teams with the context they need to decide.