- Most wallet integrations that burned engineering teams involved building key management from scratch. Modern wallet-as-a-service (WaaS) platforms hand you an SDK that ties wallet creation to an email address or passkey, and the average integration is measured in days, not quarters.
- Custody risk is configurable. MPC wallets split private keys across multiple parties so no single server holds a complete key. Passkey wallets bind signing to a device credential. Neither forces seed phrases on end users.
- The platforms below differ most on one axis: who actually controls the key material. That answer determines your regulatory exposure, your recovery story, and your vendor lock-in.
- Privy and Dynamic are the strongest choices for consumer-facing products with non-crypto users. Turnkey is the right call when your engineers want raw API control over signing. Magic is the lowest-friction option for teams that have never touched wallet infrastructure before.
- WaaS is not institutional custody. If you are holding assets on behalf of regulated entities or running a crypto exchange, you need a different conversation entirely.
Wallet-as-a-service platforms give fintech products the ability to create, manage, and sign with digital wallets through an API or SDK, without building key management infrastructure. The leading providers, including Privy, Dynamic, Turnkey, and Magic, offer embedded wallets that authenticate users via email, social login, or passkeys and abstract cryptographic complexity away from the end user. Integration typically takes one to four weeks. Custody models range from fully managed to MPC-based delegated custody, and the right choice depends on your regulatory posture and how much signing control you need to retain.
What Is Wallet-as-a-Service and Why Do Fintech Teams Use It?
A wallet-as-a-service (WaaS) platform is a hosted infrastructure layer that handles private key generation, storage, and transaction signing on behalf of your application. You call the API, a wallet gets created, and your user never sees a seed phrase. The key question is where that private key actually lives and who can reconstruct it.
The traditional alternative is building your own key management system, which means HSMs, key derivation schemes, recovery workflows, and ongoing security audits. That work takes a security-specialized engineering team months, and it never fully goes away. WaaS offloads that burden to vendors whose entire business model depends on not losing keys.
For fintech builders specifically, WaaS supports stablecoin wallets, programmable treasury accounts, loyalty point storage, tokenized asset management, and on-chain payroll, all under a familiar login flow. If you are looking at how the broader fintech infrastructure stack is evolving, the fintech infrastructure stack breakdown on FintechSpecs maps where wallet infrastructure sits relative to payments, banking rails, and identity layers.
What Are the Custody Model Tradeoffs: MPC vs Passkey vs Custodial?
This is the decision that everything else follows from. Get it wrong and you either absorb custody risk you did not intend to carry, or you ship a UX that users abandon at signup.
MPC Wallets
Multi-party computation (MPC) splits the private key into shards distributed across multiple parties, typically the user’s device, your server, and the WaaS provider’s infrastructure. No single shard can sign a transaction alone. This is the dominant model for enterprise-grade embedded wallets because it eliminates the single point of compromise without requiring the user to manage a seed phrase. Turnkey and Privy both offer MPC-backed wallets. The tradeoff is that MPC adds latency to signing operations and the recovery flow requires coordination across shards.
Passkey Wallets
Passkey wallets bind the signing credential to a WebAuthn-compatible device, typically a phone’s Secure Enclave or a hardware key. The private key never leaves the device, which means you cannot lose it server-side, but you also cannot recover it if the user loses their device without a pre-configured backup. Dynamic has leaned into passkey-native wallet creation. For consumer apps targeting mainstream users, passkeys trade some recovery flexibility for a dramatically cleaner onboarding experience.
Custodial Embedded Wallets
Fully custodial wallets store the private key on the provider’s infrastructure. The user experience is the simplest possible, because login is all that is required, but the legal exposure is real. Holding private keys on behalf of users in a financial context can trigger money transmission obligations depending on the asset type and jurisdiction. Magic operates largely in this model for its simpler tiers, which is why it works well for non-financial applications but requires careful legal review before you go live with anything that moves regulated value.
The line between WaaS and institutional custody is worth stating plainly. WaaS is for embedding wallets inside a product. Institutional custody, the kind BitGo and Anchorage Digital operate, is for holding large asset pools on behalf of funds, exchanges, or treasury desks under specific regulatory frameworks. If your use case involves segregated accounts, qualified custodian status, or cold storage for significant AUM, you need a custody provider, not a WaaS SDK. That distinction matters when you are reading this list.
The FintechSpecs WaaS Fit Test: Four Checks Before You Shortlist
Before comparing providers, run these four checks against your product requirements. Teams that work through all four typically cut a list of eight providers down to two or three candidates in under an hour, and avoid the common trap of selecting a vendor based on feature marketing rather than custody architecture fit.
- Who owns the key material? Map each provider’s custody architecture to your legal team’s tolerance for holding user funds. MPC-delegated models distribute liability differently than fully custodial ones. This is not a question to defer to post-launch; the answer affects your state money transmission analysis and your terms of service.
- What does your user’s login already look like? If your users authenticate via email or social, you want a provider whose wallet creation is tied to that same identity so there is no second onboarding step. If your users are developers or crypto-native, raw key export matters more.
- Do you need cross-chain support or EVM-only? Most WaaS providers are EVM-first. Solana, Bitcoin, and Cosmos support varies significantly and is often added later with different stability guarantees. Check whether non-EVM chain support is GA or in beta before you depend on it.
- What is your signing volume, and does the pricing model scale with it? Some providers charge per wallet created, others per transaction signed, others on flat monthly tiers. Model out your expected MAU and transaction frequency before you commit. A provider that looks cheap at 5,000 MAU can become the dominant line item on your infrastructure bill at 200,000 MAU if the pricing tier structure is steep.
The fourth check is where teams most often underestimate real cost. See the hidden costs that compress fintech SaaS margins for a broader look at how per-unit infrastructure pricing compounds at scale in ways the initial pricing page obscures.
8 Best Wallet-as-a-Service Platforms for Fintech Products
| Provider | Custody Model | Best For | Key Differentiator | Chain Coverage | Public Pricing |
|---|---|---|---|---|---|
| Privy | MPC / delegated | Consumer fintech, non-crypto users | Email/social login creates wallet invisibly | EVM, Solana | Free tier available; paid plans by MAU |
| Dynamic | MPC / passkey | Auth-heavy B2B and consumer apps | Auth + wallet in a single SDK | EVM, Solana, Bitcoin | Free tier; growth plans available |
| Turnkey | MPC (TEE-backed) | Developer-first, high-signing volume | Secure enclave architecture, raw API control | EVM, Bitcoin, Solana, Cosmos | Pay-per-use; contact for volume |
| Magic | Delegated custodial / MPC tier | Fastest time-to-wallet, non-crypto apps | Single SDK line creates wallet on email login | EVM, Solana, Flow | Free tier; paid by MAU |
| Circle Programmable Wallets | Developer-controlled / user-controlled | Stablecoin-native fintechs, USDC flows | Native USDC rails, Circle compliance stack | EVM, Solana, Stellar | Pay-per-wallet; contact for enterprise |
| Alchemy Account Kit | Account abstraction (ERC-4337) | Gas abstraction, batch transactions, smart wallets | Gasless UX via paymasters out of the box | EVM only | Free on lower tiers; usage-based above |
| BitGo WaaS | Multi-sig / MPC enterprise | Exchanges, institutional fintech, high AUM | SOC 2, insurance, qualified custodian option | 600+ assets | Enterprise only; contact sales |
| Coinbase WaaS | MPC (user-controlled) | Consumer crypto wallets backed by brand trust | Coinbase brand recognition, broad chain support | EVM, Solana, Bitcoin, and more | Contact for pricing |
Privy
Privy is the strongest default choice for consumer fintech products targeting users who have no interest in crypto. When a user signs up with their email address, Privy creates an embedded wallet in the background, and the user never knows it exists unless you surface it. The SDK handles social login, SMS, and email flows, and ties the wallet to that identity automatically.
The MPC architecture means Privy holds one key shard, the user’s device holds another, and reconstruction requires both parties. That architecture keeps Privy from being a single point of failure and keeps you from needing to hold key material yourself. Privy also supports server-side wallets, which is useful for building treasury or escrow flows that operate without a user session. For product teams building stablecoin-native features on top of traditional fintech, Privy is consistently the first SDK teams prototype with.
Dynamic
Dynamic made a deliberate product decision to bundle authentication and wallet creation into a single SDK rather than treating them as separate concerns. For B2B products where the user already has an identity with your platform, that matters. You do not add a second onboarding step; the wallet is provisioned as part of your existing login flow.
Dynamic’s passkey support is deeper than most competitors. A user can sign transactions with Face ID or a hardware key without ever seeing a confirmation dialog that references blockchain. For enterprise fintech teams that need role-based wallet access or multi-user approval flows, Dynamic’s organization-level wallet controls are worth looking at. Chain coverage includes EVM, Solana, and Bitcoin, which makes it one of the broader options at this price point.
Turnkey
Turnkey is built for engineering teams that want control. Its architecture uses trusted execution environments (TEEs), hardware-isolated compute where private key operations happen inside a secure enclave that Turnkey’s own employees cannot access. Every signing policy is defined in code, and the audit trail is cryptographically verifiable.
This level of infrastructure control comes with a steeper integration curve. Turnkey does not hand you a pre-built UI. You get an API, a policy engine, and a key management layer, and you build the product on top. For teams building high-frequency signing operations, automated treasury management, or products where the signing policy itself is a business differentiator, Turnkey’s raw model is the right call. It supports EVM, Bitcoin, Solana, and Cosmos, which is broader than most at this tier.
Magic
Magic is the fastest path from zero to a working wallet flow. The integration is genuinely one SDK call, the wallet is provisioned on email authentication, and the user experience requires no crypto knowledge whatsoever. For teams that need to ship a proof of concept or an MVP with wallet functionality in under a week, nothing in this list matches Magic’s time-to-working-demo.
The tradeoff is custody architecture. Magic’s standard tier is delegated custodial, meaning Magic holds the keys. Their newer MPC tier addresses this, but the MPC offering is newer and the documentation reflects that. Teams building regulated financial products should run the custody question past legal before committing. For non-financial applications, gaming, loyalty programs, digital collectibles, Magic’s custodial model is acceptable and the developer experience is excellent.
Circle Programmable Wallets
If your product is denominated in USDC or EURC and you are building on Circle’s payment rails anyway, Circle Programmable Wallets is the natural choice. The wallets are native to Circle’s infrastructure, which means moving USDC from a user’s embedded wallet to a Circle-powered payment flow is a single API call rather than a cross-provider integration.
Circle offers two models: developer-controlled wallets, where your server holds signing authority, and user-controlled wallets, where the user’s device holds the key. That distinction matters for compliance. Developer-controlled wallets can look like money transmission if the assets have financial value. Circle’s compliance documentation is more detailed than most WaaS providers on this point, which is useful if you are navigating fintech product and compliance readiness reviews with your legal team.
Alchemy Account Kit
Account abstraction is the concept that changes what a wallet can do beyond holding assets. With ERC-4337, a wallet becomes a smart contract account that can batch transactions, sponsor gas fees for users, set spending limits, and require multi-sig approval, all without the user paying gas or understanding what gas is. Alchemy’s Account Kit is the most mature developer toolkit for building on this standard.
The limitation is chain coverage. Account abstraction via ERC-4337 is EVM-specific. If you need Bitcoin or Solana support, Account Kit is not your answer. But for EVM-native products where the UX goal is zero friction, gasless transactions, and programmable spending rules, Account Kit is the most sophisticated option on this list. It is also the most opinionated; you are building on Alchemy’s infrastructure, and migration later requires work.
BitGo WaaS
BitGo is where this list crosses the line toward institutional use cases. Its WaaS offering supports over 600 digital assets, carries SOC 2 Type II certification, offers crime insurance, and can operate as a qualified custodian depending on structure. For a fintech handling significant asset volume, an exchange, a tokenized securities platform, or an institutional treasury product, that compliance infrastructure justifies the enterprise pricing and sales-led onboarding process.
BitGo is not the right choice for a seed-stage fintech adding a wallet feature to a consumer app. The integration timeline, pricing, and compliance overhead are calibrated for a different buyer. But if you are building something where the words “qualified custodian” appear in your term sheet or partnership agreements, BitGo belongs on your shortlist.
Coinbase WaaS
Coinbase WaaS offers MPC-based user-controlled wallets with the brand recognition that reduces user trust friction in consumer-facing crypto products. For a fintech app where users will see the Coinbase name in your documentation or help center, that familiarity has real conversion value. The platform covers a broad range of chains and benefits from Coinbase’s regulatory relationships and compliance track record.
The weakness is the developer experience relative to Privy or Turnkey. Coinbase’s developer tools have historically prioritized their own product suite. The WaaS offering is capable, but teams that have worked with Privy’s documentation report a smoother integration path. Coinbase WaaS makes more sense when brand trust is a material product consideration than when raw developer experience is the deciding factor.
How Do Embedded Wallet APIs Handle User Onboarding for Non-Crypto Users?
The pattern that most WaaS providers converge on is called progressive disclosure: the wallet exists from account creation, but its existence is hidden until the user has a reason to care about it. A user signs up with Google OAuth, your app calls the WaaS SDK, a wallet address is provisioned in the background, and nothing in your UI says “wallet” or “blockchain.”
When a user later receives a stablecoin reward, or needs to transfer value, you surface the relevant action in your own product language. “Send $20 to a friend” rather than “initiate an on-chain transfer.” The wallet infrastructure is invisible. This is exactly the pattern that resolves the seed phrase problem: there is no seed phrase in the user flow because the key material is managed by the MPC architecture, not by the user.
Recovery is the edge case that still requires thought. If a user loses their device in a passkey-native wallet setup, recovery depends on whatever backup mechanism your provider supports. Privy uses a hardware-backed encrypted backup. Dynamic supports social recovery. Magic has an account recovery flow tied to email. None of these match the simplicity of a password reset, which is why user onboarding design for wallet-powered fintech products deserves its own review. The reasons fintech users drop off during onboarding are well-documented, and recovery edge cases are a real source of abandonment if not handled carefully.
What Does Wallet-as-a-Service Actually Cost?
Pricing across WaaS providers is less transparent than it should be. Most publish a free tier with wallet creation limits, then move to custom pricing above a threshold. Here is what is publicly visible as of each provider’s current pricing pages.
Privy, Dynamic, and Magic all offer free tiers suitable for development and early-stage products. Privy and Dynamic both scale pricing with monthly active users once you pass the free tier threshold. Turnkey charges on a pay-per-use model based on signing operations and API calls, which scales favorably at high volume but is harder to predict at early stage. Circle Programmable Wallets charges per wallet created, with enterprise contracts for production scale. Alchemy Account Kit is free at lower tier usage, with costs tied to bundler and paymaster operations above free limits. BitGo and Coinbase WaaS are both enterprise-only; pricing requires a sales conversation.
The cost that does not appear on any pricing page is the engineering time to wire wallet events into your existing product, handle failure states, build admin tooling, and write the compliance documentation your legal team will ask for. A concrete example of how this plays out: a Series A consumer fintech team that chose Privy for a stablecoin yield feature reported spending three weeks on production integration after a two-day proof of concept, with roughly half that time going to compliance logging, webhook failure handling, and internal admin dashboards, none of which appear in Privy’s SDK documentation. Budget two to four weeks of engineering time for a production-grade integration regardless of which provider you choose. That timeline holds for teams with existing React or React Native codebases using any of the top four providers on this list.
This pattern is broader than WaaS. The hidden costs that compress fintech SaaS margins often show up in exactly this kind of infrastructure layer, where per-transaction or per-wallet fees compound at scale in ways the initial pricing page does not make obvious.
MPC vs Passkey vs Account Abstraction: Which Architecture Fits Your Product?
Consider a Series A consumer fintech with 50,000 registered users adding stablecoin yield to their savings product. Users are non-crypto, mobile-first, and authenticate via Google OAuth today. They have never seen a seed phrase. The product team needs automated yield allocation to run server-side, without requiring user action, and the company’s counsel has flagged that holding full custody of user funds would trigger money transmission licensing in multiple states.
In this scenario, MPC via Privy or Dynamic is the correct architecture. The users cannot manage keys, the product requires server-side wallet operations for automated yield allocation, and the company cannot carry full custody liability. MPC delegated custody keeps the user’s key shard on their device, the platform shard on the company’s server, and a recovery shard at the WaaS provider. No single party can move funds unilaterally. The compliance team gets a defensible answer to the custody question, and the product team gets an onboarding flow that looks identical to any other mobile savings app.
If that same company was building a developer wallet for API users who are technical, passkeys plus account abstraction via Account Kit becomes more interesting. Technical users can handle WebAuthn prompts. Gasless transactions and batch signing reduce UX friction for programmatic workflows. Passkey authentication is phishing-resistant in a way that email magic links are not.
For the institutional fintech managing treasury operations across multiple blockchains with six-figure transaction values, BitGo’s multi-sig and MPC enterprise architecture is the only option on this list that carries the insurance and compliance posture that institutional counterparties will accept.
How Does Wallet-as-a-Service Differ from Institutional Custody?
WaaS is product infrastructure. It creates wallets for end users inside your application. Institutional custody is a regulated service where assets are held on behalf of a third party under specific legal obligations, often including a qualified custodian designation, segregated account structures, and regulatory reporting requirements.
A fintech building a consumer savings app with stablecoin features needs WaaS. A tokenized fund platform holding $100M in on-chain securities on behalf of institutional investors needs qualified custody, likely from BitGo Trust, Anchorage Digital, or Copper, not a WaaS SDK. The overlap is that some WaaS providers, BitGo being the clearest example, can operate in both modes depending on contract structure. But defaulting to WaaS thinking when you actually need institutional custody is a compliance mistake that surfaces late and costs a great deal to unwind.
If you are unsure which side of that line your product sits on, the answer usually lives in whether your users are the beneficial owners of the assets in your wallets. If yes, and those assets have regulated financial value, that is a custody question for legal counsel before it is a WaaS vendor question.
Frequently Asked Questions
What is wallet-as-a-service in fintech?
Wallet-as-a-service is a hosted API or SDK layer that lets fintech products create and manage digital wallets without building key management infrastructure internally. Providers like Privy, Dynamic, Turnkey, and Magic handle private key generation, storage, and transaction signing. The end user logs in with email or a passkey and never interacts with cryptographic material directly. Wallet creation is typically triggered by the developer’s API call during user registration.
What is the difference between MPC wallets and custodial embedded wallets?
In an MPC wallet, the private key is never assembled in one place. It is split into shards distributed across the user’s device, the developer’s server, and the WaaS provider’s infrastructure. Signing requires coordination across those shards. In a fully custodial wallet, the WaaS provider holds the complete private key on behalf of the user. MPC distributes custody risk; custodial models concentrate it. For regulated financial applications, MPC is the safer default from a compliance standpoint.
Can non-crypto users use embedded wallets without knowing it?
Yes. This is the core value proposition of modern WaaS platforms. A user creates an account with their email address, and the SDK provisions a wallet in the background. The user sees no seed phrase, no wallet address, and no blockchain terminology unless the developer chooses to surface those elements. Privy and Magic are the clearest examples of this invisible-wallet pattern in production. The wallet address only becomes visible if the user or the application explicitly needs it.
How long does a WaaS integration actually take?
For a React or React Native application using Privy, Dynamic, or Magic, a working proof of concept typically takes one to three days. A production-grade integration that handles error states, admin visibility, and compliance logging takes two to four weeks. Turnkey integrations run longer because the product ships a raw API rather than a UI component library. BitGo and Coinbase WaaS, being enterprise-only, involve a sales process that adds timeline before the integration even starts.
What is account abstraction and when does it matter for a fintech wallet?
Account abstraction (specifically ERC-4337) converts a wallet from a simple key-value pair into a programmable smart contract account. This makes gasless transactions possible, where your app pays network fees on the user’s behalf, and also supports batch transactions, programmable spending limits, and multi-sig approval flows. It matters for fintech products where paying gas fees would confuse or alienate users, or where programmable spending rules are a product feature. Alchemy Account Kit is the most mature SDK for building on this standard, though it is EVM-only.
Is wallet-as-a-service subject to money transmission laws?
It depends on the asset type, custody model, and jurisdiction. Fully custodial wallets that hold assets with financial value can trigger money transmission obligations at the state level and potentially FinCEN registration at the federal level. MPC models where the user controls a key shard may be treated differently, but there is no universal safe harbor. Any fintech deploying WaaS for financial value transfer should conduct a regulatory analysis before launch. The compliance mistakes that end fintech startups frequently involve exactly this kind of regulatory assumption made without legal review.
Which wallet-as-a-service provider is best for a consumer app with non-crypto users?
Privy is the strongest default for consumer-facing fintech products targeting mainstream users. Its email and social login flows create embedded wallets without exposing any cryptographic concepts to the user. The MPC architecture avoids full custody liability on the developer’s part. Dynamic is the second choice, particularly for products that need a more sophisticated authentication layer or passkey-native flows. Magic is the fastest to integrate but carries more custody risk in its standard tier.
How do I evaluate whether my product needs WaaS or a full custody solution?
If your product creates wallets for individual end users as a product feature, WaaS is the correct layer. If your product holds pooled assets on behalf of third parties, requires qualified custodian designation, needs segregated account structures, or manages significant AUM for institutional counterparties, you need an institutional custody provider like BitGo Trust or Anchorage Digital. A useful shortcut: if your term sheet, investor diligence, or potential partner agreements use the words “qualified custodian,” you are not shopping for WaaS. The best fintech APIs for SaaS breakdown on FintechSpecs covers where wallet infrastructure fits relative to other API categories.
How to Pick the Right WaaS Provider Without Wasting a Sprint
The most common mistake teams make is benchmarking WaaS providers on feature lists instead of on custody architecture fit. Two providers can both offer “MPC wallets” and have meaningfully different answers to the question of who holds which shard, under what conditions recovery works, and what happens if the provider goes offline. Read the architecture documentation before the sales deck.
For teams that have never shipped wallet infrastructure, starting with Privy or Magic for a sandbox build is the right call regardless of where you ultimately land. Both have free tiers, both have React and React Native SDKs, and both get you to a working wallet flow fast enough to have a meaningful internal conversation about what you actually need. The critical mistakes when choosing fintech infrastructure almost always involve committing to a vendor before building anything, which is a particularly expensive error in the WaaS category because key material becomes a migration headache later.
The two-week integration timeline is real, but it assumes you have answered the custody question, cleared the regulatory question with legal, and decided on your chain requirements before the first line of code. Teams that skip those conversations ship faster and then rebuild slower. Get the architecture decision right in week one, and the integration itself is exactly as fast as the vendors claim.
