Privy Embedded Wallet Auth Quickstart
Privy is a strong choice for teams that want wallet-backed product flows without making every new user start with a browser extension or a fully crypto-native login. Instead of forcing wallet setup on the first screen, teams can let users enter with familiar auth methods such as email, social login, SMS, or passkeys, then create embedded wallets when the app actually needs them.
This quickstart is for builders evaluating how Privy fits into onboarding, wallet creation, and trusted backend verification. It focuses on the decisions that matter early: how users sign in, when wallets get created, how client state should be gated, and where server-side verification belongs.
Why teams choose Privy for embedded wallet auth
Embedded wallet auth is usually not a wallet decision alone. It is an onboarding decision.
Most teams evaluating Privy are trying to reduce first-session friction without giving up the wallet-backed actions their products still need later in the journey.
- the product needs wallet-backed actions, but the first-run flow cannot assume a crypto-native user
- signup friction is hurting activation before the user understands the product
- wallet creation should happen progressively instead of on the first screen
- the app needs trusted server-side verification instead of relying only on browser-visible wallet state
- the team wants one auth and wallet system that can support both EVM and, where needed, Solana-oriented flows
That combination is what makes Privy different from a pure wallet-connect path. It lets a product team separate identity entry from wallet complexity.
What a practical Privy onboarding flow looks like
Let the user enter through a familiar auth method
Start with the sign-in methods that best match the audience, such as email, Google, SMS, passkeys, or an existing wallet.
Create an embedded wallet progressively
If the app needs a wallet later, create one for users who do not already have one instead of forcing immediate setup.
Gate the UI on readiness, not assumptions
Auth state and wallet state are separate. Do not render wallet-dependent flows until both are ready.
Show a clear first wallet-backed action
Signing in should lead directly into something useful, such as account setup, a gated feature, a message-signing step, or the first onchain action.
Verify identity on the server before trusted actions
Client hooks are useful for interface state, but backend trust should come from token verification, not from whatever address the browser appears to show.
That flow matters because it reduces first-session friction without removing wallet-backed capability from the product.
The setup values that matter first
A typical Privy setup starts with two environment variables:
- NEXT_PUBLIC_PRIVY_APP_ID for the client
- PRIVY_APP_SECRET for the server
The current repo integration pattern points to these packages:
pnpm add @privy-io/react-auth
pnpm add @privy-io/server-authThe client app is then wrapped in PrivyProvider with an explicit configuration for login methods and embedded wallet behavior.
<PrivyProvider
appId={process.env.NEXT_PUBLIC_PRIVY_APP_ID!}
config={{
loginMethods: ["email", "google", "wallet"],
embeddedWallets: { createOnLogin: "users-without-wallets" },
}}
>This is the point where the product team decides what sign-in means in practice. A consumer product may lead with email or Google. A more crypto-native flow may still keep wallet login visible. The important part is that the login configuration matches the audience and the downstream wallet journey.
A Privy embedded wallet auth quickstart
1. Pick the right login methods for the product
Privy can support multiple entry points, but the best configuration depends on how users arrive and what you want them to do next.
- email for simple, familiar onboarding
- Google or other social login for consumer-friendly account creation
- SMS for mobile-forward experiences
- passkeys for teams prioritizing modern authentication UX
- wallet login for users who already expect a crypto-native flow
If the audience is mixed, the best path is often not to choose one method exclusively. It is to prioritize the least confusing default while still leaving a wallet path available for experienced users.
2. Decide when embedded wallets should be created
One of Privy’s most useful patterns is progressive wallet creation.
embeddedWallets: { createOnLogin: "users-without-wallets" }That tells the app to create embedded wallets for users who need them instead of making wallet setup the first requirement. For many onboarding flows, this is the difference between an app that feels consumer-ready and one that assumes prior wallet literacy.
- the user does not need to understand wallets before they see product value
- the first onchain action happens later in the journey
- the team wants smoother recovery and account continuity options
- signup conversion matters as much as downstream wallet functionality
3. Read auth state and wallet state separately
A common integration mistake is treating auth readiness and wallet readiness as the same thing. The client state is easier to reason about when those signals stay separate.
const { ready: authReady, authenticated, user } = usePrivy();
const { ready: walletsReady, wallets } = useWallets();That distinction matters because the app can appear signed in before wallet state is fully ready. If you render wallet actions too early, the first-run experience can feel broken even when the setup is otherwise correct.
- wait for auth readiness before treating the user as signed in
- wait for wallet readiness before exposing signing or wallet-dependent UI
- avoid chaining sensitive actions off a partially initialized client state
4. Make the first wallet-backed action obvious
Signing in is not the goal. Progress is. Once the user is authenticated and the wallet state is ready, the app should move them into the first meaningful action right away.
- unlock a gated feature
- create a wallet-backed account
- sign a message to continue
- fund or connect the next step of an onboarding flow
- start an EVM or Solana-specific action path
This is where embedded wallet auth either feels smooth or underwhelming. If the user reaches a connected state and then sees nothing useful to do, the onboarding flow loses momentum.
5. Verify tokens on the server before trusted operations
Privy’s client hooks are for UI state. Trusted backend actions should verify identity on the server.
const client = new PrivyClient(appId, appSecret);
await client.verifyAuthToken(token);This is the trust boundary that matters most. A visible client wallet address can inform the interface. It should not be treated as the final source of truth on its own.
- attach wallet-backed permissions to an account
- grant access to protected resources
- process sensitive account updates
- trust a wallet address for backend business logic
- perform privileged actions tied to the authenticated user
Where Privy fits best
Privy is usually strongest when the product needs wallet capability but cannot afford to make wallet complexity the first user experience.
- consumer crypto apps serving mixed Web2 and Web3 audiences
- products that want users inside the app before the first onchain action
- onboarding flows that benefit from progressive wallet creation
- teams that need one system for auth and embedded wallets
- builders who want explicit server-side verification in the trust model
A wallet-first flow can still be the right choice for strongly crypto-native users. But many apps do better when wallet creation is delayed until it has context and purpose.
Architecture choices that shape the experience
Embedded wallet first vs external wallet first
If the audience includes newcomers, embedded wallets usually create a cleaner default. If the product is aimed at existing wallet-native users, an external wallet option may still need to stay prominent.
The real decision is not whether one mode exists. It is which mode is the default and when the alternative appears.
EVM only vs EVM plus Solana
The current integration data describes Privy as supporting both EVM and Solana-oriented journeys. That can be useful for broader product strategies, but it should not be treated as a reason to skip chain-specific testing.
Client-visible identity vs verified identity
This tradeoff should stay clear in the architecture: client hooks drive responsive interface state, server verification establishes trusted backend identity, and browser-visible wallet information should not be treated as a security boundary.
Common Privy implementation pitfalls
Showing wallet actions before readiness is complete
Auth and wallet state can initialize at different times. If signing buttons or wallet-dependent screens render too early, the product can look inconsistent on first load.
Trusting the browser wallet address by itself
A visible address is useful for UI. It is not enough for backend trust. Sensitive actions should verify the auth token on the server and derive trusted identity from verified claims.
Treating MFA as a separate concern from signing UX
If MFA is enabled in your Privy configuration, test signing and recovery flows together. Security settings that look fine in isolation can add friction to embedded-wallet actions if they are not validated in the real user journey.
Assuming Solana behavior is automatic
If the product includes Solana-specific flows, enable and test them deliberately. Multi-chain support should be proven in the real onboarding path, not inferred from a successful EVM setup.
Copying the web setup into mobile without checking package differences
The integration notes point out that React Native and Expo use a separate package path. Teams building beyond the web should treat mobile setup as its own implementation track.
A builder checklist for launching faster
Product and onboarding
- 01choose the login methods that match the real audience
- 02define when wallets should be created
- 03decide what the first wallet-backed action is
- 04make the post-login path obvious instead of leaving the user in a neutral connected state
Frontend implementation
- 01wrap the app in PrivyProvider
- 02configure NEXT_PUBLIC_PRIVY_APP_ID
- 03set loginMethods intentionally instead of accepting a generic default
- 04gate wallet-dependent UI on both auth readiness and wallet readiness
Backend trust model
- 01keep PRIVY_APP_SECRET server-side only
- 02verify auth tokens on the server before trusted actions
- 03avoid relying on browser-visible wallet state as final authority
- 04log and handle verification failures explicitly
Chain and environment testing
- 01test the actual first-run onboarding flow, not just isolated components
- 02validate wallet creation behavior for users without wallets
- 03confirm chain-specific behavior for any EVM or Solana path you plan to ship
- 04treat web and mobile builds as separate implementation surfaces when both matter
How Privy compares with a wallet-first connection flow
A standard wallet-first flow often asks the user to connect an external wallet before the product has shown much value. That can be fine when the audience is deeply crypto-native, but it creates avoidable friction for broader consumer use cases.
Privy changes the sequence: identity can start with familiar auth methods, embedded wallets can be created progressively, wallet-backed features can appear only when needed, and the app can still preserve trusted backend verification for sensitive actions.
FAQ
What is Privy used for in embedded wallet auth?
Privy helps teams combine familiar authentication methods with progressive embedded wallet creation so users can start with email, social login, SMS, passkeys, or wallet login before the product requires deeper wallet-backed actions.
When should a team choose Privy over a wallet-first onboarding flow?
Privy is often the better choice when the product serves mixed Web2 and Web3 audiences, needs a lower-friction first-run experience, or wants wallet functionality to appear later in the journey instead of immediately on the first screen.
What setup values matter first in a Privy quickstart?
A typical starting point is NEXT_PUBLIC_PRIVY_APP_ID on the client and PRIVY_APP_SECRET on the server, plus an explicit loginMethods configuration and an embedded wallet creation rule that matches the onboarding strategy.
Why is server-side token verification important?
Client hooks help drive interface state, but sensitive backend actions should verify the auth token on the server so trusted identity does not depend only on what the browser appears to show.
Can Privy support both EVM and Solana wallet flows?
The current web3.new integration notes describe Privy as supporting both EVM and Solana-oriented journeys. Teams should still enable and test chain-specific behavior explicitly before treating a multi-chain experience as production ready.
What is the most common implementation mistake?
One common mistake is rendering wallet-dependent UI before both auth readiness and wallet readiness are complete. That can make the onboarding flow feel unreliable even when the underlying setup is mostly correct.
Start with the protocol reference, then shape the onboarding flow
A strong Privy integration usually comes down to a handful of decisions made early: how users enter, when wallets are created, how readiness is handled, and where trusted backend verification begins.