Invoice Payment Attempt

Overview

An invoice payment attempt is one identifiable effort by a payer or payment client to satisfy an invoice, whether the attempt succeeds, fails, expires, or remains pending. For reliable reconciliation, the value should remain traceable from invoice creation through payment monitoring and final reporting.

An attempt can be represented by a transaction, a checkout initialization, or a provider-side record that later receives blockchain evidence. An invoice may have multiple attempts because users retry, change assets, replace transactions, or send partial payments. 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.

Systems should assign attempt identifiers, preserve status history, prevent double credit across attempts, and distinguish retries from additional payments. Matching logic should not assume the first observed transaction is the only relevant attempt. 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.

A payment attempt is narrower than the invoice payment session. A session is the checkout context and instructions; one session may contain several attempts or transactions. It should be interpreted alongside Invoice Payment Session, Multi-Transaction Payment, Invoice Acceptance Rule. These concepts belong to the same workflow, but each answers a different operational question and should not be collapsed into one ambiguous field.

A payer may submit a low-fee transaction, replace it, and then create another transaction; the invoice records the attempts but credits only the transfer that satisfies the acceptance rule. 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.