Key Takeaways
Launching stablecoin pay-ins and payouts takes seven steps: wallet structure, deposit pipeline, screening, gas and sweeping, payouts, fiat ramps, and reconciliation.
Licence coverage, stablecoins and chains, a fiat ramp partner and a screening vendor should be chosen before integration work starts.
A common setup gives each customer a dedicated deposit address and sweep funds into treasury, with one gas wallet paying all network fees.
Deposits that fail AML screening are frozen until the admin quorum approves a release, and payouts above policy thresholds wait for approvers.
A staged go-live starts with one chain, one stablecoin and low limits, then adds chains as daily reconciliation runs clean.
When a business accepts card or bank payments, a processor does most of the work: it receives the funds, matches them to the right customer, screens them and settles the total to the business's account. Stablecoin payments work differently. Funds arrive directly in wallets the platform controls, settle in minutes at any hour, and can be paid out again to any address worldwide without a correspondent bank in between.
That directness removes settlement delays, and it also moves the processor's work onto the platform. Each incoming payment has to be attributed to the right customer, checked for risk, credited, consolidated into treasury, and eventually paid out and reconciled. A platform that sets those steps up before launch can run them automatically at volume, while one that discovers them in production ends up moving funds and fixing balances by hand.
This guide sets out the launch in seven steps, in the order teams build them, based on Utila's work with PSPs, merchant acquirers, payroll platforms, exchanges and gaming operators. Each step covers what to decide, how to set it up, and the mistake to avoid.
Before You Start
A few decisions shape every step that follows, so it pays off to settle them before any integration work begins. Most of them are commercial or regulatory rather than technical:
Decision | Why it matters | Typical answer |
|---|---|---|
Regulatory coverage | Holding and transferring customer funds usually needs a licence in each market | Your own licence, or a regulated partner from Utila's Licensed Partner Network |
Stablecoins and chains | Customers and payout partners already hold particular assets on particular networks | USDT and USDC, most often on Tron, Ethereum and Solana |
Fiat conversion | Decides whether the platform ever holds stablecoins on its balance sheet | Ramp partners such as Bridge, or counterparties found through Utila Link |
Screening vendor | Every deposit and payout should be screened before funds move on | Chainalysis or Elliptic, connected to Utila |
Expected volume | Sizes approval thresholds, gas budgets and the Utila plan | Monthly pay-in and payout volume, and transaction count |
With those settled, the build itself follows the path of the money:
Step | What you set up | Utila feature |
|---|---|---|
1. Wallet structure | Vaults, deposit model, wallet naming | Vaults, wallet groups, wallet API |
2. Deposit pipeline | Detecting and crediting incoming payments | Webhooks, transaction API |
3. Screening | Checking deposits and freezing risky funds | Chainalysis and Elliptic integrations |
4. Gas and sweeping | Moving deposits into treasury without funding each wallet | Sponsored Transfers, Co-Signer |
5. Payouts | Sending funds under approval rules | Batch transfers, transaction policy, whitelists |
6. Fiat ramps | Converting between stablecoins and local currency | Bridge, Utila Link |
7. Reconciliation and go-live | Clean books and a staged launch | Gas and revenue wallets, exports, accounting integrations |
Step 1: Set Up the Wallet Structure
The wallet structure decides how the platform recognises each customer's payment and how funds are kept apart for accounting and regulatory purposes. It is the hardest step to change later, because customers save their deposit addresses, so it comes first.
How to set it up. In Utila, a vault is a workspace with its own security policy, holding any number of wallets. A common setup uses one production vault for client funds, one for the platform's own treasury, and a testnet-only vault for integration. Inside the client vault, the platform chooses a deposit model per chain:
Model | How the platform recognises the payer | Best for |
|---|---|---|
Dedicated address per customer | The receiving address identifies the payer | Platforms that need per-customer attribution; funds are later swept to treasury |
Memo-based | One shared address plus a memo or tag that the platform assigns and validates | Stellar, XRP and TON, where Utila neither assigns nor checks memos |
Omnibus | Needs extra information from the sender | Internal and low-volume flows |
Segregated, never swept | The receiving address identifies the client | Legal or contractual segregation requirements |
Dedicated wallets are created through the API, named by internal customer ID so ledger and blockchain records match, and organised into wallet groups so policies apply per segment. In Utila one wallet maps to one address per chain, so a product that gives each user several separate balances creates several wallets per user and groups them.
Mistake to avoid: Changing the deposit model after launch. Customers save their deposit addresses, so moving to new ones means asking every customer to update their payment details.
Step 2: Build the Deposit Pipeline
The deposit pipeline tells the platform's ledger that money has arrived. It has to credit each payment exactly once, and only when the payment is final.
How to set it up. Utila's deposit monitoring guide sets out the pattern:
Subscribe to webhooks. Utila sends signed webhooks for new transactions and retries them for up to 24 hours. Payloads carry IDs only, so the platform fetches transaction details with a separate call.
Credit at CONFIRMED. Each deposit appears as an incoming transaction that moves from MINED to CONFIRMED, and only CONFIRMED is final.
Key each credit to the transaction ID. A repeated notification then cannot credit the same deposit twice.
Poll as a backup. A periodic query for incoming transactions catches anything a webhook missed.
Use a read-only service account. A Viewer role is enough for monitoring, which keeps signing credentials out of the pipeline.
Mistake to avoid. Crediting on the first webhook. A payment seen on-chain is not yet final, and a credit that has to be reversed is far harder to fix than a short delay.
Step 3: Connect Compliance Screening
A blockchain address cannot refuse a payment, so funds from a sanctioned or high-risk source arrive whether the platform wants them or not. Screening has to catch those funds after arrival and stop them from moving any further.
How to set it up. Connect a screening vendor to Utila; Chainalysis and Elliptic both support policy enforcement. Flagged deposits are frozen: they cannot be transferred or swept through Utila until an operator reviews them and the admin quorum approves the release. Screening is charged per transaction, so screening conditions let the platform choose which wallets to screen and set a USD threshold below which small deposits are skipped. Transfers between regulated institutions can also run through Utila's Notabene integration for the Travel Rule.
Mistake to avoid. Leaving the frozen-funds procedure undefined. Decide before launch who reviews flagged deposits, how quickly, and who approves a release.
Step 4: Set Up Gas and Sweeping
Dedicated deposit addresses leave funds spread across thousands of wallets, so platforms sweep them into a central treasury wallet before paying out or converting to fiat. Every sweep is an on-chain transfer, and every transfer needs a network fee paid in the chain's native token, such as ETH or TRX. A new deposit wallet holds only the stablecoin the customer sent, so it cannot pay that fee on its own.
How to set it up. Utila's Sponsored Transfers let one central gas wallet (called the sponsor in Utila's docs) pay fees for every deposit wallet. The gas wallet is the same on every chain; only the one-time setup differs:
Chain family | Who pays the fee | Setup |
|---|---|---|
EIP-7702 EVM chains (Ethereum, Polygon, Base, Optimism, Arbitrum, BNB Smart Chain) | Gas wallet | Delegation added automatically on first use |
Solana, Sui, Aptos | Gas wallet | No native tokens needed in the deposit wallet |
ERC-20 and TRC-20 tokens, including USDT on Tron | Gas wallet | One-time approval after a single gas top-up |
Bitcoin, Cosmos, TON | The deposit wallet itself | Gas funded before sweeping |
The sweep job itself follows Utila's sweep pattern: query balances across all wallets, skip balances below a threshold, and send one sponsored transfer per wallet, signed automatically by the Co-Signer. On EVM chains, Delegated Calls can bundle sweeps from many wallets into one transaction, and for USDT on Tron the Utila Gas Station cuts fees by up to 70% compared with burning TRX.
Mistake to avoid. Sweeping every balance regardless of size. Without a threshold, the platform can spend more on fees than it consolidates.
Step 5: Configure Payouts
Payouts put the platform's own money at risk, because a transfer to a wrong address or for an inflated amount cannot be reversed on-chain. Payroll, marketplace and gaming businesses can send more than a thousand payouts a day, so the controls have to work without slowing every payment down.
How to set it up. Four pieces work together:
Batch transfers. Batch payouts send to many recipients in one transaction on 26 EVM networks, Bitcoin, Litecoin, Dogecoin, Bitcoin Cash, Tron, Solana and Stellar. Próspera runs batch payroll on Utila, with about 30% of employees paid in USDC.
Transaction policy. The transaction policy sets amount thresholds, so small payouts clear automatically and larger ones wait for approvers.
Role separation. Non-signing operators create payouts and signers approve them, which gives maker-checker control without extra tooling.
Whitelists. Address-book entries, uploadable in bulk by CSV, block any destination that is not on the list.
Routine payouts are then signed by the Co-Signer within policy, and people approve only the transfers that exceed their thresholds.
Mistake to avoid. Starting with high auto-approval limits. Begin low and raise thresholds as payout history builds.
Step 6: Connect Fiat On- and Off-Ramps
Many platforms offer stablecoin payments without wanting stablecoins on their own balance sheet. In that model, a customer pays in stablecoins, the deposit is screened and swept, and an off-ramp partner converts the funds and pays the merchant or recipient in local currency. Payouts work the same way in reverse.
How to set it up. Utila provides the wallet layer and connects it to conversion partners:
Bridge. Utila's Bridge integration covers USD on- and off-ramps by ACH or wire, and linked bank accounts become destinations that transaction policies can govern.
Utila Link. Utila Link connects platforms to more than 80 vetted organisations, including OTC desks and ramps for other currencies. Once both sides approve a connection, the counterparty's deposit address fills in automatically.
Mistake to avoid. Relying on a single ramp partner for each currency. A second partner keeps payouts running when the first one has an outage or a weekend cut-off.
Step 7: Reconcile, test and go live
Reconciliation closes the loop, and it only works if network fees and platform revenue are kept apart from client funds. A launch that is staged and tested on testnet first keeps any reconciliation issue small.
How to set it up.
Separate gas and revenue wallets. Client balances then change only through deposits, sweeps and payouts. Mandioca keeps dedicated profit wallets for this reason.
Use transaction IDs as ledger keys. Each on-chain movement maps to one ledger entry, so fees are booked exactly once. Utila exports wallet data and connects to accounting tools such as Cryptio and Cryptoworth.
Test end to end on testnet. Run deposits, screening, sweeps and payouts in the test vault before any client funds move.
Go live in stages. Start with one chain, one stablecoin and low limits, then add chains and raise thresholds as daily reconciliation runs clean.
Platforms moving from another provider can keep their existing deposit addresses through Business Continuity, so customers do not need to update saved payment details.
Scope the integration
A working session with Utila maps your deposit model, sweep logic and payout approvals onto vaults, wallet groups and policies, and sizes gas and screening costs for your volume. Talk to the team.
Frequently Asked Questions
How does a platform accept stablecoin payments?
It gives each customer a dedicated deposit address, credits funds once the transfer is confirmed and screened, and sweeps the balance into a treasury wallet.
Do deposit wallets need native tokens to sweep?
Not on chains that support fee sponsorship. A central gas wallet pays fees on EVM chains, Solana, Sui, Aptos and token transfers on Tron. Bitcoin, Cosmos and TON wallets still need gas funded first.
What happens when a deposit fails AML screening?
Utila freezes the funds. They cannot be transferred or swept until an operator reviews them and the admin quorum approves the release.
Can stablecoin payroll run on the same setup?
Yes. Payroll uses batch transfers under the same policies and whitelists. Próspera pays about 30% of its employees in USDC this way.
Related guides: How to Launch Cross-Border Stablecoin Payments · How to Launch a Stablecoin Yield Offering · How to Migrate Stablecoin Payment Infrastructure




