Pourquoi le navigateur ne décide jamais si un utilisateur a payé

Le contexte

Le flux documenté dans l’article Next.js, Supabase et Stripe donne au webhook le rôle de confirmation, puis enregistre l’accès durablement. Le cas Atamatax décrit aussi le passage en préparation après confirmation du paiement.

La règle

Checkout → webhook signé → état durable côté serveur → interface qui lit cet état. Le navigateur affiche une confirmation, il n’accorde pas les droits.

Pourquoi ça compte

Une URL de succès peut être ouverte sans paiement et les webhooks peuvent être renvoyés. Sans signature vérifiée et traitement idempotent, l’accès peut diverger de l’état réel.

Ce que je fais maintenant

Je vérifie la signature, traite les événements de manière idempotente et accorde les droits depuis un entitlement durable.

Applique-la à ton projet

1. 01Crée le prix et la session Checkout côté serveur.
2. 02Vérifie la signature webhook avant de traiter l’événement.
3. 03Enregistre achat et entitlement avec une clé idempotente.
4. 04Fais lire l’accès à l’interface depuis cet état durable.

Vérifie

• Un retour navigateur seul ne débloque rien.
• Le même événement traité deux fois ne double pas l’effet.
• Échec, attente et remboursement ont un état défini.