Integrated Address

Overview

A Monero integrated address combines a standard address with an encrypted short payment ID in one longer encoded string. Exchanges historically used it to associate incoming XMR transfers with a particular customer or invoice without requesting a separate identifier field.

The embedded value supports attribution but does not create a new wallet or destination key. Integrated addresses differ from subaddresses, which provide distinct receiving addresses and stronger separation for individual payers or purposes. Modern services commonly prefer subaddresses. Wallets and processors must validate the complete address type and network, preserve every character, and ensure their software supports integrated-address transactions. A payment ID should never be treated as a security secret. Deposit systems should credit only after detecting the canonical transaction, confirming the destination, amount, and required network confirmations.

Integrated Address is an identifier or spendable object, not proof of legal ownership and not a secret credential. Authorization depends on keys, scripts, contracts, or protocol rules, while custodial systems may expose an identifier without giving the user direct control of the underlying account. Normalization, case conversion, truncation, and alias resolution need protocol-aware rules, because a visually similar value can represent a different destination or fail checksum validation. Systems storing Integrated Address should preserve the exact value together with chain identifiers and type metadata.

Testing for Integrated Address should include valid and invalid examples, wrong-network values, boundary encodings, contract destinations, and any memo or tag requirements. Higher-value transfers benefit from an independent destination check rather than reliance on shortened display text. Technical takeaway: Integrated Monero addresses package destination and attribution data together, but subaddresses are generally the cleaner modern receiving method.