Types of stablecoin APIs: issuer, wallet, orchestration, payout, and non-custodial APIs compared

There are five main types of stablecoin APIs: issuer APIs that mint and redeem, custodial wallet APIs that hold balances, orchestration APIs that route across providers, payout and collection APIs that connect stablecoins to bank rails, and non-custodial payment APIs that convert without holding the customer's funds. The type decides who holds custody and who carries compliance.

Definition. A stablecoin API is a programming interface that lets software create, move, convert, or settle stablecoins such as USDC and USDT without the developer running blockchain nodes or banking relationships directly.

Key takeaways

• "Stablecoin API" covers five different products. Two vendors using the same label can do completely different jobs.
• The first question for any of them is custody: at which step does a third party hold your customer's money?
• Custody drives compliance. Under FinCEN's 2019 guidance, a hosted wallet provider is a money transmitter. Someone using their own unhosted wallet to pay for things is not.
• Issuers mint and redeem. They do not pay a supplier in Mexico. Payout and collection APIs do that part.
• Most products combine two types. Draw the fund flow before you sign with a second provider.

If you need the basics first, start with what a stablecoin API is. This page sorts the category into types.

What are the five types of stablecoin APIs?

The five types are issuer, custodial wallet, orchestration, payout and collection, and non-custodial payment APIs, and they differ mainly in who holds the funds.

The last two overlap. A payout API can be custodial or non-custodial, and some providers offer both models in the same product.

What does an issuer API do?

An issuer API mints new stablecoins when you send fiat and redeems them when you send stablecoins back. It is the primary market.

Circle Mint is the clearest example. Circle describes it as a product for institutional customers minting USDC or EURC: you deposit fiat from a linked bank account, convert it to USDC, and send the tokens to blockchain wallets. USDC redeems 1:1 for US dollars through the same account.

What an issuer API does not do: pay a person in Colombia, collect a Pix transfer, or screen your end customers. You are the customer. Your end users are your problem.

In the US, who may issue a payment stablecoin is now set by the GENIUS Act. The GENIUS Act explainer covers what that changes for companies that move stablecoins without issuing them.

What does a custodial wallet API do?

A custodial wallet API creates blockchain wallets for your users and holds the keys or the balance on their behalf. Your users see a balance; the provider moves it.

Circle Wallets is one example. Circle offers developer-controlled and user-controlled wallets and says developers do not manage raw private keys; keys are secured with MPC or passkeys depending on the product. That distinction matters. In a developer-controlled wallet, you (through the provider) control the funds. In a user-controlled one, the user signs.

The regulatory line follows control. FinCEN's 2019 guidance on convertible virtual currency calls hosted wallet providers "account-based money transmitters." It also says a person using an unhosted wallet to buy goods or services on their own behalf is not a money transmitter.

So the custody model of your wallet API can change your own licensing posture. Custodial vs non-custodial vs MPC wallets walks through the trade-offs.

What does an orchestration API do?

An orchestration API sends one payment request to whichever underlying provider fits best, by corridor, price, or uptime. It is a routing layer, not a rail.

Orchestrators usually do not hold funds; the providers they route to do. They also tend to pass compliance down the chain, which leaves gaps if nobody owns screening for the whole payment. What is payment orchestration covers the routing logic in depth.

Use one when you already have three or more providers and the routing decision is costing you engineering time. Skip it when one provider covers your corridors.

What does a payout and collection API do?

A payout and collection API connects stablecoins to bank accounts: it pays out USDC or USDT as local currency over rails like ACH, Pix, or SPEI, and collects bank deposits back into stablecoins. This is the off-ramp and on-ramp layer.

These APIs typically verify the customer (KYC or KYB), store the recipient's bank details, lock a rate on a short-lived quote, and fire webhooks as the payment moves. The quote is the core object: it fixes the rate, the fees, and the amount the recipient gets, and it expires fast.

Custody varies more here than anywhere else. Some providers require you to pre-fund a balance they hold. Others pull the exact quoted amount from your wallet at execution. Ask which.

What makes a stablecoin payment API non-custodial?

A stablecoin payment API is non-custodial when the customer's stablecoins stay in a wallet the customer controls until the customer authorizes one specific, quoted payment. No pooled balance sits with the provider between payments.

BlindPay works this way for payouts funded from an external wallet. The customer holds USDC or USDT in its own wallet, BlindPay returns a payout quote that expires in 5 minutes, and on EVM chains the customer approves the token contract to release exactly the quoted amount. BlindPay then pays out over Pix, SPEI, ACH, RTP, SEPA, or SWIFT (POBO/COBO). BlindPay also offers managed wallets (in beta), and those are custodial: BlindPay holds the keys.

That nuance is the point. "Non-custodial" describes a flow, not a company. Non-custodial payments explained has the questions to ask a provider that uses the term.

Who holds the money at each step of a stablecoin API request?

Custody can change hands several times in one cross-border payment, and the API type decides who holds the money at each step. Here is a payout from a US fintech to a supplier's bank account in Brazil, step by step, in a non-custodial flow.

1. Customer onboarding. The fintech's business customer passes KYB. Funds: still at the customer's bank or in the customer's wallet. Nobody new holds anything.
2. Quote. The API locks a rate and fee for a short window (often minutes). Funds: still with the customer. A quote moves no money.
3. Authorization or deposit. The customer approves the exact stablecoin amount, or wires fiat if it starts in dollars. Funds: still with the customer until execution in an approval flow. In a pre-funded flow, they now sit with the provider.
4. Conversion. Stablecoins are exchanged for local currency through a liquidity provider. Funds: in transit through the provider's settlement path for minutes.
5. Onchain transfer. The stablecoin leg settles on the chain the quote named. Funds: onchain, final once the chain confirms.
6. Local payout. The provider sends BRL over Pix to the supplier's account. Funds: with the receiving bank, then the supplier.
7. Webhook confirmation. The API notifies the fintech that the payout completed, or that it failed or was refunded. Funds: with the supplier on success, or back in the funding wallet on a refund.

Picture it as a horizontal diagram: customer wallet on the left, provider in the middle, Brazilian bank on the right, with a shaded band over each step marking the custody holder. In a pre-funded custodial flow, the provider's band starts at step 3 and runs for days or weeks. In a non-custodial flow, it covers only steps 4 and 5.

How is a stablecoin API different from a traditional payment API or an exchange API?

A stablecoin API is built to deliver a fixed amount to a named recipient across borders, a traditional payment API moves money inside the banking system, and an exchange API trades assets on an order book.

A fourth thing gets confused with all three: crypto checkout gateways for merchants, which accept payments at a point of sale and rarely pay anyone out.

Which type of stablecoin API does your product need?

Pick the type by the job, then check custody. These illustrative scenarios map common jobs to types.

• A wallet app that shows users a dollar balance. Custodial wallet API, plus a payout API for bank withdrawals.
• A payroll platform paying contractors in Latin America. Payout API. Non-custodial if you want funds to stay in your wallet until each pay run.
• A PSP with five off-ramp providers. Orchestration API, or your own routing layer.
• An exchange that needs fresh USDC supply. Issuer API.
• An importer paying suppliers in Mexico from USDC it already holds. Non-custodial payment API.
• A marketplace collecting from US buyers and paying sellers abroad. Collection plus payout API, ideally from one provider so one KYB covers both directions.

What are the risks and limits?

Every type shares five limits, whatever the vendor says.

• Regulation. Rules differ by country and are still moving. Confirm your own obligations with qualified counsel before launch.
• Depegging. A stablecoin can trade below $1 under stress. Short payment windows reduce exposure; balances held for weeks increase it.
• Corridor liquidity. A provider can list a country and still have thin liquidity for large amounts there.
• Off-ramp coverage. Minting is global; paying out in local currency is not. Check that the rail you need is live in production.
• Lock-in. Custodial balances and proprietary wallet formats are slow to move. Ask how you exit.

How do you get started with a stablecoin API?

Start from the fund flow, not the vendor list.

1. Write down the job. Direction (in, out, or both), corridors, currencies, and average payment size.
2. Mark every custody moment. For each step, note who holds the funds and under which license.
3. Shortlist by type. Use the table above, then how to choose a stablecoin API to compare vendors within the type.
4. Test in a sandbox. Run a success, a failure, an expired quote, and a duplicate webhook before anything else.
5. Get the compliance split in writing. Who verifies customers, who screens recipients, who files reports.

BlindPay's development instances run on testnets with a test stablecoin, so step 4 costs nothing, and its SDKs cover Node.js, Python, Go, PHP, and Swift.