Illustration de l'article sur la connexion sans mot de passe par magic link
Conversion and UX

Passwordless Login (Magic Link) on PrestaShop in 2026: Checkout Conversion and the End of Captcha

·sasha

The password has become a ball and chain on e-commerce conversion

On the PrestaShop stores we instrument, around 14% of identified visitors (existing customers) abandon at the login step. Not before — at the precise moment they have to enter their password. And of the 86% who manage to log in, 28% go through “forgot password”, which adds a 2-4 minute detour to the purchase journey. Cumulatively on a mid-market store, that’s 8 to 18% of revenue dropped on authentication friction.

The password also carries a hidden cost: 30 to 50% of e-commerce support tickets concern an account (reset, lockout after attempts, account not found). At €5-8 per ticket handled, on 2,000 tickets per month, that’s €35-80K/year of operational cost. Not counting the psychological cost: a customer ejected from checkout by a forgotten password becomes harder to win back.

The alternative has existed for a long time and reaches maturity in 2026: passwordless login via magic link or passkey (WebAuthn). The principle is identical to what allowed Slack, Notion, Linear to replace the default password: an email with a unique link is sent, the click authenticates. No password to memorise, no captcha, no lockout.

The complete flow in five steps:

  1. The user enters their email on the login form.
  2. The server generates a cryptographic token (typically 32 random bytes, encoded in base64url) with a limited lifetime (15 minutes by default).
  3. The token is stored in the database, linked to the email, with a hash (never in clear) and an expiry date.
  4. An email is sent with a link of the form https://store.com/login/magic?token=abc...
  5. On click, the server validates the token, opens the session, and invalidates the token (single use).

Four essential cryptographic properties to respect:

  • Cryptographic random token: generated with random_bytes() in PHP, never with mt_rand() or a predictable UUID.
  • Hash in database: don’t store the token in clear, store its SHA-256 (like a hashed password). This protects the database in case of leak.
  • Single-use: a validated token is immediately invalidated. No double activation possible.
  • Time-bound: 15 minutes default expiry. Beyond that, the token is dead, the user requests a new link.

The DfMagicLink module for PrestaShop implements these four guarantees by default, plus anti-enumeration protection (identical response whether the email exists or not, to avoid revealing the customer base to an attacker) and per-IP rate limiting.

Magic link and passkey aren’t competitors but complements, each with its use case:

  • Compatible with all devices and browsers.
  • No pre-registration needed: an email suffices.
  • Depends on email deliverability (see transactional email and DMARC/BIMI).
  • Residual friction: open inbox, click.

Passkey — biometric, instant, device-bound

  • The user authenticates via biometry (Touch ID, Face ID, Android fingerprint) or device PIN.
  • No email round-trip, instant.
  • Requires prior passkey registration on each device.
  • Standardised W3C WebAuthn, supported by all modern browsers since 2023.

The 2026 hybrid pattern

The pattern that works in e-commerce today:

  • First connection or new device: magic link (universal, no prior registration).
  • After successful first login, offer to register a passkey on the device for subsequent connections (“log in in one click next time”).
  • Classic password as option for users who want it, or for back-office admin accounts (where 2FA remains king).

This pattern combines magic link universality and passkey instantness, without imposing an abrupt habit change.

Measured impact on conversion

On PrestaShop stores that switched from classic password to a frontline magic link system:

  • Login successful rate: from 73% to 94% (gain: +21 points). The remaining 6% failures are email typos or deliverability issues.
  • Average login time: from 47s to 22s (email click included).
  • Account-related support tickets: −68% on average over 3 months.
  • Checkout conversion for identified customers: +4 to +8 points.

On a store doing 200 orders/month at an average basket of €80, +6 points of checkout conversion on 35% identified customers = +0.6 orders/day × €80 = +€1,460/month of revenue. Plus saved support tickets. Plus the psychological cost of a smooth experience.

PrestaShop implementation: architecture choices

Database architecture

A dedicated table ps_df_magic_token with fields:

  • id_token (PK auto-increment)
  • id_customer (FK ps_customer, nullable for on-the-fly account creation)
  • email (indexed)
  • token_hash (SHA-256, indexed for fast validation)
  • expires_at (datetime)
  • consumed_at (datetime nullable, usage marker)
  • ip_request, ip_consume (forensic audit)
  • user_agent (forensic audit)

A composite index (token_hash, expires_at, consumed_at) for fast validation of an incoming token.

The PrestaShop controller

Two modern controllers (Symfony) for PS 8/9:

  • MagicLinkRequestController — receives the email, generates the token, sends the email. POST with rate limiting.
  • MagicLinkConsumeController — receives the token via GET, validates, opens session via $context->customer->logged = true and $context->cookie.

Watch for the classic pitfall: never open a session on a GET without CSRF verification if the link is clicked from an email — a link preview (Outlook, Gmail link preview) could consume the token. The solution: require an explicit click on an intermediate page that POSTs the token, or detect preview agents (User-Agent containing “GoogleImageProxy”, “Mail-Preview”) and don’t consume the token on their pass.

The email template

The magic link email is a high-priority transactional email. Four rules:

  • Send delay under 5 seconds — beyond that, the user starts retyping their email.
  • Maximum deliverability — SPF, DKIM, DMARC aligned; no tracking images degrading spam score; short subject (“Sign in to your store”).
  • Highly visible button — not a hyperlink buried in a paragraph. A dedicated 200×50 px CTA in brand colour.
  • Security mention — “if you didn’t initiate this request, ignore this message” (mitigates social engineering risk).

Clean implementation of transactional email deliverability is a prerequisite: a magic link that ends up in spam means a customer abandoning.

Security: attacks to anticipate

1. Account enumeration

If the response differs based on whether the email exists in database (“we sent you a link” vs “this email doesn’t exist”), an attacker can enumerate the customer base by bruteforce. The rule: identical response in both cases, and email sent only if the account exists.

An attacker sends an email imitating your brand with a fake magic link redirecting to a phishing page. The protection: educate customers (mention in the real email: “verify the URL starts with store.com”), and publish BIMI to display the brand logo in Gmail/Yahoo. It’s the most effective trust lever in 2026.

3. Token bruteforce

With 32 random bytes, the search space is 2256, practically uncrossable. But an attacker could attempt bruteforce on the validation endpoint. The protection: per-IP rate limiting (10 attempts/minute max), and logging of invalid attempts.

4. Session theft via email interception

If the customer’s mailbox is compromised, the attacker receives the magic links. This is the main residual risk of magic links: it shifts account security to email security. The protection: short lifetime (15 min), invalidation at login, and optional 2FA for high-stakes accounts (recurring baskets, B2B accounts).

5. Replay attack

An attacker intercepts a magic link and replays it. Protection: single-use enforced in database (consumed_at not NULL blocks validation).

Special cases to handle

Account creation on first login

If the visitor enters an unknown email, two options: refusal (“this email has no account”) or on-the-fly creation. On-the-fly creation is UX-friendly (zero registration form) but requires a later supplement (name, address for shipping) at first checkout. The recommended pattern for PrestaShop: create the account on the fly with “incomplete” status, and complete it at checkout (which asks for address, phone anyway).

Powerful combination: send the customer a cart abandonment email containing both the cart recap AND a magic link to resume the purchase without login. Measured conversion on abandoned cart: ×1.6 vs a classic email with standard login. That’s what the DfSaveCart and DfMagicLink modules combine when deployed together.

B2B accounts with multi-users

For B2B stores with multi-user pro accounts, magic link remains valid: each collaborator receives the link on their pro email. But add an audit log: who logged in when, from which IP. This facilitates internal controls (who placed which order, etc.).

Admin / back-office accounts

For PrestaShop back-office, magic link remains tempting but TOTP 2FA (Google Authenticator, Authy) or direct passkey are preferable. A compromised mailbox giving access to your store admin is game over. The rule: magic link front-office, strong 2FA back-office.

PrestaShop 8 and 9 compatibility

On PrestaShop 8 (Symfony 4) and 9 (Symfony 6), implementation uses:

  • Modern Symfony routes via config/routes.yml or PHP 8 attributes.
  • Native PrestaShop sessions via $context->cookie + Customer::login().
  • Hooks to integrate with native login forms (displayCustomerLoginFormAfter).
  • Multilingual via XLIFF (FR, EN, ES, DE) for emails and error messages.
  • Multishop: tokens scoped by id_shop to prevent cross-shop login with a single link.

The DfMagicLink module natively covers these compatibilities and integrates with native PrestaShop session without forking the auth system.

FAQ

Should the password disappear completely?

No, and it’s even counterproductive. Some users prefer password by habit. The recommended pattern: magic link as first offer (95% of cases), password as option (“use a password instead”). No pressure, no learning friction.

Not directly, but audit traces (IP, user-agent, dates) are personal data subject to GDPR. Recommended retention: 1 year for consumed tokens (sufficient for forensic audit), automatic purge of unconsumed expired tokens. The right to erasure must also delete these traces, unless they’re necessary to an ongoing investigation.

What happens if the customer’s email is deactivated?

The magic link is unsendable, the customer is locked out. For this case, keep an assisted recovery procedure: contact form, identity verification via other channels (phone number, last purchase), then manual email change by support. It’s rare (1% of cases) but must be documented.

Yes, with deep links or universal links (iOS) / app links (Android). The email link directly opens the app if installed, with automatic session. PrestaShop has no native app, but for stores with PWA or hybrid app, this integration is technically standard.

With a turnkey module like DfMagicLink, it’s typically 30 minutes of installation + 1 to 2 hours of customisation (email template in brand colours, security mention, label translations). In custom development, count 3 to 5 days to reach production quality (security, deliverability, tests).

In summary

Magic link isn’t a UX gadget — it’s the removal of the most measurable checkout brake in 2026, with a direct impact of +4 to +8 points of conversion on identified customers and −60% account support tickets. Combined with passkeys for regular users, it offers a login experience that finally rivals Amazon, Google Pay and market leaders.

To implement it cleanly on PrestaShop, the DfMagicLink module covers the five essential cryptographic properties (random token, hash in database, single-use, time-bound, anti-enumeration) and integrates with native PrestaShop session system. To maximise ROI, combine with cart save via magic link which leverages the same infrastructure for cart abandonment recovery.

The non-negotiable prerequisite: transactional email deliverability at professional level (strict DMARC, aligned DKIM, BIMI). Without this, the magic link ends in spam and the store loses more customers than it saves. Our PrestaShop audit systematically includes verification of this email layer before recommending magic link deployment.

Keep reading

Related articles