Une exportation de clients WHMCS ne constitue pas un mandat de paiement transférable. Avant de migrer la facturation récurrente, identifiez le compte du prestataire, la référence de paiement enregistrée et l’autorisation utilisée par chaque service. Vérifiez ensuite si la destination peut utiliser ces informations ou si le client a besoin d’une nouvelle autorisation. Les données de facturation et l’autorisation de prélèvement sont des enregistrements distincts.
Ce guide aide les hébergeurs à planifier cette décision. Il ne fournit pas de script de copie de jetons ni ne promet la portabilité automatique des moyens de paiement. La fiche de préparation originale ci-dessous peut être remplie sans collecter les données brutes des cartes bancaires. Pour une migration plus complète, commencez par consulter le guide «Liste de contrôle pour la migration depuis WHMCS ».
Que représente un moyen de paiement enregistré dans WHMCS ?
Une référence de paiement enregistrée identifie une relation au sein d’une passerelle et d’un compte de prestataire spécifiques. Sa signification dépend du module. Elle peut faire référence à un client, à un moyen de paiement enregistré ou à un accord de paiement récurrent externe. Le libellé seul ne permet pas de savoir si la nouvelle plateforme pourra effectuer le prélèvement.
La documentation officielle Documentation du module Stripe pour WHMCS décrit le stockage tokenisé et les références spécifiques aux modules. Vérifiez le module que votre installation utilise réellement. Un identifiant client Stripe n’est pas un calendrier d’abonnement complet, et un calendrier n’identifie pas en soi une carte utilisable.
Certaines passerelles créent des accords récurrents en dehors de WHMCS. La page Documentation sur la gestion des abonnements WHMCS décrit les hooks de résiliation de la passerelle pour ces accords. Il s’agit d’un mécanisme différent de celui d’une application décidant quand générer une facture et demander un paiement.
Notez le nom et la version réels de la passerelle, le compte du fournisseur et le propriétaire de l’encaissement. Demandez qui initie chaque renouvellement : WHMCS, le système d’abonnement du fournisseur ou une autre intégration. Sans cette réponse, il est facile de désactiver un calendrier alors qu’un accord indépendant continue de facturer.
Considérez l’inventaire initial comme une collecte de preuves. Ne modifiez pas les références en production pendant que vous les identifiez. Un instantané stable permet à l’équipe de facturation de comparer l’ancien accord avec la configuration souhaitée et d’identifier les comptes nécessitant un traitement particulier avant le prochain renouvellement.
Séparer les données client, les autorisations et les calendriers de renouvellement
Les détails du client vous aident à vérifier l’identité. L’autorisation établit un moyen valide de prélèvement. Le calendrier détermine quand et quel montant facturer. Conservez ces éléments sous forme de trois vérifications distinctes, même si l’ancienne interface les affiche sur une seule page.
Télécharger le fichier CSV de préparation des paiements. Le modèle en anglais enregistre les résultats de vérification et des références fictives. Il s’agit d’une feuille de travail de planification, et non d’un fichier d’importation de mandats de fournisseur. N’y inscrivez pas de numéros de carte, de codes de sécurité, de mots de passe ou de clés API.
| Enregistrement | Question de planification | Exemple de résultat |
|---|---|---|
| Correspondance client | Cette référence appartient-elle au client visé ? | Identité vérifiée |
| Compte du prestataire | À quel compte appartient le moyen de paiement enregistré ? | Compte existant enregistré |
| Autorisation de paiement | La destination peut-elle l’utiliser pour ce service ? | En attente de confirmation |
| Calendrier de renouvellement | Quelle période a déjà été payée ? | Octobre payé ; novembre prochain |
| Responsable du prélèvement | Quel système initie le paiement aujourd’hui ? | Workflow de passerelle existant |
| Mappage de destination | Une référence prise en charge a-t-elle été vérifiée à cet endroit ? | Pas prêt pour le prélèvement automatique |
Pour un client fictif A, toutes les coordonnées peuvent être transférées correctement alors que le mappage de paiement reste non confirmé. Ce client n’est pas prêt pour le prélèvement automatique. Marquer l’enregistrement comme « importé » ne doit pas regrouper les trois vérifications en un seul statut vert.
Pour le client B, les modalités de paiement peuvent être confirmées, mais la période suivante a déjà été payée. Une autorisation correcte ne justifie pas un nouveau prélèvement. Combinez cette feuille de calcul avec le document «Registre de transfert des renouvellements» avant l’activation.
Vérifiez si vous changez de prestataire de paiement
Le passage à une nouvelle interface de facturation et le passage à un nouveau prestataire de paiement sont deux projets distincts. Conserver le même prestataire peut réduire la charge de travail, mais cela ne garantit pas que deux intégrations puissent utiliser les mêmes références client et de paiement.
Si le compte du prestataire reste le même, demandez à l’intégration de destination quels types de références elle accepte, comment la propriété est vérifiée et quelle configuration est requise. Validez ces informations auprès d’un petit groupe test autorisé. Ne vous fiez pas à un nom de compte familier pour supposer que le mode de prélèvement est effectivement pris en charge.
Si le prestataire change, renseignez-vous auprès des deux prestataires sur le processus de migration pris en charge. Le document « Guide d’importation des mandats de carte bancaire de Mollie » décrit un transfert coordonné entre prestataires et un mappage vers de nouvelles références. Il sépare explicitement la migration des informations de carte de la logique d’abonnement. Cette distinction est essentielle pour planifier le transfert de facturation.
Le processus de traitement des cartes de Mollie n’est pas une méthode universelle applicable à tous les types de paiement. Sa documentation distingue la migration des cartes des voies de prélèvement SEPA et PayPal. Planifiez en fonction de votre méthode, de votre compte et de votre intégration réels, plutôt que de considérer chaque ligne de paiement enregistrée comme interchangeable.
Séparez la coordination entre prestataires de toute promesse concernant l’expérience client. Tant que le mappage vers la destination et la première voie de prélèvement n’ont pas été vérifiés, le statut honnête est « en cours de vérification ». Une date de migration doit refléter l’état de préparation, et non une hypothèse générale selon laquelle tous les moyens de paiement enregistrés seront transférés.
Déterminez quand une nouvelle autorisation client constitue la solution la plus claire
Lorsqu’il n’est pas possible de confirmer la validité d’un accord existant, prévoyez une nouvelle autorisation client plutôt que de tenter une copie de référence non prise en charge. Indiquez au client l’action requise, le service concerné et la date à laquelle le prochain prélèvement aura lieu.
La réautorisation ne doit pas demander au client d’envoyer les détails de sa carte par e-mail. Dirigez-le vers le processus de paiement sécurisé configuré. Le personnel ne doit pas recueillir de numéro de carte ou de code de sécurité dans un ticket d’assistance pour contourner une intégration incomplète.
Utilisez des messages différents pour les comptes confirmés et non confirmés. Un client dont le mappage de paiement est prêt ne doit pas recevoir de demande inutile d’ajouter une autre carte. Un client dont le mappage n’est pas prêt ne doit pas recevoir de message rassurant indiquant « aucune action requise » simplement parce que son adresse e-mail a été importée avec succès.
Voici un exemple de message réutilisable : « La facturation du [service] sera transférée vers [portail] à compter de [période]. Nous vous demandons d’autoriser le mode de paiement via [lien de configuration vérifié] avant le [date]. Votre couverture payante actuelle prend fin le [date]. Nous vous confirmerons le prochain montant prévu avant de lancer le nouveau prélèvement. »
Remplacez chaque champ par les informations réelles et utilisez l’URL de destination vérifiée. Vérifiez qui est habilité à répondre aux questions des clients et comment sont gérées les autorisations incomplètes. L’envoi répété d’e-mails de rappel ne peut pas rendre éligible un accord de paiement non pris en charge.
Comprendre la facturation automatique et manuelle des abonnements avec PayRequest
La documentation de PayRequest (Documentation relative au paiement des abonnements) décrit le prélèvement automatique à l’aide d’un mandat valide attribué et la facturation récurrente manuelle. Le workflow de mandat documenté utilise Mollie. Ne considérez pas la présence d’une connexion Stripe ailleurs comme une preuve que n’importe quelle référence Stripe de WHMCS peut être attribuée à ce flux.
Vérifiez le mode de paiement indiqué sur l’abonnement concerné. Confirmez l’identité du client et le statut valide du mandat via l’interface prise en charge. Une référence familière copiée dans un champ sans rapport ne prouve pas qu’un mode de prélèvement fonctionne ni que le client l’a autorisé.
La facturation récurrente manuelle peut convenir aux clients qui paient par virement bancaire, lorsque le produit et la configuration le permettent. Elle fournit au client une facture à régler plutôt que de procéder à un prélèvement automatique. Cela modifie le processus opérationnel : une personne doit surveiller la facture et le résultat du paiement avant de considérer le solde comme réglé.
Choisissez la méthode de manière réfléchie. La facturation manuelle ne doit pas être une solution de secours invisible après l’échec d’un prélèvement automatique promis. Indiquez aux clients si le montant sera prélevé ou s’ils doivent régler la facture, et veillez à ce que ces instructions soient cohérentes avec l’état du portail.
L’portail cliente fait partie de l’expérience, mais le portail ne constitue pas à lui seul une autorisation de paiement. Utilisez l’Démonstration du portaile pour évaluer les tâches des clients tandis que le mappage des paiements est examiné séparément.
Testez le mappage de référence avant le premier renouvellement en production
Préparez un bref compte-rendu de vérification pour chaque compte pilote. Celui-ci doit mentionner l’ancienne référence de service, le client destinataire, la période suivante, le mode de paiement et la personne ayant effectué la vérification. Consignez les observations et les résultats sans collecter de données de paiement sensibles.
Pour un parcours automatique, confirmez les modalités de paiement éligibles et le montant dû avant tout contrôle de prélèvement autorisé. Observez le résultat réel du prestataire et l’état de la facture. Un abonnement affiché comme actif ne remplace pas la vérification du paiement correspondant.
Pour un parcours manuel, vérifiez les instructions de facturation et la manière dont le paiement est rapproché. L’absence de mandat peut être intentionnelle. La question est de savoir si le workflow sélectionné correspond à la configuration du produit et à l’engagement pris envers le client.
Vérifiez également que l’ancien responsable du prélèvement ne peut pas facturer la même période. Un mode de paiement de destination correct peut faciliter un prélèvement en double si l’ancienne passerelle fonctionne toujours de manière indépendante. Consultez la documentation « Guide de migration pour éviter la double facturation » avant de réactiver un ancien traitement après un contrôle ayant échoué.
Utilisez une condition de mise en production fondée sur des preuves : référence prise en charge, client correct, montant et date corrects, un seul responsable du recouvrement et un résultat validé. « Toutes les lignes importées » est une étape importante dans le traitement des données. Ce n’est pas le test complet d’acceptation du paiement.
Gérer les paiements incomplets sans perdre le contrôle
Conservez les comptes non confirmés dans un groupe distinct. Attribuez à chacun une action : confirmation du prestataire, réautorisation du client, parcours manuel de la facture explicitement convenu ou transfert reporté. Évitez d’activer l’ensemble du groupe en espérant que les paiements échoués permettront d’identifier les exceptions ultérieurement.
Pour les renouvellements urgents, maintenez l’ancien dispositif responsable uniquement tant qu’il reste le responsable de facturation convenu. Consignez la date de transfert révisée. Si le nouveau système a déjà effectué une tentative, vérifiez le résultat avant de laisser l’ancien système procéder à un nouveau prélèvement.
Conservez l’historique des paiements et les notes d’assistance. Un tableau de correspondance des prestataires est utile pour faire correspondre les références, mais les clients peuvent tout de même poser des questions sur un ancien remboursement, une facture ou une description de relevé. Donnez au personnel les moyens de retracer ces demandes sans conserver de copies inutiles des informations d’identification.
Apportez la fiche de préparation dûment remplie à l’équipe «Évaluation de la migration depuis WHMCS». Décrivez votre prestataire, vos méthodes et l’automatisation de vos services. Cela fournit à l’équipe une configuration concrète à examiner, plutôt qu’une simple demande de « transfert de tous les abonnements » sans préciser ce que cela inclut.
PayRequest Business coûte 20 € par mois et inclut le portail client et la facturation récurrente. Les frais de paiement standard de la plateforme sont de 0 % tant que le forfait payant est actif. Les frais de traitement des prestataires s’appliquent séparément ; les paiements de commissions conservent leurs frais distincts. Effectuez la configuration complète du compte et activez le forfait Business lors du paiement. La sélection du forfait Business lors de l’inscription n’active pas les fonctionnalités payantes. Consultez tarifs actuels avant de choisir votre configuration.
Note de la rédaction : l’IA a contribué à la rédaction de cet article et à la création de sa couverture illustrative. La documentation officielle a été consultée le 7 octobre 2026. Les feuilles de calcul et les messages clients sont des modèles de planification originaux. Tous les exemples sont fictifs ; aucune facturation réelle, migration de client ou résiliation d’hébergement n’a été effectuée pour cet article.
