uxMode: 'redirect' plan requirement + wallet service 1003 during connectTo() causing Safari popup blocking?

Embedded Wallets (Web3Auth)
1

Hi,

We recently upgraded from Web3Auth v9 to v10 (@web3auth/modal ^10.15.0) and have two related questions we can’t find definitive answers to in the docs.

Setup

  • SDK: @web3auth/modal v10.15.0
  • Auth method: email_passwordless via connectTo(WALLET_CONNECTORS.AUTH, { authConnection: ‘email_passwordless’ })
  • Network: Sapphire Mainnet
  • Plan: Base
  • Framework: Next.js 14 (Pages Router)

Question 1 — Which plan is required for uxMode: ‘redirect’?

We’re trying to fix a Safari popup blocking issue. Safari blocks the Web3Auth popup because connectTo() is called after an async operation, losing the
user gesture context. The natural fix is uxMode: ‘redirect’.

However, when we set uxMode: ‘redirect’ on the Base plan, we get:
code: 1003 — “wallet service not available on base plan”

We’ve also seen a community post where someone on the Growth plan received the same error:
▎ “The current subscription plan is growth and requesting features (wallet service) are not available on growth plan.”

This suggests redirect mode might require the Scale plan ($399/month), not just Growth ($69/month). Could you confirm:

  • Which plan is the minimum to use uxMode: ‘redirect’?
  • Is it tied to “Wallet Services” (the product feature on the pricing page), or is it a separate internal feature flag?

Question 2 — Does the wallet service 1003 error fire during connectTo() (not just init())?

We can see the 1003 wallet service error in our network tab on every login attempt, even on the Base plan without uxMode: ‘redirect’ set. Login works fine
on Chrome and Firefox, but fails on Safari.

We understand the error fires during init() at page load. But we suspect it may also fire inside connectTo() — and if Web3Auth internally retries or
recovers from the 1003 asynchronously before opening window.open(), that async gap would cause Safari to block the popup.

Could you confirm:

  • Does the wallet service 1003 error also occur inside connectTo()?
  • If yes, does this async recovery inside connectTo() affect the user gesture context for Safari popup opening?
  • Is there any config option to disable wallet service initialization entirely on Base plan, to avoid this internal async gap?

Why this matters

If the 1003 inside connectTo() is causing Safari to block the popup, the fix isn’t just restructuring our code — it requires either a plan upgrade or a
way to opt out of wallet service checks. Knowing which plan actually fixes uxMode: ‘redirect’ will help us decide whether the plan cost is justified or
whether there’s a code-level workaround.

Thanks in advance.

1 Like
2

Thanks — this is clear and helpful. Quick answers based on the docs and internal guidance plus a recommended workaround.

SDK: @web3auth/modal v10.15.0 (Web, Next.js) — noted.

  1. uxMode: ‘redirect’ and plan
  • uxMode:‘redirect’ depends on Web3Auth “Wallet Services” which is a Scale-tier feature. Base and Growth do not enable Wallet Services, so you’ll see code 1003 on those plans.
  • If you need an explicit billing/contract exception confirmed, I’ll flag this to the team to verify account-level feature flags.
  1. wallet service 1003 during connectTo() and Safari popup blocking
  • 1003 can surface not only at init() but also when wallet-related calls trigger wallet-service initialization (e.g., inside connectTo()).
  • If the SDK does async recovery/initialization before it opens the auth popup, that async gap can break Safari’s user-gesture requirement and cause the popup to be blocked.
  • There’s no public config to fully disable wallet-service checks on Base/Growth — this is a plan-limited capability.

Workarounds / next steps

  • Best: upgrade to Scale so you can use uxMode:‘redirect’ natively.
  • Code workaround (no plan change): make connectTo() run synchronously within the user gesture, or open a user-initiated window immediately and navigate it later (pattern: const win = window.open(‘about:blank’); await connectTo(…); win.location.href = redirectUrl). This preserves the user gesture for Safari.
  • Test in Safari with a click handler that calls connectTo directly; capture console + network traces if you want me to review.

If you want, I’ll escalate to the billing/engineering contact to confirm plan-flag behavior for your dashboard project and check whether any account-level opt-outs exist.

Note: This response was generated by an AI bot and may require further verification. The MetaMask Community Team has tracked this issue and will be responding as soon as possible.

Additionally, we would recommend you to join our monthly Office Hours to discuss this with our engineering team. MetaMask Developer Office Hours

3

Hi @Anas_Shaikh, feel free to let us know if you need further help on this.