What a destination tag is
Some networks let a single address represent many separate accounts. A custodian, an exchange, or a payment service can hold one XRP Ledger address and use it to receive funds for thousands of customers at once, rather than creating and funding a fresh address for every account. That keeps the number of on-ledger addresses small, but it raises an obvious problem: if everyone pays to the same address, how does the receiver know which payment belongs to which account?
The destination tag solves that. It is a 32-bit unsigned integer attached to the payment as a separate field — not part of the address itself, but sent with the transaction. When the payment arrives, the receiving service reads the tag and credits the matching internal account. The address gets the money to the right wallet; the tag gets it to the right account inside that wallet. On the XRP Ledger this field is called a destination tag; on chains such as Cosmos-based networks, Stellar, or some others, the equivalent is usually called a memo, and a few networks have no such concept at all.
Because the tag lives outside the address, getting it wrong does not bounce the payment — the funds still reach the address. They simply arrive unattributed, and the receiver has to reconcile or return them by hand. This is why a shared address is almost always published together with a required tag, and sending without it is a common, avoidable mistake.
What it means in a crypto payment
For a merchant, the destination tag matters most when paying out to, or collecting from, a counterparty that uses a shared address. Exchanges and custodial wallets routinely do this for XRP, so a payout to a customer's exchange account, or a settlement into a partner's pooled wallet, frequently comes with both an address and a tag. Treat the tag as part of the payment instructions: dropping it is the difference between funds being credited automatically and a support ticket to chase down an untagged deposit.
The flip side is receiving. If you publish one shared XRP address and rely on a destination tag to tell payments apart, a missing or wrong tag leaves you with a payment you cannot confidently attribute. Per-account deposit addresses avoid that ambiguity — each account has its own address, so the address alone identifies the payer and there is no tag to forget.
Destination tags on halfin
halfin gives each merchant persistent, per-merchant deposit addresses rather than pooling everyone behind one shared XRP address, so on the receiving side a payment is identified by its own address and a destination tag is not something a payer has to supply to be credited correctly. Invoices and deposit addresses carry what the customer needs to pay, and on the XRP Ledger that includes a destination tag whenever the receiving setup requires one — the value is shown in the payment details, not left for the customer to guess.
On the payout side, the tag is part of the destination. When you send a single or mass payout to an XRP destination that sits behind a shared address — a customer's exchange account, for example — the destination tag belongs with that payout request the same way the address does. Supplying it is how the receiving service attributes the funds to the right account; omitting it is the most common reason an otherwise valid XRP payout arrives but is not credited.