Prévenir les clients d’un paiement échoué dans Intercom
Utiliser Intercom pour prévenir les clients d’un paiement d’abonnement échoué : données de l’appli Stripe, messages sur événement, bannières et réponses.
Par Florian
Quand un renouvellement échoue, le client ne le sait généralement pas. Il le découvre quand l’accès s’arrête, ou quand un email de relance atterrit dans l’onglet promotions. Si vous utilisez déjà Intercom pour parler à vos clients dans votre produit, il peut porter le message de paiement échoué là où le client se trouve vraiment : dans l’appli.
Ce guide montre ce qu’Intercom peut faire avec les données d’échec de paiement, comment mettre en place un message dans l’appli, et comment traiter les conversations de support qui suivent. Il s’appuie sur le centre d’aide d’Intercom pour l’appli Stripe, les messages déclenchés par événement, les bannières et les macros, et sur la référence de la Data Events API (tous consultés en novembre 2026).
Intercom ne relance pas les paiements
Commencez par ce qu’Intercom n’est pas. Il ne prélève pas les cartes, ne relance pas les paiements et ne met pas à jour les moyens de paiement. Tout cela reste dans votre système de facturation : sur Stripe, les nouvelles tentatives viennent des Smart Retries ou de votre propre calendrier, et la mise à jour de carte se fait sur une page hébergée par Stripe ou dans votre appli. Le rôle d’Intercom est la communication : prévenir le client, au bon moment, avec un lien qui règle le problème. Pour le côté facturation, voir comment récupérer les paiements échoués sur Stripe.
Faire entrer les données d’échec de paiement dans Intercom
Option 1 : l’appli Stripe
L’appli Stripe d’Intercom importe les données des clients Stripe comme attributs sur les utilisateurs Intercom. Parmi les attributs documentés :
| Attribut | Ce qu’il contient |
|---|---|
stripe_delinquent |
Le statut d’impayé de Stripe (true ou false) |
stripe_subscription_status |
Le statut de l’abonnement |
stripe_card_expires_at |
La date d’expiration de la carte enregistrée |
stripe_card_brand |
La marque de la carte |
L’appli envoie aussi des événements à Intercom, dont charge_failed, charged, invoice_created et deleted_subscription. Contraintes tirées du même article : seules les données du mode live sont synchronisées (le mode test n’est pas pris en charge), l’appli demande un compte Stripe payant, et elle est disponible sur les offres Essential, Advanced et Expert d’Intercom. Par défaut, un utilisateur Intercom n’est créé à partir d’un client Stripe que si le client Stripe a à la fois un email et un identifiant utilisateur dans ses métadonnées.
Option 2 : envoyer votre propre événement
Si vous n’êtes pas sur Stripe, ou si vous voulez plus de contrôle, envoyez vous-même un événement quand votre système de facturation signale un échec. La Data Events API prend un POST sur /events avec un event_name, un horodatage Unix created_at, un identifiant utilisateur (user_id ou email) et des metadata facultatives. Le JSON imbriqué n’est pas pris en charge dans les métadonnées, et la documentation de l’API limite le nombre de clés de métadonnées suivies par événement : restez à plat et concis, par exemple un montant, un identifiant de facture et l’URL de la page de mise à jour de carte.
Un événement personnalisé vous permet de le nommer clairement (payment_failed) et d’y joindre le lien de mise à jour, ce que les événements de l’appli Stripe ne font pas pour vous.
Choisir le type de message
Les bannières : visibles jusqu’à ce que le problème soit réglé
Une bannière se place en haut de la page. Si vous masquez le bouton de fermeture, Intercom continue de l’afficher jusqu’à ce que l’utilisateur ne corresponde plus aux règles d’audience ou réalise l’action configurée. Cela convient bien à un paiement échoué : ciblez les utilisateurs pour lesquels stripe_delinquent est true (ou votre propre attribut), et la bannière disparaît d’elle-même une fois le paiement passé et l’attribut revenu à false.
Limites tirées de la documentation d’Intercom :
- Les bannières n’acceptent que des audiences dynamiques.
- Elles ne sont délivrées que quand l’utilisateur est vu en ligne dans le Messenger.
- Elles ne fonctionnent pas nativement dans les applis iOS ou Android.
- Si plusieurs bannières se chevauchent, elles s’affichent dans l’ordre de leur mise en ligne, et une bannière non fermable placée en premier bloque les suivantes.
Chats ou posts déclenchés par événement : une fois par échec
Pour envoyer un message à chaque échec, utilisez un message déclenché par événement. Intercom documente plusieurs conditions :
- Il demande l’add-on Proactive Support Plus.
- Le message doit utiliser une audience dynamique, et vous ne pouvez ajouter qu’une seule règle basée sur un événement.
- Les événements survenus avant la mise en ligne du message ne le déclenchent pas.
- Si l’événement arrive en dehors du calendrier du message, le message n’est pas envoyé pour cet événement ; il n’est pas mis en attente jusqu’à l’ouverture du calendrier.
- Les métadonnées d’événement ne peuvent pas être utilisées dans des messages à l’intérieur d’une Series. Intercom suggère de construire d’abord le message seul, puis de le copier dans la Series.
L’email : toujours nécessaire
Les messages dans l’appli n’atteignent que les clients qui se connectent. Un client qui a cessé d’utiliser le produit a besoin d’un email, et c’est souvent celui qui compte le plus. Gardez une séquence d’emails de relance depuis votre système de facturation ou un outil dédié. Des exemples prêts à l’emploi se trouvent dans modèles d’emails de relance.
Rédiger le message
Le message dans l’appli doit être court et précis :
Votre dernier paiement n’est pas passé. Mettez à jour votre moyen de paiement pour garder votre offre [nom de l’offre] active. [Mettre à jour le moyen de paiement]
Des règles à suivre :
- Une seule action. Un seul bouton vers la page de mise à jour de carte. N’envoyez pas les clients vers une page de réglages générale.
- Pas de reproche, pas de raison. N’affichez pas la raison du refus. Pour certains codes, comme les cartes perdues ou volées, Stripe vous demande de présenter le refus comme générique ; voir les codes de refus Stripe expliqués.
- Dites ce qui se passe ensuite, honnêtement : quand vous réessaierez, ou quand l’accès changera. N’inventez pas une échéance que vous n’appliquerez pas.
- Montrez-le à la bonne personne. Dans les produits B2B, la personne qui voit la bannière n’est pas forcément celle qui paie. Ciblez les administrateurs ou les contacts de facturation si vous avez cet attribut.
Traiter les réponses
Les messages de paiement échoué créent des conversations : « j’ai mis à jour ma carte, pourquoi ça échoue encore ? », « puis-je payer par virement ? », « annulez, c’est tout ». Préparez des macros pour chacune. Les actions des macros peuvent ajouter des tags et assigner à une équipe : taguez donc ces conversations payment-failed pour en mesurer le volume.
Avant de répondre, consultez le panneau de l’appli Stripe, qui affiche les abonnements du client et ses trois paiements les plus récents à côté de la conversation. Quelques situations courantes :
| Le client dit | À vérifier | Réponse |
|---|---|---|
| « J’ai mis à jour ma carte » | Un nouveau moyen de paiement a-t-il été ajouté, et la facture a-t-elle été relancée ? | Si elle n’a pas encore été relancée, expliquer quand ; ou relancer depuis votre système de facturation |
| « Ma banque dit que tout va bien » | Le code de refus | Pour les refus génériques, suggérer une autre carte ou de rappeler la banque |
| « Annulez, c’est tout » | S’il le pense vraiment | Annuler s’il confirme ; un paiement échoué n’est pas une raison de rendre l’annulation plus difficile |
| « J’ai été prélevé deux fois » | Historique des paiements | Expliquer ou rembourser rapidement ; c’est ainsi que commencent les litiges |
Erreurs fréquentes
- Utiliser la bannière comme seul canal. Les clients qui ne se connectent pas ne la voient jamais.
- Laisser la bannière après la récupération. Utilisez un attribut qui revient automatiquement à sa valeur, pas une liste manuelle.
- Tester avec le mode test de Stripe. L’appli Stripe ignore les données de test : testez plutôt avec un événement personnalisé sur un utilisateur de test.
- Envoyer un message pendant une nouvelle tentative sur le point de réussir. Si votre système de facturation réessaie en quelques heures pour certains refus, un délai avant le premier message peut éviter une inquiétude inutile.
Le faire avec NoChurn
NoChurn gère le côté facturation qu’Intercom ne couvre pas : des relances intelligentes calées sur la raison du refus et sur les jours de paie probables, des emails de récupération rédigés par l’IA que vous relisez, et une page hébergée de mise à jour de carte que vous pouvez lier depuis une bannière ou une macro Intercom. Son connecteur Intercom est en lecture seule : il n’envoie donc pas de messages Intercom à votre place ; vos bannières et macros restent dans Intercom. Il lit les conversations, rattachées aux clients par email (les correspondances douteuses sont suggérées, jamais fusionnées automatiquement), et les utilise dans le churn score. Voir NoChurn + Intercom.