A practical guide to deposits, payouts, and what to settle before choosing a provider
Vinny Mullin
|Aug 27, 2026

Stablecoins have transformed global money movement because they settle in seconds and cost fractions of a cent to move.
Leading blockchains and ecosystems like Ethereum, Tempo, Solana, and Base have made moving stablecoins like USDT, USDC, and OUSD fast and straightforward to integrate into an organization’s wallets.
The challenging part of stablecoin-powered money movement often comes at the beginning and end of a transaction: getting money from traditional financial rails onto a blockchain, and then moving it back offchain into a spendable account
The process of moving money across onchain and offchain sources is called orchestration. But what is it, and do you need it? It’s an ambiguous term that can lead teams evaluating providers to accidentally compare very different products and offerings.
Here are seven things worth knowing about orchestration.

Stablecoin orchestration is the process of moving funds from one place to another, and all the actions that are required to facilitate it.
It allows businesses to run remittances, payroll, supplier payments, and more, and to give customers outside the US a way to save and spend in desirable currencies.
Privy works directly with Bridge for orchestration. At Bridge, orchestration is a software layer that lets a business manage every part of a payment flow through one interface, turning banks, chains, processors, currencies and compliance systems into a single operating model.
Conversion, multi-chain connectivity, compliance, and custody each carry their own technical and regulatory requirements, and unifying them is what makes stablecoins usable in a payments or payouts product.

Deposits (getting money in) and payouts (getting money out) are multi-step processes requiring complex orchestration behind what appears to be a simple movement of funds to the end user.
Multiple steps occur between a user deciding to move funds onchain or offchain and the transaction being completed. For example, a user withdrawing 1,000 USDC to a fiat bank account may require the following steps before the funds arrive:
Conversion: 1,000 USDC leaves the chain and becomes a fiat balance held by the provider. Stablecoins that exit into fiat are eventually redeemed with the issuer and burned (though not necessarily as part of your transaction).
FX (if the destination currency requires it): Converting to the destination currency has its own cost and potentially its own party performing it. The provider converts at the market rate and charges an FX fee for non-dollar currencies.
Last mile: The fiat money is now in an institutional account, and must be moved into the user’s bank account.
Each of these steps is a sequential transaction with its own regulatory requirements. Orchestrating this involves maintaining the liquidity needed to execute these transactions and sourcing the partner network needed to execute transactions that fall outside a provider’s scope. Making this available through a single API makes orchestration usable: one identity per user instead of one per provider, one set of statuses to reconcile, and one place to look when a payment fails.

Before any of the above actions can happen, legal identities usually need to be confirmed with the provider.
Identifying the end user, whether a business or consumer, is a legal requirement that comes with its own complexities including terms of service, programmatic approvals, and more. Customers have to be verified before transactions are ever submitted.
There are two main verification flows:
Hosted: an identification flow that the provider runs via a hosted URL
Headless: sending identification data directly via API
Each process has its own terms and infrastructure, and they often overlap or are offered within the same product flow. Users are individuals, not pieces of infrastructure, so programmatic logic has to be in place to prevent a single user from having to verify their identity for every wallet or account they use.
Failure during identity verification often leaves users in a broken conversion flow. Customers can get stuck or locked out, and these issues can drag on.

Deposits and payouts might seem like the same action in reverse, but they work differently.
Deposits happen outside the wallet. A deposit account is essentially a bank account provisioned for a wallet that can be repeatedly used to deposit fiat funds. Once the account is provisioned, a user can initiate a transfer from their bank account to fund the wallet without further interaction with the provider.
Payouts, in contrast, are initiated from the wallet itself. Payout recipients can be registered as external bank accounts, and the wallet initiates a distinct payout action for each time it needs to send funds.
Paying money out thus requires different infrastructure and partners than accepting deposits.
With deposits, your business can also prefund accounts, meaning capital is held with a provider in advance so that deposits can be credited immediately. This may be necessary when the deposit experience needs to feel instant.
The "instant" speed often comes from having capital already available with the provider, not the underlying infrastructure, even if the fiat portion takes hours or days to settle.

The steps involved in deposits or payouts are regulated differently, require different licenses, and can be performed by different providers.
Providers can have extensive fiat currency licenses in a country but be legally unable to convert those fiat currencies to stablecoins. And many stablecoin providers rely on trusted partners who specialize in regulation for a specific step in a specific country. Rather than being dictated by geography alone, an orchestration provider’s country coverage hinges on the individual operational steps required throughout the orchestration flow.
The other side of this issue is routing, or how different assets are permitted to move across geographies. Routing is complex and requires a competent partner with the right coverage.
Two assets that look similar might route completely differently. USDT is excluded from certain fiat payout routes and can settle more slowly than other stablecoins like USDC. And routing has timing cutoffs while crypto transactions generally do not. Transaction size can also introduce additional delays, with larger transactions often requiring additional processing. When evaluating a provider, it’s important to judge the depth of its coverage, not simply its size.

Virtually no company requires every component of orchestration.The specific steps and routes that matter depend on what you're building.
Global payroll and contractor payouts
Executing global payouts across multiple countries can incur heavy fees and multi-day settlement delays on traditional rails. Platforms like Deel do this by using Privy wallets to let contractors hold dollar-denominated balances directly, bypassing multi-tiered intermediary networks.
Remittances
At its core, a remittance involves a sender, a recipient, and a cross-border corridor with enough liquidity to process the transfer. Providers like Félix and MAJORITY demonstrate that establishing deep liquidity in target corridors is far more critical than broad geographic coverage with limited off-ramp capacity.
Payouts at platform scale
Structurally similar to payroll, creator payouts operate at a larger scale for platforms processing high-frequency disbursements. Prioritizing automated execution, these systems execute parallel payments from centralized balances while flagging exceptions for review.
Getting funds into an app
Depositing funds is both a conversion and collection challenge because users rarely hold the exact asset an app requires. The primary difficulty stems from geographic and asset variety across global users, making a streamlined entry point essential for engagement.
Treasury movement and more
Some orchestration never touches traditional currency at all: moving value between chains, sweeping idle balances, rebalancing across entities. What matters is routing funds automatically as they arrive, rather than waiting for someone to run a manual sweep.
Cards funded from onchain balances are a closely related problem with enough of its own complexity to deserve separate treatment.
Learn more about standing up a card program.

Teams that successfully use stablecoin orchestration often narrow the problem they’re solving before choosing a provider.
Start with one flow, not a capability
"We want to support stablecoins" is not a specific goal. "We want to be able to pay our contractors in three countries" is.
Write down your corridors first
Identify your required geographic corridors, assets, supported currencies, and maximum transaction sizes upfront. Evaluating providers solely against a list of countries often leads to hidden coverage gaps when payouts fail due to less common requirements or steps.
Settle identity before mechanics
Decide who gets verified, and whether you build that interface or hand it off to your provider. This decision is difficult to reverse once users are onboarded.
Choose how much to abstract
Building on primitives offers greater control, whereas a unified interface simplifies record-keeping. Your choice depends on your expansion strategy: as you scale into more markets, mapping identifiers across systems becomes increasingly complex.
Moving money on and off chain is made easier when APIs and providers work well together. At Privy, we make orchestration easier through simplified APIs, working closely with Bridge to make the developer experience of building products that move money easy. If you’re building products that need to deposit or pay out funds, we’d love to talk to you. Read our Funding docs to learn more.