Invoice Payment

Overview

Invoice payment is a payment attempt or completed transfer applied to an invoice balance. It can be full, partial, late, duplicated, reversed, refunded, or overpaid and must be linked to the exact invoice and currency context. An invoice can have several attempts and several applied payments, so systems should not store payment as one unstructured field or overwrite earlier events.

The payment rail returns method-specific states such as authorization, pending, confirmed, settled, returned, or chargeback. The invoice balance should update only according to the organization’s application rules.

For crypto, the transaction must match asset, network, address or memo, amount, execution, and confirmation policy. Sender address alone does not prove customer identity.

A replacement invoice or new quote can coexist with an earlier unpaid attempt. Idempotent mapping prevents one transaction from paying two invoices or one callback from creating duplicate credits.

Risks include premature paid status, unmatched transactions, duplicate application, incorrect exchange rate, partial payment ignored, and refunds detached from the original payment.

Systems should store payment ID, invoice ID, attempt, method, amount, currency or asset, transaction, status history, amount applied, fees, settlement, and reversal.

For Invoice Payment, the operational boundary with Expired Invoice Payment and Wallet-Based Invoice Payment should be explicit. Identifiers for Invoice Payment should connect those records without allowing either linked status to overwrite its own state.

For Invoice Payment, the invoice and the payment used to settle it should remain separate records. When Invoice Payment interacts with Expired Invoice Payment, the invoice defines the commercial obligation, parties, amount, denomination, tax, due date, and revision history; payment records hold quotes, addresses, transaction identifiers, confirmations, fees, refunds, and settlement. In the relationship between Invoice Payment and Wallet-Based Invoice Payment, keeping these layers separate prevents a late payment, repricing event, or refund from silently changing the document originally issued to the customer.