<h1>Prerequisites</h1>Before you decide on a sign-in method, make sure you have:Transactional email setup (for email OTP):<ul class="accent-bullets"><li>Verified sender domain.</li><li>Deliverability and spam settings checked.</li></ul>SMS provider setup (for phone login / SMS OTP), e.g. Twilio:<ul class="accent-bullets"><li>API keys configured.</li><li>Country coverage and cost per SMS known.</li></ul>Basic BI / analytics access to:<ul class="accent-bullets"><li>Historical signups per day.</li><li>Active user counts.</li><li>Average trips per user.</li><li>Internal clarity on your main objective:<ul class="accent-bullets"><li>Maximize conversion &amp; UX, or</li><li>Minimize per-user variable cost, or</li><li>Balance both.</li></ul></li></ul><hr><h1>How It Works</h1><h2>Core Concepts</h2>All sign-in methods in Wunder Mobility lead to the same outcome:<ol class="steps-list"><li>The user proves they control an identifier (phone or email).</li><li>Wunder Mobility issues a short-lived access token and a longer-lived refresh token.</li><li>As long as tokens are valid, the user stays logged in without new OTPs or passwords.</li><li>When tokens expire (or are revoked), the user must sign in again.</li></ol>Important: How aggressive your token expiry is determines how often users must log in again.<ul class="accent-bullets"><li>Tighter expiry → more OTP events (and SMS cost).</li><li>Looser expiry → fewer OTP events but slightly higher risk if a device is lost.</li></ul>To adapt the configuration of expiry times, please open a support ticket.<hr><h3>Sign-In Options</h3><h4>A. Phone Login (SMS OTP)</h4><ul class="accent-bullets"><li>User enters their mobile phone number.</li><li>Receives a short code via SMS.</li><li>Enters the code and gets logged in.</li></ul>Pros<ul class="accent-bullets"><li>Very familiar flow for users; almost all large consumer apps support phone login.</li><li>Phone number is a strong real-world identifier (useful for customer support and fraud detection).</li><li>One-tap verification on many modern devices via SMS auto-fill.</li></ul>Cons<ul class="accent-bullets"><li>Every OTP SMS is a direct variable cost to you (Twilio or other provider).</li><li>Sensitive to network coverage and roaming issues.</li><li>Temporary spike at launch / migration: existing users must log in at least once with SMS.</li></ul><hr><h4>B. Email OTP (Passwordless Email Login)</h4><ul class="accent-bullets"><li>User enters their email address.</li><li>Receives a one-time code (or magic link) by email.</li><li>Enters the code (or taps the link) to log in.</li></ul>Why email OTP instead of email + password?<ul class="accent-bullets"><li>No password to remember → fewer failed logins and password reset flows.</li><li>Much lower attack surface:<ul class="accent-bullets"><li>No weak passwords.</li><li>No password reuse across services.</li><li>No need to store password hashes.</li></ul></li><li>Cleaner UX: single step, similar to many modern SaaS and consumer apps that moved to passwordless email.</li><li>Support cost reduction: fewer “I forgot my password” tickets.</li><li>Comparable or better security when users’ email accounts are already secured with 2FA.</li></ul>Compared to SMS, email OTP typically has:<ul class="accent-bullets"><li>Near-zero marginal cost per email (vs. paid SMS).</li><li>Slightly more friction on mobile if auto-fill is weaker than SMS, but often acceptable.</li></ul><hr><h4>C. Email + Password (Legacy)</h4><ul class="accent-bullets"><li>User creates a password during signup.</li><li>Logs in later with email + password.</li><li>Uses a password reset flow if they forget it.</li></ul>Pros<ul class="accent-bullets"><li>No per-login SMS cost.</li></ul>Cons<ul class="accent-bullets"><li>Higher friction at signup (creating and confirming a password).</li><li>Ongoing password reset overhead and support tickets.</li><li>Users often choose weak or reused passwords, which worsens security and compliance posture.</li><li>The market is clearly moving away from passwords toward passwordless OTP and device-bound credentials (e.g., passkeys).</li></ul><hr><h3>Cost and Cohort Logic (How to Think About SMS Cost)</h3>For any OTP-based login, think in two cost buckets:<ol class="steps-list"><li>Customer acquisition cost (CAC)<ol class="steps-list"><li>OTPs for new users signing up.</li><li>Usually worth it: better signup conversion leads to more users and more trips.</li></ol></li><li>Operating cost for existing users<ol class="steps-list"><li>OTPs for returning users logging in again (after token expiry or app reinstall).</li><li>These hit your margin per active user and per trip.</li></ol></li></ol>To understand SMS impact:<ul class="accent-bullets"><li>Split your user base into new vs existing cohorts.</li><li>Estimate:<ul class="accent-bullets"><li>SMS per new user during signup and first sessions.</li><li>SMS per existing user per month (driven by token lifetime and user behavior).</li><li>Multiply by SMS price per message to get monthly cost.</li><li>Compare the expected revenue uplift from better conversion vs. extra SMS cost.</li></ul></li></ul><hr><h1>Step-by-Step Guide: Choosing Your Sign-In Method</h1>Use this simple decision workflow when configuring your project.<h3>Step 1 – Define Your Primary Objective</h3>Choose one:<ol class="steps-list"><li>Maximize conversion and UX (especially for new users).</li><li>Minimize variable communication cost (SMS) for existing users.</li><li>Balance conversion, UX, and cost.</li></ol><blockquote>If you don’t make this explicit, discussions will circle around “extra costs” instead of clear trade-offs.</blockquote><hr><h3>Step 2 – Gather Your Key Inputs</h3>From your BI/analytics:<ul class="accent-bullets"><li>Average new signups per day.</li><li>Number of monthly active users (MAU).</li><li>Average logins per active user per month (or estimate).</li><li>Average trips per user.</li></ul>From your providers:<ul class="accent-bullets"><li>SMS cost per message in your markets.</li><li>Email cost (usually negligible on a per-message basis for OTP).</li></ul>From your config:<ul class="accent-bullets"><li>Access/refresh token lifetimes (how long users stay logged in).</li></ul><hr><h3>Step 3 – Evaluate Options</h3><h4>When to Choose Phone (SMS) Login as Primary</h4>Choose SMS OTP if:<ul class="accent-bullets"><li>You want the strongest identity binding (phone numbers used in support, payments, fraud checks).</li><li>Your user base is mobile-first and responds better to SMS than email.</li><li>You operate in markets where email usage is weak or unreliable.</li><li>You’re running high-value trips (e.g., cars vs low-margin scooters) and can absorb extra SMS cost for better UX and risk control.</li></ul><hr><h4>When to Choose Email OTP as Primary</h4>Choose email OTP if:<ul class="accent-bullets"><li>You want passwordless UX but need to keep variable auth costs low.</li><li>Your users already rely on email for receipts, support, and marketing.</li><li>You operate in markets where email is robust and widely used.</li><li>You want to avoid the long-term overhead of password resets and password security management.</li></ul>You can still add phone verification selectively for high-risk actions (e.g., high-value bookings) without making SMS the default for every login.<hr><h4>When (or Whether) to Keep Email + Password</h4>You may keep or temporarily use email + password when:<ul class="accent-bullets"><li>Your user base is highly desktop-oriented and comfortable with passwords.</li></ul>However, for most operators, the recommended target is:<blockquote>Email OTP or Phone OTP</blockquote><hr><h3>Step 4 – Model the Impact (Fast Calculation)</h3>For a rough monthly cost estimate of SMS login:<ol class="steps-list"><li>Estimate login events per month:<ol class="steps-list"><li><code class="inline-code-shadow bg-gray-100 border border-gray-200/60 dark:border-gray-800 font-medium dark:bg-gray-700/60 text-gray-700 dark:text-gray-200 font-mono text-md px-1 py-0.5 rounded-[0.2rem] [&amp;::before]:content-none [&amp;::after]:content-none">MAU × average logins per active user</code></li></ol></li><li>Multiply by percentage of logins that use SMS (e.g., 100% if SMS is mandatory).</li><li>Multiply by cost per SMS.</li></ol>Result = approximate monthly SMS auth cost.Compare this to:<ul class="accent-bullets"><li>Expected extra trips or revenue from improved signup/login conversion.</li><li>Your margin per trip.</li></ul><hr><h3>Step 5 – Configure and Monitor</h3>Once you choose:<ol class="steps-list"><li>Set the chosen method as default sign-in by contacting our support team.</li><li>Configure token lifetimes to strike a balance between security and re-login frequency.</li><li>Monitor after launch:<ol class="steps-list"><li>Signup → first trip conversion rate.</li><li>Login error rate / “I can’t log in” support tickets.</li><li>OTP resend rates and failure rates.</li><li>SMS spend (if using phone login).</li></ol></li></ol>Iterate if needed (e.g., adjust token lifetime or switch primary method).<hr><h1>Tips and Best Practices</h1><ul class="accent-bullets"><li>Align marketing and auth. If your acquisition campaigns collect phone numbers, use phone login. If they collect emails, email OTP is natural.</li><li>Tune token lifetimes, not just methods. A slightly longer refresh token can dramatically reduce OTP frequency (and SMS cost) without noticeably changing risk.</li><li>Track OTP failures. High failure or resend rates might indicate:<ul class="accent-bullets"><li>Poor SMS routing in certain countries.</li><li>Email deliverability issues (spam / promotions folder).</li></ul></li><li>Plan for migration spikes. Expect a one-time spike in OTP usage (especially SMS) when moving existing users to a new platform. Treat this as migration cost, not steady-state.</li><li>Educate your users. A short in-app message explaining the new login method (“We’ve upgraded security and made login easier…”) reduces confusion.</li><li>Review regularly. Revisit your auth decision at least once a year as prices, user behavior, and industry standards evolve.</li></ul><hr><h1>Troubleshooting</h1>Issue: SMS / OTP costs are higher than expected<ul class="accent-bullets"><li>Check token lifetimes – aggressive expiry increases logins.</li><li>Investigate whether users frequently reinstall the app or clear data.</li><li>Confirm that only the intended flows trigger SMS (e.g., avoid duplicate sends on retry).</li><li>Consider switching primary method to email OTP or limiting SMS to specific cases.</li></ul><hr>Issue: Users complain about “too many logins”<ul class="accent-bullets"><li>Verify refresh token configuration – you may be forcing re-authentication too often.</li><li>Ensure app updates or environment changes are not unintentionally invalidating sessions.</li><li>Communicate clearly: tell users they stay logged in on their trusted device unless they log out.</li></ul><hr>Issue: Many users don’t receive the OTP<ul class="accent-bullets"><li>For SMS:<ul class="accent-bullets"><li>Check provider logs for delivery errors by country/operator.</li><li>Validate phone number formatting (E.164 recommended).</li></ul></li><li>For Email:<ul class="accent-bullets"><li>Check spam / promotions placement.</li><li>Verify sending domain (SPF/DKIM/DMARC) and reputation.</li></ul></li></ul>

Best Practices & Use Cases

This article explains how Wunder V2 authentication works and how to choose between email OTP, phone (SMS) login, and legacy email + password. 