Comment récupérer les paiements échoués dans Zuora

Zuora vous donne beaucoup de contrôle sur l’encaissement, ce qui veut aussi dire beaucoup de réglages à bien faire. Les paiements échoués dans Zuora touchent au moins quatre domaines : les payment runs, les règles de nouvelles tentatives, les notifications, et la façon dont les clients mettent à jour leur moyen de paiement. Ce guide passe chacun en revue et se termine par un plan de configuration pratique.

Il s’en tient à la documentation de Zuora : Payment runs, Configure payment retry rules, Payment Retry, Configurable Payment Retry, Payment attempts and retry rules, Standard events for Zuora Payments et How do I allow customers to modify their stored payment methods? (toutes consultées en novembre 2026). Les noms de champs peuvent varier selon la version de votre tenant : vérifiez-les dans vos propres réglages.

Étape 1 : comprendre les payment runs

Dans Zuora, l’encaissement automatique passe par les payment runs. Un payment run encaisse les factures ouvertes avec des moyens de paiement électroniques comme les cartes ou l’ACH. D’après la documentation des payment runs :

• Un run peut traiter jusqu’à 200 000 factures.
• Il existe des runs ad hoc, que vous lancez à la main, et des runs récurrents, qui s’exécutent selon un calendrier quotidien, hebdomadaire ou mensuel.
• Les runs n’encaissent que sur les comptes où l’auto-pay est activé. L’auto-pay se règle sur chaque compte client : un compte sans auto-pay ne sera jamais prélevé par un run, et ses factures resteront simplement ouvertes.
• Quand une facture est en cours de traitement par un paiement, elle est verrouillée, et tout autre paiement sur cette facture échoue. Zuora recommande de décider quelles factures sont encaissées par quelle méthode (payment run, payment page, API) pour éviter les collisions.

La première chose à vérifier quand « Zuora ne retente pas », ce n’est souvent pas du tout les nouvelles tentatives : c’est de savoir si l’auto-pay est activé sur le compte et s’il existe un moyen de paiement électronique par défaut.

Étape 2 : choisir votre mécanisme de nouvelles tentatives

Zuora a deux façons de retenter un paiement électronique échoué. Zuora déconseille de faire tourner les deux en même temps.

Les règles de nouvelles tentatives au niveau du tenant

Les règles intégrées, décrites dans Configure payment retry rules, s’appliquent par défaut aux traitements de paiement échoués quand le payment retry est activé dans votre tenant. Vous réglez :

• le nombre maximal de fois consécutives qu’un moyen de paiement en échec est retenté ;
• un intervalle minimal depuis la dernière tentative échouée (par exemple, avec 8 heures, aucune nouvelle tentative automatique n’a lieu si le dernier échec date de moins de 8 heures) ;
• une période pendant laquelle les paiements ne sont pas retentés.

Vous pouvez les remplacer par moyen de paiement. Ces règles sont simples et prévisibles, mais les mêmes règles s’appliquent à chaque refus, quel que soit son motif.

Configurable Payment Retry (CPR)

Configurable Payment Retry est l’option plus souple de Zuora. Elle permet de régler la logique de nouvelles tentatives par groupe de clients et par code de réponse de la passerelle, en associant les codes à des catégories comme refus définitifs, moyens et temporaires. Les points clés de la doc :

Réglage ou comportement	Ce que documente Zuora
Fenêtre de tentatives	Jours entre l’entrée en nouvelle tentative et la dernière tentative, 90 jours maximum
Nombre de tentatives	20 maximum ; le payment run fait la première tentative, CPR fait le reste
Smart Retry	Un modèle de machine learning facultatif qui choisit les moments des tentatives à partir des caractéristiques de l’abonné et de la transaction
Refus définitifs	Une option Stop Retry On Hard Declines met fin au cycle sur un refus définitif
Moment	Les tentatives s’exécutent par lots à l’heure pile, elles ne peuvent donc pas être plus fréquentes qu’une par heure
Moyens de paiement	Paiements par carte seulement, pas les prélèvements comme l’ACH ou le SEPA
Changements de règles	S’appliquent aux tentatives futures seulement ; les cycles terminés ne sont pas relancés

Deux comportements tirés des bonnes pratiques CPR sont faciles à rater :

• CPR désactive l’auto-pay pendant un cycle de nouvelles tentatives, pour que le payment run habituel ne prélève pas de nouveau la facture. D’après la page des réglages auto-pay, ce qui change dépend du niveau de nouvelle tentative : au niveau facture, seul l’indicateur auto-pay de la facture est désactivé ; au niveau compte, l’auto-pay du compte est désactivé et réactivé seulement une fois le paiement encaissé. Zuora recommande le niveau facture, qui garde le compte éligible aux futurs payment runs. Une ancienne page de bonnes pratiques décrit les deux indicateurs passés à false : vérifiez quel niveau utilise votre tenant.
• Pour arrêter immédiatement les tentatives (par exemple, le client a payé par virement), vous terminez le cycle à la main, ce que vous pouvez faire via les API CPR.

Si vous ne savez pas comment classer un code de réponse, Zuora suggère de l’associer à un refus temporaire et de surveiller les résultats. Zuora documente aussi une façon de tester Smart Retry face à votre logique existante avant de tout basculer.

Étape 3 : prévenir le client, avec notifications et callouts

Les nouvelles tentatives récupèrent les refus temporaires. Les cartes expirées, remplacées ou bloquées demandent l’intervention du client. Les événements standard pour les paiements de Zuora vous donnent les points d’accroche :

• Payment Declined : se déclenche quand la passerelle refuse un paiement électronique. Un réglage « Sequence of failed attempt » détermine à quel échec consécutif la notification part ; il est comparé au NumConsecutiveFailures du moyen de paiement et vaut 1 par défaut. Les paiements externes ne déclenchent pas ces notifications.
• Alertes d’expiration de carte : des événements 15 et 30 jours avant l’expiration de la carte par défaut (la date d’expiration est le dernier jour du mois d’expiration). Ils permettent de demander une nouvelle carte avant que quoi que ce soit échoue.
• Payment Method Updated : se déclenche quand le moyen de paiement par défaut change, ce qui est votre signal pour arrêter les rappels.

Chaque notification peut être livrée par email ou sous forme de callout, une requête HTTP vers votre endpoint, configurée dans la définition de la notification. Utilisez les callouts pour mettre à jour votre propre application (bandeau, accès) et déclencher les messages que vous gérez hors de Zuora. Zuora Workflow peut aussi réagir à ces événements et envoyer des emails à partir de modèles ou appeler des API externes si vous préférez garder la logique dans Zuora.

Un plan de notifications simple :

Déclencheur	Message	Canal
La carte expire dans 30 jours	« Votre carte expire bientôt, mettez-la à jour ici »	Email
Premier paiement refusé	« Votre paiement n’est pas passé », avec le lien de mise à jour	Email et dans l’application
Troisième échec consécutif	Rappel avec la date à laquelle l’accès est affecté	Email
Moyen de paiement mis à jour	Confirmation, plus de rappels	Email

Étape 4 : laisser le client mettre à jour son moyen de paiement

Le lien de mise à jour de ces emails doit mener quelque part. Zuora documente trois façons de modifier un moyen de paiement enregistré dans son guide sur la modification des moyens de paiement enregistrés :

1. La page hébergée de moyen de paiement pour les cartes bancaires, en transmettant l’ID du moyen de paiement existant (pmId) pour que le client puisse mettre à jour ses informations de carte. C’est la voie qui garde les données de carte hors de vos serveurs ; Zuora recommande Payment Pages 2.0 plutôt que de manipuler les données de carte via l’API.
2. L’opération REST Update a payment method. La référence API de Zuora recommande fortement Payment Pages 2.0 plutôt que de l’appeler directement, et y envoyer un numéro de carte fait entrer vos propres systèmes dans le périmètre PCI.
3. L’interface Zuora, dans la section Electronic Payment Methods du compte client, pour les agents du support.

Une fois un nouveau moyen de paiement par défaut enregistré, assurez-vous que la facture ouverte est réellement encaissée, soit par le payment run suivant (vérifiez l’auto-pay, que CPR a pu désactiver), soit par un paiement immédiat. Souvenez-vous du verrou de facture : ne laissez pas une payment page et un payment run prélever la même facture en même temps.

Une check-list de récupération pour Zuora

1. Auditez l’auto-pay sur chaque compte d’abonnement actif et confirmez qu’un moyen de paiement électronique par défaut existe.
2. Choisissez un seul mécanisme de nouvelles tentatives : les règles du tenant pour la simplicité, CPR pour une logique adaptée aux refus et aux groupes de clients. Pas les deux.
3. Associez les codes de réponse dans CPR et activez Stop Retry On Hard Declines, pour qu’une carte volée ne soit pas retentée pendant des semaines.
4. Gardez une fenêtre de tentatives plus courte que la période de facturation pour les offres mensuelles.
5. Activez les alertes d’expiration de carte à 30 et 15 jours, et regardez Payment Method Updater, qui demande aux services d’updater Visa, Mastercard et American Express les nouvelles données de carte avant le bill cycle day sur les passerelles prises en charge.
6. Configurez la notification Payment Declined avec un lien vers une page de paiement hébergée, plus un callout vers votre application.
7. Encaissez après une mise à jour : confirmez que la facture est prélevée une fois une nouvelle carte enregistrée.
8. Passez en revue les refus chaque mois par code de réponse et groupe de clients.

Faire tout cela avec NoChurn

Zuora reste aux commandes de la facturation, des payment runs, des nouvelles tentatives et de votre passerelle. NoChurn se connecte via un client OAuth Zuora, importe comptes et abonnements, reçoit les notifications de Zuora et ajoute des emails de récupération rédigés par l’IA que vous relisez avant l’envoi, avec un lien pour mettre à jour le moyen de paiement. Il ajoute aussi des parcours d’annulation avec des raisons, des offres (une réduction ou un changement d’offre sur l’abonnement Zuora) et une résiliation en un clic toujours visible, des emails de reconquête à J30, J60 et J90 selon la raison de résiliation, et un score de churn de 0 à 100. Les litiges viennent de la passerelle derrière Zuora ; avec Stripe ou Braintree, NoChurn réunit les preuves et rédige une réponse que vous relisez. Voir NoChurn + Zuora.