Connecter Stripe à n8n : clé API, node, trigger et webhooks (guide complet)

Stripe encaisse vos paiements, mais ne prévient pas votre comptable, ne met pas à jour votre CRM et n'envoie pas d'email de bienvenue au nouvel abonné. Chaque événement de paiement qui reste enfermé dans le Dashboard, c'est une ressaisie manuelle quelque part. Ce guide couvre la récupération de la clé API, la credential n8n, le node Stripe et ses limites, le Stripe Trigger pour réagir en temps réel, et le node HTTP Request pour tout le reste.

Pourquoi brancher n8n sur Stripe

Trois motifs reviennent chez les PME : la comptabilité (chaque facture payée doit finir dans l'outil compta sans copier-coller), le cycle de vie client (nouvel abonné à créer dans le CRM, abonnement annulé à analyser) et la réactivité (un paiement échoué relancé dans l'heure vaut mieux qu'un export hebdomadaire).

C'est le terrain où l'automatisation rend le plus : l'étude de Mary Lacity et Leslie Willcocks « A New Approach to Automating Services », publiée en 2016 dans la MIT Sloan Management Review (voir sur Google Scholar), a documenté des retours sur investissement importants dès la première année sur l'automatisation de processus de service répétitifs — le profil exact d'un flux de facturation Stripe.

Récupérer sa clé API Stripe

Direction le Dashboard Stripe, menu Développeurs → Clés API. Deux décisions :

Mode test ou mode live. Stripe sépare strictement les deux environnements : les clés de test (sk_test_…, rk_test_…) ne voient que les données de test, les clés live que les vraies. Construisez toujours votre workflow avec une clé de test — les cartes de test Stripe (4242 4242 4242 4242…) simulent paiements réussis et échoués sans risque.

Clé secrète complète ou clé restreinte. La clé secrète (sk_) donne un accès total : lecture, écriture, remboursements, virements. Pour n8n, préférez une clé restreinte (rk_), créée via « Créer une clé restreinte » : vous cochez ressource par ressource les permissions nécessaires (Customers : lecture, Coupons : écriture…). Principe du moindre privilège : si la clé fuit, le rayon d'action est borné, et vous la révoquez sans toucher aux autres intégrations. Créez une clé par usage plutôt qu'une clé unique partagée.

Créer la credential dans n8n

Dans n8n : Credentials → Add credential → Stripe API, collez la clé dans le champ Secret Key, testez, sauvegardez. La clé est alors chiffrée dans la base n8n et référencée par les nodes sans jamais apparaître en clair. Ne la collez jamais dans un paramètre de node ou une expression : les réflexes de notre guide de sécurisation des credentials API — une credential par environnement, rotation, pas de clé dans les logs — s'appliquent d'autant plus que cette clé touche à l'argent.

Le node Stripe : ce qu'il couvre (et ce qu'il ne couvre pas)

Le node Stripe natif expose les ressources suivantes :

• Customer : Create, Get, Get Many, Update, Delete — la base de toute synchronisation CRM ;
• Charge : Create, Get, Get Many, Update — consulter et créer des paiements ;
• Coupon : Create, Get Many — générer des codes de réduction à la volée ;
• Customer Card et Source : les moyens de paiement d'un client ;
• Balance : Get — le solde du compte, utile en reporting quotidien ;
• Token et Meter Event : jetons de paiement et événements de facturation à l'usage.

Notez ce qui manque : les factures (invoices), les abonnements (subscriptions), les sessions Checkout, les payment links et les remboursements ne sont pas couverts par le node natif. Pas bloquant : le node HTTP Request comble le trou, on y revient plus bas.

Le Stripe Trigger : réagir aux événements en temps réel

Le node Stripe Trigger est la moitié la plus intéressante de l'intégration : à l'activation du workflow, il enregistre lui-même un endpoint webhook dans votre compte Stripe, abonné aux événements cochés — rien à configurer dans le Dashboard. Parmi les plus utiles :

• checkout.session.completed : un paiement finalisé via Stripe Checkout — le point d'entrée type d'un onboarding automatisé ;
• invoice.payment_succeeded et invoice.payment_failed : facture d'abonnement payée, ou prélèvement échoué ;
• customer.subscription.created / updated / deleted : tout le cycle de vie de l'abonnement, changements de plan et annulations compris ;
• charge.refunded, customer.created, ou * pour tout recevoir (à réserver au debug : en production, abonnez-vous au strict nécessaire).

Deux points d'attention. Stripe réessaie la livraison d'un webhook resté sans réponse rapide : le même événement peut arriver deux fois, d'où l'intérêt d'une clé d'idempotence basée sur l'event.id avant toute action non répétable. Et chaque livraison est signée : ne traitez jamais un événement de paiement sans vérifier sa signature — principe détaillé dans notre guide de sécurisation des webhooks n8n.

HTTP Request : l'API Stripe complète, même credential

Pour tout ce que le node natif ignore — créer un abonnement, lister les factures, générer un payment link — le node HTTP Request attaque directement https://api.stripe.com/v1/…. Deux authentifications possibles : l'option Predefined Credential Type qui réutilise la credential Stripe existante, ou un en-tête Authorization: Bearer sk_… en credential Header Auth. Subtilité : l'API Stripe attend des corps en application/x-www-form-urlencoded, pas en JSON — réglez le Body Content Type sur « Form Urlencoded ». Exemple : POST /v1/payment_links avec line_items[0][price]=price_xxx et line_items[0][quantity]=1 renvoie une URL de paiement prête à envoyer.

Trois workflows Stripe qui rapportent vite

• Facture payée → comptabilité : Stripe Trigger invoice.payment_succeeded → ligne ajoutée dans un Google Sheets de suivi → génération du PDF de reçu → archivage Drive.
• Nouvel abonné → CRM + bienvenue : Stripe Trigger checkout.session.completed → upsert du contact via le pattern de notre guide de synchronisation HubSpot/Pipedrive → email de bienvenue → notification Slack.
• Paiement échoué → relance intelligente : événements à écouter, anti-doublons, rédaction de la relance par IA et journalisation sont couverts pas à pas dans notre guide n8n + Stripe : automatiser les relances de paiement échoué.

Vous encaissez via une boutique en ligne ? Ces patterns se combinent avec notre guide de connexion Shopify à n8n.

Sécurité : trois règles non négociables

Vérifier la signature des webhooks. Une URL de webhook peut fuiter ; la signature garantit que l'événement vient bien de Stripe et n'a pas été altéré. Un faux invoice.payment_succeeded accepté sans vérification, c'est potentiellement un accès livré sans paiement.

Ne jamais logger ni stocker de données de carte. Vos workflows ne doivent manipuler que les objets Stripe (IDs client, montants, statuts), jamais de numéros de carte : c'est le fondement de la conformité PCI DSS déléguée à Stripe. Même les protocoles les plus déployés ont des failles : l'étude « Chip and PIN is Broken » de Murdoch, Drimer, Anderson et Bond, primée à l'IEEE Symposium on Security and Privacy 2010 (voir sur Google Scholar), démontrait une faille du protocole EMV permettant de valider un paiement sans connaître le PIN. La sécurité des paiements est un métier : laissez les données sensibles chez Stripe et ne faites transiter dans n8n que le minimum.

Séparer test et live. Deux credentials distinctes, nommées sans ambiguïté, et une vérification avant chaque activation : créer un coupon de test en live arrive plus souvent qu'on ne croit.

En résumé

Connecter Stripe à n8n tient en quatre briques : une clé API restreinte testée en mode test avant le live, une credential chiffrée dans n8n, le node Stripe pour les clients, paiements et coupons, et le Stripe Trigger qui crée lui-même ses webhooks — le node HTTP Request comblant le reste de l'API. Chaque euro encaissé devient alors un événement que vos workflows exploitent : comptabilité, CRM, relances. Pour tracer tout ce qui touche à l'argent, le Pack Conformité & Audit (149 €) fournit la piste d'audit Supabase et les patterns de relance journalisée qui complètent naturellement cette intégration.