Why One Address Per Invoice Is a Functional Requirement
Crypto payment detection works by monitoring a set of blockchain addresses and triggering order updates when transactions arrive at those addresses. If a single address is shared across multiple invoices, the gateway cannot automatically determine which incoming payment belongs to which order — two customers paying simultaneously produce two incoming transactions at the same address, both of which the gateway detects but neither of which can be automatically matched to an order based on address alone.
Amount-based matching is an unreliable secondary approach: two customers could be paying the same amount for different orders, or the amounts could differ slightly due to rounding. Time-based matching (the earlier arriving payment belongs to the first invoice) fails for simultaneous arrivals and creates edge cases for late payments. The unique address model eliminates these problems entirely by making the address itself the order identifier.
How Gateways Generate Unique Addresses at Scale
Large payment gateways may have thousands of merchants, each processing hundreds of orders simultaneously, requiring millions of unique receiving addresses across multiple blockchain networks. Generating and monitoring this volume of addresses is feasible through HD wallet architecture combined with address derivation and monitoring infrastructure.
For each merchant account, the gateway maintains an extended public key (xpub) derived from the merchant's HD wallet master key. When a new invoice is created, the gateway's address generation service derives the next child address in the merchant's derivation sequence and assigns it to the invoice. The gateway's blockchain monitoring service adds this address to its watch list and begins scanning incoming blocks and the mempool for transactions to it. When the invoice is complete (paid or expired), the address remains on the watch list for a period to catch late or partial payments.
UTXO Management — the Hidden Cost of Many Unique Addresses
On Bitcoin and other UTXO-based blockchains, each incoming payment to a unique address creates a separate Unspent Transaction Output (UTXO). A gateway receiving 1,000 Bitcoin payments per day accumulates 1,000 new UTXOs daily. To spend these funds — for merchant settlements, refunds, or treasury management — the gateway must construct transactions that consolidate multiple UTXOs as inputs, which increases transaction size, network fees, and node storage requirements.
Professional gateways manage this through UTXO consolidation: periodically combining many small UTXOs into fewer larger ones during periods of low network fee pressure, reducing the cost of future spending. UTXO consolidation is a background operational task that merchants never see but that affects the gateway's operational efficiency and the settlement fees they charge. Gateways with poor UTXO management accumulate fragmented balances that become expensive to spend as fee markets tighten.
Monitoring for Late Payments to Expired Addresses
When an invoice expires, the associated unique payment address is no longer considered active for that order. But the address still exists on the blockchain and can still receive funds — a customer who pays 45 minutes late to an expired invoice will have their transaction confirmed at an address the gateway is still technically capable of detecting.
Gateways handle this by keeping recently-expired addresses on a secondary watch list for a period — typically 24–72 hours — flagging any incoming transactions as 'late payments' requiring manual review. The merchant's operations team can then decide to credit the customer's order manually, issue a refund, or apply the payment to a new order. Gateways with automated late payment handling can significantly reduce the manual workload from this edge case.
Compliance Note: This glossary entry is provided for general educational purposes only and does not constitute financial, investment, legal, or tax advice. Industry terminology may vary across jurisdictions and providers; definitions herein may not directly reflect the specific features, terms, or specifications of Finassets' services. For details on Finassets' offerings, please refer to official product documentation or contact our team directly.