A crypto invoice can be correct in two ways and still fail in the third. The recipient may be legitimate, but the payer chooses the wrong network. The network may be correct, but the token is a look-alike contract. The token may be correct, but a compromised email substitutes the destination. Because blockchain transfers are often difficult to reverse, verification has to cover all three dimensions before the wallet is authorized.
The routine does not need to be complicated. It needs to be consistent, independent of the current email when risk is high, and visible to the person approving the transaction. The goal is to move from “the message looks familiar” to “the exact recipient, asset, and network have each been checked against a trusted reference.”
Verify the recipient before the destination
Begin with the business relationship. Is the invoice expected? Does the amount and purpose match an order, contract, or conversation? Is the sender using the normal domain and tone? A valid-looking address does not prove who controls it. For a new vendor, changed destination, unusual amount, or urgent exception, confirm the instructions through a contact method already on file. Do not use a phone number or alternate email introduced only in the payment message.
Why approval needs a second person
For teams, separate the person who requests a destination change from the person who approves it. Record who verified the change, when, and through which channel. A simple second-person check is valuable because business email compromise often exploits a single compromised account. The recipient check establishes who should be paid before technical details create a false sense of certainty.
Name the network exactly
Do not accept phrases such as “Ethereum network” when the request could refer to Ethereum mainnet, an Ethereum-compatible sidechain, or a layer-two network. Use the network’s full name and, where appropriate, its chain identifier. If the payer is using an exchange, confirm that the withdrawal network label corresponds to the recipient’s network rather than to a similarly branded route.
Network compatibility is not guaranteed by address appearance. Several networks use the same hexadecimal address format, which means a wallet can accept the pasted destination while preparing a transfer on the wrong chain. The payer must check the active network in the wallet and compare it with the invoice. A payment link that attempts to switch networks should still leave the chosen network visible before approval.
Identify the token beyond its symbol
Token symbols are labels, not unique identifiers. A malicious or unrelated token can use the same symbol as a widely recognized asset. Verify the full token name, contract address, network, and decimal behavior from an approved source. When a business supports a token regularly, store the verified contract in a controlled asset registry and generate invoices from that registry instead of searching for the contract each time.
Be especially careful when a wallet automatically discovers tokens or a payment page adds a custom asset. The visual logo can be copied. Confirm the contract displayed in the transaction and make sure the transfer function targets the expected token. For native network assets, confirm that the request is a simple native transfer rather than an interaction with an unrelated contract.
Understand what the wallet is signing
A blockchain transaction is a signed instruction, not merely a payment confirmation. The ethereum.org transaction documentation explains that transactions are cryptographically signed instructions from accounts and can include simple transfers or smart-contract interactions. That distinction is essential when an email says “pay” but the wallet shows a token approval, contract call, message signature, or opaque data. The action in the wallet—not the label on the web page—is what will be authorized.
Review the destination, value, asset, network, fee, and function. An unlimited approval is not equivalent to paying one invoice. A permit or signature can grant later authority even when no asset moves immediately. If the wallet cannot decode the action, stop and use a known payment path. Routine invoices should be designed so the payer can understand the final instruction without blind signing.
Compare the complete destination
Compare more than the first and last four characters. Clipboard malware and address-poisoning techniques can present destinations that share familiar fragments. Use a trusted address book, hardware-wallet display, or full-address comparison. For repeat vendors, label the verified destination and alert on changes, but still confirm that the label has not been created from an untrusted import.
Human-readable names can improve usability, but they add a resolution step. Confirm what address the name resolves to at payment time and whether the wallet uses the intended network. A name that resembles a known contact is not proof of ownership. For large payments, ask the recipient to confirm a short fingerprint or the full address through the established secondary channel.
Check amount, decimals, and fee asset
Verify whether the amount is expressed in whole tokens, atomic units, or a fiat value converted to tokens. Token contracts can use different decimal settings, and interfaces can misrepresent a raw amount if metadata is missing or malicious. The wallet should display a human-readable amount that matches the invoice. When the amount is generated from a quote, check the rate timestamp and expiration before paying.
Confirm which asset pays the network fee. A payer may hold the invoice token but lack the native asset required for gas. An exchange may charge a withdrawal fee or send through an internal network that the recipient does not support. The invoice should state whether the exact requested amount must arrive and whether fees are paid separately.
Use a test transfer when risk justifies it
A small test can verify that the destination is reachable on the selected network and that the recipient can see the correct asset. Use it for first-time destinations, unfamiliar networks, high-value payments, or changes to a known workflow. The recipient should confirm the exact test transaction through the verified channel before the remainder is sent.
A test does not replace identity verification. An attacker who substituted the destination can also confirm receipt of the test. It also does not prove that a bridge, contract, or custodial claim process is safe. Treat the test as a final operational check after recipient, network, and token verification—not as a shortcut around them.
Record the verification and settlement
Capture the invoice reference, verified recipient contact, network, token contract, destination, amount, approver, transaction identifier, and confirmation status. For recurring vendors, note whether the destination matched the approved record or was newly verified. This record helps finance teams reconcile the transfer and gives security teams a starting point if the payment is disputed.
After broadcast, confirm the transaction on the intended network through a trusted source. Match the on-chain asset, destination, and amount to the invoice. Do not rely on a screenshot sent by the payer or recipient. Mark the invoice complete only after it meets the organization’s confirmation policy, and issue a receipt that repeats the essential details.
Use an approval worksheet for material payments
For payments above a defined threshold, place the checks in a one-page approval record. The reviewer should see the invoice reference, recipient verification method, approved network, token contract, full destination, amount, fee asset, and test-transfer status. The approver then compares that record with the wallet preview before signing.
This worksheet reduces context switching and makes skipped steps visible. It can be generated automatically, but the critical fields should come from controlled records rather than from the current email alone. Store the completed approval with the receipt so a later reviewer can understand why the payment was considered valid.
Conclusion
Recipient, network, and token verification are separate checks. Completing only one or two can still produce a valid transaction that settles in the wrong place or with the wrong asset.
Use a fixed order: verify the business relationship, name the network, identify the token contract, compare the destination, inspect the wallet instruction, and record settlement. A repeatable sequence is more reliable than intuition under deadline pressure.
