Transaction-Based Matching

Overview

A matching engine begins with expected payment data: invoice ID, supported network, asset identifier, destination, requested amount, expiration, and optional memo or tag. It then evaluates observed transactions against those conditions.

Exact transaction matching works well when every invoice has a unique address or reference. Reused addresses require additional context such as amount, time window, customer mapping, or memo. Token payments need verification of the correct contract and transfer event, because the top-level transaction destination may be a router or token contract.

One invoice can receive multiple partial transactions, and one transaction can include several transfers. The data model should support many-to-many relationships rather than assuming one transaction equals one payment. Overpayments, late payments, and unsupported assets need exception paths.

Idempotency prevents the same transaction from being matched twice when providers repeat events or an indexer replays blocks. Canonical block tracking allows matches to be reversed or re-evaluated after a reorganization.

The result should remain auditable. Store the matching rules, evidence, confidence, and any manual decision. Transaction-based matching provides accurate attribution only when technical blockchain data and business payment context are evaluated together.

Matching engines should protect against ambiguous equal-amount payments. Two customers can send the same asset and amount to a shared address within seconds. Unique addresses or references provide stronger attribution. When ambiguity remains, the system should pause automatic credit and request evidence rather than guess. Manual matches need approval and should record why competing transactions or invoices were excluded. Matching confidence should remain visible when attribution depends on timing or reused destinations.