Ajouter un paiement Stripe à son application : du lien simple à l’accès payant

Encaisser et ouvrir une fonction payante sont deux opérations à relier. Voici comment choisir un premier parcours Stripe et préparer les essais de paiement, d’annulation et de notification répétée, sans encaisser d’argent réel.

Ajouter un bouton de paiement peut être rapide. Savoir quel compte a payé, quel service il a acheté et quand lui ouvrir l’accès demande un parcours plus complet. Une page « Merci » n’est pas une preuve suffisante : elle peut ne jamais s’ouvrir après le paiement, ou être visitée sans que l’achat attendu ait eu lieu.

Nous suivons un exemple fictif : un petit service permet de préparer gratuitement un dossier, puis d’acheter un export avancé. Il s’agit d’un achat unique pour commencer. Le guide explique ensuite ce qui change avec un abonnement. Tous les scénarios proposés doivent être réalisés dans l’environnement de test Stripe, sans transaction réelle.

Définir exactement ce que la personne achète

Écrivez l’offre avant de choisir l’intégration. Dans notre exemple, l’achat débloque l’export avancé d’un dossier donné pour un compte identifié. Il ne débloque pas tous les dossiers de l’entreprise, un abonnement permanent ou un accompagnement humain. Cette précision doit se retrouver dans le texte affiché avant le paiement et dans la règle d’accès.

Précisez également ce qui se passe après l’achat : retour vers le dossier, confirmation lisible et possibilité de retrouver l’export plus tard. Si vous prévoyez un traitement manuel, indiquez-le clairement avec ses conditions. Un paiement réussi suivi d’un écran sans résultat devient rapidement une demande de support.

Les prix, taxes, conditions de vente et modalités de remboursement doivent être définis pour votre activité avec les compétences appropriées. L’intégration technique ne choisit pas ces règles à votre place. Ce guide se concentre sur le lien entre paiement et accès, sans fournir de conseil fiscal ou juridique.

Choisir entre un lien de paiement et un parcours intégré

Payment Links permet de créer un lien vers une page de paiement hébergée par Stripe, à partir de sa configuration. La présentation officielle des liens de paiement décrit ce parcours. Il peut convenir à une offre simple, notamment lorsque la livraison reste manuelle et explicitement annoncée.

Un parcours construit autour de Checkout peut relier plus étroitement la demande d’achat au compte et au dossier concernés. Le serveur prépare alors les informations autorisées de la commande. Le navigateur ne doit pas choisir librement le prix, l’offre ou le compte bénéficiaire en modifiant une valeur dans l’adresse.

Un lien simple n’empêche pas d’automatiser la livraison, mais cette automatisation reste à construire. Inversement, un parcours intégré peut rester assez sobre pour l’utilisateur. Choisissez à partir de l’offre et du besoin d’attribution, pas seulement du nombre de lignes de code annoncé par un tutoriel.

Pour comprendre · illustration du guide

Relier la commande au bon utilisateur

Créez une référence interne avant de commencer le paiement. Elle permet de relier le compte, le dossier, l’offre acceptée et l’état de la commande. L’application doit vérifier que la personne a bien le droit d’acheter cette option pour ce dossier. Une référence reçue du navigateur ne constitue pas une autorisation.

Dans notre cas fictif, Alice achète l’export du dossier DOS-014. La commande CMD-008 correspond à ce dossier et à son compte. Le serveur conserve cette relation et transmet au service de paiement les références appropriées. Après confirmation, l’accès doit être ouvert à Alice pour DOS-014, sans toucher au dossier de Bilal.

Évitez de rattacher l’accès uniquement à l’adresse électronique saisie au paiement. Une personne peut utiliser une autre adresse de facturation ou partager une adresse avec une équipe. Le compte bénéficiaire doit être déterminé par un parcours authentifié ou une procédure d’attribution explicite, puis contrôlé côté serveur.

Recevoir une confirmation indépendante de la page de retour

Stripe peut notifier votre serveur lorsqu’un événement survient. Cette notification est appelée webhook. La documentation de livraison après paiement explique pourquoi le retour du navigateur ne suffit pas et pourquoi un même achat doit être traité une seule fois, même lorsque plusieurs notifications arrivent.

Le serveur doit vérifier l’origine de la notification et l’état pertinent de l’achat avant d’ouvrir l’accès. Les recommandations de sécurisation des webhooks détaillent notamment la signature. Ne confondez pas réception d’un message et validation de son authenticité. Un message fabriqué par un tiers ne doit jamais débloquer une fonction payante.

Certains moyens de paiement aboutissent plus tard. Un parcours terminé côté client ne signifie donc pas toujours que l’accès peut être livré immédiatement. Définissez un état « en attente » et les événements qui permettront de le faire évoluer. L’utilisateur doit comprendre cette attente sans être invité à payer une seconde fois par erreur.

Préparer des états lisibles pour le client et le support

Dans notre exemple, une commande peut être créée, en attente, payée et livrée, ou abandonnée selon les événements réellement connus. Un remboursement ou une contestation demande ensuite un traitement distinct. Évitez un seul champ « payé : oui/non » si vous ne pouvez plus expliquer ce qui est arrivé.

Du côté du client, affichez l’action pertinente : poursuivre l’achat, attendre sa confirmation, accéder à l’export ou demander de l’aide. Du côté du support, conservez des références qui permettent de rapprocher la commande et le paiement dans le tableau de bord autorisé. Ne recopiez pas des informations bancaires dans votre propre journal applicatif.

Si le paiement réussit mais que la création de l’export échoue, le problème est une livraison à reprendre. Il ne faut ni lancer automatiquement un nouvel encaissement ni demander au client de recommencer sans diagnostic. Préparez une reprise de livraison liée à la commande existante.

Essayer le parcours sans argent réel

Utilisez les réglages et moyens de test documentés par Stripe. Vérifiez visiblement l’environnement avant chaque essai et gardez ses clés séparées de la production. N’utilisez pas une vraie carte pour simuler un refus. La documentation des tests Stripe fournit les cas adaptés aux différentes situations.

Notre recette comprend deux comptes et deux dossiers fictifs. Alice peut acheter pour DOS-014 ; Bilal ne doit recevoir aucun droit par cet achat. Le résultat attendu porte sur l’accès réel au service, pas seulement sur le message de paiement. Ouvrez donc la fonction protégée depuis les deux comptes après chaque scénario.

• Paiement de test réussi : l’accès s’ouvre au bon compte, pour le bon dossier et une seule fois.
• Paiement refusé : aucun accès payant n’est attribué ; le client peut comprendre et corriger la situation.
• Fenêtre fermée après paiement : la notification permet quand même la livraison prévue.
• Notification identique reçue deux fois : aucune deuxième livraison ni droit supplémentaire n’apparaît.
• Notification à signature invalide : elle est refusée sans modifier la commande.
• Paiement en attente : l’application n’annonce pas prématurément une livraison confirmée.
• Échec de génération de l’export : la commande reste identifiable et sa livraison peut être reprise.

Cette liste décrit les essais à exécuter sur votre intégration. Elle ne prétend pas qu’ils ont déjà été réalisés sur un compte Stripe. La fiche paiement et accès fournit les références fictives et un emplacement pour noter chaque résultat observé.

Ajouter un abonnement seulement lorsque son cycle est défini

Un abonnement ajoute des renouvellements, des paiements échoués, des changements d’offre et une fin d’accès. Décidez ce qui arrive à la date d’échéance, pendant une éventuelle période de tolérance et après une résiliation. Ces règles doivent être expliquées au client et appliquées à partir de l’état confirmé du service de paiement.

Consultez les événements d’abonnement documentés par Stripe avant de bâtir la synchronisation. Ne traitez pas la première confirmation d’achat comme une autorisation éternelle. Ne supprimez pas non plus automatiquement toutes les données au premier incident de paiement sans règle produit et procédure adaptées.

Pour une équipe, il faut encore décider qui peut modifier l’offre et à quelle organisation les droits appartiennent. Une personne qui quitte l’entreprise ne devrait pas emporter implicitement tout l’abonnement. Ces sujets se relient au modèle des espaces d’entreprise et méritent une recette propre.

Préparer le passage en production comme une nouvelle vérification

Le domaine public, les secrets, la destination des notifications et les références d’offres diffèrent souvent de l’environnement de test. Faites vérifier chaque correspondance avant l’ouverture. Une intégration correcte en local peut échouer si les notifications sont encore envoyées vers une ancienne adresse.

Définissez aussi la personne qui surveille les commandes non livrées et la manière de contacter un client lorsque c’est nécessaire. L’interface ne doit pas promettre une disponibilité que votre organisation ne peut pas assurer. Un petit tableau de suivi des exceptions peut apporter davantage qu’un grand écran de revenus fictifs.

Vous pouvez préparer ce parcours dans Maestro avec les états, les références et les essais de la fiche. Le projet devra intégrer et configurer Stripe ; ce guide ne présente pas le paiement comme une fonction native déjà prête de Maestro. Commencez par un achat simple, prouvez la bonne attribution de l’accès, puis ajoutez les cycles plus complexes.