Intégration API Stripe
Nous développons votre connecteur Stripe
Nous branchons l'API Stripe sur votre produit pour encaisser, reverser à vos vendeurs, facturer vos abonnements et ouvrir les accès au bon moment.
- Équipe produit senior
- intégrations de paiement en production
- du cadrage au monitoring
À quoi sert l'API Stripe et que devient le paiement une fois intégré ?
Stripe est la plateforme de paiement de référence pour les startups, les SaaS et les marketplaces. Son intégration permet à votre application d'encaisser un paiement, de gérer des abonnements avec essais gratuits et changements d'offre, et de reverser une commission à des vendeurs tiers si vous êtes une plateforme. Chaque événement de paiement : réussi, échoué, remboursé, litigieux, déclenche un webhook que votre application reçoit et traite. L'encaissement et la facturation deviennent des fonctions de votre produit, pilotées par des événements, et non plus des tâches traitées à part dans un espace admin.
Ce que nos clients construisent sur l'API Stripe
Place de marché avec commission
L'acheteur règle une commande qui contient les articles de plusieurs vendeurs. La répartition et la commission de plateforme partent au moment du paiement, pas en fin de mois.
Abonnement SaaS avec paliers et essais
Changements d'offre au prorata, périodes d'essai, planifications à phases. Le calcul de prorata maison disparaît, avec la classe de bugs la plus coûteuse d'un SaaS.
Ouverture des accès pilotée par la facturation
Les droits produit suivent l'état de l'abonnement au lieu d'un indicateur maintenu à la main dans deux systèmes. Un impayé restreint l'accès, un paiement le rouvre.
Recouvrement relié au produit
Le passage en impayé déclenche un message dans l'application, puis une relance, puis la restriction. La séquence est mesurable au lieu d'être envoyée à la main.
Ce que ça change dans votre modèle économique
La technique au service d'un résultat mesurable : des encaissements qui ne se perdent pas, une facturation juste, moins d'impayés.
Votre commission part avec le flux
La plateforme prélève sa part au moment du paiement. Plus de refacturation a posteriori aux vendeurs, plus de risque d'impayé sur votre propre commission.
Vous facturez le bon montant
Prorata, paliers et fins d'essai sont calculés par Stripe et testés avant la mise en production. Les avoirs et les gestes commerciaux d'excuse se raréfient.
Un impayé ne passe plus inaperçu
Chaque échec de paiement remonte dans votre produit, avec une suite d'actions définie. Vous savez ce qui est dû, par qui, et depuis combien de temps.
Une comptabilité qui retombe juste
Encaissements, commissions et reversements sont rapprochés avec vos factures. Votre comptable arrête de reconstituer les flux à partir d'un export.
Comment nous livrons votre connecteur Stripe
Cadrage
Quel modèle de flux, qui porte les litiges, qui paie les frais, quels événements comptent. On tranche l'axe risque avant d'écrire une ligne de code.
Développement
Connecteur typé, clés d'idempotence dérivées de l'intention métier, file de reprise sur erreur, version d'API épinglée. Démonstration chaque semaine.
Recette
Fin d'essai, échec de paiement au renouvellement, changement d'offre, authentification 3DS : chaque scénario est rejoué avec les horloges de simulation avant la bascule.
Monitoring
Alertes sur événement non traité, journal des paiements, tableau de bord de santé du connecteur. Vous savez qu'un flux est cassé avant vos clients.
Ce que permet l'API Stripe
- Encaissement et commission
- Paiement créé sur votre compte ou sur celui du vendeur, avec commission de plateforme prélevée au passage. Le choix décide de qui porte remboursements et litiges.
- Comptes connectés et reversements
- Création des comptes vendeurs, collecte des pièces de vérification, transferts vers leur solde et annulation de transfert quand une commande est annulée.
- Abonnements et factures
- Cycle de vie complet : essai, actif, impayé, résilié, suspendu. Factures créées, finalisées, payées, avec planification à phases et calcul de prorata.
- Événements et droits d'accès
- Webhooks sur la création d'abonnement, la fin d'essai, l'échec de paiement, plus les entitlements qui ouvrent et ferment les fonctionnalités de votre produit.
Le vocabulaire de l'API Stripe
- application_fee_amount
- Le montant que votre plateforme retient sur un paiement encaissé pour le compte d'un vendeur. C'est la ligne qui transforme Connect en modèle économique plutôt qu'en fonctionnalité.
- on_behalf_of
- Paramètre qui désigne le compte connecté comme entreprise de référence du paiement : pays de règlement, grille tarifaire, libellé sur le relevé bancaire du client.
- Idempotency-Key
- En-tête qui garantit qu'un même ordre rejoué ne crée pas deux paiements. Stripe mémorise le code et le corps de la première réponse, y compris quand elle est en erreur serveur.
- past_due
- Statut d'un abonnement dont la facture n'a pas été réglée. C'est le point de bascule entre relance et restriction d'accès, et il doit être câblé à votre produit.
- Entitlement
- Droit d'accès dérivé de l'état de facturation. Un événement de mise à jour signale que le périmètre de fonctionnalités d'un client a changé, sans indicateur maintenu à la main.
- Version d'API épinglée
- Un événement est figé dans la version en vigueur au moment où il survient. Les releases majeures sont nommées, la version courante est 2026-07-29.dahlia, et un endpoint webhook peut être épinglé séparément.
Les contraintes réelles de l'API Stripe
invoice.created retarde tout l'encaissement
Cet événement est bloquant : sans réponse positive de votre serveur, la finalisation des factures en encaissement automatique est repoussée jusqu'à 72 heures. Un webhook cassé retarde la facturation de tout le parc client, pas d'un seul compte.
Les événements n'arrivent ni dans l'ordre ni une seule fois
Stripe ne garantit aucun ordre de livraison, et les doublons sont attendus. Une machine à états qui suppose une séquence est fausse par construction : il faut dédupliquer et relire l'objet quand un événement arrive en avance.
Trois étages de limites, plus un quota de lecture
Cent requêtes par seconde en production, des plafonds propres à Billing par abonnement, et un quota de lecture distinct calculé sur trente jours glissants. Un travail de fond qui relit tout le catalogue chaque nuit sort du cadre.
Le type de flux Connect est une décision de risque
Selon le modèle retenu, remboursements et litiges sont débités du solde du vendeur ou du vôtre. Ce n'est pas un choix technique, c'est une ligne de votre compte de résultat, et il se tranche au cadrage.
Paiements directs ou transferts séparés ?
Deux façons de faire circuler l'argent entre vos vendeurs et vous. Le bon choix dépend de qui doit apparaître comme le commerçant, pas de la technique.
| Critère | Paiements directsLe vendeur encaisse | Transferts séparésLa plateforme encaisse |
|---|---|---|
| Qui apparaît sur le relevé | Le vendeur | Votre plateforme |
| Qui porte remboursements et litiges | Le solde du vendeur | Le solde de la plateforme |
| Panier multi-vendeurs | Un paiement par vendeur | Un paiement, plusieurs reversements |
| Commission de plateforme | Prélevée sur le paiement | Retenue sur le montant reversé |
| Prérequis côté vendeur | Capacité de paiement par carte activée | Compte connecté pouvant recevoir des transferts |
| Marche arrière | Remboursement sur le solde du vendeur | Annulation de transfert, si le solde le permet |
| Le bon cas | Le vendeur est le commerçant | Panier multi-vendeurs, commission au flux |
Le choix se fait au cadrage, avec votre direction financière, parce qu'il déplace le risque d'un bilan à l'autre. Il se change ensuite au prix d'une reprise complète des flux.
Ce que nous mesurons sur une intégration Stripe
Les autres API de paiement
Si Stripe n'est pas le bon choix pour votre modèle, ces options se discutent au cadrage.
StripeNous développons votre connecteur StripeCette page
PayPalUn moyen de paiement que vos acheteurs connaissent déjà, souvent en complément.
SumUpL'encaissement en présence du client, quand la vente se conclut sur le terrain.
GoCardlessLe prélèvement SEPA récurrent, moins coûteux que la carte sur les montants élevés.
MollieNous développons votre connecteur MollieOn combine Stripe avec
La stack qui entoure Stripe sur nos projets.
Intégration Stripe : vos questions
Trois étapes. D'abord choisir le modèle de flux : encaissement simple, abonnement, ou Connect avec reversement à des vendeurs. Ensuite construire le connecteur côté serveur, avec une clé d'idempotence dérivée de l'intention métier sur chaque création, pour qu'un rejeu ne produise jamais un second paiement. Enfin traiter les webhooks correctement : vérifier la signature sur le corps brut de la requête, répondre immédiatement, et faire le travail dans une file. La partie sensible n'est pas l'appel API, c'est la reprise sur erreur et le fait que les événements arrivent en désordre et parfois en double.
Cela dépend surtout du modèle de flux et du parcours d'inscription de vos vendeurs. Un encaissement simple avec commission fixe se chiffre bien plus bas qu'une place de marché avec panier multi-vendeurs, reversements différés, annulations partielles et collecte des pièces de vérification. La difficulté n'est presque jamais l'appel de paiement, elle est dans les cas de bord : commande annulée après reversement, vendeur au solde insuffisant, litige ouvert deux mois plus tard. Nous cadrons le périmètre en amont et donnons une estimation ferme avant de commencer.
Ce sont deux produits qui répondent à deux questions différentes, et beaucoup de projets ont besoin des deux. Connect répond à « comment faire circuler l'argent entre plusieurs parties », c'est le produit des places de marché et des plateformes qui prélèvent une commission. Billing répond à « comment facturer dans le temps », c'est le produit des abonnements, des paliers, des essais gratuits et du prorata. Une plateforme SaaS qui permet à ses clients d'encaisser leurs propres clients tout en leur facturant un abonnement mensuel utilise les deux, avec un modèle de données qui doit être pensé pour les deux dès le cadrage.
En traitant le handler comme un accusé de réception, pas comme un traitement métier. Il vérifie la signature à partir du corps brut de la requête, enregistre l'événement, répond immédiatement, et laisse une file faire le travail. Deux raisons à cela. La première est que certains événements sont bloquants : sans réponse positive, la finalisation des factures en encaissement automatique est repoussée jusqu'à 72 heures. La seconde est que les doublons sont attendus et l'ordre d'arrivée non garanti, donc la déduplication et la relecture de l'objet concerné sont indispensables. Les redirections sur l'URL de réception comptent comme des échecs.
Oui, et c'est une demande fréquente. Pennylane rapproche nativement les encaissements Stripe à partir de la référence de paiement, ce qui supprime le lettrage manuel sur ce flux. Pour les autres logiciels comptables, nous construisons le flux qui pousse les encaissements, les commissions et les reversements avec le bon découpage, puis un contrôle de cohérence périodique entre ce que Stripe expose et ce que votre comptabilité enregistre, avec alerte sur écart plutôt que correction silencieuse. Une écriture comptable ne se répare pas dans le dos du comptable.
Un projet d'intégration Stripe ?
Parlons-en. 30 minutes pour cadrer votre modèle de flux, vérifier ce que l'API permet vraiment et vous dire franchement ce qui est faisable.
Parler de mon projet Stripe