Échéance d'abonnement impayée : rappels, délai et décisions

Une échéance d'abonnement impayée suit chez ChariPay un déroulé simple : à la date d'échéance, votre client a reçu par e-mail un lien de paiement pour la période ; tant qu'il ne l'a pas réglé, il reçoit chaque jour un rappel avec le même lien, et aucune nouvelle période ne s'ouvre. Le lien reste payable 14 jours après la date d'échéance ; passé ce délai sans paiement, l'abonnement est annulé automatiquement et votre serveur reçoit le webhook subscription.canceled. Ce qui vous revient : décider du sort du service, relancer le client par votre propre canal si besoin et garder une trace comptable propre. Ce guide déroule chaque étape, puis vos options.

Ce qui se passe quand une échéance n'est pas payée, pas à pas

ChariPay est une plateforme de paiement marocaine, un PSP opéré par Chari Money, établissement de paiement agréé par Bank Al-Maghrib. Ses abonnements fonctionnent par liens de paiement : à chaque échéance, ChariPay génère un lien de paiement à usage unique pour la période et l'envoie par e-mail à votre client, qui le règle par carte sur la page de paiement hébergée, avec 3-D Secure. La mise en place complète est décrite dans intégrer les abonnements par l'API. Quand ce lien n'est pas réglé, voici ce qui se passe, dans l'ordre :

1. 1Le lien de l'échéance part par e-mail. À la date d'échéance, le client reçoit un e-mail « Nouvelle échéance », suivi de la description de l'abonnement, avec le lien de paiement de la période.
2. 2Un rappel part chaque jour. Tant que l'échéance n'est pas réglée, le client reçoit chaque jour un e-mail « Rappel de paiement », avec le même lien.
3. 3Aucune nouvelle période ne s'ouvre. Tant que l'échéance reste impayée, aucun nouveau lien n'est généré : le client ne cumule pas plusieurs échéances en retard.
4. 4Une tentative refusée ne ferme pas le lien. Si le client essaie de payer et que sa carte est refusée, votre serveur reçoit subscription.payment_failed ; le lien reste payable, et le client peut réessayer.
5. 5Un paiement règle l'échéance. Dès que le client paie, votre serveur reçoit subscription.payment_succeeded, et l'abonnement poursuit son cours.
6. 6Sans paiement dans le délai, l'abonnement est annulé. Le lien d'une échéance reste payable 14 jours après la date d'échéance — ou après son envoi, s'il est parti plus tard. S'il expire sans paiement, l'abonnement passe au statut « annulé » (CANCELED) et votre serveur reçoit subscription.canceled.

Ce déroulé ne vous demande aucune action. Il vous laisse en revanche des décisions à prendre — sur le service, sur la relance, sur l'abonnement lui-même —, que les sections suivantes détaillent.

Le calendrier d'une échéance impayée

Le délai se compte à partir de la date d'échéance, sur le fuseau Africa/Casablanca comme les échéances elles-mêmes.

Exemple : pour une échéance le 5 du mois, le client reçoit le lien le 5, puis un rappel chaque jour tant qu'il n'a pas payé ; le lien reste payable jusqu'au 19 ; s'il n'est toujours pas réglé à son expiration, l'abonnement est annulé. Une échéance payée se signale par l'événement subscription.payment_succeeded. Notez ce calendrier dans vos procédures : c'est lui qui rythme vos propres messages au client.

Avant qu'un vrai client ne soit concerné, voyez dans le portail à quoi ressemblent un abonnement, ses échéances et ses webhooks. Le mode test s'ouvre dès l'activation de votre compte, sans validation à attendre : Commencer en mode test — trois champs (nom, e-mail professionnel, entreprise), un lien d'activation reçu par e-mail pour choisir votre mot de passe, puis le portail, où vous créez vous-même votre clé de test après une ré-authentification ; la clé complète ne s'affiche qu'une seule fois. Payez avec la carte de test 4918 9141 0719 5005, CVV 123, n'importe quelle date d'expiration future, code 3-D Secure 555 : seule cette carte est acceptée, et aucun argent réel ne circule. La vérification de votre entreprise (KYB) se fait en parallèle et ne conditionne que le passage en production. En mode test, créez un abonnement dont la date de début est aujourd'hui : le premier lien est créé immédiatement et renvoyé dans currentCharge. Payez-le avec la carte de test — l'abonnement passe actif et subscription.payment_succeeded arrive —, puis, avec une périodicité quotidienne (DAILY), laissez l'échéance du lendemain impayée et suivez son état par GET /v1/subscriptions/{reference}/charges.

Ce que reçoit votre client : le lien de l'échéance et ses rappels

Chaque e-mail — celui de l'échéance comme chaque rappel — porte le même lien de paiement. Il ouvre une page de paiement ChariPay où le client règle l'échéance par carte. Comme tout paiement par carte, il passe par l'authentification 3-D Secure : le porteur confirme auprès de sa banque. La description de l'abonnement figure sur chaque lien et dans l'objet de l'e-mail d'échéance : rédigez-la pour que le client reconnaisse votre service au premier coup d'œil, « Formule Pro — mensuel » plutôt qu'un code interne.

Encore faut-il que le paiement puisse aboutir. Si la carte du client est plafonnée pour les paiements en ligne, ou fermée à ce type de paiement — beaucoup de cartes marocaines sont, par défaut, fermées au paiement en ligne —, sa tentative est refusée : vous recevez subscription.payment_failed, et le lien reste payable. Votre client doit alors régler la question avec sa banque, ou payer avec une autre carte, sur le même lien. Les causes de refus vues de l'acheteur, et ce qu'il peut faire pour chacune, sont expliquées dans carte refusée en paiement en ligne ; la mesure des échecs côté commerçant reste dans 3-D Secure et taux de réussite.

Votre rôle à ce stade : faire en sorte que le client sache que ce lien existe et qu'il vient bien de vous. Un message de votre part, signé de votre marque (voir les messages types plus bas), évite qu'il ne l'ignore ou ne le prenne pour un e-mail suspect.

Ce que vous voyez : statuts, échéances et webhooks

Pendant le délai, l'abonnement ne change pas de statut : il reste actif — ou « à démarrer » (INCOMPLETE) s'il s'agit de la première échéance, puisque c'est le premier paiement qui active l'abonnement. C'est l'échéance elle-même qui porte l'impayé. Dans le portail, la page Abonnements liste vos abonnements, leur prochaine échéance et leur statut, et la fiche de chacun montre chaque échéance envoyée avec son état. Par l'API, GET /v1/subscriptions/{reference}/charges liste les échéances, la plus récente d'abord, chacune avec son statut et son lien (payUrl) ; la réponse de GET /v1/subscriptions/{reference} porte, dans currentCharge, le lien de la période en cours. Trois événements de webhook suivent la vie d'un abonnement :

Aucun événement ne part au seul passage de la date d'échéance : une échéance est impayée tant que vous n'avez pas reçu subscription.payment_succeeded pour sa période. Trois règles de réception évitent les erreurs classiques. Routez chaque événement sur l'en-tête Chari-Event-Type. Dédupliquez sur Chari-Event-Id, pas sur Chari-Webhook-Id — ce dernier identifie la livraison, pas l'événement. Et retrouvez le client et la période grâce à ce que chaque événement d'abonnement vous renvoie : votre metadata, tel quel, votre identifiant d'abonnement (ExternalId) et la date de la période concernée (PeriodDate) — inutile de deviner à partir d'un montant ou d'une date de réception.

Répondez 2xx seulement après avoir enregistré l'événement et la mise à jour de votre fiche client ; la livraison se fait au moins une fois, parfois dans le désordre. La vérification de signature et la gestion des rejeux sont détaillées dans réussir son intégration des webhooks.

Vos décisions : attendre, relancer autrement, suspendre, annuler

Les rappels automatiques ne vous retirent pas la main. Quatre décisions s'offrent à vous — pause, reprise et annulation se font depuis la fiche de l'abonnement dans le portail, ou par l'API :

Le lien à renvoyer est celui que porte currentCharge, ou l'échéance en attente dans la liste des échéances : c'est le même que celui des e-mails, et il ne se paie qu'une fois. Un client qui veut payer avec une autre carte n'a rien à changer dans l'abonnement : il saisit la carte de son choix sur la page du lien.

La pause agit sur l'avenir : elle arrête la génération de nouveaux liens, le temps d'une difficulté annoncée — un client saisonnier, un mois difficile. Elle ne remplace pas une conversation avec le client sur l'échéance déjà envoyée.

Ces décisions se combinent : vous pouvez laisser courir le délai tout en écrivant au client, puis annuler s'il vous le demande. Les appels correspondants — pause, reprise, annulation, liste des échéances — sont décrits dans intégrer les abonnements par l'API et dans la référence du module Abonnements.

Couper ou maintenir le service : votre règle, déclenchée par webhook

ChariPay encaisse ; le service que vous rendez — l'accès à un logiciel, l'envoi d'une box, l'entrée à la salle — reste sous votre contrôle. Fixez votre règle à l'avance et branchez-la sur les webhooks, jamais sur une redirection : la redirection dit que l'acheteur est revenu, pas que le paiement est acquis. Chaque cas a son guide : facturer un SaaS au Maroc, vente par abonnement et abonnements de salle de sport.

Trois politiques reviennent souvent :

Les politiques graduée et stricte reposent sur votre propre calendrier : votre système connaît la date de chaque échéance et constate l'absence de subscription.payment_succeeded pour cette période. Quand c'est vous qui annulez, depuis le portail ou par l'API, coupez le service au même moment, sans attendre d'événement : la réponse de l'annulation porte déjà le statut CANCELED. Pour rétablir le service, appuyez-vous sur subscription.payment_succeeded, qui signale une échéance payée. Si le client vous dit avoir réglé, vérifiez que l'échéance est payée — sur la fiche de l'abonnement dans le portail, ou par l'API — avant de rouvrir l'accès. Après une annulation, reprendre la relation suppose un nouvel abonnement.

Écrivez cette règle dans vos conditions d'abonnement — ce qui se passe pendant le délai de paiement, à l'annulation, et comment revenir —, sans promettre de délai qui ne dépende pas de vous. Un client prévenu de la règle sait à quoi s'attendre.

Relance d'une échéance impayée : vos messages types

Les rappels quotidiens font leur travail ; un message de votre part, signé de votre marque et envoyé par votre canal habituel, leur donne du contexte. Trois messages à adapter :

Quelques jours après l'échéance

Bonjour Salma, l'échéance de votre abonnement n'est pas encore réglée. Vous avez reçu de notre part, par e-mail, un lien de paiement : il suffit de l'ouvrir pour payer par carte. Vous ne le retrouvez pas ? Répondez à ce message, nous vous le renvoyons.

Avant la fin du délai

Bonjour Salma, votre échéance reste impayée à ce jour. Le lien de paiement reçu par e-mail reste valable jusqu'au 19 ; au-delà, votre abonnement sera annulé. Si votre carte est refusée, votre banque peut l'ouvrir au paiement en ligne, ou vous pouvez payer avec une autre carte sur le même lien.

À l'annulation

Bonjour Salma, faute de paiement, votre abonnement a été annulé et votre accès est suspendu. Si vous souhaitez reprendre, répondez à ce message : nous préparerons un nouvel abonnement avec vous.

Trois conseils pour les adapter : collez à votre règle de service (ne parlez pas de suspension si vous maintenez l'accès), restez factuel — un refus de carte n'est pas une faute —, et donnez toujours un moyen de vous répondre. Pour une facture ponctuelle, la relance se fait autrement : voir se faire payer une facture en ligne.

La trace comptable d'une échéance impayée

Une échéance impayée ne doit pas devenir une ligne fantôme dans vos comptes. Les échéances d'un abonnement se consultent dans le portail et par l'API (GET /v1/subscriptions/{reference}/charges) : l'échéance impayée y reste visible avec son état, et comme aucune nouvelle période ne s'ouvre tant qu'elle reste impayée, il n'y a jamais d'échéances fantômes à rapprocher derrière elle.

Pour rattacher chaque événement à votre fiche client, appuyez-vous sur le metadata, l'ExternalId et la PeriodDate renvoyés par les événements d'abonnement. Chaque échéance payée devient ensuite un mouvement du compte, avec sa référence, repris dans l'export CSV des transactions.

Trois réflexes pour votre comptable :

• enregistrer une échéance comme payée à réception de subscription.payment_succeeded, jamais avant ;
• suivre les échéances impayées dans une liste à part, revue chaque semaine, avec leur date limite de paiement ;
• clore le dossier client à l'annulation, en notant la dernière période réellement payée.

L'offre et ses autres fonctions sont présentées sur la page abonnements et paiements récurrents.

Questions fréquentes

Combien de temps le client a-t-il pour payer une échéance ?

Le lien d'une échéance reste payable 14 jours après la date d'échéance — ou après son envoi, s'il est parti plus tard —, comptés sur le fuseau Africa/Casablanca. Pendant ce délai, le client reçoit chaque jour un rappel par e-mail, avec le même lien. S'il ne paie pas avant l'expiration du lien, l'abonnement est annulé automatiquement et votre serveur reçoit subscription.canceled.

Le client est-il prévenu quand son échéance n'est pas payée ?

Oui : tant que l'échéance n'est pas réglée, il reçoit chaque jour un e-mail « Rappel de paiement », avec le lien de la période. Rien ne vous empêche d'ajouter votre propre message, signé de votre marque, pour expliquer la situation, rappeler la date limite et indiquer comment vous joindre. Vous pouvez aussi lui renvoyer le lien par WhatsApp ou par SMS.

Un abonnement impayé continue-t-il à facturer de nouvelles périodes ?

Non. Tant qu'une échéance reste impayée, aucune nouvelle période ne s'ouvre et aucun nouveau lien n'est envoyé : votre client ne cumule pas plusieurs échéances en retard, et votre comptabilité ne porte pas de dette silencieuse. Si l'échéance en attente n'est jamais payée, l'abonnement est annulé automatiquement à l'expiration du lien, et votre serveur en est prévenu par subscription.canceled.

Quand un abonnement impayé est-il annulé automatiquement ?

Quand le lien de l'échéance expire sans avoir été payé, 14 jours après la date d'échéance. Le statut passe alors à « annulé » (CANCELED) et votre serveur reçoit l'événement subscription.canceled. L'annulation est définitive : pour reprendre la relation avec ce client, il faudra créer un nouvel abonnement sur sa fiche client.

Que se passe-t-il si la carte du client est refusée sur le lien ?

Votre serveur reçoit subscription.payment_failed, mais le lien reste payable : le client peut réessayer après avoir réglé la question avec sa banque, ou payer avec une autre carte sur la même page. Les rappels quotidiens continuent tant que l'échéance n'est pas réglée, dans la limite des 14 jours. Les causes de refus les plus courantes sont détaillées dans carte refusée en paiement en ligne.

Quel webhook signale une échéance impayée ?

Aucun événement ne part au seul passage de la date : une échéance est impayée tant que vous n'avez pas reçu subscription.payment_succeeded pour sa période (PeriodDate). subscription.payment_failed signale une tentative de paiement par carte refusée sur le lien, et subscription.canceled l'annulation au terme du délai. Routez sur Chari-Event-Type, dédupliquez sur Chari-Event-Id, et répondez 2xx une fois l'événement enregistré.

Que voit-on dans le portail quand une échéance n'est pas payée ?

La page Abonnements liste vos abonnements, leur prochaine échéance et leur statut. Sur la fiche d'un abonnement, chaque échéance envoyée apparaît avec son état : celle qui n'est pas réglée y reste en attente tant qu'elle n'est pas payée. Depuis cette fiche, vous pouvez suspendre, reprendre ou résilier l'abonnement. S'il est annulé à l'expiration du lien, son statut devient « annulé », dans le portail comme par l'API.

Prochaine étape

Créez un abonnement de test, branchez vos webhooks subscription.* et écrivez votre règle de service en cas d'échéance impayée avant d'abonner votre premier client : Commencer en mode test. Pour revoir la mise en place d'un abonnement, de la fiche client au premier lien, relisez intégrer les abonnements par l'API ; pour la référence des appels, voyez la documentation du module Abonnements.