Accepting cryptocurrency can give freelance clients another way to pay, but a wallet address alone is not a payment guide. A client also needs to know which asset to send, which network to use, how much to transfer and when you will consider the invoice paid. Small ambiguities can lead to delays, unexpected fees or funds sent somewhere they cannot be recovered.
The best guide reflects the payment process you actually use. Write it before sending an invoice, agree on the important terms with the client and keep transaction verification separate from any tool used to draft the instructions.
Start with verified payment rules before drafting client instructions
First, make a short internal policy. Check the details against your receiving wallet or payment provider rather than relying on an old invoice or a generic template. At a minimum, decide:
- Which assets and networks you accept, and whether your wallet supports receiving each combination.
- How the invoice amount is set, who pays network fees and whether a payment deadline applies.
- How you verify receipt, handle underpayments and approach refunds or payment mistakes.
- Which contact channel clients should use if they are unsure about the instructions.
Once those decisions are made, a redacted policy can help you draft a client-friendly version. For example, https://www.ohlas.uk/ is an optional marketing workspace that can use uploaded company documents for strategy recommendations and provide copy feedback based on an audience and goal. It is not a wallet or transaction verifier, and it should not decide your payment terms or validate an address.
Remove private keys, recovery phrases, passwords and unnecessary client information before uploading any document to a drafting service. Even if the wording is generated for you, the underlying policy needs to be yours: if you have not decided how a short payment will be handled, polished copy cannot make that decision for you.
Explain the asset, network and invoice amount without ambiguity
Name both the asset and the network in the instructions. “Pay in USDC” is incomplete because a client may hold USDC on a different network from the one your receiving wallet supports. A clearer instruction is “Send USDC on Ethereum to the address shown on this invoice,” provided you have verified that your receiving setup supports that exact combination.
Do not assume that a familiar token symbol or an address that looks plausible proves compatibility. Where appropriate, identify the token using information from your wallet or the token issuer, such as the relevant contract address, and ask the client to check it in their sending app. If you accept several combinations, list them separately and make clear which address belongs to each one. If you accept only one, say so explicitly.
Next, distinguish the value of the work from the amount the client must send. An invoice denominated in a fiat currency but paid in crypto needs an agreed conversion method: specify the rate source, when the rate is determined, how rounding works and how long the quoted crypto amount remains valid. Alternatively, if the agreement sets a fixed token amount, say that the token amount itself is due. A stablecoin is designed to track a reference value, but its market price can move away from that value; avoid promising that it will always be worth exactly one unit of fiat currency.
Include fees in the conversation before the client pays. A network transaction fee is generally paid by the sender, but an exchange or payment provider may also charge its own withdrawal fee or deduct a fee from the amount sent. Explain whether the invoiced amount is the amount you must receive after deductions and how the client should handle a shortfall. Do not quote a fixed fee unless you can support it: fees can change with network conditions and provider terms.
A useful invoice block might read: “Amount due: 250 USDC. Network: Ethereum. Amount must arrive in full; sender pays applicable transfer and withdrawal fees. Payment deadline: the date agreed on the invoice.” This is an example of wording, not a universal policy. Add the verified receiving address and make sure the commercial agreement supports the terms you use.
Show clients how to pay without exposing sensitive information
Give clients a short sequence rather than assuming they already understand their wallet. Ask them to select the specified asset and network, copy the receiving address from the invoice or another agreed channel, check the address carefully, enter the amount and review the transaction before submitting it. If their app does not offer the stated network, they should stop and contact you instead of choosing a similar-looking option.
For a USDC-on-Ethereum example, Phantom’s Send tokens from Phantom instructions explain matching the token and network, checking the recipient address and accounting for network fees. They also distinguish sending a transaction from its network confirmation. The client’s own wallet or exchange may use a different interface, so invite them to consult its instructions rather than inventing steps for an app you have not tested.
A receiving address is intended to be shared for payment; a recovery phrase or private key is not. Neither you nor a legitimate client needs the other person’s secret credentials to send a normal payment. Never include seed phrases, private keys, wallet passwords or authentication codes in a client guide, invoice, support ticket or AI prompt. Be cautious of anyone claiming that payment requires you to connect a wallet to an unfamiliar site or disclose a secret.
Address substitution is another practical risk. A compromised email account or altered document can redirect a payment even when the rest of the invoice looks genuine. Agree on a trusted way to confirm the address, particularly for a first payment, a large invoice or a change to previously supplied details. For example, verify the address through a known contact method independently of the message announcing the change. Check the entire address, not only the first and last few characters.
A small test transfer can be useful when both parties agree it is worthwhile, but it adds fees and does not guarantee that a later transfer will be correct. Recheck the asset, network and address for the full payment. Also tell clients whether your receiving service requires an additional identifier, such as a memo or tag; if it does, provide the correct identifier through the same verified process.
Set expectations for confirmations, mistakes and refunds
A transaction submitted by the client is not necessarily a completed payment. Explain what evidence you need and how you will check it. A transaction hash can help you locate a transfer in a suitable block explorer or receiving service, but it is a reference, not proof by itself that the correct amount reached the correct destination on the correct network.
Decide in advance what confirmation or provider status you require before marking an invoice paid or starting work. The appropriate threshold depends on the network, the value and your risk tolerance; there is no single confirmation count that fits every payment. Tell the client that network congestion or a provider review can delay recognition, and give them a way to report a transfer that appears stuck. Verify the transaction independently instead of relying only on a screenshot or email notification.
Include a simple exception process. If the amount received is too low, contact the client with the verified shortfall and agree how to settle it. If the client sends more than expected, do not assume the excess is a tip or immediately send it elsewhere: confirm the details through a trusted channel and follow your agreed refund process. Keep the original invoice and any amendment so both parties can understand what happened.
Wrong-network and wrong-address transfers may be difficult or impossible to recover. Recovery, if available at all, depends on the destination and the services involved; never promise it in advance. Tell clients to stop and contact you promptly with the transaction hash, asset, network and sending service. They should not share private keys or a recovery phrase while seeking help. Phantom notes that it cannot reverse transactions or retrieve incorrectly sent tokens.
Refunds deserve their own terms. State when a refund may be available, whether it will be calculated in the original token amount or a fiat equivalent, how the conversion rate is chosen if relevant, and who pays transfer fees. Verify the refund address through a trusted channel rather than assuming the original sender address is suitable: payments sent from an exchange or another service may not have a return address controlled directly by the client. Make sure the policy is consistent with your contract and applicable obligations.
Review the guide yourself and keep payment records separately
Read the finished guide as a first-time client would. Can they identify the asset, network, amount and deadline without asking you? Can they tell where to find the address and whom to contact before sending? Remove vague phrases such as “use the usual network” or “payment is instant,” and keep the instructions consistent with the actual invoice.
Human review matters especially when software has helped draft the copy. OhlasAi’s approach at https://www.ohlas.uk/about states that users review and adjust AI recommendations and make the final decision. Apply that principle here: check each payment instruction against your wallet, invoice process and refund policy. Its general review principle is not a substitute for crypto-specific security checks or professional advice.
Maintain payment records separately from the client-facing guide. Depending on your circumstances, useful records can include the invoice, agreed conversion method, date and amount received, asset and network, transaction hash, relevant fees, and details of any refund or adjustment. Record the fiat value and supporting rate information where needed for your accounts. Store client and transaction information securely, limit access and avoid retaining secrets or unnecessary personal data.
For UK businesses, HMRC’s CRYPTO40050 — Cryptoassets for businesses: which taxes apply explains that receiving cryptoassets for goods or services does not remove tax obligations. Income, expenditure, profits and gains may need to be reported as applicable. Treatment depends on the business and circumstances, so consult a qualified adviser if you need an assessment of your position.
Finally, revisit the guide whenever you change wallets, networks, payment providers or commercial terms. Test the instructions against the current receiving setup before issuing the next invoice. A short, accurate guide will do more for clients than a lengthy one that describes a process you no longer use.
