A Customer Wants to Pay You in Stablecoins: What Should You Check Before Accepting?
A customer proposes to settle an invoice in USDC, EURC or another stablecoin. Before sending a receiving address, a business should be able to answer six questions: who is the customer and who will pay, which invoice is being settled, which asset will be used, on which network, through which receiving channel and under what rules the receivable will be considered settled.
The objective is not to treat every stablecoin payment as suspicious. It is to know, before an irreversible transaction, what the business accepts, from whom and how it will later explain the transaction. This is the Stablecoin Acceptance Gate.
1. Start with the commercial transaction, not the blockchain
Identify the invoiced customer, the relevant invoice, its amount and currency, the commercial purpose and the payer when different from the customer. A third-party payer is not automatically an anomaly, but the difference should be explainable and documented.
The first chain to establish is therefore CUSTOMER → INVOICE → PAYER. Resolve inconsistencies before sending payment instructions.
2. “I’ll pay you in USDC” is not yet a complete payment instruction
The stablecoin’s commercial name is not enough. Internal policy should specify the issuer, accepted asset, authorized blockchain, official identifier or contract where relevant, and the authorized receiving address or infrastructure.
This discipline reduces the risk of receiving a similarly named asset, an unintended bridged version, or the correct asset on a network the business cannot process. A separate article will address how to build the allowlist.
3. Determine where the business will receive the funds
Funds may be received on a business-controlled address, an account or wallet provided by a crypto-asset service provider, or another approved infrastructure. This choice affects operational responsibilities, available information and intermediaries.
When a CASP is involved, verify the legal entity actually providing the service, not merely the brand or app. In France, the transitional period for certain former PSANs ended on 1 July 2026; from 2 July 2026 that transition is over. ESMA’s MiCA register can be used to identify authorized providers.
4. Business and CASP: do not confuse their obligations
EU Regulation 2023/1113 imposes certain transfer-information obligations on crypto-asset service providers. It does not turn every business receiving a payment into a CASP.
For transfers involving a self-hosted address, the Regulation provides, in certain configurations above EUR 1,000, for CASP measures to assess ownership or control of the address. Regulatory duties of the provider must therefore be distinguished from the internal control policy adopted by the business.
5. Do you know where the payment is expected to come from?
When this information is available before payment, establish whether funds should come from the customer’s wallet, the customer’s account with a CASP, an identified third party or another infrastructure. A blockchain address is not, by itself, a legal identity: the process should link off-chain commercial information with the on-chain transaction.
If an inconsistency appears, additional verification may be required. A separate 16 October article will address unknown wallets and the signals that may trigger enhanced review.
6. Before the transfer, define what “invoice paid” means
Where the invoice currency differs from the settlement stablecoin, define before transfer the conversion rule, price source, reference time, expected quantity, treatment of network fees and treatment of discrepancies. This operational framework does not, by itself, determine the accounting, tax or legal treatment of the transaction.
7. Build your Stablecoin Acceptance Gate
ACCEPT: customer and invoice identified, payer coherent or third party explained, asset and network authorized, receiving infrastructure validated, settlement terms defined and no significant unresolved issue.
REVIEW: missing information, insufficiently documented third party, new asset or network, unexpected channel change or an inconsistency requiring additional analysis.
DO NOT EXECUTE: internal policy conditions are not met, the asset or network is unauthorized, infrastructure is incompatible or a significant anomaly remains unresolved. This does not mean the customer or funds are illicit; it means the business’s acceptance conditions are not met.
8. The checklist before communicating your wallet
Before sending payment instructions, check and document the following items:
CUSTOMER — Who is invoiced?
INVOICE — Which receivable is being settled?
PAYER — Who is making the transfer?
ASSET — Which stablecoin is being used?
NETWORK — On which blockchain?
TOKEN — Which exact asset is authorized?
RECEIVING CHANNEL — Which wallet or provider receives the funds?
EXPECTED SOURCE — Customer wallet, CASP, identified third party or other?
SETTLEMENT RULE — What quantity is expected and under which rule?
DECISION — Accept, Review or Do Not Execute?
Conclusion
Accepting a stablecoin payment should not begin with “Send it to this address.” The proper sequence is: identify → verify → define terms → authorize → receive → document. The blockchain executes the transfer; internal control should explain why the business accepted it.
After receipt, the next issue is retaining the information needed to reconcile the blockchain transaction, invoice, accounting records and audit trail. This is part of BECTRA’s Stablecoin Accounting & Control Framework (SACF).
Further reading
Sources
EU Regulation 2023/1113 on information accompanying transfers of funds and certain crypto-assets; EBA Travel Rule Guidelines; AMF information on the end of the French MiCA transition; ESMA MiCA register; Circle official documentation on USDC networks and versions.
Comments