Développement digital · fiche technologique
StripeFiche technologique · Développement digital
Encaisser en ligne avec Stripe : le parcours complet
Stripe est un service de paiement en ligne que l'on pilote depuis un site ou une application. Encaisser n'est que le début : il faut authentifier le client, confirmer le résultat de façon fiable et éviter les doublons. Voici ce qu'il faut décider, et comment nous l'intégrons.
Le besoin
Un paiement qui aboutit une seule fois.
Vous ne cherchez pas une interface de programmation : vous voulez que chaque paiement réussi déclenche une commande, et qu'aucun ne soit encaissé deux fois.
Stripe peut s'intégrer de trois façons, de la plus simple à la plus personnalisée : une page de paiement prête à l'emploi, hébergée par Stripe ou intégrée à votre site, un formulaire intégré à vos pages, ou des composants (Elements) pour bâtir un formulaire entièrement sur mesure. Plus la personnalisation est poussée, plus il y a de code à maintenir : c'est le premier arbitrage à poser, avant toute ligne de développement.
En Europe, l'authentification forte du client s'applique à de nombreux paiements par carte : la règle est en vigueur depuis le 14 septembre 2019, dans le cadre de la directive européenne sur les services de paiement. Le client peut être renvoyé vers sa banque, et le paiement n'est alors pas terminé quand il quitte votre page. L'API Payment Intents suit donc chaque paiement tout au long de son cycle de vie, au lieu de le traiter comme un geste instantané.
Notre travail consiste à choisir le bon niveau d'intégration, à relier le paiement à vos commandes et à prévoir les cas qui se passent mal : paiement abandonné, authentification refusée, notification reçue deux fois. Nous mettons Stripe en œuvre dans des sites et des applications, et nous le raccordons à votre boutique ou à vos outils par des intégrations d'API suivies.
Un paiement n'est pas un instant
Il passe par des états : en attente d'une action du client, en cours de traitement, réussi ou à reprendre. Votre commande doit suivre ces états, pas seulement le retour du navigateur.
La confirmation vient du serveur
Le client peut fermer l'onglet juste après avoir payé. C'est la notification que Stripe envoie à votre serveur, et non la page de retour, qui doit valider la commande.
Réessayer sans payer deux fois
Un réseau qui coupe, un clic répété : sans clé d'idempotence, une nouvelle tentative peut créer un second paiement. Avec elle, Stripe reconnaît la demande déjà reçue.
Applications concrètes
Ce qu'on en fait, concrètement.
Six usages courants, du paiement unique à la place de marché. Chacun peut se combiner avec les autres.
Paiement d'une commande en ligne
Une page de paiement hébergée pour démarrer vite, ou un formulaire intégré à votre parcours, relié à la commande et à son suivi.
Abonnement et facturation récurrente
Des paiements qui reviennent à échéance, avec le suivi de l'état de chaque abonnement, pilotés par la facturation de Stripe (Billing).
Place de marché
Répartir un paiement entre plusieurs vendeurs, avec les comptes connectés de Stripe (Connect) et les règles de versement propres à votre plateforme.
Facture payable en ligne
Un acompte ou une facture envoyés au client, qui peut les régler en ligne, avec le paiement rapproché de la pièce comptable.
Carte enregistrée pour les clients réguliers
Une carte authentifiée une fois, réutilisable ensuite avec l'accord du client, pour un réachat en un geste ou un paiement ultérieur.
Rapprochement des paiements et des commandes
Le numéro de commande est attaché à chaque paiement côté Stripe : la comptabilité retrouve l'un depuis l'autre, sans ressaisie.
Le parcours, étape par étape
Le parcours d'un paiement, du navigateur à la commande.
Six étapes, et deux messages qui font la différence entre une intégration qui marche en démonstration et une qui tient en production : l'authentification éventuelle et la notification signée.
Navigateur
Le client valide son panier sur votre site. Le montant n'est jamais décidé par le navigateur.
Votre serveur
Il crée le paiement chez Stripe avec le montant calculé de son côté et une clé d'idempotence tirée du panier.
Stripe
Stripe évalue si une authentification est requise, selon la réglementation, les règles de risque et la banque.
Authentification forte
Si la banque l'exige, le client confirme auprès d'elle (3-D Secure). Le paiement attend une action, puis reprend.
Notification signée
Stripe prévient votre serveur du résultat. La signature prouve que le message vient bien de lui, et n'a pas été modifié.
Commande
Votre serveur ignore une notification déjà traitée, puis passe la commande à « payée » et lance la suite.
Schéma pédagogique : l'enchaînement exact dépend du mode d'intégration choisi (page hébergée, formulaire intégré ou composants sur mesure).
Faire le bon choix
Stripe : oui, ou pas ?
Le paiement est un domaine où l'on regrette les raccourcis. Voici les situations où Stripe se justifie, et celles où il vaut mieux revoir le besoin avant de développer.
Elle convient quand
- Vous vendez à des clients en Europe par carte et vous voulez que l'authentification forte soit gérée par l'interface de Stripe plutôt que codée à la main.
- Au-delà du paiement unique, vous avez besoin d'abonnements, de factures payables en ligne ou de paiements répartis entre plusieurs vendeurs.
- Votre équipe, ou votre prestataire, veut piloter le paiement par programme : création, suivi des états, remboursements, rapprochement avec les commandes.
- Vous acceptez de dépendre d'un prestataire externe, de ses conditions contractuelles et de ses évolutions de version d'API, qu'il faudra suivre.
Il vaut mieux l'éviter, ou la compléter, quand
- Votre banque ou votre groupe impose un autre prestataire de paiement : cette contrainte se cadre avant tout développement, pas après.
- Votre volume est très faible et un simple lien de paiement suffirait : un développement complet serait disproportionné.
- Vous voulez un formulaire personnalisé à l'extrême sans en assumer la maintenance : plus la personnalisation est poussée, plus il y a de code à suivre.
- Vous comptez rester sur d'anciennes méthodes (3-D Secure 1, API de charges directes) : les grands réseaux de cartes ne prennent plus en charge la première, et la seconde expose à des refus de banque.
Un exemple lisible
Vérifier une notification avant de croire un paiement.
Une trentaine de lignes qui montrent l'essentiel : lire le corps brut, vérifier la signature, écarter les doublons, puis confier le travail à une file. Sans cette vérification, n'importe qui pourrait envoyer un faux message « paiement réussi » à votre serveur.
- La clé secrète vient de l'environnement du serveur, jamais du code ni du navigateur.
- Le corps est lu tel quel : la signature porte sur le texte exact reçu, et la moindre modification (une relecture en JSON, par exemple) la rend invalide.
- La bibliothèque officielle compare la signature de l'en-tête à celle qu'elle recalcule avec votre secret, et refuse les messages trop anciens.
- Stripe peut envoyer deux fois le même événement : on note les identifiants déjà traités pour ne rien exécuter en double.
- Le travail lourd est confié à une file et la réponse part vite : le numéro de commande avait été attaché au paiement à sa création.
import Stripe from "stripe";
declare function dejaTraite(idEvenement: string): Promise<boolean>;
declare function mettreEnFile(tache: { commande: string; evenement: string }): Promise<void>;
const stripe = new Stripe(process.env.STRIPE_API_KEY!);
const secret = process.env.STRIPE_WEBHOOK_SECRET!;
export async function POST(request: Request): Promise<Response> {
const corpsBrut = await request.text();
const signature = request.headers.get("stripe-signature");
if (!signature) return new Response("Signature absente", { status: 400 });
let evenement: Stripe.Event;
try {
evenement = stripe.webhooks.constructEvent(corpsBrut, signature, secret);
} catch {
return new Response("Signature invalide", { status: 400 });
}
if (await dejaTraite(evenement.id)) return new Response(null, { status: 200 });
if (evenement.type === "payment_intent.succeeded") {
const paiement = evenement.data.object;
await mettreEnFile({ commande: paiement.metadata.commande, evenement: evenement.id });
}
return new Response(null, { status: 200 });
}
Notre façon de l'intégrer
Comment nous l'intégrons.
Une méthode en quatre temps, qui part de la page la plus simple et ne personnalise que ce qui le justifie.
Choisir le niveau d'intégration
Page hébergée, formulaire intégré ou composants sur mesure : nous mettons côte à côte le contrôle visuel souhaité et la maintenance qu'il entraîne, puis nous consignons le choix.
Relier paiement et commande
Un paiement par panier, le numéro de commande attaché au paiement, des clés d'idempotence dérivées du panier : une nouvelle tentative reprend le même paiement au lieu d'en créer un autre.
Confirmer par notification signée
Un point d'entrée en HTTPS, la vérification de la signature, un registre des événements déjà traités. L'ordre d'arrivée des notifications n'est pas garanti : le traitement doit s'en accommoder.
Éprouver les cas défavorables
Cartes de test avec authentification, authentification refusée, abandon, notification rejouée, secret renouvelé. En production, nous préférons des clés d'accès restreintes aux droits strictement nécessaires.
Aller plus loin
De la technologie au projet.
La technologie se choisit après le besoin : voici les expertises qui portent le projet, et les technologies voisines à comparer.
Expertises métier
- API et intégrationsRelier le paiement à vos commandes, votre facturation et vos outils, avec des échanges suivis et rejouables.
- Solutions e-commerceLe parcours d'achat complet dans lequel s'insère le paiement.
- Places de marchéRépartir les paiements entre vendeurs et suivre les versements sur une plateforme multi-vendeurs.
- Sécurité des applications et APIProtéger les points d'entrée, les secrets et les notifications reçues de services tiers.
Technologies voisines
- WooCommerceLa boutique WordPress à laquelle un paiement Stripe est le plus souvent relié, avec ses extensions de paiement et son parcours en blocs.
- OWASP Top 10Les grandes familles de failles web, à confronter à une intégration de paiement et aux notifications qu'elle reçoit.
Toutes les technologies du pôle
Questions fréquentes
Les questions qu'on nous pose sur Stripe.
Des réponses courtes, pour décider avant de lancer un chiffrage.
Sources
- Stripe : l'API Payment Intents
- Stripe : Strong Customer Authentication (SCA)
- Stripe : authentification 3D Secure (3-D Secure 1 non pris en charge par les grands réseaux)
- Stripe : requêtes idempotentes
- Stripe : recevoir des événements sur un point d'entrée (webhooks) et vérifier leur signature
- Stripe : construire une page de paiement (Checkout, formulaire intégré, Elements)
- Stripe : versions de l'API
Fiche relue en novembre 2026.
Faut-il une page de paiement hébergée ou un formulaire sur mesure ?
Nous recommandons de commencer par la solution la plus simple qui respecte votre image. La documentation de Stripe classe la page complète, hébergée ou intégrée, comme la moins coûteuse à maintenir, et les composants Elements comme les plus personnalisables mais les plus exigeants. La personnalisation poussée se justifie quand elle apporte un gain mesurable au parcours.
Pourquoi un client peut-il avoir payé sans que la commande apparaisse ?
Parce que le client peut fermer l'onglet, perdre sa connexion ou quitter la page de sa banque avant le retour sur votre site. Si la commande dépend de cette page de retour, elle manque. La parade est la notification envoyée par Stripe à votre serveur : en production, il retente la livraison pendant plusieurs jours en cas d'échec.
À quoi sert une clé d'idempotence dans un paiement ?
Elle identifie une demande de façon unique. Si la connexion coupe et que votre serveur renvoie la même demande avec la même clé, Stripe ne crée pas un second objet : il renvoie le résultat de la première. Il suffit de dériver la clé de l'identifiant du panier. Stripe compare aussi les paramètres, et signale une erreur si la même clé sert pour une demande différente.
Le 3-D Secure est-il obligatoire pour tous les paiements par carte ?
Non, pas pour tous. L'authentification forte vise les entreprises basées dans l'Espace économique européen qui servent des clients de cette zone par carte. Certaines opérations à faible risque en sont exemptées, mais la banque peut toujours la demander : l'intégration doit donc savoir la gérer. Stripe décide dynamiquement s'il faut l'activer. Pour votre cas précis, une analyse juridique reste nécessaire.
Faut-il suivre les changements de version de l'API de Stripe ?
Oui, avec méthode. D'après la documentation de Stripe, de nouvelles versions paraissent chaque mois sans rupture, et deux fois par an une version majeure peut exiger des changements dans votre intégration. Les notifications suivent la version de votre compte, sauf indication contraire à la création du point d'entrée. Nous planifions une revue après chaque version majeure, sur un environnement d'essai.
Notre intégration actuelle utilise l'ancienne API de charges : faut-il migrer ?
Stripe prévient que les intégrations non prêtes pour l'authentification forte, comme celles qui reposent sur l'ancienne API de charges, peuvent subir de nombreux refus de banque. La voie recommandée passe par les Payment Intents ou par Checkout. Nous commençons par un état des lieux de votre code et de vos notifications, puis nous proposons une bascule par étapes, testée avant la mise en ligne.
Un paiement à intégrer, à reprendre ou à fiabiliser ?
Décrivez-nous votre parcours d'achat et vos outils : nous vous disons quel niveau d'intégration retenir, et comment confirmer chaque paiement sans doublon ni oubli.