Monero’s Integrated Addresses in XMRWallet: Payment ID Replacement and Why Its Privacy Isn’t Obvious

A merchant accepting Monero payments faces a practical constraint: how to tie an incoming transaction to a specific customer order without exposing the relationship on the blockchain. Before integrated addresses, merchants used payment IDs—a 64-character or 8-character identifier appended to transactions that could link payments to orders but also created a permanent record visible to anyone examining the blockchain. Integrated addresses were designed to solve that problem by encoding the payment ID directly into the address itself, making the system more compact and less obviously identifiable as a privacy mechanism. Yet convenience and privacy are rarely the same thing, and the integrated address system introduces its own set of assumptions about what “private” actually means in practice.

The question is not whether integrated addresses work technically—they do. It is what metadata they reveal despite being layered into Monero’s stealth address system, and how a merchant or wallet user should think about that revelation. A non-custodial wallet like XMRWallet wallet can manage integrated addresses without intermediaries, but the wallet’s role is to implement the mechanism, not to eliminate the user’s need to understand what it protects and what it does not.

How integrated addresses encode payment information

A Monero address is normally 95 characters long and consists of a public view key and a public spend key. An integrated address extends that by 16 additional characters representing an 8-byte payment ID, creating a 106-character string. When a sender uses an integrated address, the payment ID is encrypted and embedded in the transaction output itself. The recipient, who possesses the corresponding private view key, can derive the payment ID after receiving the transaction by decrypting it with their view key.

The encryption is one-way from the sender’s perspective. A sender cannot be sure that only the intended recipient sees the payment ID; they only know that their action was to include it in the transaction. The recipient, by contrast, can scan transactions and automatically retrieve the payment ID without needing to maintain a separate database or ask the sender to communicate it through another channel. This is why integrated addresses were presented as an improvement over the old payment ID system: the information is kept closer to the transaction and less obviously identifiable to an outside observer as a correlation vector.

The critical detail is that integrated addresses create a deterministic one-to-one mapping between a merchant’s receiving address and the payment ID embedded within it. If a merchant generates a new integrated address for each customer order, each address corresponds to exactly one order ID. From the recipient’s perspective, this is invaluable—they can simply check which payment IDs arrived and process orders automatically. From a privacy perspective, this creates a potential liability if the same integrated address is reused across multiple transactions, because all transactions to that address become linked.

Monero’s stealth addresses are designed to prevent the blockchain observer from determining which outputs belong to which address. Every transaction to a Monero address generates a unique one-time public key, so even if the same address receives multiple payments, the outputs are computationally unlinkable on the blockchain. Integrated addresses operate within this system, but they add a second layer—the payment ID itself—that can serve as a secondary linking vector if not managed carefully.

The metadata leakage that integrated addresses permit

An observer cannot decrypt the payment ID in a transaction without possessing the recipient’s private view key, which is the security foundation. However, several metadata patterns can emerge that do not require decryption. First, if a merchant publishes an integrated address on their website and later announces that they received payment via that address for a specific order, the observer can correlate the published address with the payment ID embedded in the transaction. Second, if a merchant uses a predictable or sequentially generated payment ID, an observer can infer order volumes or payment patterns even without decrypting the ID itself.

Third, and most practically, if a sender reuses the same integrated address, the stealth address mechanism continues to generate unique one-time outputs, but the payment ID is always the same. An observer cannot see the payment ID, but they can see multiple outputs to the same address—a visible pattern that contradicts Monero’s privacy goal of breaking the link between address and transaction. Regular Monero addresses are most private when used once; integrated addresses amplify this principle because linking multiple outputs to one address is less visible but still forensically possible if the merchant later reveals which address was used for which order.

The most significant leakage occurs at the point of disclosure. When a merchant publishes a QR code or address and associates it with an order number, a third party observing that publication learns the correlation. The integrated address itself prevents the public ledger from revealing the payment ID, but it does not prevent the merchant from revealing it through their own business processes. A better model is to treat the integrated address as a semi-private communication channel between the merchant’s wallet and the customer—useful for automation, but not a substitute for careful business-process design around which addresses are published and when.

Why old payment IDs are still worth understanding

The original payment ID system, which predated integrated addresses, allowed merchants to include a separate 64-character or 8-character identifier in a transaction using a transaction extra field. This was not encrypted; any observer could see it in the transaction data. A merchant might encode an order number or customer reference directly in that field, making the correlation obvious to anyone analyzing the blockchain. The payment ID was a convenience feature for the merchant, but it was a privacy catastrophe because the linking information was transparent.

Integrated addresses were created to hide that linking information through encryption, making the same workflow less transparent to outside observers. But the shift from transparent to encrypted does not mean the merchant can ignore the privacy implications. The payment ID is still being created and still being sent; it is just no longer immediately readable without the private view key. This is a real improvement, but it is contingent on proper use. If a merchant publishes the integrated address, announces the payment ID through a different channel, or links the address to customer identity through their website, the privacy gain diminishes.

The practical lesson is that the old payment ID system forced merchants to think about linkage because the field was visible. The integrated address system can encourage merchants to ignore linkage because it is encrypted. In reality, both systems require the same discipline: using a unique address or payment ID per transaction, not reusing addresses, and being cautious about which correlations are revealed through business processes outside the blockchain itself.

Stealth addresses and why they do not fully protect integrated address patterns

Monero’s stealth address mechanism works by deriving a unique one-time public key for each output, ensuring that an observer cannot cluster payments to the same address by examining the blockchain alone. The recipient, who holds the private view key, can scan the blockchain and identify which outputs belong to their wallet by attempting to decrypt the one-time keys. This is the core of Monero’s privacy model: the public ledger does not reveal address-to-transaction relationships, while the recipient can efficiently identify their own payments.

Integrated addresses inherit this protection. The payment ID encrypted within the transaction is not guessable by an observer without the view key, and the one-time keys continue to provide unlinkability. However, the privacy model has a weak point when integrated addresses are reused. If a merchant receives multiple payments to the same integrated address, an observer sees multiple outputs that share no obvious public link on the blockchain—because stealth addresses prevent that link from being visible. But the merchant’s own business records, website, or customer service interactions may later reveal which address was used for which order. At that point, the privacy of multiple transactions becomes interdependent.

A more robust approach is to treat stealth addresses and integrated addresses as complementary but separate mechanisms. Stealth addresses protect the link between address and output; integrated addresses encrypt the payment ID. Neither one prevents the merchant from leaking correlation information through operational practices. A merchant accepting payments for customer orders should generate a new integrated address for each transaction, never publish the address after use, and be cautious about combining blockchain analysis with customer records that might reveal the address-to-order relationship retroactively.

Practical merchant workflows that preserve payment privacy

A sound payment flow begins with generating a unique integrated address for each customer order, either manually or through automated wallet software. The address is communicated to the customer through a private channel—an invoice, email, or payment page that is not publicly archived or indexed. The customer sends XMR to that address with confidence that the payment ID will reach the merchant without being visible to blockchain observers. The merchant’s wallet automatically derives the payment ID upon receiving the transaction and updates the order status without manual correlation.

The critical step many merchants miss is to retire the address after use. If an address is used once and never published afterward, an observer cannot easily correlate the address with an order even if they examine the merchant’s website months later. If the same address is reused, the observer can eventually infer that multiple payments share a common destination, which violates the privacy assumption. This is why fungibility in Monero depends partly on merchant discipline: every reused address is a potential point where transaction linkage becomes possible.

For higher-value transactions, a merchant might also consider whether to publish the integrated address at all. Instead, the address could be generated on demand during checkout, communicated through HTTPS, and then discarded from the merchant’s public-facing systems. The customer receives a one-time address, verifies the payment ID matches what was shown, and submits the transaction. The merchant’s wallet processes the payment using the payment ID, and the address never appears in public records. This flow requires more infrastructure but provides stronger privacy guarantees.

A related consideration is transaction timing. If a merchant publishes an integrated address at noon and the payment arrives within seconds, an observer with sufficient network monitoring might infer a correlation based on timing alone. This risk is low for most merchants, but it illustrates why privacy should be thought of as a system rather than as a feature. The integrated address provides one layer; business process design provides another; and the customer’s own network and device behavior provides a third.

What wallet users should know when receiving to integrated addresses

From a user’s perspective, receiving XMR to an integrated address is straightforward: the wallet generates or receives an address, displays it to the payer, and the transaction arrives normally. The payment ID is decrypted automatically by the wallet software. Users do not need to understand the encryption mechanism any more than email users need to understand TLS; the wallet handles the technical details. However, users should understand one important principle: transaction privacy on the receiving side depends on the privacy of the address itself.

If a user publishes an integrated address on their website and later a payment arrives to that address, an observer can build a record that “this address received a payment at this time.” They cannot see the payment ID, but they can see that a transaction occurred. If the user later publishes another integrated address and another payment arrives, an observer can correlate the two addresses as belonging to the same entity through timing, IP addresses, or other metadata. The takeaway is that integrated addresses are most private when used exactly once and not published after use.

Users also benefit from understanding that the payment ID itself is not magic; it is simply a piece of data encrypted and embedded in the transaction. If a user is expecting a payment and knows what payment ID to look for, they can have their wallet notify them automatically. But this also means that if a user compromises their private view key—by sharing it with a third party, storing it insecurely, or using it on a compromised device—that third party can now decrypt and read all payment IDs in all transactions to that wallet’s addresses. The view key is called “private” for a reason; it should be protected as carefully as the spending key.

Comparing integrated addresses to alternatives

An alternative to integrated addresses is to maintain a separate database mapping addresses to orders. A merchant could generate a standard Monero address for each customer, record the address and order ID in a local database, and then manually or automatically match incoming transactions to orders based on the address alone. This approach preserves the stealth address privacy model without adding an encrypted payment ID field. The drawback is operational: the merchant must manage the mapping database and ensure that addresses are retired or tracked correctly.

Another alternative is to use subaddresses, which Monero wallets can generate in large numbers from the same underlying seed phrase. A subaddress is a separate receiving address derived from the wallet’s private view key and a unique index. Each subaddress generates its own stealth outputs, but all subaddresses are controlled by the same private key. A merchant could assign one subaddress per customer and let the wallet automatically distinguish incoming payments by subaddress. This approach avoids the payment ID altogether and relies purely on address-based differentiation. It is simpler than maintaining an external database and does not introduce an encrypted field that requires careful handling.

Integrated addresses are most useful when merchants want automatic payment ID recognition without maintaining an address-per-order database or generating new subaddresses for every transaction. They are less useful when privacy is paramount and the merchant can afford the operational complexity of explicit address retirement. The choice depends on the merchant’s infrastructure, transaction volume, and privacy requirements. For most use cases, integrated addresses are a reasonable middle ground: better than transparent payment IDs, but not a substitute for careful address hygiene.

Long-term privacy implications and responsible disclosure

Monero’s strength is that privacy is the default, not an optional add-on. Every transaction uses ring signatures and confidential transactions by default; the sender does not need to choose a privacy mode or enable a feature. Integrated addresses fit that model by encrypting the payment ID automatically, without requiring the merchant to make an additional decision. However, this default-private design can create a false sense of security if users or merchants assume that using Monero means their transactions are private regardless of how they manage addresses.

The real privacy boundary is between what the blockchain can reveal and what the merchant’s operational practices reveal. The blockchain will not show the payment ID or link multiple outputs to the same address (due to stealth addresses). But the merchant’s own records, website, customer communications, and business analytics can reveal all of that information and more. A merchant using integrated addresses responsibly accepts this boundary and makes decisions accordingly: never reusing addresses, retiring addresses after use, and being cautious about publishing which addresses correspond to which orders.

Looking forward, the privacy community continues to debate whether payment IDs—integrated or otherwise—are necessary. Some proposals suggest that Monero could eventually move to pure address-based or subaddress-based differentiation, eliminating the payment ID field entirely. Other suggestions focus on improving wallet software to make the address retirement workflow more automatic and less error-prone. The goal is to reduce the number of operational decisions that merchants must make correctly to preserve privacy. Until that evolution occurs, integrated addresses represent a functional improvement over transparent payment IDs, but they require the same discipline and awareness from users.