Network-Based Confirmation Threshold

Overview

A network-based confirmation threshold is a payment policy that assigns different confirmation or finality requirements according to the blockchain on which a payment occurs. For reliable reconciliation, the value should remain traceable from invoice creation through payment monitoring and final reporting.

The threshold accounts for block production, reorganization behavior, consensus finality, transaction replacement, security assumptions, and the provider’s ability to observe the network. It can also vary by transaction value within each network. In practice, the system should preserve the original request, the observed blockchain or checkout evidence, and every status change that affects this value. This makes support investigations and financial reconciliation possible without reconstructing the payment from screenshots or mutable client data.

The configuration should use canonical network identifiers, distinguish probabilistic confirmations from explicit finality, be reviewed after protocol changes, and avoid presenting one universal confirmation number as equally secure everywhere. The implementation should use exact asset precision, authenticated server-side updates, and idempotent processing wherever repeated API calls, blockchain observations, or webhook deliveries can occur.

It differs from invoice confirmation threshold, which is the concrete requirement attached to one invoice; the network-based threshold is a reusable policy input used to calculate that requirement. It should be interpreted alongside Invoice Confirmation Threshold, Merchant Confirmation Policy, Low-Value Confirmation Policy. These concepts belong to the same workflow, but each answers a different operational question and should not be collapsed into one ambiguous field.

A merchant may require more block confirmations on Bitcoin, explicit finalized status on Ethereum, and a different commitment level on Solana before marking comparable payments paid. The practical test is whether a merchant can explain how the value was produced, verify it independently, and apply the same rule consistently when the payment is delayed, duplicated, partially paid, refunded, or reviewed manually.