The Technical Stack Behind Payment Detection
Blockchain monitoring for payment gateways requires a layered technical architecture that processes blockchain data from raw network events to merchant-facing payment status updates. At the network layer, the gateway connects to blockchain nodes — either self-operated or via third-party providers — that stream new blocks and mempool transactions as they are observed by the network. Raw transaction data from the node is parsed by a transaction filter that extracts only transactions relevant to the gateway's monitored addresses.
Relevant transactions are passed to a confirmation tracker that maintains state for each monitored payment — the TXID of the transaction, its current confirmation count, the required threshold for the associated invoice, and the invoice status. As new blocks arrive, the tracker increments confirmation counts for all transactions in those blocks and evaluates whether any have reached their threshold. When a threshold is reached, the tracker triggers a payment confirmation event that updates the invoice status, credits the merchant's gateway account, and queues a webhook notification for delivery.
Mempool Monitoring vs. Block Monitoring
Most production payment gateways monitor both the mempool (unconfirmed transactions) and confirmed blocks, for different purposes. Mempool monitoring enables 'payment detected' early notifications — the gateway tells the merchant and customer that a payment has been broadcast and is awaiting confirmation, providing feedback that the customer's transaction was received before the 10-minute wait for a Bitcoin block. This early notification is important for customer experience: without it, customers see no feedback after initiating payment and may worry the transaction was lost.
Mempool monitoring also enables zero-confirmation acceptance (for gateways that offer it) and RBF detection (identifying transactions that have opted into Replace-by-Fee and therefore carry double-spend risk). Block monitoring handles confirmation counting and final status updates. Some gateways also monitor the mempool for conflicting transactions — a second transaction spending the same inputs as a pending payment — as an early warning of potential double-spend attempts.
Handling Chain Reorganisations in Payment Monitoring
A chain reorganisation occurs when the network switches from one chain tip to a longer alternative chain, invalidating blocks that were previously considered confirmed. From a payment gateway's perspective, a reorg can invalidate transactions that were already credited to merchant accounts — the payment was 'confirmed' in the original chain but does not appear in the replacement chain. The gateway's monitoring system must detect reorgs, identify affected transactions, and reverse any merchant credits that are no longer valid on the canonical chain.
Reorg detection requires comparing the gateway's internal record of which block contained each confirmed transaction against the current canonical chain state after a potential reorg is detected. Shallow reorgs (1–2 blocks) occur naturally in healthy networks and should be handled gracefully. Deep reorgs are rare on established networks but devastating if not handled — a 6-block reorg on Bitcoin, while extraordinarily unlikely, would invalidate transactions that many gateways had already considered final. Confirmation threshold requirements (waiting for 6 blocks for Bitcoin) exist precisely to make deep reorgs economically prohibitive for any realistic attack.
Multi-Chain Monitoring Architecture
A payment gateway supporting 10 or more blockchain networks must maintain independent monitoring pipelines for each chain, since they all have different block structures, transaction formats, address types, and event models. Scaling this monitoring while maintaining consistent reliability across chains requires careful architecture: a common monitoring abstraction layer with chain-specific adapters, centralised confirmation state management across all chains, unified alerting and incident response for monitoring failures per chain, and separate health dashboards for each chain's node connectivity and monitoring latency.
The operational discipline required for multi-chain monitoring is one of the reasons that gateway network coverage quality varies significantly between providers. Adding a new chain to the supported list is not simply a checkbox — it requires provisioning nodes, implementing the chain-specific monitoring adapter, testing against the chain's testnet, establishing blockchain analytics coverage for the new chain, and integrating the new chain's network fees into the gateway's fee management system.
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.