Transformez vos e-mails en revenus avec Brew.
Connectez Stripe à Brew, choisissez les bons événements de facturation et vérifiez l’état actuel de la facture ou de l’abonnement avant les rappels ultérieurs.
Stripe émet des événements quand les abonnements, les factures et les paiements changent. Ces événements peuvent lancer des e-mails utiles, mais chaque message a toujours besoin d’un destinataire, d’un objectif et d’une règle définis pour décider s’il arrive au bon moment.
L’intégration Stripe de Brew gère la connexion OAuth et la configuration du webhook. Ce guide explique comment concevoir le programme d’e-mails qui en découle. Pour les séquences qui partent d’événements produit plutôt que de la facturation, consultez Automatisation e-mail par l’IA.
| Objectif | Événement candidat | À vérifier avant l’envoi |
|---|---|---|
| Accueillir un abonné | customer.subscription.created |
Éviter un doublon avec la bienvenue déclenchée par Checkout |
| Annoncer la fin d’un essai | customer.subscription.trial_will_end |
Date de fin réelle et prélèvement éventuel |
| Signaler l’échec du paiement d’une facture | invoice.payment_failed |
Facture actuelle, lien de facturation, avis déjà envoyés par Stripe |
| Expliquer un changement d’offre | customer.subscription.updated |
Champs modifiés et portée réelle du changement |
| Accuser réception d’une résiliation | customer.subscription.deleted |
Date de fin de l’accès et demande du client |
| Expliquer un remboursement | refund.created |
Champs propres au remboursement disponibles dans l’événement |
Appuyez-vous sur la référence des événements Stripe et sur le schéma du déclencheur Brew sélectionné. Une mise à jour d’abonnement peut correspondre à plusieurs types de changements : n’envoyez pas un e-mail de changement d’offre à chaque mise à jour sans en vérifier les données.
Autorisez Stripe depuis la page Intégrations de Brew. Brew enregistre le webhook et crée les déclencheurs pris en charge. Il n’existe pas d’interrupteur pour activer ou désactiver un événement. Seules les automatisations actives associées à l’événement s’exécutent.
Utilisez « Synchroniser les clients Stripe » si vous devez importer vos contacts existants. Importer un contact de facturation ne vaut pas consentement marketing. Le paramètre « Synchroniser le nom complet », propre à chaque événement, contrôle la mise à jour des noms, pas le déclenchement des e-mails.
Créez la première automatisation en brouillon, examinez l’e-mail généré et testez-la avec des destinataires que vous contrôlez avant de la publier. Suivez le guide de configuration de Stripe pour le détail de la connexion ; Brew connecte des comptes Stripe en production, et les événements du mode test ne lancent aucune automatisation.
Un avis d’échec immédiat peut partir de invoice.payment_failed. Expliquez ce qui s’est passé et renvoyez vers votre propre page de facturation. Ne promettez pas que Brew retentera le paiement : c’est Stripe qui gère les opérations de paiement.
Pour un rappel trois jours plus tard, faites programmer par votre application une vérification du statut de la facture. Si la facture reste impayée et que le client est toujours éligible, déclenchez un événement de rappel Brew distinct. Si le paiement a été régularisé, arrêtez-vous là sans le déclencher.
Après une étape d’attente, les champs de l’événement contiennent toujours le payload d’origine. Une condition sur contact.stripe_subscription_status lit la valeur actuelle du champ sur le contact Brew au moment où ce nœud s’exécute. Elle n’interroge pas Stripe et ne prouve pas que cette facture précise a été payée. Un événement invoice.paid ultérieur n’annule pas automatiquement l’exécution précédente. Mettre à jour un moyen de paiement ne prouve pas non plus que le paiement a eu lieu.
Testez trois cas : un paiement régularisé avant la vérification du rappel, une facture qui reste impayée et une tâche relancée. Réutilisez la même clé d’idempotence pour un même événement logique, dans la fenêtre de nouvelle tentative documentée.
Brew peut synchroniser des champs de facturation sur les contacts, dont le statut et l’offre de l’abonnement. Les payloads d’événement et les champs de contact sont deux sources différentes. Lisez le schéma du déclencheur avant d’utiliser amount, currency, invoiceNumber, previousPlan, newPlan ou failureMessage : tous les événements ne fournissent pas chacun de ces champs.
Les identifiants des objets Stripe sont absents du payload d’automatisation. Ne construisez pas d’URL de portail client à partir d’un ID de facture ou d’abonnement supposé. Utilisez la page de facturation authentifiée de votre application, ou un lien fourni délibérément dans un événement personnalisé. Suivez le guide des balises de fusion.
Passez en revue les paramètres des e-mails clients de Stripe. Décidez quel système envoie les reçus, les avis d’échec de paiement et les rappels. Activer une automatisation Brew ne désactive pas les e-mails de Stripe.
Ne glissez pas de contenu promotionnel dans un avis lié au compte sans avoir vérifié la finalité du message et les autorisations. Les rappels marketing exigent le consentement correspondant et la gestion des désabonnements.
Vérifiez que l’événement apparaît dans Brew, que l’automatisation associée est active et que son historique d’exécution montre le destinataire et le résultat attendus. Examinez ensuite l’e-mail reçu et le lien de facturation. Si un événement est arrivé mais qu’aucun message n’est parti, contrôlez les filtres, les exclusions et l’état du domaine d’envoi avant de conclure à une défaillance du webhook.
Commencez par un événement et un e-mail testé. N’ajoutez de rappels ultérieurs que lorsque les vérifications de l’état actuel et le comportement en cas de nouvelle tentative sont couverts par les tests de votre application.
