Stablecoin Cashier

Who the stablecoin cashier is for

The Copay stablecoin cashier serves businesses with an overseas entity that need to accept, pay out, or settle USDT commercially. Five patterns are common.

Cross-border trade: buyers willing to settle in stablecoins. What you need is not merely "the money arrived" — it is knowing which invoice each payment belongs to, producing a month-end reconciliation your finance team can read, and landing the funds in a bank account in your own company name. The more wires a business has had held, queried, or returned by a correspondent bank, the more obvious a second settlement path becomes.

E-commerce and independent stores: a settlement path alongside card rails. The point is not to replace cards — most buyers still pay by card — it is that your cash flow does not go to zero when the primary channel is throttled. A less obvious benefit: stablecoin settlement has no chargebacks, which is a structural difference for high-chargeback categories.

SaaS and digital services selling abroad: for subscription and usage-based billing, small cross-border wires simply do not survive their own fees. Stablecoin settlement pushes the fixed cost per transfer down far enough that small, frequent collection finally makes arithmetic sense.

Platforms and marketplaces: collecting on the platform side and paying sellers or service providers in batches. These businesses have the strictest need for separation of duties — who can initiate, who approves, and who may only read must be three distinct permissions, not three people sharing one login.

A fifth pattern is paying overseas suppliers and contractors: both directions run on one ledger, which removes the reconciliation nightmare of collecting in one system and paying from another. We are equally direct about what does not fit: high-frequency consumer retail payments, and any customer who cannot present a corporate entity and explain their business.

The lifecycle of an order

The unit of work is the order — not a wallet address, and not a transaction hash. That single decision shapes everything else: you create an order with your own reference, amount and currency; the payer pays on a page that states amount, network and expiry explicitly; the system watches for on-chain confirmation so you never run nodes, handle reorgs, or maintain an address index; the balance settles and a webhook pushes the status to your systems; and the order reference, amount, hash, timestamp and fees are all recorded and exportable.

Why not simply hand out an address: one address collecting from everyone means you cannot prove at month-end who paid what — and a payer choosing the wrong network is the single most common failure in stablecoin collection. The four cases below are where real operational time goes, and the system handles each of them deliberately.

Three ways to integrate, four steps to launch

Pick one or combine all three: the merchant console (start with no engineering — create orders manually, check balances, read statements and reconciliation, manage team permissions), the API (create orders, initiate payouts, query status and balances; public documentation on the developer page), and webhooks (status changes pushed in real time, backed by the query API).

Launch is four steps: commercial conversation, business review (KYB), sandbox integration, production access. On the engineering side there are usually only three pieces of code: create an order, receive webhooks, and run a reconciliation sweep as a fallback. The last one is the easiest to skip and the most likely to bite at 3 a.m. — networks flap, endpoints 500, queues back up, so webhooks must always be paired with a scheduled status query. It is in our integration checklist because every merchant who has ever needed it discovered they had skipped it on the day they needed it.

The long pole is rarely development — it is assembling the business-review pack. The checklist is published in our KYB guide, so it can be prepared in parallel with the commercial conversation.

Reconciliation you can hand to your auditor

This section is written for a finance lead, not an engineer.

• Order-level attribution: every collection and payout is bound to your own reference — not reverse-engineered from an address, not guessed from a timestamp.
• On-chain evidence retained: transaction hashes and every status change are recorded. A hash is evidence any third party can verify independently — stronger in that respect than a bank advice, which only you and your bank can see.
• Balances broken out: available, pending settlement and fees are booked separately, so nothing has to be derived by hand at month-end.
• Export and three-way checks: reconciliation records export straight into your accounting process, and our ledger, the chain, and your own systems can be aligned transaction by transaction.

How pricing works — and what we do not offer

Copay charges on three lines: pay-in (a contracted rate on the amount, with a per-transaction minimum), same-chain payout (a flat fee per transfer, charged separately from the amount), and cross-chain payout (a contracted rate within a per-transfer floor and cap). Rates are agreed in writing before integration and every charge is visible in the console and the API. There are no fees added after the fact.

We are equally clear about what we do not do: Copay does not issue invoices. We say so in the first conversation rather than let it surface at the end.

In a money system, permissions are part of the product

The real problem with an exchange account or a shared wallet is not security — it is that permissions do not exist at all. Once a login is shared, who did it, who approved it, and who to ask when something goes wrong all become unanswerable. The cashier makes these part of the product.

• Separation of duties: initiate, approve and read-only are three distinct permissions that can sit with three different people.
• Approval gate: payouts above a configured amount require human approval — enforced by the system, not by a policy document.
• Payee management: payout destinations are registered once and reused rather than typed per transfer. On-chain transfers cannot be recalled, and a single wrong character is a permanent loss. This is a discipline, not a suggestion.
• Audit trail: who did what, and when, is always recoverable.

Why not an exchange account or a self-custody wallet

Plenty of teams start with an exchange account or a self-custody wallet, and at small scale that is genuinely fine. Three problems appear as you grow: attribution (one address collecting from every customer means month-end cannot prove who paid what, and refunds become an exercise in reading old chat logs), permissions (a shared key or login means approval simply does not exist), and channel stability (an exchange can change its withdrawal and compliance policy at any time, and it is not accountable for your business continuity).

The value of a cashier was never "it can receive USDT" — a wallet does that. It is order-level attribution, role-based permissions, a per-transaction audit trail, and traceability when something goes wrong. That is the layer that survives an audit, explains itself to a bank, and scales with the business.

Why we are KYB-first

Production access follows a business review, and we lose signups because of it. That is deliberate.

A provider that onboards you in five minutes without asking anything is quietly betting its banking and channel relationships on not getting caught. When that bet fails — and it tends to fail suddenly — the thing that stops working is your settlement. So when we review incorporation documents, ownership structure and business model, we are not being difficult; we are becoming the kind of counterparty whose banking still works next year. Slower onboarding, boring compliance, and rails that do not disappear are themselves part of the product.