Getting paid in cryptocurrency can shorten the path between an international client and a freelancer, but it also moves several checks that banks normally perform onto the parties themselves. A ticker such as USDT is not a complete payment instruction: the client also needs the correct network, destination address, and, where required, a Memo or Tag. The freelancer then needs an on-chain transaction record, a credited balance, and a documented exchange result before treating the invoice as settled.

The route below follows one practical task: agree on a USDT-denominated freelance payment, receive it safely, and exchange it for another supported crypto asset if needed. USDT is used as the example because it exists on multiple blockchains, making network selection especially relevant. Tether’s own documentation instructs users to confirm the correct transport protocol before sending. ^[1] The same process can be adapted to another asset, but the address format, fees, confirmation model, and recovery options may differ.

Operation State Map: From Invoice to Verified Exchange

1. State 1: Define the payment task
   1. Transition condition: the client and freelancer agree on the invoice currency, crypto asset, amount, payment deadline, and who bears transfer or withdrawal costs.
   2. Check: the written agreement states whether the freelancer must receive an exact token amount or whether platform and network charges may be deducted from it.
   3. If it does not match, stop: do not generate an address while the amount or responsibility for fees remains ambiguous.
2. State 2: Establish the source and destination
   1. Transition condition: the client identifies the wallet or platform from which the payment will be sent, while the freelancer selects a wallet or account that can receive the chosen asset.
   2. Check: both sides can select the same asset and exactly the same network. The destination platform currently supports deposits on that network and has not marked them as suspended or under maintenance.
   3. If it does not match, stop: a familiar-looking address is not enough. Do not proceed if one side says only “USDT,” “Ethereum,” or “BNB” without confirming the complete asset-and-network combination.
3. State 3: Verify the payment instructions
   1. Transition condition: the receiving wallet or platform has generated a deposit address and, if applicable, a Memo or Tag.
   2. Check: copy the address from the receiving interface, compare the first and last characters after pasting, confirm the network label, and include the displayed Memo or Tag exactly as provided. If no Memo or Tag is shown as required, do not invent one.
   3. If it does not match, stop: reject instructions copied from an old invoice, unrelated chat, search advertisement, or third-party message. A changed address may indicate a genuine update, clipboard malware, or account compromise.
4. State 4: Approve the irreversible action
   1. Transition condition: the sender’s final confirmation screen shows the intended asset, network, destination, Memo or Tag where required, and expected recipient amount.
   2. Check: compare the screen with the current invoice and receiving interface rather than relying on memory. For a new address or unfamiliar route, consider a small test transfer if the applicable minimums and total fees make it practical.
   3. If it does not match, stop: do not authorize the transfer if the platform automatically substituted another network, changed the amount, or displays a warning that the destination may be incompatible.
5. State 5: Wait for an on-chain result
   1. Transition condition: the sender supplies a transaction hash that appears in the appropriate blockchain explorer.
   2. Check: the explorer shows the expected destination, token or native asset, amount, network status, and inclusion in a block. “Submitted” inside a wallet is not necessarily the same as an on-chain transaction.
   3. If it does not match, stop: do not mark the invoice paid based only on a screenshot, email, wallet notification, or transaction hash that belongs to another address or network.
6. State 6: Confirm receipt
   1. Transition condition: the receiving wallet or platform recognizes the transaction and reaches its required confirmation threshold.
   2. Check: the spendable or exchangeable balance has increased by the expected amount, allowing for any charges explicitly accepted in advance.
   3. If it does not match, stop: a successful explorer status without a credited balance requires diagnosis. Do not send a second payment merely because the first one has not yet appeared in the account interface.
7. State 7: Exchange the payment
   1. Transition condition: the received funds are available, the desired exchange direction is currently supported, and the quoted terms are acceptable.
   2. Check: verify the source asset and network, destination asset and address, quoted output, applicable network and service charges, rate validity, limits, and any verification requirements before creating the order. Conditions may depend on the direction and the results of compliance checks.
   3. If it does not match, stop: do not repurpose an order for a different asset, network, amount, or destination. Create a new request only after reviewing the revised terms.
8. State 8: Record the confirmed result or enter recovery
   1. Transition condition: the exchanged asset reaches the stated destination and is credited after the confirmations required by that destination.
   2. Check: retain the invoice, agreed valuation method, receiving address, transaction hashes, timestamps, exchange order details, and records of fees.
   3. If it does not match, stop: preserve all evidence and follow the diagnostic branch below. Do not disclose seed phrases, private keys, passwords, or remote access to anyone claiming they can recover the payment.

Choose the Asset Before Choosing the Network

The invoice should name the asset separately from the unit used to price the work. For example, a contract might price the service in US dollars while requiring settlement in the corresponding amount of USDT at an agreed reference time. Alternatively, the parties may agree on a fixed amount of BTC or ETH. These arrangements create different commercial risks: a fixed crypto amount can change substantially in fiat value before payment, while a stablecoin is designed to track a reference currency but still carries issuer, platform, liquidity, and potential depegging risks.

A freelancer who expects to exchange the payment soon should check the intended exit route before sending deposit instructions to the client. Confirm that the receiving wallet, exchange provider, and final destination all support the same asset and network. The exchanger in this route supports assets including USDT, BTC, ETH, DAI, LTC, BNB, XMR, and TRX, with additional assets being introduced gradually. That does not mean every pair, blockchain network, or direction is available for every order, so current availability must be checked before funds are moved.

If the actual objective is to receive money in a bank account, a crypto-to-crypto exchange does not complete that objective. Use only a fiat conversion route that is lawfully available in your country and compatible with your bank or payment provider. Ruble bank-card purchases and sales are planned for the service but are not currently a working feature, and no launch date should be assumed.

Network Selection Is Part of the Payment Instruction

Some tokens use the same ticker on several blockchains. USDT, for example, is issued through multiple protocols, so selecting USDT in two different interfaces does not prove compatibility. ^[1] The client’s withdrawal network must match the freelancer’s deposit network exactly. A low fee is irrelevant if the receiving platform does not support that route.

Do not infer compatibility merely because two networks use similar address formats. An address beginning with the expected characters can still belong to a different chain, token contract, account type, or deposit system. The reliable source is the current deposit screen of the receiving wallet or platform, checked against the current withdrawal screen used by the sender.

Network choice also determines how transaction costs are paid. A token transfer generally requires the network’s native asset for fees when sent from a self-custody wallet. A custodial platform may instead show a withdrawal charge or an estimated recipient amount. Because these models differ, the invoice should specify the net amount the freelancer expects to receive rather than assuming the displayed send amount will always arrive unchanged.

Address, Memo, and Final-Amount Checks

Verify the destination at the last possible moment

Generate or retrieve the address from the intended receiving account immediately before sharing it. Copying is safer than manual typing, but it does not eliminate clipboard substitution. Compare multiple characters at both ends after every paste. For a high-consequence payment, verify the address through a second communication channel already known to both parties rather than replying to a newly created account.

Cryptocurrency transfers are not designed to correct an incorrect recipient automatically. The FTC warns that funds sent to the wrong person, or lost through a compromised wallet, may have no party able to restore them. ^[2] This is why an address check belongs immediately before authorization, not only when the invoice is prepared.

Use a Memo or Tag only when the destination requires it

Some custodial receiving systems use one shared blockchain address for many customers and identify the intended account with an additional Memo, Tag, message, or payment ID. When the deposit screen displays such a field as required, send both components exactly. A correct address with a missing or incorrect identifier can reach the platform on-chain without being credited automatically to the freelancer’s account.

If a wallet does not request an identifier, adding a random value does not make the payment safer. When the sender’s and recipient’s interfaces disagree about whether one is needed, stop and obtain clarification from the receiving platform before transferring.

Separate the invoice amount from transfer costs

Before the client clicks Send, the final screen should answer three different questions:

• How much will leave the client’s balance?
• What network or withdrawal charge will be applied?
• How much is expected to reach the freelancer?

If the invoice requires an exact net payment, the expected recipient amount is the controlling figure. If costs may be deducted, the agreement should say so explicitly. Avoid resolving a shortfall by sending an immediate second transfer until the first transaction and the platform’s fee calculation have been verified.

Confirmations: When “Sent” Becomes “Received”

After broadcast, a blockchain transaction normally has a hash that can be checked independently. Its lifecycle may include pending, included in a block, confirmed, finalized, failed, or replaced states, depending on the network. On Ethereum, a transaction is broadcast, enters a transaction pool, and must be selected by a validator for inclusion in a block; later consensus stages provide stronger finality. ^[3] TRON similarly documents separate broadcast, block-inclusion, and confirmation stages. ^[4]

Bitcoin uses accumulating block confirmations rather than a single universal point at which every recipient must accept a payment. More confirmations provide greater protection against a competing transaction history, while an unconfirmed broadcast should not automatically be treated as final payment. ^[5]

The practical acceptance rule is therefore set by the receiving wallet, platform, or exchange provider for that asset and network. Do not impose a confirmation count copied from another blockchain, and do not promise a fixed arrival time. Network demand, fee selection, platform processing, maintenance, and compliance review can all affect when a credited balance becomes usable.

Exchange Only After the Receipt Checks Pass

Once the payment is credited and available, define the exchange as a separate operation. The source state is now “spendable USDT on a known network,” and the destination might be BTC, ETH, DAI, or another currently supported asset. Confirm the actual purpose: holding a different asset, paying a contractor, moving funds to another wallet, or preparing for a separately arranged lawful fiat conversion. If the destination does not serve the original purpose, the route has changed and should be reconsidered before an order is created.

Review the live order terms rather than relying on an earlier estimate. Check the exact input asset and network, expected output asset, destination address, displayed rate, charges, limits, and the time for which the quote remains valid. Verification requirements can differ by direction and may change following compliance checks; clarify the current requirements before creating the request.

After these checks, the practical next step is to check the available exchange direction and create a reviewed order. Use only the deposit details attached to that specific order. Do not send funds to details retained from an older transaction, and do not divide or restructure an operation to avoid verification or compliance requirements.

Delayed or Incorrect Transaction: Diagnostic Branches

No transaction hash exists

If the sending interface says “processing” but cannot provide a verifiable hash, the transaction may not have been broadcast. The sender should check the platform’s withdrawal history and contact its support if necessary. The freelancer should not issue a receipt or mark the invoice paid. A screenshot of an internal status is evidence of an instruction, not evidence that funds entered the blockchain.

The hash exists but the transaction is pending

Confirm that the hash belongs to the correct network and inspect its status in an appropriate explorer. A pending transaction may be waiting for inclusion because of network conditions, fee settings, sender-wallet sequencing, or platform processing. Do not ask the client to repeat the transfer to the same invoice without determining whether both transactions could eventually confirm.

If the sender’s wallet offers a legitimate fee-bump or cancellation mechanism, the sender must follow that wallet’s documented procedure. The recipient should not provide private keys, install remote-control software, or pay a supposed recovery agent.

The transaction is confirmed but the balance is missing

Compare the explorer record with the deposit instructions:

• Does the destination address match exactly?
• Is the asset the expected token rather than a similarly named or counterfeit token?
• Was it sent on the network supported by the receiving account?
• Was a required Memo or Tag included and correct?
• Has the receiving platform reached its required confirmation threshold?
• Is the deposit under maintenance, manual review, or a compliance check?

For a self-custody wallet, the token may need to be displayed or imported using its official contract information, but contract details should be obtained from official project documentation rather than an unsolicited message. For a custodial account, provide support with the transaction hash, network, asset, amount, destination address, Memo or Tag, time, and relevant screenshots. Support may be able to investigate, but recovery or crediting cannot be promised.

The transaction failed or reverted

A failed on-chain transaction does not deliver the intended payment, although a network fee may still have been charged depending on the blockchain and failure mode. Verify the explorer result before retrying. Recreate the payment from current instructions instead of copying every field from the failed attempt, because the original error may have involved the wrong network, an invalid contract interaction, insufficient fee balance, or an expired platform request.

The wrong address, network, or Memo was used

Stop all further transfers and contact the sending and receiving providers immediately with complete transaction evidence. Do not attempt to “correct” the first payment by sending more funds to an address supplied by an unknown helper. Blockchain transfers are generally difficult or impossible to reverse without the cooperation and technical capability of whoever controls the destination. A wrong-network deposit or missing Memo may sometimes be investigated by a custodial platform, but technical feasibility, policy, fees, compliance requirements, and recovery outcomes vary.

Records, Security, and Local Rules

Keep an audit trail that connects the commercial agreement to the blockchain result: contract or invoice, asset, network, agreed valuation method, address, transaction hash, timestamp, amount credited, exchange order, output transaction, and fees. This is useful for payment disputes, bookkeeping, compliance questions, and tax reporting.

Tax treatment differs by country. In the United States, the IRS states that digital assets received for services are treated as income based on their fair market value in U.S. dollars when received, and digital assets received for independent-contractor services generally constitute self-employment income. ^[6] Other jurisdictions may use different valuation times, reporting rules, classifications, or documentation standards. Check the rules that apply to the freelancer, the business structure, and the client rather than assuming that crypto payment removes ordinary tax or reporting obligations.

Protect the route from phishing by opening wallets and exchange services through a trusted bookmark or known application, checking the domain and device prompts, and distrusting urgent requests to replace an address. Seed phrases and private keys are never payment details. Anyone who obtains them can control the wallet, and legitimate transaction support does not require them.

What Counts as a Completed Route

The route is complete only when the original invoice can be matched to a confirmed on-chain transaction, the expected amount is credited to the freelancer’s usable balance, and any requested exchange has produced a separately verifiable credit or output transaction at the stated destination. A sender’s “completed” screen alone does not satisfy all three conditions.

Some uncertainty can remain even after completion: the fiat value may change, a stablecoin may deviate from its reference value, a custodial provider may apply later account checks, and tax or reporting treatment may depend on facts outside the transaction record. Those uncertainties do not invalidate a correctly executed payment, but they should be separated from the narrower technical question of whether the agreed asset reached the agreed destination and whether the exchange result is verifiable.