Invoice Acceptance Rule

Overview

An invoice acceptance rule is the set of conditions a payment system applies before treating an observed blockchain transfer as a valid payment for a specific invoice. In an operational payment system, this field or policy should have one authoritative meaning across the API, checkout, webhook, ledger, and support tools.

The rule normally evaluates the destination, asset, network, requested amount, permitted tolerance, payment window, transaction status, and required confirmation level. Some implementations also check memo or destination-tag values, token contract addresses, and whether a transfer has already been attributed elsewhere. 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 merchant should define the rule server-side, version it, record which version was applied, and keep exception reasons when a payment is rejected or held. Acceptance should be idempotent so repeated webhooks or chain scans cannot credit the same transfer twice. 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 is not the same as an invoice fulfillment rule. Acceptance decides whether money satisfies the payment instruction; fulfillment decides whether the business should release goods, activate service, or update an order after that decision. It should be interpreted alongside Invoice Fulfillment Rule, Invoice Confirmation Threshold, Invoice Payment Window. These concepts belong to the same workflow, but each answers a different operational question and should not be collapsed into one ambiguous field.

For example, an invoice requesting 100 USDT on Tron may accept a transfer only when it reaches the assigned address before expiry, uses the approved token contract, meets the amount tolerance, and has the required network confirmations. 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.