Invoice Confirmation Threshold

Overview

An invoice confirmation threshold is the minimum blockchain confirmation depth or finality condition that a payment must satisfy before the invoice can be treated as sufficiently secure. In an operational payment system, this field or policy should have one authoritative meaning across the API, checkout, webhook, ledger, and support tools.

The threshold may be expressed as a number of blocks, a finalized checkpoint, or a provider-defined network state. It can depend on the blockchain, asset, payment value, merchant risk tolerance, and whether fulfillment is reversible. 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.

Thresholds should be configured by network rather than copied blindly across chains, documented as policy, and applied consistently by the payment state machine. Changes should not retroactively alter already accepted invoices without a controlled migration rule. 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 confirmation count, which reports current progress, and from the merchant confirmation policy, which is the broader framework that may include thresholds, exceptions, value bands, and fulfillment timing. It should be interpreted alongside Invoice Confirmation Count, Low-Value Confirmation Policy, Merchant 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 low-value digital purchase may require one Bitcoin confirmation, while a high-value shipment may require several; a proof-of-stake network may instead require an explicit finalized state. 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.