---
title: "Wallet API vs embedded SDK vs white-label: which fits?"
seoTitle: "Wallet API vs embedded wallet SDK vs white-label wallet"
description: "Compare the three wallet integration models on control, launch time, engineering effort, security, lock-in, and cost, with a five-question decision tree."
date: "2026-08-26"
updated: "2026-08-26"
category: "stablecoins"
author: "BlindPay Team"
faq:
  - q: "What is wallet as a service (WaaS)?"
    a: "Wallet as a service is hosted wallet infrastructure sold to businesses. The provider runs key management, signing, chain connectivity, and balance tracking, and exposes them through a backend API, a client SDK, or both. The business builds its product on top without operating key storage or blockchain nodes itself. White-label wallets are sometimes sold under the same name."
  - q: "What is the difference between an embedded wallet and a wallet API?"
    a: "An embedded wallet SDK runs inside your web or mobile app and creates a wallet for each user, who signs transactions in your interface after logging in with email, social, or a passkey. A wallet API runs on your server, and your backend creates wallets and requests signatures under policies you set. Consumer apps lean on SDKs. Treasury and payout flows lean on APIs."
  - q: "Is a white-label crypto wallet a good idea?"
    a: "A white-label wallet is a good idea for a pilot or a non-core feature, because it is the fastest way to put a branded wallet in front of users. It is a weaker choice when the wallet is central to your product, since the provider controls the roadmap, much of the user data, and how hard it is to leave."
  - q: "Can I use more than one wallet integration model?"
    a: "Yes, and many products do. A common setup is an embedded SDK for end users who sign their own transactions, plus a wallet API with approval policies for the company's treasury and payout wallets. The two models can come from the same provider or from different ones, as long as your backend tracks which addresses belong to which flow."
  - q: "Which wallet integration model is fastest to launch?"
    a: "White-label is fastest, because the provider ships the whole application and you mostly configure branding. An embedded SDK is next, since the provider supplies login, key, and signing flows while you build the rest of the app. A wallet API takes the most engineering, because your team builds every screen, policy, and state transition around the provider's endpoints."
  - q: "Does the wallet model affect payouts to bank accounts?"
    a: "Not directly. No wallet model on its own converts stablecoins into bank money. That needs an off-ramp with banking partners and local rails. The wallet model only changes who signs the authorization for a payout: the user in an embedded wallet, or your backend under policy with a wallet API. The payments integration can stay the same."
---

Choose a wallet API if you have engineers and need full control of the product, an embedded wallet SDK if you want wallets inside a consumer app without building key flows, and a white-label wallet if speed to launch matters more than control. Most teams land on an API or an SDK, and plenty use both.

All three are forms of **wallet as a service (WaaS)**: hosted wallet infrastructure where the provider runs key management, signing, and chain connectivity. What changes is how much of the product you build around it. If you're earlier in the project, [what is crypto wallet integration](/resources/more/what-is-crypto-wallet-integration) covers the components first.

## Wallet API, embedded SDK, or white-label: which should you choose?

The choice comes down to two questions: who signs transactions, and how much of the interface you want to own. If your backend signs, use an API. If your users sign inside your app, use an SDK. If you want someone else to own the whole app for now, use white-label.

| Choose | When | Avoid when |
| --- | --- | --- |
| Wallet API | Your backend moves funds, you need custom flows, and you have engineers to build the interface | You need a consumer wallet live before you can staff the work |
| Embedded SDK | Your users sign their own transactions inside your web or mobile app | You need deep control over key flows or unusual chains the SDK doesn't cover |
| White-label | You're testing demand, or the wallet is a side feature | The wallet is the core of your product and roadmap |

## What is a wallet API and when does it fit?

A wallet API is a set of server-side endpoints for creating wallets, reading balances, requesting signatures, and receiving webhooks about on-chain activity. Your backend calls the provider, the provider signs under policies you configure, and you build every screen the user sees.

Providers usually protect keys behind a wallet API with MPC or a **hardware security module (HSM)**, a tamper-resistant device that stores keys and signs without exposing them. You never handle raw keys. You do own the policy engine configuration: which destinations are allowed, which amounts need a second approver, and which API keys can request a signature.

A wallet API fits when:

- Your backend initiates transfers: payouts, treasury moves, fee collection, refunds.
- You need custom flows that no prebuilt UI supports.
- You serve businesses, not consumers, and signing happens under company policy rather than a user's thumb.

Your responsibility is larger than it looks. API credentials become the keys to the kingdom, so they need rotation, scoping, and monitoring. Retries need idempotency so a network blip doesn't sign a transfer twice. And every state a transaction can be in needs a screen.

## What is an embedded wallet SDK and when does it fit?

An embedded wallet SDK is a client library that creates a wallet for each user inside your web or mobile app. The user logs in with an email, a social account, or a passkey, and the SDK handles key creation, storage, and signing prompts. Nobody installs a separate wallet app.

Under the hood, embedded wallets usually split the key into MPC shares between the user's device and the provider, or keep it in the device's secure hardware. Passkey login builds on the [W3C WebAuthn standard](https://www.w3.org/TR/webauthn-3/). Some SDKs deploy a smart-contract account for each user, following [ERC-4337](https://eips.ethereum.org/EIPS/eip-4337), which adds features like sponsored gas and spending limits. [Custodial vs non-custodial vs MPC wallets](/resources/more/custodial-vs-non-custodial-vs-mpc-wallets) explains how the share split decides who controls the funds.

An embedded SDK fits when:

- Your users are consumers or small businesses who have never used a crypto wallet.
- Users sign their own transactions, and you want the prompt inside your interface.
- You want wallets tied to your existing login instead of a recovery phrase.

Check four things before you commit: platform coverage (web, iOS, Android, React Native), how far the prebuilt UI can be customized, which chains and signature schemes are supported, and whether users can export their key if you ever change providers.

## What is a white-label wallet and when does it fit?

A white-label wallet is a finished wallet application that the provider runs and you brand as your own. You configure logos, colors, supported assets, and sometimes fees. The provider owns the code, the release schedule, and usually much of the user data.

A white-label wallet fits when:

- You're running a pilot to see whether your users want a wallet at all.
- The wallet is a side feature, not the product.
- You have no engineering capacity for wallet work this year.

The trade-off 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 your own wallet means new addresses for every one of them, which is a support campaign, not a deploy.

## How do the three models compare?

The three models trade control for speed. A wallet API gives the most control and the most work, a white-label wallet the least of both, and an embedded SDK sits in the middle. There is no reliable public benchmark for launch times, so the table describes relative effort.

| | Wallet API | Embedded SDK | White-label |
| --- | --- | --- | --- |
| Control over UX and data | Full | Your app, with prebuilt wallet flows | Branding and configuration |
| Time to launch | Longest | Medium | Shortest |
| Engineering effort | High: backend, policies, every screen | Medium: app integration, login, states | Low: configuration and support |
| Security responsibility | Shared: provider protects keys, you own policies and credentials | Shared: provider owns key flows, you own the app and session security | Mostly the provider |
| Vendor lock-in | Medium: addresses and policies tie you in | Medium to high: user keys live in the provider's scheme | High: the whole product lives with the provider |
| Cost drivers | Platform fee, per-wallet or per-transaction fees, gas | Monthly active wallets, per-transaction fees, gas sponsorship | Licensing or revenue share, per-user fees |

## Which model fits? Five yes/no questions

Answer these in order. Each answer either points to a model or sends you to the next question.

1. **Do you need a wallet in front of users before you can staff wallet engineering?** Yes: start with a white-label pilot, and plan the migration now. No: go to question 2.
2. **Will end users sign transactions themselves inside your app?** No, your backend moves the funds: use a wallet API. Yes: go to question 3.
3. **Do most of your users already have their own wallets?** Yes: let them connect those wallets through the standard [EIP-1193 provider interface](https://eips.ethereum.org/EIPS/eip-1193), and skip the wallet vendor for them. No: use an embedded SDK.
4. **Does your company also move its own funds, such as treasury, fees, or payouts?** Yes: add a wallet API with approval policies next to the SDK. No: the SDK alone may be enough.
5. **Does money have to reach bank accounts?** Yes: add a payments layer for on-ramps and off-ramps. No wallet model solves that on its own. [What is a crypto on-ramp and off-ramp](/resources/more/what-is-a-crypto-on-ramp-and-off-ramp) explains the pieces.

## How do wallet infrastructure and payments infrastructure work together?

Wallet infrastructure holds and signs. Payments infrastructure connects the wallet to bank accounts. They're separate layers, and keeping them separate lets you change one without rebuilding the other.

A typical stack looks like this:

```text
1. Your app            login, balances, business logic
        |
2. Wallet provider     creates wallets, holds or splits keys, signs under your policies
        |              (for example Privy, Dfns, Circle wallets, Fireblocks, or Utila)
        |
3. BlindPay            virtual accounts, quotes, on-ramp and off-ramp, payouts
        |
4. Local rails         Pix, SPEI, ACH, RTP, SEPA, SWIFT (POBO/COBO), TED, ACH Colombia
```

Here's how the layers meet. The wallet address your provider creates is registered with BlindPay as a [blockchain wallet](/docs/blockchain-wallets). A [virtual account](/resources/more/stablecoin-virtual-accounts-explained) gives the customer US bank details, and each deposit converts to USDC or USDT and lands at that address. For a payout, the wallet authorizes the quoted amount, and BlindPay converts it and pays out on the local rail.

BlindPay is not the wallet provider in this picture. It never holds the keys to that wallet, and the wallet provider never has to touch a bank. The integration model only changes who signs the payout authorization: the user in an embedded wallet, or your backend under policy with a wallet API. Nothing has to be pre-funded for an external-wallet payout, as [what no pre-funding means](/resources/more/no-pre-funding-stablecoin-payouts) explains.

## What mistakes do teams make when choosing an integration model?

Most mistakes come from choosing on the demo instead of on the key architecture and the exit. Five that come up again and again:

1. **Picking on UI polish.** A smooth demo says nothing about who can sign without the user. Ask for the key and share diagram first.
2. **Ignoring chain coverage until chain two.** Ethereum and Tron sign with ECDSA, Solana and Stellar with Ed25519. A provider that supports one scheme well may not support the other, and your second chain becomes a second vendor.
3. **Treating the wallet as the payments stack.** A wallet holds stablecoins. It doesn't collect ACH deposits, run KYC, or pay out over Pix. Budget the payments layer from the start ([build vs buy](/resources/more/build-vs-buy-stablecoin-payments) shows what that layer contains).
4. **No exit plan.** Key export, address export, and transaction history export belong in the contract before launch, not after a price increase.
5. **Leaving compliance for later.** User verification and wallet address screening need hooks in the first version. Retrofitting them means re-onboarding users. [How to automate KYC and KYB](/resources/more/how-to-automate-kyc-kyb-stablecoin-payments) covers the verification side.

## What to do next

Run the five questions above with your product and engineering leads in one meeting, and write down the model for each flow: end users, treasury, and payouts. Then ask each shortlisted provider the same thing: who can sign without the user, and how do we leave?

If bank accounts are in scope, check the [blockchain wallet docs](/docs/blockchain-wallets) to see how a wallet from any of these models links to payins and payouts.