There are six types of stablecoin APIs: issuer APIs that mint tokens, wallet APIs that hold balances, ramp APIs that convert bank money and stablecoin, payout APIs that deliver local currency, orchestration APIs that route across providers, and non-custodial APIs that never hold the funds. The type decides who holds the money and who carries compliance.
The definition is in what a stablecoin API is.
What are the six types of stablecoin APIs?
Six types of stablecoin API compared by what they do, who holds the funds and where they fail first.
Type | What it does | Who holds the funds | Where compliance sits | What breaks first |
Issuer API | Mints a stablecoin against fiat and redeems it back | The issuer holds the reserve, you hold the tokens | The issuer onboards you as an institution, and your end users are yours to check | Nothing in it pays a person |
Wallet API | Creates wallets, holds balances, signs on your instruction | Whoever controls the keys: the provider in a hosted model, the end user in a user-controlled one | The provider screens the holders it hosts | Key handling, and no bank rail on its own |
Ramp API | Converts bank money to stablecoin (on-ramp) and back (off-ramp) | The provider between steps, the customer otherwise | The provider verifies the customer, the receiving bank handles the local leg | Quotes that expire, deposits that arrive late |
Payout API | Delivers a fixed local-currency amount to a named recipient over a local rail | Varies by vendor, so ask per step | The provider verifies the customer and the recipient | Recipient details the bank rejects, rail cut-off times |
Orchestration API | Routes one request across several providers by corridor, price or uptime | Usually the downstream providers | Split, often passed down the chain | Nobody owns screening for the whole payment |
Non-custodial payment API | Converts and settles a quoted amount without holding a balance | The customer, until it authorizes the exact amount | Varies by provider, so ask for the split in writing | Every payment waits for a signature |
Issuer, wallet and ramp APIs: the money side
An issuer API is the primary market. Circle Mint is the standard example: Circle describes it as a product for institutional customers who deposit fiat from a linked bank account, mint USDC or EURC and send the tokens to blockchain wallets, with redemption back at 1:1.
A wallet API creates wallets and holds balances for the people or companies a business serves. Models split by who controls the keys: Circle's wallet products separate developer-controlled wallets, where the business holds the keys through the API, from user-controlled wallets, where the end user does. The regulatory line follows control: FinCEN guidance FIN-2019-G001 (May 9, 2019) calls hosted wallet providers account-based money transmitters. Custodial vs non-custodial wallets covers that split.
A ramp API sits between the bank and the blockchain. The on-ramp turns a local-currency deposit into stablecoin in a wallet, and the off-ramp turns stablecoin in a wallet into a payment to a bank account. The price object is the quote, which fixes the rate, the fee and the amount that arrives, and which expires. The failure that shows up first is the late deposit: a payer sends funds after the on-ramp transaction has expired, and the ramp has to decide what happens to them.
Lumx is the wallet and ramp types. It has its own mint account at Circle and also buys USDC through BTG Pactual. When a deposit lands after its on-ramp has expired, Lumx does not process it and refunds the sender on the same rail, so the integration starts a new on-ramp. Every customer gets a custodial wallet on each supported network (Ethereum, Polygon, Base and Tron, plus Stellar for BRL to USDC on-ramps only), enabled when the customer is approved. The wallet keeps its balance between operations, and Lumx pays the network fee on its own legs, so the customer needs no ETH or TRX. Each on-ramp, off-ramp and transfer status change fires a webhook event. What a custodial wallet is covers the model, and the custodial wallets page the product.
The delivery side: payout and orchestration APIs, and non-custodial flows
A payout API connects a stablecoin balance to a recipient's bank account in local currency. The buyer registers the recipient once, asks for a quote, starts the payout and watches the status. The type sells the last mile: the rail, the bank's rejections and cut-off times. Some ask the business to pre-fund a balance they hold, and others pull a quoted amount at execution.
An orchestration API sends one request to whichever provider fits by corridor, price or uptime. It earns its place when a business already runs several providers; with one provider covering the corridors it adds a layer and no reach. Stablecoin orchestration covers the routing.
A non-custodial payment API converts and settles without holding a balance. The customer's stablecoins stay in a wallet it controls until it authorizes one specific, quoted payment. The term describes a flow, and one provider can offer both models, so the useful question is the moment funds leave the customer's control.
On Lumx, the payout type is the off-ramp: the wallet is debited, the stablecoin is converted and the local currency goes to a registered destination, with the holder relationship (supplier, employee, the customer itself) declared when the destination is created. The rail follows the registered destination, so a Pix (Brazil's instant payment system, run by the Central Bank) payout and a SPEI (Mexico's interbank transfer system, run by Banxico) payout are the same off-ramp call against different destinations. As of November 1, 2026, the coverage page lists Pix and SPEI as instant, and SWIFT, which Lumx runs in USD, is the route to recipients, such as those in Asia-Pacific, where no local rail is listed. Lumx runs quote, conversion and payout inside one provider and one KYB (know your business, the verification of a company and its owners). The global payments product page and the coverage page list the corridors.
What is the difference between a platform API and a payout API?
A payout API covers one layer of a cross-border payment, the local delivery. A platform API covers three: the account and wallet that receive and hold the money, the conversion between currencies, and the local payout. The difference is how much of the stack the buyer still supplies.
Three layers of a cross-border stablecoin payment, and what the buyer supplies under a payout API versus a platform API.
Layer | Under a payout API, the buyer supplies | Under a platform API, the provider runs |
Account and wallet | A receiving account, a wallet and the funds in it | An account per currency and a wallet per customer |
Conversion | A stablecoin balance and liquidity at a rate | The quote, the conversion and the liquidity behind it |
Local payout | Nothing, since this is the layer the API sells | The same delivery, tied to the same customer record |
Verification | One check for the payout and another for the layers before it | One verification covering all three layers |
A payout API is the smaller purchase when the business already has a licensed way to receive money and a stablecoin balance. A platform API fits when the product both receives and pays.
Lumx sells the platform shape, and customers use the Lumx dashboard next to the API: one API and one KYB cover the named virtual account that receives, the custodial wallet that holds and converts, and the payout that delivers. A named virtual account is an account number in the customer's own name, tied to one currency. A business needing only the payout leg can use the wallet and the off-ramp. The named virtual accounts product page describes the receiving side.
Match the type to the job
Start from what the product has to do with money, then check custody. A business that only pays suppliers from a stablecoin balance needs a payout API, or a platform API if it also collects from customers. The types are unranked, and the table names no vendor: compare providers inside a type with the four questions below.
Six common stablecoin payment jobs, the type that fits and what is left to build.
Job | Type that fits | What is left to build |
A payroll platform paying contractors abroad | Payout API, or a platform API if it also collects from employers | The payee list and a run schedule |
A marketplace collecting from buyers and paying sellers | Platform API, each seller onboarded as its own customer | Fee logic and seller onboarding screens |
An exchange that needs fresh USDC supply | Issuer API | A route from the token to a bank account |
A PSP running several off-ramp vendors | Orchestration API, or your own router | Screening that covers the whole payment |
A company paying suppliers from stablecoin it already holds | Non-custodial payment API | An approval step on every payment |
A B2B seller collecting from foreign buyers in local currency | Platform API with named virtual accounts | Matching deposits to invoices |
Four questions sort vendors inside a type. Who holds the funds, under which licence? Who verifies the customer and screens the recipient, in writing? Is the quote locked, and for how long? How does a balance get out? The wider checklist is in how to choose a provider.
How do the types charge, and how long does each take to integrate?
How each type commonly charges and what integration involves; no vendor prices are quoted.
Type | How it commonly charges | Integration effort |
Issuer API | Mint and redeem terms in an institutional agreement | Institutional onboarding comes before any code |
Wallet API | A wallet or platform fee, sometimes per active wallet | Key handling and signing flows |
Ramp API | A spread on the quote plus a fee per conversion | Quotes, expiry and status webhooks |
Payout API | A payout fee per transaction, plus spread | Recipient registration and rail rules |
Orchestration API | A routing fee on top of each downstream provider's charges | Several provider contracts and one routing layer |
Non-custodial payment API | A fee per payment | A signature step in the product |
On Lumx, pricing is a monthly platform fee plus usage-based per-transaction fees, transparent FX on locked quotes, no pre-funding; no published plans. No pre-funding means no capital parked in settlement accounts before a transaction. An API integration goes live in two to three weeks.
Most products need two types, and the seam is where they break
I would choose by drawing the payment as a line, marking where the money sits at each step, and buying the fewest types that cover the line. Every extra type adds a seam: another verification, webhook format and party to reconcile against. When the product both receives and pays, I would start from a platform API, because one onboarding then covers collecting and paying. I would buy a payout-only API only when the business already holds liquidity and a licensed way to receive. The cost of the platform choice is that the balance sits with one provider, and I would say so to a security team before the integration.
The seam to watch is custody: a wallet with a payout type behind it fails when users' money and the company's treasury share one wallet.
On Lumx that is the Nested Payments rule: Lumx has to see every payer and payee, so each payout debits the customer's own wallet to a destination registered under that customer, or moves to another onboarded customer's wallet. Pooling funds for third parties Lumx has not onboarded is not allowed. For a marketplace, each seller is its own customer with its own wallet.
Exchange, gateway and card APIs sit next to the six
Three neighbors get called stablecoin APIs and belong elsewhere. A crypto exchange API places orders on an order book, for price discovery. A payment API delivers a fixed amount to a named recipient, so the quote, the destination and the status are its core objects. A crypto payment gateway lets a merchant accept a stablecoin at checkout and rarely pays anyone out, and stablecoin API vs crypto payment gateway draws that line. Against a bank's API, see stablecoin API vs banking API.
Lumx's objects are customers, accounts, wallets, destinations, exchange rates and transactions.
When a platform API is the wrong tool
A platform API is the wrong choice when the funds must stay with the customer until each payment, which needs a non-custodial flow; when the business wants its own token, which needs an issuer; and when the volume is a handful of payments, where onboarding costs more than the saving and a dashboard or an OTC desk is enough.
Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, Bre-B, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.
How a quote lock and the technical design look on Lumx
A locked rate returns an identifier passed on the transaction, for 30 seconds, one minute or five minutes, and the 30-second lock carries no fee. The self-serve sandbox runs on test stablecoins with mock banking partners. The API publishes an OpenAPI specification, and how to integrate a stablecoin API walks through the build.
Methodology and sources
Lumx behavior was read in the Lumx documentation on November 1, 2026: Welcome, Stablecoin Wallets, Accounts, Transactions, Destinations, Exchange Rates, Coverage, Nested Payments, Webhooks, Environments and OpenAPI Specification. Circle Mint and Circle's wallet products were read in Circle's developer documentation the same day, and the hosted wallet language comes from FinCEN guidance FIN-2019-G001, section 4.2.1, issued May 9, 2019. The six types are an editorial grouping.
Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Natalia Y. on Unsplash.
What are the types of stablecoin APIs?
There are six: issuer APIs that mint, wallet APIs that hold balances, ramp APIs that convert, payout APIs that deliver, orchestration APIs that route and non-custodial APIs that never hold the funds. Many products combine two. Lumx covers the wallet and ramp types plus payout, with named virtual accounts for receiving, under one API and one KYB.
Is a stablecoin issuer API the same as a payment API?
No. An issuer API mints a token against a fiat deposit and redeems it back, usually for institutional customers. It does not pay a supplier or collect a bank transfer, which a payment API does on top of issuers. Lumx sells the payment layer: custodial wallets, on-ramp, off-ramp and payout under one API and one KYB.
Who carries compliance in each type of stablecoin API?
A wallet provider screens the holders it hosts and, in the US, is a money transmitter under FinCEN guidance FIN-2019-G001. A payout provider verifies the customer and the recipient. An orchestration layer often passes screening down the chain, so ask for the split in writing. On Lumx, the customer completes KYB once, and every payment is tied to an onboarded customer under the Nested Payments rule.
What do I check in a stablecoin API's technical design?
Check four things: a published API specification, webhooks for status changes, a sandbox that does not move real money, and quotes that can be locked. A type with none of them leaves the status polling and testing to you. Lumx publishes an OpenAPI specification, fires a webhook on each on-ramp, off-ramp and transfer status change, and runs a sandbox on test stablecoins with mock banking partners.
How is a stablecoin API different from a crypto exchange API?
An exchange API places orders on an order book and holds balances in exchange accounts. A stablecoin payment API quotes a conversion, moves a fixed amount to a named recipient and reports the delivery status. On Lumx, the core objects are customers, wallets, destinations, exchange rates and transactions.
