Gérer les cartes qui expirent dans Zuora
Éviter que des cartes expirées fassent échouer les renouvellements Zuora : Payment Method Updater, updaters temps réel, alertes à 15 et 30 jours.
Par Florian
Les cartes expirées sont les paiements échoués les plus prévisibles qui soient. Vous connaissez la date d’expiration des mois à l’avance, et pourtant beaucoup de renouvellements échouent encore sur des cartes expirées le mois dernier. Zuora vous donne deux outils complémentaires contre cela : un updater automatique qui récupère les nouvelles données de carte auprès des réseaux, et des événements d’expiration qui vous permettent de solliciter le client avant que quoi que ce soit échoue.
Ce guide explique les deux, puis vous donne une configuration à appliquer. Il s’en tient à la documentation de Zuora : Payment Method Updater, la présentation de Payment Method Updater, Set up Chase Payment Method Updater, Support for Real Time Account Updater (Adyen), Standard events for Zuora Payments et How do I allow customers to modify their stored payment methods? (toutes consultées en novembre 2026). Pour le contexte général sur les updaters et les network tokens, voir network tokens et card account updaters.
Pourquoi les cartes expirées échouent encore
Les banques remplacent les cartes pour de nombreuses raisons : expiration, perte, fraude, nouveau design de carte. Le client reçoit une nouvelle carte et met à jour les endroits dont il se souvient ; les abonnements souscrits il y a longtemps ne sont pas sur la liste. Quand le renouvellement passe sur l’ancienne carte, il est refusé. Si personne n’intervient, un client qui n’avait jamais voulu partir churne.
Il y a deux façons de corriger cela :
- Obtenir les nouvelles données auprès du réseau, sans impliquer le client. C’est ce que font les services d’account updater.
- Demander au client de mettre à jour sa carte, idéalement avant que l’ancienne expire.
Il vous faut les deux, car les updaters ne couvrent que les banques émettrices participantes et certains types de cartes.
Payment Method Updater (par lots)
Le Payment Method Updater (PMU) de Zuora envoie les données de carte par lots aux services d’updater des réseaux de cartes et réécrit les résultats dans Zuora. D’après la documentation PMU et sa présentation :
- Il couvre Visa, Mastercard et American Express, via les services Visa Account Updater, Mastercard Automatic Billing Updater et American Express Card Refresher.
- Il tourne avant chaque bill cycle day, pour que les données mises à jour soient en place quand le payment run prélève la carte.
- Les résultats peuvent inclure un nouveau numéro de carte (Zuora l’enregistre comme nouveau moyen de paiement par défaut), une nouvelle date d’expiration, ou un indicateur de compte clôturé. Les cartes marquées clôturées ne sont plus utilisées pour traiter des paiements.
- Le service prend généralement 2 à 5 jours, car l’updater de chaque réseau suit son propre calendrier.
Passerelles prises en charge
Le PMU se configure par type de passerelle. La doc de Zuora liste la prise en charge du PMU pour des passerelles dont Adyen, BlueSnap, Chase, Checkout.com, CyberSource, First Data, Merchant e-Solutions, Vantiv et Worldpay, et indique Global Payments comme non pris en charge. Certains updaters (CyberSource, et l’updater American Express de Zuora) fonctionnent sans contrat distinct de traitement des paiements avec cette passerelle ; les autres exigent que vous traitiez aussi vos paiements via elle. Un updater couvre tous les moyens de paiement d’un type de passerelle ; la mise à jour d’instances de passerelle précises n’est pas prise en charge.
Caler le lot dans le temps
Vous configurez combien de jours avant le bill cycle day le service démarre. Le bon délai dépend de la passerelle : pour Chase, Zuora recommande 10 jours, sous Settings, Payments, Set Up Payment Method Updater (configuration Chase). Démarrer trop tard veut dire que la mise à jour arrive après que le payment run a déjà été refusé.
Quand des cartes ne peuvent pas être envoyées
Le guide de dépannage de Zuora indique que les données de carte invalides apparaissent avec un statut Warning et un type de mise à jour NotApprovedForSubmitted, que vous pouvez exporter depuis Reporting, Data Sources. Ces cartes ne seront jamais mises à jour automatiquement : elles passent donc directement au contact client.
Les updaters en temps réel
Certaines passerelles mettent à jour les données de carte au moment du paiement plutôt que par lots. Zuora documente la prise en charge d’un real-time account updater pour Adyen (Adyen RTAU), limitée aux cartes Visa et Mastercard émises aux États-Unis et au Canada, et une page distincte pour un real-time account updater Stripe. Vérifiez les conditions sur ces pages pour votre compte avant de compter dessus.
Les événements d’expiration : demander avant l’échec
Les événements standard pour les paiements de Zuora incluent deux alertes d’expiration liées à l’événement Payment Method Expiration :
| Événement | Quand il se déclenche |
|---|---|
| 30 Day Warning | Le moyen de paiement par défaut du compte expire dans les 30 jours |
| 15 Day Warning | Le moyen de paiement par défaut du compte expire dans les 15 jours |
Détails tirés de la doc de Zuora :
- La date d’expiration d’une carte est le dernier jour de son mois d’expiration.
- Une tâche planifiée évalue ces événements chaque jour (à 5 h 15 UTC pour les tenants EU et US Cloud Data Center 1, 5 h 15 heure de Los Angeles pour US Cloud Data Center 2).
- Les alertes partent quand même pour un moyen de paiement clôturé ; Zuora conseille de ne pas laisser un moyen clôturé comme moyen par défaut du compte.
- Elles ne concernent que le moyen de paiement par défaut.
Chaque alerte peut être livrée par email ou sous forme de callout vers votre système. Comme le PMU peut rafraîchir la carte entre-temps, faites revérifier l’expiration sur le compte par votre gestionnaire d’email ou de callout avant d’envoyer quoi que ce soit au client.
Donner au client un moyen de mettre à jour
Quand l’updater ne peut pas aider, le client doit saisir une nouvelle carte. Le guide de Zuora sur la modification des moyens de paiement enregistrés décrit les options :
- La page de paiement hébergée (Payment Pages 2.0), chargée avec l’ID du moyen de paiement existant (
pmId) pour que le client puisse mettre à jour ses informations de carte. Cela garde les données de carte hors de vos serveurs. - L’API Update a payment method, que Zuora déconseille pour les données de carte au profit de Payment Pages 2.0.
- L’interface Zuora, pour les agents du support.
Faites pointer vos emails d’expiration directement vers une page qui charge le formulaire de paiement hébergé pour ce compte. Une fois la nouvelle carte enregistrée comme moyen par défaut, le payment run suivant l’utilise.
Un plan de configuration
- Activez le PMU pour chaque type de passerelle que vous utilisez, avec un délai adapté à la passerelle (10 jours pour Chase, selon Zuora).
- Vérifiez les options d’updater en temps réel si vous traitez via Adyen ou Stripe.
- Activez les alertes à 30 et 15 jours avec un callout vers votre système.
- Revérifiez avant d’envoyer. Si le PMU a déjà mis à jour la carte, sautez l’email.
- Envoyez l’email à 30 jours avec un lien vers la page de paiement hébergée. Restez bref : quelle carte, quand elle expire, un bouton.
- Envoyez le rappel à 15 jours seulement si la carte n’a toujours pas changé.
- Exportez chaque mois les cartes NotApprovedForSubmitted et contactez directement ces clients.
- Gardez un filet pour les paiements échoués. Certaines cartes échoueront quand même ; voir comment récupérer les paiements échoués dans Zuora.
Faire tout cela avec NoChurn
Le Payment Method Updater, les événements d’expiration et les payment runs de Zuora restent dans Zuora. NoChurn lit le type de moyen de paiement et la date d’expiration depuis Zuora et ajoute des emails rédigés par l’IA que vous relisez avant l’envoi, avec un lien pour que le client mette à jour son moyen de paiement, plus des emails de récupération quand un renouvellement échoue malgré tout. Chaque client reçoit aussi un score de churn de 0 à 100. Voir NoChurn + Zuora.