Invoice Destination Tag

Overview

An invoice destination tag is a secondary routing identifier included with a payment address on networks that use one shared address to receive funds for many users or invoices. For reliable reconciliation, the value should remain traceable from invoice creation through payment monitoring and final reporting.

The payer must submit both the destination address and the assigned tag, memo, or numeric identifier. The payment system reads that secondary value from the transaction and uses it to attribute the transfer to the correct invoice or account. 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.

Checkout instructions should display the tag prominently, validate its format, and warn that omitting or changing it can prevent automatic credit. Matching logic should never rely on the shared address alone when a tag is required. 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 destination tag is not a blockchain address and does not control funds. It is also distinct from a free-form payment memo because many networks treat the tag as a structured routing field. It should be interpreted alongside Invoice Payment Address, Invoice Payment Memo, Memo-Based Payment Matching. These concepts belong to the same workflow, but each answers a different operational question and should not be collapsed into one ambiguous field.

When several invoices receive XRP at the same custodial address, each invoice can have a different destination tag; the combination identifies the intended payment record. 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.