Vue d'ensemble
Klink utilise Stripe comme processeur de paiement. Chaque achat passe par un Payment Intent — l'objet central de Stripe qui représente une intention de paiement.
Le flow de paiement
1. Création du Payment Intent
Quand l'acheteur clique sur "Buy now", l'API crée un Payment Intent côté Stripe avec :
- Le montant exact (prix × quantité + frais éventuels)
- La devise (EUR)
- Les métadonnées (orderId, dropId, userId)
2. Paiement côté client
Le Payment Element Stripe (intégré dans la page checkout) gère :
- La saisie de la carte
- Apple Pay / Google Pay
- La validation 3D Secure si nécessaire
Le client ne touche jamais les données de carte — tout est géré par Stripe.
3. Confirmation par webhook
Après le paiement, Stripe envoie un webhook payment_intent.succeeded à notre API. C'est ce webhook qui :
- Crée la commande en base de données
- Décrémente le stock
- Envoie l'email de confirmation
Pourquoi les webhooks et pas le retour client ?
Le retour client (redirect après paiement) n'est pas fiable : l'utilisateur peut fermer l'onglet, perdre sa connexion, etc. Le webhook est la source de vérité — il arrive toujours.
Idempotence
Un même webhook peut arriver plusieurs fois (retry Stripe). On gère ça avec un set de webhooks déjà traités : si on a déjà vu cet event ID, on ignore.
Sécurité
- Signature webhook : chaque webhook est vérifié avec le secret Stripe — impossible de forger un faux paiement
- Pas de données carte côté serveur — jamais
- HTTPS obligatoire partout
En résumé
Payment Intent → Payment Element (client) → Webhook (serveur) → Commande créée. Fiable, sécurisé, idempotent.