Vendor onboarding: how to verify a wallet address before you pay it

There is no recall on a blockchain payment. No bank to call, no chargeback window, no correspondent to reverse the entry. Once a transfer confirms, the funds are under the control of whoever holds the keys to the receiving address.

That single property moves the entire control burden upstream. In a wire process, controls can sit at the payment run because errors are sometimes recoverable. On-chain, the controls have to sit at vendor onboarding, because by the time a payment executes it is already too late.

This article covers what to verify before an address enters your vendor master, the two fraud patterns that target it, and how to keep the record trustworthy over time.

Why does address verification belong in onboarding?

Because verification at the payment run is both too late and too rushed.

Payment runs happen under time pressure, usually against a due date, often by someone who did not negotiate the contract. That is the worst moment to be checking whether a 44-character string is the right 44-character string.

Onboarding is unhurried, has a named owner, and already includes identity checks. Adding address verification there costs minutes once per vendor instead of risk on every payment.

The rule worth adopting: an address that has not been verified cannot be paid. Not "should not" as guidance, but enforced by the system, so the control does not depend on whoever is running payables that week.

The two fraud patterns you are defending against

Address poisoning. An attacker sends a dust transaction to your address from a vanity address engineered to share the first and last characters of an address you have paid before. Your transaction history then contains two near-identical-looking entries. When someone copies an address from history rather than from the vendor record, they copy the attacker's.

This works because almost every interface truncates addresses in the middle, showing something like 0x867c…C010. The attack targets the truncation, not the human. Checking the first and last few characters is exactly the behaviour it defeats.

The defences: never copy from transaction history, always from the verified vendor record; compare the full string rather than the ends; and filter dust out of the view operators actually look at.

Vendor impersonation. An email arrives from a supplier, or something that looks like one, advising that payment details have changed. This is the oldest fraud in accounts payable, moved to a new rail where it pays better because the money cannot be recalled.

The defence is the same as it has always been and is still routinely skipped: verify any change to payment details out of band, using a phone number you already hold, never one supplied in the message requesting the change. On-chain, treat a change of address as equivalent to a change of bank account, because it is.

What to verify before the address enters the vendor master

Confirm the vendor actually controls it. The strongest evidence is a signed message: ask the vendor to sign an agreed string with the private key for that address and send you the signature. You verify it against the address without any funds moving. This proves control at a point in time, which is more than a test transfer proves.

Send a test transfer anyway. A small amount, confirmed received by the vendor through a channel you initiated. The signed message proves control; the test transfer proves the whole path works, including that the vendor's wallet actually displays the token you are sending on the chain you are sending it on.

Record the chain, not just the address. The same EVM address exists on Ethereum, Base, Arbitrum and every other EVM chain. An address is not a destination until it is paired with a network. Sending USDC on Arbitrum to a vendor expecting it on Ethereum is a support ticket at best and a loss at worst if they do not control the address on that chain.

Record the token contract, not the symbol. Symbols are not unique and can be set to anything. Several tokens display as "USDC" while being worthless. What makes a token real is its contract address, and that is what your system should match on. This matters more on receipt than on payment, but the master data discipline is the same.

Screen the address. Sanctions obligations apply to on-chain payments exactly as they do to wires, and OFAC has designated specific addresses on its SDN list. Screen at onboarding and re-screen periodically, because an address that was clean when you added it can be designated later. Our travel rule guide covers the wider compliance picture.

Keeping the record trustworthy after onboarding

Verification is not a one-time event, because the risk is in changes.

Treat a change of address as a new verification. Full process, not an edit. The most dangerous moment in vendor master data is an update, because it inherits the trust of the original record without having earned it.

Require dual control on changes. The person who can change a payment address should not be the person who can release a payment. If one person can do both, a single compromised account is sufficient to move money.

Log who changed what and when. When something goes wrong, the first question is when the address changed and who approved it. If that is not answerable from the system, it will be reconstructed from email, badly.

Re-screen on a schedule. Monthly is reasonable for most payables books. The obligation is continuous, not an onboarding gate.

Where approval thresholds fit

Verification establishes that the address is right. Approvals establish that the payment should happen at all, and on-chain these can be enforced in a way that fiat cannot match.

With a multisig smart account, the signature threshold is enforced by the contract itself rather than by a policy someone can override. A payment requiring two of three signers cannot be released by one, because the chain will reject it. There is no administrator who can make an exception under pressure, which is precisely the pressure social engineering applies.

That is how Plaitr accounts work: balances sit in a self-custodial Squads smart account owned by your business, signing happens from wallets your team holds, and the threshold lives in the contract. See security and control for the architecture, and approvals and roles for how they map to a payables policy.

FAQ

Can a blockchain payment to the wrong address be reversed?

No. There is no recall mechanism, no chargeback and no intermediary able to reverse a confirmed transfer. Recovery depends entirely on whoever controls the receiving address choosing to send the funds back. This is why controls move to onboarding rather than sitting at the payment run.

What is address poisoning?

An attacker sends a tiny transaction from an address crafted to look like one you have paid before, matching the leading and trailing characters that interfaces display. The goal is that someone copies the address from transaction history instead of from the verified vendor record. Defend by copying only from the vendor master and comparing full strings.

How do you prove a vendor controls an address?

Ask them to sign an agreed message with the private key for that address and verify the signature against the address. This proves control without moving funds. Follow it with a small test transfer to confirm the full path works on the specific chain and token you intend to use.

Do sanctions rules apply to stablecoin payments?

Yes. Sanctions obligations attach to the counterparty regardless of rail, and OFAC has designated specific blockchain addresses on the SDN list. Screen addresses at onboarding and re-screen periodically, since a previously clean address can be designated later.

Is the same address valid on every chain?

An EVM address format is valid across EVM chains, but whether the vendor controls it and can access funds there is a separate question. Always record the chain alongside the address, and confirm with a test transfer on the specific network you will use.

What should you do next?

Add two fields to your vendor master if they are not there: chain, and verification evidence. Then make unverified addresses unpayable in the system rather than by policy.

If you are paying vendors across countries and rails, Plaitr puts approvals, limits and the payout rail in one place, with the signing threshold enforced on-chain rather than by an internal override. See cross-border payments.