Passer au contenu principal

Qu’est-ce qu’une Checkout Session ?

Une Checkout Session représente la session de paiement de votre client. Elle contrôle ce que le client voit sur la page de paiement : les produits, le montant, la devise, et les options disponibles.
Format de l’identifiant : cs_ suivi de 24 caractères alphanumériques.Exemple : cs_abc123def456ghi789jkl012

Modes de la session

payment

Paiement uniquePour les achats ponctuels de produits ou services.

subscription

AbonnementPour créer un abonnement récurrent avec facturation automatique.

setup

ConfigurationPour enregistrer un moyen de paiement sans effectuer de paiement immédiat.

Créer une Checkout Session

Requête de base

Paramètres requis

Paramètres optionnels

Définir les articles (line_items)

Vous avez deux options pour définir les articles :
Définissez le prix directement dans la requête :

Structure du line_item

Structure de price_data

Structure de product_data

Abonnements récurrents

Pour créer un abonnement, utilisez mode: "subscription" et ajoutez recurring dans price_data :

Intervalles disponibles

Options avancées

Collecter les adresses

Collecter le numéro de téléphone

Autoriser les codes promo

Appliquer un code promo automatiquement

Personnaliser le bouton de paiement

Quantité ajustable

Permettez au client de modifier la quantité sur la page de paiement :

Exemple complet

Réponse

Champs de la réponse

Rediriger le client

Une fois la session créée, redirigez le client vers l’URL de paiement :

Après le paiement

Redirection

Après le paiement, le client est redirigé vers success_url avec l’ID de session :

Vérifier le statut

Ne faites jamais confiance uniquement à la redirection. Vérifiez toujours le statut de la session côté serveur.

Webhooks

Pour une intégration robuste, ne vous fiez pas à la seule redirection vers success_url : abonnez-vous aux événements de la session (famille checkout.*). Paiement réussi — checkout.session.completed :
Tentative échouée — checkout.session.payment_failed :
  • Les champs sont directement sous data (il n’y a pas de data.object). amount est en unité majeure de la devise (35000 = 35 000 XAF).
  • Identifiez le paiement par data.checkoutSessionId. data.orderId peut apparaître sur completed : ne vous appuyez pas dessus.
  • Pour une session créée depuis une facture, data.invoiceId est ajouté.
  • error est une chaîne opaque, à journaliser, pas à interpréter.
  • checkout.session.payment_failed n’est pas terminal : la session reste ouverte et le client peut réessayer. Il est émis quand l’échec est connu à la réponse de confirmation ; un dépassement de délai est porté par intent.expired.
  • checkout.session.expired n’est pas émis aujourd’hui.
  • Un paiement par lien de paiement émet payment_link.checkout.*, et une session d’abonnement émet les événements d’abonnement, jamais checkout.session.*.
Voir la documentation Webhooks pour la signature et la livraison.

Statuts de la session

Bonnes pratiques

  • Créez toujours les sessions côté serveur
  • Ne stockez jamais les clés API côté client
  • Vérifiez le statut via l’API ou les webhooks
  • Pré-remplissez l’email si vous le connaissez
  • Utilisez client_reference_id pour lier à votre commande
  • Personnalisez le submit_type selon le contexte
  • Gérez le cas où le client annule
  • Prévoyez l’expiration de la session
  • Utilisez les webhooks pour les cas edge

Prochaines étapes

Webhooks

Recevez des notifications en temps réel

Codes promo

Appliquez des réductions à vos sessions