Compare wallet links, plain addresses, hosted request pages, QR codes, and the fallback details that keep a payment understandable when a link fails.
Best at: prefilling destination, amount, network, token, and reference in compatible wallets.
New risk: the payer must verify both the web domain and the decoded blockchain transaction.
Required fallback: a complete plain-text payment block.
Best at: broad portability across wallets, exchanges, hardware devices, and command-line tools.
New risk: the payer manually selects network, token, amount, and any memo.
Required context: exact network, token identity, amount, fee rule, and reference.
Use a short first-party host. Avoid URL shorteners and tracking redirects that conceal the destination.
Show the full destination, asset, network, amount, reference, and expiration before opening a wallet.
The wallet should explain the transfer or contract interaction and require explicit approval.
When unsupported or expired, display the verified invoice details instead of silently changing parameters.
Some wallets ignore amounts, fail to switch networks, support native transfers but not tokens, or do not register as link handlers. Test the exact route on the devices your customers use.
The page may prepare a request. It should not ask for a seed phrase, private key, exported wallet file, one-time code, or remote-control access. The final transaction belongs in the user’s chosen wallet.
For a material payment, compare the wallet preview with the plain-text invoice and independently confirm a new or changed destination.
Open the security checklist →See when a link reduces manual errors, when an address is more portable, and why a hybrid request is often the strongest practical design.
Read payment links vs addresses →