How to Accept Crypto Payments From Abroad for Business

To accept crypto payments for business from a client abroad, make three records agree: the commercial agreement, the blockchain transaction, and the recipient’s credited balance. This workflow connects them from the first client conversation through reconciliation, so neither side treats a wallet screenshot as proof of completion. Official sources reviewed August 26, 2026.

Receiving a cryptocurrency payment from another country involves three separate agreements: what the customer owes, which digital asset and network will settle it, and how both sides will prove completion. A wallet address alone does not answer those questions.

Circle public payments page presenting a cross-border stablecoin payment use case

Circle's public payments page, captured 2026-08. The amounts shown belong to the page's promotional artwork; they are not our transaction, fee quote or promised result. Use the verification workflow below for a real payment.

Use this guide for: running the payment from agreement through reconciliation. For the document itself, use the crypto invoice template; for the later bank withdrawal, use the selling USDT and cashing out in Cambodia.

In this guide

Can your business accept this crypto payment route?
Agree commercial terms before sharing an address
Worked example: a USD 1,350 client invoice
Create a payment route card
Execute the payment step by step
Reconcile the payment record
Handle common exceptions
Stop signals
The payment is finished when all three records agree
Send the payer one authenticated instruction block

Can your business accept this crypto payment route?

Before quoting crypto as a payment method, confirm:

the payer can lawfully send the selected asset from their country and provider;
you can lawfully receive, hold and convert it where you live;
both services support the exact same blockchain network;
the transaction is for a legitimate customer and documented service or product;
neither side needs a VPN, borrowed account, false residence or third-party bank account;
the expected amount fits both providers' limits and review requirements.

For Cambodia, check current SERC sandbox participants and authorized trial activities and the National Bank of Cambodia's Prakas and Circulars. An accessible app or an old announcement is not enough to establish current permission or product availability.

Put the following in writing:

Term	Decision to record	Why it matters
Invoice currency	Usually the currency used to price the work	Separates the commercial price from token price
Settlement asset	Exact stablecoin or cryptocurrency	Prevents the payer choosing a different token
Network	Exact blockchain route	Prevents a network mismatch
Rate source and time	How invoice currency converts to token amount	Avoids arguments during volatility or depeg
Fees	Who pays network and platform deductions	Ensures the intended net amount arrives
Test transfer	Amount, deadline and who bears its fee	Proves the route before the main payment
Confirmation rule	Required network/provider credit status	Defines when payment is complete
Shortfall/overpayment	How differences will be settled	Avoids informal address reuse
Refund route	Verification and who bears refund fees	Reduces refund fraud
Record retention	Invoice, TxID and statements to retain	Supports accounting and compliance

Do not write “pay in USDT” without a network, amount rule and confirmation rule. Read crypto invoice template for a reusable template.

Worked example: a USD 1,350 client invoice

Assume a Cambodian freelancer invoices an overseas customer USD 1,350 for a completed website project and agrees to receive USDC.

The invoice remains denominated at USD 1,350.
Both sides select a network supported by the payer and the receiver's current provider.
The invoice states the rate source and timestamp used to calculate the USDC amount.
The payer covers the sending fee so the agreed net amount reaches the recipient.
The parties first send a test amount above the receiver's minimum.
The recipient confirms the test is credited inside the receiving account.
The payer sends the balance to a freshly reconfirmed address and route.
The recipient records invoice number, agreed amount, actual amount, fee, TxID, time and conversion result.

This example explains documentation, not tax treatment or permission to use a particular provider. The actual route must be checked on the day of payment.

Create a payment route card

Send the customer one controlled instruction block rather than scattered chat messages:

Route-card field	What to enter
Invoice number	Your unique invoice reference
Recipient name	Person or business named on the invoice
Asset	Exact supported asset
Network	Exact network displayed by the receiving service
Address	Fresh address copied from that service
Memo/tag	Exact value if displayed; otherwise state not required only after checking
Token amount	Amount calculated under the written rate rule
Test amount	Above any minimum, small enough to limit loss
Expiry	When the quote/address must be reconfirmed
Completion	Credited balance plus required confirmations

Share the address and network together. For a material payment, confirm them through a second authenticated channel. Never ask the payer to copy an address from an article or old screenshot.

Execute the payment step by step

1. Reopen the receiving screen

Confirm account identity, asset, network, deposit status, address, memo/tag, minimum and required confirmations. Stop if deposits are paused or the account is under review.

2. Authenticate the payer

Confirm the person or business matches the contract and invoice. If a new contact suddenly changes the payer, asset or destination, re-verify through the established channel.

3. Send and verify the test

The payer sends the agreed test amount. Record the TxID. You verify it on the correct explorer and wait until your provider credits the balance. A sender screenshot is not proof of receipt. See crypto test transaction guide.

4. Reconfirm the route

Compare the asset, network, address and memo with the route card again. If the deposit address changed, do not automatically send the main payment; regenerate and authenticate the instruction.

5. Send the main payment

The payer sends the remaining amount under the agreed fee rule. Do not split it into unexplained transactions to avoid provider review. Keep all related TxIDs.

6. Confirm commercial completion

Check three layers:

Blockchain: the correct transaction exists and has sufficient confirmations.
Provider: the receiving balance is credited and available under the account's rules.
Invoice: the net amount satisfies the written settlement terms.

Only then mark the invoice paid or partially paid.

Reconcile the payment record

Keep one evidence folder containing:

contract or purchase order;
final invoice and payment instructions;
authenticated customer communication;
payer name and business details appropriate to the transaction;
asset, network, receiving address record and memo/tag;
test and main-payment TxIDs;
receipt time, token amount and invoice-currency value;
platform/network fees;
later conversion and bank-withdrawal records;
any support case or exception explanation.

This creates a traceable chain from work performed to funds received. Read the KYC, AML and source-of-funds overview before accepting recurring or higher-value payments.

Handle common exceptions

Situation	Do first	Resolution rule
Test does not arrive	Stop the main payment; check network, address, memo, minimum and TxID	Continue only after credited balance or a newly verified route
Customer sent too little	Compare net amount with invoice fee rule	Request a documented top-up or record partial payment
Customer overpaid	Verify payer and original route	Refund only under written terms to an authenticated compatible route
Wrong asset or network	Stop and preserve TxID	Use official receiving-provider support; recovery is not guaranteed
Stablecoin loses its peg	Apply the agreed rate/depeg clause	Pause if no clause exists and document a new agreement
Payment comes from an unknown third party	Do not mark paid automatically	Obtain a lawful explanation and supporting records or return through a verified process
Customer asks for refund to a different address	Treat as possible refund fraud	Re-authenticate customer and document ownership/reason before any action
Provider requests source of funds	Gather the evidence folder	Submit only genuine requested material through the official secure channel

Stop signals

Stop when anyone asks you to:

accept a different network because it is “basically the same”;
reveal a seed phrase, private key, password or OTP;
pay an activation, unlocking or tax fee to a wallet;
use another person's verified account;
return an overpayment to an unrelated address;
release goods or mark the invoice paid before the balance is credited;
delete invoices or conceal the real business purpose.

Review crypto scam red flags before dealing with a new counterparty.

The payment is finished when all three records agree

The goal is complete only when:

lawful provider and regional eligibility were checked;
the customer and commercial purpose were documented;
invoice currency, asset, network, rate, fees and refund terms were written;
the test transfer reached the credited balance;
the main payment used the reconfirmed route;
blockchain, provider and invoice statuses all agree;
exceptions were resolved in writing;
the full accounting and source-of-funds record is stored securely.

If you plan to convert the payment to bank funds, continue to selling USDT and cashing out in Cambodia.

Send the payer one authenticated instruction block

After the invoice is accepted, send one short instruction block through the same authenticated business channel. This reduces the chance that a wallet address copied from an old message or a compromised email replaces the agreed route.

PAYMENT INSTRUCTION — [INVOICE NUMBER]
Amount due: [FIAT AMOUNT AND CURRENCY]
Settlement asset: [FULL TOKEN NAME AND TICKER]
Network: [EXACT NETWORK NAME]
Destination: [CURRENT ADDRESS]
Memo/tag: [VALUE OR NOT REQUIRED]
Test amount: [AMOUNT ABOVE LIVE MINIMUM]
Test treatment: [DEDUCTED FROM TOTAL / ADDITIONAL]
Quote or tolerance rule: [RULE]
Completion: credited balance of [NET AMOUNT]
Valid until: [RFC3339 TIME WITH OFFSET]
Confirmation channel: [KNOWN EMAIL, CONTRACT THREAD OR PORTAL]

Read the block back with the payer before the test. If any field changes, cancel the old block in writing and issue a new version; never edit only the address inside an old message. The block is operational data, not a place for a password, OTP, seed phrase, private key or identity-document image.

Official sources

Educational information only, not legal, tax or financial advice. Provider access, asset support, networks, limits, fees and local rules can change.