A link or QR code makes it easy for someone to find your receiving address.
Review the payment
The sender checks your identity and amount before approving. Opening the link never sends money by itself.
Receive with a record
The completed payment carries its own receipt, separate from the request that prepared it.
An explanatory model. No account action is performed.
Share where to pay
Receive offers your username and a link that opens a payment addressed to your account. Copy or share it through the available device controls. The destination is resolved through Receiz; a familiar username is a convenient address, not the signing authority.
Opening is not paying
Opening a receiving link prepares a payment. It does not transfer money. The sender still checks the recipient and amount and authorizes the action with their own identity. A request can describe an intent without granting access to either account.
Links and QR codes
A QR code or programmed NFC link is another way to carry a request. Check the resolved destination rather than trusting an image or surrounding text. A tampered request must not silently change the recipient of a signed payment.
An amount, when provided
A request may include an amount or leave it for the sender. The final review is authoritative for the action being approved. Changing a requested amount means reviewing that new amount before signing; the visual appearance of the request cannot expand consent.
Share the result separately
A receiving link asks for payment. A transaction receipt records an event and its supported result. Share the receipt when someone needs the actual evidence, including its moment, amount and source context. Keep private identity material out of either link.
Method, sources and assessment
This explanation describes the supported implementation. Exact protocol requirements come from the pinned Receiz contracts and original sources. A reference result does not qualify a production deployment or a physical device.