A wallet API is a set of server-side endpoints where a business creates wallets and moves funds from its backend. An embedded wallet SDK is a client library that gives each end user a wallet inside the app, and the user approves each transaction. A white-label wallet is a finished wallet application that the provider runs under the buyer's brand.
The three are not three prices for the same product. They put the signature in different hands, leave a different amount to build, and make leaving a provider cheap or expensive. This post compares them on those terms and lists what to measure before signing.
A wallet API puts your backend in charge
A wallet API is the model where the business, not the end user, decides when money moves. Your backend calls the provider to create a wallet, read a balance, send a transfer or start a payout, and the provider executes it. You build every screen the user sees, and the provider runs the keys and the network connections, which is why the model is often called wallet as a service. The API layer on its own is defined in what a stablecoin API is.
It fits when a company moves funds for its product: payouts to suppliers or contractors, fee collection, refunds, treasury moves between entities, flows that run with nobody holding a device.
The cost is that the credential becomes the asset. An API key that can start a payout is as sensitive as a bank login, so it lives on a server and gets rotated. Retries need an idempotency key, and every payment state needs a screen, because the provider gives you events and not an interface. On Lumx, creating a customer provisions a wallet on five networks, and your backend moves funds by API call.
An embedded wallet SDK puts the user in charge
An embedded wallet SDK is a library that runs inside your web or mobile app and creates a wallet for each user. The user signs in with an email, a social account or a passkey, and the library handles key creation and the signing prompt. Nobody installs a separate wallet app, and the user sees your brand throughout.
Many embedded wallets, though not all, split the key into shares between the user's device and the provider, or keep it in the device's secure hardware. The point of the model follows: the provider cannot, on its own, move the user's funds. That suits a consumer or small-business product where the user must own the balance.
It asks more of you than the demo suggests: check which platforms the library covers, how far the prebuilt screens bend to your design, which networks it signs for, and whether a user can export a key if you change provider. A payout that needs a user's approval cannot run unattended, so a company treasury flow does not belong here.
A white-label wallet hands the whole product to the provider
A white-label wallet is a finished application that the provider builds and runs, and you configure with a logo, a color palette and sometimes the assets and fees on offer. It is the shortest road to a branded wallet, and your team releases nothing.
The trade shows up later. Features you need wait on the provider's roadmap, user data may live in the provider's systems under its terms, and moving users to a wallet you own means new addresses for every one of them, which is a support campaign and not a deploy. White-label suits a pilot or a side feature, and a poor choice when the wallet is the product.
How do the three models compare?
The three models trade control for speed: the API gives the most control and the most work, white-label gives the least of both, and the SDK sits in between.
The wallet API, embedded wallet SDK and white-label models compared on who signs, who builds, and how hard it is to leave.
Wallet API | Embedded wallet SDK | White-label wallet | |
Who authorizes a transaction | Your backend, by API call | The end user, in your app | The end user, in the provider's app |
Who builds the screens | You, all of them | You, around prebuilt wallet flows | The provider |
Who holds the keys | Usually the provider | Typically split between the user's device and the provider, or the user alone; varies by vendor | The provider |
Can a payout run unattended | Yes | No, it waits for the user | Depends on the provider |
What you are responsible for | Credentials, retries, every payment state | The app, the session and the login | Configuration and support |
Cost of leaving | Medium: addresses and integration code | Typically medium to high: user keys sit in the provider's scheme | Typically high: the product and the users' addresses sit with the provider |
Typical cost drivers | Platform fee, per-transaction fees | Monthly active wallets, per-transaction fees | License or revenue share, per-user fees |
Best for | Payouts, treasury, a platform paying its users | Consumer wallets where users own the balance | A pilot or a side feature |
No public benchmark of launch times across the three turned up on November 1, 2026, so the only launch figure here is Lumx's own, in the evaluation table below.
Choose by who authorizes the money movement
Start with one question: when money moves, who has to approve it? If your business does, you want an API. If the user must, you want an SDK. If neither of you wants to build the wallet this year, you want white-label, and you should plan the exit on day one. Four further questions settle the rest:
Will end users sign their own transactions inside your app? If not, stop: the API is the model.
Do most of your users already have a wallet? If they do, let them connect it and skip the vendor for those users.
Does your company also move its own funds, such as treasury, fees or payouts? If so, add an API next to whatever you chose for users.
Does the money have to reach a bank account in local currency? If so, no wallet model does that alone. You need a payments layer with on-ramps, off-ramps and local rails, and the cleanest version is one where the wallet and the payments layer are the same provider.
I would put any flow in which the business authorizes the movement of money on a wallet API, and I would reach for an SDK only when the end user has to hold a key to hold the funds. That is the recommendation, and it has a cost I would rather say out loud: an API wallet on a custodial provider means trusting a company instead of a signing policy you wrote yourself, which is what lets a payout clear unattended and what a security team should hear before the integration. I would not start with white-label unless the wallet is a pilot, because the exit is a migration of every user's address.
Custody follows from the choice. A wallet API with a custodial provider means the provider holds the keys and signs on your instruction; what a custodial wallet is covers that arrangement, and who should hold the keys, a different question from the integration model, is in custodial vs non-custodial wallets for business. Lumx wallets are custodial, and Lumx signs on your API instruction.
How do you evaluate a wallet integration provider?
Ask every shortlisted vendor the same eight questions and compare answers you can measure. The table gives Lumx's answer from its documentation on November 1, 2026.
Eight questions to put to any wallet provider, the answer to look for, and what Lumx documents today.
Ask | Look for | Lumx, as documented |
Who can sign without the user | One sentence, in the contract | Lumx wallets are custodial: your backend instructs by API call, and no end user signs |
Which networks and stablecoins | A list by network, not a count | Ethereum (USDC, USDT), Polygon (USDC, USDT), Base (USDC), Tron (USDT), Stellar (USDC, BRL on-ramp only) |
A sandbox with no real money | Test assets and a key before any contract | Sandbox runs on test stablecoins with mock banking partners, and keys come from the Dashboard |
How many states to map | A count of event types | 15 money events: 7 on-ramp, 5 off-ramp, 3 transfer, plus 5 customer events |
Retry safety | A stated idempotency window | An Idempotency-Key header with a UUID v4, kept 24 hours; same key with a different body returns 409 |
An exit | A way to move the balance to an address you control | The Transfer endpoint sends stablecoin to any external wallet address, and the standard agreement covers the funds-return sequence on exit, history and address export, and a liability cap |
Compliance before the first release | Screening on the user and on the chain | Identity verification through the API, plus Chainalysis monitoring |
A go-live date | Weeks, stated | Two to three weeks for an API integration to go live, with the Lumx dashboard available next to the API |
Two of the eight carry most of the weight. Who can sign decides custody. The exit is cheapest to negotiate before launch and nearly impossible afterwards, so key export, address export and history export belong in the contract. The wider question, beyond wallets, is in stablecoin infrastructure provider selection. For one named wallet-first vendor, the Lumx vs Crossmint comparison is where the detail lives.
Most products end up combining models
Most products that outgrow their first model end up with two: an embedded wallet or a white-label app for users who hold their own balance, and a wallet API for the company's treasury and payout wallets. What breaks is one model stretched over both jobs, with users' money and company treasury in the same wallet and a ledger to tell them apart.
That pattern is hard to defend in a compliance review. Lumx treats it as a nested structure that needs written compliance approval: each payout debits the customer's own wallet to a destination registered under that customer (Nested Payments). One wallet per customer, each customer verified, is the structure that survives that review, and structuring custodial wallets shows how institutions lay it out.
When a wallet API is the wrong tool
A wallet API on a custodial provider is the wrong choice in four cases.
When the user must own the keys. A product whose promise is that the provider cannot move funds needs an SDK with a key scheme the user controls.
When the wallet is the product. A consumer wallet competes on its login and how it feels to sign, and an SDK gives you those.
When nobody can build it this year. For a pilot, white-label gets you in front of users first.
When the money never leaves the wallet. A product that only holds assets gains little from a payments API.
Lumx is not the pick when the end user must hold the keys or the wallet is itself the consumer product, because Lumx is a custodial wallet API with no end-user signing.
What a wallet API looks like on Lumx
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.
Lumx is the wallet API model, delivered as a REST API with an OpenAPI specification (3.1.0). A team can import the specification into Postman or Insomnia or generate a client from it, and a docs server for coding agents sits at docs.lumx.io/mcp. The OpenAPI and docs MCP guide covers both. Creating a customer provisions a wallet on each of five networks, and the wallet is enabled once the customer is approved. The project sets a default network, which a request overrides with a blockchain field. The custodial wallets product page describes the same wallets from the buyer's side.
Signing is Lumx's, on your instruction. An on-ramp credits the wallet when local currency lands, a transfer moves stablecoin between two customers or to an external address, and an off-ramp debits the wallet and pays a bank account that was registered as a destination. A payout from the wallet to a Brazilian bank account runs over Pix (Brazil's instant payment system, run by the Central Bank), and the other currencies run over their own rails, listed on the coverage page. A business funds the wallet once and runs many payouts against the balance. Each payout debits the customer's own wallet to a destination registered under that customer, and a structure that moves money for parties Lumx has not onboarded needs written approval from compliance.
A first release needs a sandbox key from the Dashboard and one webhook endpoint. Production needs a call with the Lumx team and uses an IP allowlist, which the docs schedule to be enforced from September 21, 2026. Integration through the API takes two to three weeks until go-live. Lumx does not sell a white-label dashboard or wallet app: you get access to the Lumx dashboard next to the API. The step-by-step build is in the app integration guide. Pricing is a monthly platform fee plus usage-based per-transaction fees, transparent FX on locked quotes, no pre-funding; no published plans.
Methodology and sources
Product behavior was read from the Lumx documentation on November 1, 2026: Stablecoin Wallets, Customers, Environments, Authentication, Webhooks, Idempotency, Nested Payments, OpenAPI Specification and MCP Server. The descriptions of embedded SDKs and white-label wallets are conceptual, and no vendor's pricing or launch time is quoted. The event counts come from the Webhooks page. Res. BCB 520/2025 is on the BCB normative page.
Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: David Hellmann on Unsplash.
What is the difference between a wallet API and an embedded wallet SDK?
A wallet API runs on your server: your backend creates wallets and starts transfers, and the provider executes them. An embedded wallet SDK runs inside your app: each user gets a wallet and approves their own transactions after signing in. APIs suit payouts and treasury, SDKs suit consumer wallets. On Lumx, the model is the API: creating a customer provisions wallets on five networks, and your backend starts every transfer and payout by API call.
Is a white-label wallet a good idea?
It is a good idea for a pilot or a side feature, because it is the fastest way to put a branded wallet in front of users. It is a weak choice when the wallet is central to your product, since the provider sets the roadmap and leaving is costly. On Lumx, wallets are custodial and instructed by API call, and the screens your users see are yours.
Which wallet integration model is fastest to launch?
White-label is the fastest, because the provider ships the application. An SDK is next, since login and signing are supplied. A wallet API takes the most engineering. On Lumx, an API integration takes two to three weeks until go-live, and Lumx does not sell a white-label wallet.
Does a wallet integration need a licence or a regulated provider?
In many jurisdictions, a business that holds customer funds or moves them for third parties needs its own authorization or a regulated provider acting for it, and the answer depends on where the users and the money are. On Lumx, the Brazilian entity has requested its SPSAV authorization and operates in the transition regime under Res. BCB 520/2025, Art. 88, and Lumx US OP LLC is a FinCEN-registered MSB; each customer is verified through the API.
What happens if a wallet API credential is compromised?
Whoever holds a key that can start a payout can start one, so the response is to revoke it, issue a new one and restrict where calls may come from. On Lumx, an API key is shown once, and if compromised it is revoked and rotated from the Dashboard; production keys are meant to be limited to the IP addresses you allowlist.
