Invoice Confirmation Threshold

Overview

Context and purpose

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.

How it works

The threshold defines the minimum chain-specific security or finality condition before an invoice is considered sufficiently confirmed. Some networks use block counts; others have explicit finalized states that cannot be compared one-for-one.

Practical checks and failure points

Do not apply an Ethereum block count to Solana or a rollup without translating the finality model. Record the policy version used for each invoice.

Related concepts

Invoice Network · Invoice Reconciliation