Payment ID

An accounting reference

The recipient assigns the reference for its own accounting. It can help a service distinguish deposits that otherwise arrive under the same public wallet keys. A transaction ID instead identifies the transaction itself, regardless of the service account it is meant to credit.

An integrated address packages the short ID with the normal public address information. The wallet can then construct the supported encrypted payment-ID field. The address string itself contains the reference, so sharing that string shares the embedded value too.

References: Integrated addresses · Monero source: wallet/wallet2.cpp

Subaddresses and older instructions

Subaddresses provide another way to distinguish incoming payments without asking a sender to manage a separate reference field. They have their own key derivation and privacy properties.

Do not assume every payment-ID instruction found in an older guide applies to a current wallet. Check the address type and supported workflow before sending, particularly when depositing to a service that performs its own account matching.

References: Integrated addresses · Subaddress construction

Example

A service gives a customer an integrated deposit address. A compatible wallet reads the embedded short payment ID and includes it encrypted in the payment so the service can associate the incoming transfer with that customer.

References: Integrated addresses · Monero source: wallet/wallet2.cpp

Limits and cautions

A payment ID is not the transaction hash, and it is not a wallet secret. Historical unencrypted long payment IDs differ from the short encrypted form. Follow the recipient and wallet instructions rather than adding a separate legacy ID by habit.

References: Integrated addresses · Monero source: wallet/wallet2.cpp