Embedded wallets vs. standalone wallets: which fits your product?
Same underlying technology, two completely different user experiences. The choice isn't about which wallet is "better" — it's about where the wallet should live relative to everything else your user is doing.
What each one actually is
An embedded wallet lives inside your product. The user never sees a separate app, never installs an extension, never leaves your UI — their balance, their transactions, their signing flow are all just another screen in the product they're already using.
A standalone wallet is its own application. It has its own login, its own interface, its own identity — and your product connects to it, rather than containing it. The user installs it once and can use the same wallet across many different apps.
Neither is more "real" than the other. Both can be fully non-custodial — that's a separate axis entirely, decided by who holds the keys, not by where the interface lives. The question this article is actually about is narrower: given your product, which of these two shapes should the wallet take?
The fork: four questions that actually decide it
Is crypto the point of your product, or a feature inside it?
If your product's entire reason for existing is crypto — an exchange, a trading platform, a dedicated wallet app — standalone makes sense. Users expect a dedicated, full-featured interface, and building that expectation into a bigger, unrelated product usually undersells it.
If crypto is a capability your product offers — a marketplace that happens to settle in stablecoins, a game with in-app rewards, a platform where payments are one feature among many — embedded is almost always the right call. The wallet should feel like it belongs to the product, because for your users, it does.
Do you need conversion, or do you need portability?
Embedded wallets remove friction at the exact moment it costs you the most: onboarding. No extension to install, no separate account to create, no context switch — just a user completing an action inside the app they already opened. That difference shows up directly in signup and transaction completion rates.
Standalone wallets trade that friction for something embedded can't offer: portability. A user's standalone wallet works across every app that supports it — one identity, one balance, carried everywhere. If your users are already crypto-native and expect to bring their own wallet, forcing an embedded-only flow can feel like a step backward, not an improvement.
Who are you actually building for?
A crypto-native audience already has a wallet, already understands seed phrases and connections, and often prefers to use their own tools. Fighting that expectation with a forced embedded flow adds friction where none needs to exist.
A mainstream audience — most consumer, gaming, and marketplace users — has none of that context, and every extra step between "I want to do this" and "I did it" is a drop-off point. For that audience, an embedded wallet isn't a limitation. It's the thing that makes crypto usable at all.
How much control do you actually want over the experience?
An embedded wallet is yours to design end to end — the balance display, the confirmation flow, the error states, all inside your own product, on your own brand. A standalone wallet hands that experience to whoever built the wallet app your user connects: their UI, their update schedule, their design decisions, sitting on top of your product whether you like the look of it or not.
The trade-off nobody puts on the slide
Embedded wallets win on conversion and control, but they cost the user something real: portability. A balance embedded in your product doesn't travel with the user to the next app they open. If your users genuinely operate across many crypto products — moving assets between platforms, expecting a single identity everywhere — an embedded-only wallet can start to feel like a walled garden, however good the onboarding was on day one.
That's not an argument against embedded. It's a reason many products end up supporting both: an embedded wallet for the fast, native path most users take, with the option to connect an external standalone wallet for the users who already have one and want to keep using it.
"The wallet doesn't have to pick a side. Your product does — and it should pick based on what your users are actually trying to do, not on which model looks more sophisticated on a roadmap."
Where CPAY fits
CPAY's Wallet-as-a-Service is built for the embedded path — a non-custodial wallet your users never have to leave your product to use, provisioned and controlled through a single API. The keys stay non-custodial regardless of which shape the wallet takes; what changes is only where the interface lives, and that's the decision this article was actually about.
Most consumer products don't need their users to think about wallets at all. The ones that do — exchanges, dedicated crypto platforms, power-user tools — are usually the exception, not the rule. Start from what your users are trying to accomplish, and the fork mostly resolves itself.
