Paiements pour les clients existants
Découvrez comment débiter un moyen de paiement existant pendant une session.
Pour contrôler totalement l’affichage des moyens de paiement existants, utilisez l’implémentation de l’API Direct.
Afficher les moyens de paiementCôté clientCôté serveur
Appelez l’enpoint list Payment Method avec le paramètre allow_
pour récupérer les moyens de paiement réutilisables d’un client.
Utilisez les données de la réponse de l’API pour afficher les moyens de paiement dans votre propre interface utilisateur et laissez le client en sélectionner un.
Créer un PaymentIntentCôté serveur
Créez un PaymentIntent pour essayer de facturer le client avec le moyen de paiement qu’il a sélectionné.
Si l’appel à l’API échoue et renvoie une erreur 402, cela signifie que le paiement a été refusé. Demandez au client de réessayer ou d’utiliser un autre moyen de paiement.
Vérifier l'état du PaymentIntentCôté clientCôté serveur
Si la création du PaymentIntent a bien abouti, vérifiez son status
:
succeeded
indique que le client a été débité comme prévu. Affichez un message de réussite du paiement pour votre client.requires_
indique que vous devez demander une action supplémentaire, telle que l’authentification avec 3D Secure. Appelezaction handleNextAction
dans le front-end pour déclencher l’action que le client doit effectuer.
const { error, paymentIntent } = await stripe.handleNextAction({ clientSecret: "{{CLIENT_SECRET}}" }); if (error) { // Show error from Stripe.js } else { // Actions handled, show success message }
Gérer les événements post-paiementCôté serveur
Stripe envoie un événement payment_intent.succeeded à l’issue du paiement. Utilisez l’outil de webhook du Dashboard ou suivez le guide consacré aux webhooks pour recevoir ces événements et exécuter des actions, comme envoyer une confirmation de commande par e-mail à votre client, enregistrer la vente dans une base de données ou lancer un flux de livraison.
Plutôt que d’attendre un rappel de votre client, écoutez ces événements. Côté client, il arrive en effet que l’utilisateur ferme la fenêtre de son navigateur ou quitte l’application avant l’exécution du rappel. Certains clients malintentionnés peuvent d’autre part tenter de manipuler la réponse. En configurant votre intégration de manière à ce qu’elle écoute les événements asynchrones, vous pourrez accepter plusieurs types de moyens de paiement avec une seule et même intégration.
En plus de l’événement payment_
, nous vous recommandons de gérer ces autres événements lorsque vous encaissez des paiements à l’aide de l’Element Payment :
Événement | Description | Action |
---|---|---|
payment_intent.succeeded | Envoyé lorsqu’un client effectue un paiement avec succès. | Envoyez au client une confirmation de commande et traitez sa commande. |
payment_intent.processing | Envoyé lorsqu’un client initie un paiement, mais qu’il ne l’a pas encore finalisé. Dans la plupart des cas, cet événement est envoyé lorsque le client initie un prélèvement bancaire. Il est suivi par un événement payment_ ou payment_ . | Envoyez au client une confirmation de commande qui indique que son paiement est en attente. Pour des marchandises dématérialisées, vous pourrez traiter la commande sans attendre que le paiement soit effectué. |
payment_intent.payment_failed | Envoyé lorsqu’un client effectue une tentative de paiement qui se solde par un échec. | Si un paiement passe de l’état processing à payment_ , proposez au client de retenter le paiement. |