Notifications aux clients

Abuna informe vos clients de leur abonnement à votre place : ce qu'ils doivent payer, ce qu'ils ont payé, et quand leur formule se termine. Chaque message part par e-mail. Il part aussi sur Telegram si le client a connecté Telegram. Vous n'avez aucun de ces messages à écrire ni à envoyer vous-même.

Les messages sont en français ou en anglais, selon la langue du client. Un client sans langue définie les reçoit en français. Les montants et les dates suivent la langue : 5 000 FCFA et 4 oct. 2026 en français, FCFA 5,000 et 4 Oct 2026 en anglais.

Ce que reçoivent les clients

Chaque message a un kind, indiqué ici entre parenthèses. L'API Notifications utilise les mêmes noms.

• Abonnement démarré (subscription_started) : 30 minutes après la création d'un abonnement, si la première période n'est pas payée à ce moment-là. Il demande au client de payer la première période et renvoie vers le lien de paiement. Un client qui paie sur la page de paiement ne reçoit que le reçu. En mode Test, il est enregistré quand l'abonnement est créé.
• Paiement reçu (payment_received) : un reçu, après chaque paiement réussi. Quand le paiement met une mise à niveau en vigueur, le reçu indique aussi que la formule a changé. Pour une facture que vous avez marquée payée, il indique que vous avez enregistré le paiement.
• Paiement échoué (payment_failed) : quand un paiement échoue après que le client a quitté la page de paiement, par exemple quand il ne l'a jamais validé sur son téléphone, avec la raison. Un refus que le client voit sur la page de paiement n'envoie rien. Au plus un part par heure pour la même facture.
• Renouvellement à venir (renewal_upcoming) : quand la facture du renouvellement part avant la fin de la période payée, comme l'indique le réglage Facture de renouvellement de votre application (3 jours avant par défaut). Il contient le montant dû, la date limite de paiement et le lien de paiement, et le client peut payer tout de suite. Avec le réglage à 0, ou avec une rétrogradation programmée, il part 3 jours avant la fin de la période sans lien de paiement, et indique que le lien arrivera le jour du renouvellement.
• Renouvellement dû (subscription_renewed) : quand la facture d'un renouvellement part au début de sa période, avec le montant dû et un lien de paiement. Il demande au client de payer pour renouveler sa formule.
• Paiement en retard (payment_overdue) : une fois par jour tant qu'un renouvellement est impayé.
• Dernier rappel (payment_final_notice) : 1 jour avant l'annulation d'un abonnement impayé, ou à mi-parcours avec 1 jour pour payer.
• Abonnement qui se termine (subscription_cancel_scheduled) : quand une annulation est fixée pour la fin de la période payée, que ce soit vous ou le client qui l'ayez fixée. Il indique la date de fin de l'abonnement et comment le conserver.
• Abonnement maintenu (subscription_cancel_undone) : quand une annulation programmée est annulée. Une courte confirmation.
• Abonnement annulé (subscription_canceled) : quand l'abonnement prend fin. C'est immédiat quand vous ou le client annulez maintenant, à la fin de la période payée pour une annulation programmée, ou quand il prend fin faute de paiement. Une première page de paiement jamais payée prend fin sans message.
• Changement de formule proposé (plan_change_offered) : quand vous proposez une autre formule au client depuis le tableau de bord, et chaque fois que vous la renvoyez. Il renvoie vers la page où il l'accepte. Une session de changement de formule ne l'envoie pas.
• Formule mise à niveau (plan_upgraded) : quand une mise à niveau prend effet, avec la nouvelle formule et la nouvelle date de facturation. Si la nouvelle période reste à payer, il contient le montant dû et le lien de paiement. Une mise à niveau qui prend effet quand le client paie envoie le reçu à la place, pour qu'il ne reçoive qu'un message.
• Mise à niveau à payer (plan_upgrade_due) : quand une mise à niveau attend que le client paie le reste de la nouvelle formule, avec le montant, la date limite de paiement et le lien de paiement. Il indique que le client garde sa formule s'il ne paie pas, et, si la mise à niveau a remplacé une annulation programmée, que l'abonnement prend quand même fin à sa date. Rien n'est envoyé quand la mise à niveau expire.
• Rétrogradation programmée (plan_downgrade_scheduled) : quand une rétrogradation est fixée pour la fin de la période payée, avec la nouvelle formule et la date à laquelle elle commence.
• Rétrogradation annulée (plan_downgrade_undone) : quand une rétrogradation programmée est annulée, que ce soit vous ou le client qui l'ayez annulée. Il indique que le client garde sa formule, avec la prochaine date de facturation et son montant.
• Changement de tarif (price_change_scheduled) : quand vous programmez un nouveau montant pour un tarif et que les abonnés actuels y passeront, avec le nouveau montant et la date à laquelle il s'applique pour la première fois. Les clients qui s'abonnent pendant que le changement est en attente le reçoivent au moment de leur abonnement.
• Changement de tarif annulé (price_change_canceled) : quand vous annulez ce changement, ou le remplacez par un autre qui garde les abonnés actuels sur l'ancien montant. Il indique que leur tarif reste le même.
• Coordonnées modifiées (contact_changed) : quand le client change son adresse e-mail ou son numéro de téléphone dans l'espace client. Il part vers son ancienne adresse e-mail et sa conversation Telegram connectée, jamais vers la nouvelle adresse.
• Liens de l'abonnement (portal_links) : quand un client demande les liens vers ses abonnements sur votre page. Il part uniquement par e-mail, au plus une fois toutes les 5 minutes.

Les e-mails viennent de <nom de votre application> via Abuna, et quand le client répond, la réponse arrive à votre e-mail d'assistance. Chaque e-mail se termine par votre e-mail d'assistance ou votre page d'aide, un lien vers l'espace client, et, tant que le client n'a pas connecté Telegram, un lien pour recevoir les mêmes mises à jour là-bas. Les e-mails au sujet d'un abonnement terminé, et les liens de l'abonnement, omettent les liens vers l'espace client et Telegram. Quand vous définissez vos propres conditions, le pied de page les lie. Avec le forfait Gratuit, le pied de page indique aussi Facturé avec Abuna. Définissez votre e-mail d'assistance et vos conditions dans le tableau de bord, sous Paramètres, Général, Assistance client.

Les dates et les heures s'affichent dans le fuseau horaire de votre application. Les nouvelles applications démarrent à l'heure du Cameroun. Changez-la sous Paramètres, Général, Fuseau horaire.

Quand les rappels partent

Les renouvellements sont facturés à l'avance. Abuna envoie la facture de renouvellement avant la fin de la période payée, autant de jours à l'avance que l'indique le réglage Facture de renouvellement de votre application, de 0 à 7, et le client peut la payer dès ce moment. La nouvelle période commence quand la période payée se termine, peu importe la précocité du paiement. À partir de cette date, le client dispose des Jours pour payer de votre application, de 1 à 14 jours, avant que l'abonnement soit annulé. Les nouvelles applications démarrent à 3 jours pour les deux. Vous les définissez dans Paramètres, Général, Renouvellements et délai de paiement.

1. 3 jours avant la fin d'une période payée (par défaut), le client reçoit la facture de renouvellement avec son lien de paiement.
2. Avec le réglage à 0, il reçoit un avis 3 jours avant à la place, et la facture au début de la nouvelle période.
3. Chaque jour ensuite, tant qu'elle est impayée, il reçoit un rappel de retard.
4. 1 jour avant la date d'annulation, il reçoit un dernier rappel à la place.
5. Si elle est toujours impayée à la date d'annulation, l'abonnement est annulé et le client en est informé.

Abuna saute un rappel qui arriverait dans l'heure suivant la facture ou un reçu, pour que les clients ne reçoivent pas deux fois le même message. Chaque facture impayée reçoit au moins un rappel avant l'annulation : avec 1 jour pour payer, le dernier rappel part à mi-parcours, 12 heures avant l'annulation. Un rappel qui n'est plus vrai, parce que le client a payé ou que l'abonnement a pris fin, est annulé avant d'être envoyé.

Tant qu'une application Réelle ne peut pas encaisser de paiements, par exemple sans prestataire de paiement connecté, les factures de renouvellement et les rappels de paiement attendent, et personne n'est annulé pour non-paiement. Une fois que l'application encaisse de nouveau, le client reçoit le rappel qui est dû à ce moment-là, avec le lien de paiement.

Telegram

Chaque e-mail contient un lien Recevoir les mises à jour de l'abonnement sur Telegram. Quand le client l'ouvre et appuie sur Démarrer, le bot d'Abuna connecte sa conversation. À partir de là, chaque message part à la fois vers son e-mail et son Telegram. Les liens de l'abonnement partent toujours uniquement par e-mail.

• Chaque lien fonctionne une seule fois. Une fois une conversation connectée, les e-mails cessent de porter le lien, pour qu'un e-mail transféré ne puisse pas déplacer les messages du client vers la conversation de quelqu'un d'autre. L'espace client l'affiche toujours.
• Seules les conversations privées peuvent se connecter. Une conversation de groupe montrerait les liens de paiement d'un client à tout le monde.
• Si le client connecte un autre compte Telegram, les messages y sont déplacés, et l'ancienne conversation en est informée.
• Le client peut envoyer /stop au bot à tout moment. Les messages partent alors uniquement par e-mail, et ceux qui attendaient encore Telegram sont annulés.

Mode Test

Les clients en mode Test ont souvent de vraies adresses e-mail et conversations Telegram, donc le mode Test n'envoie jamais de message. Abuna enregistre chacun comme un événement notification.captured à la place, avec le sujet et le texte qu'il aurait envoyés. Ces événements ne vont pas à votre point de terminaison de webhook. Listez-les pour vérifier votre flux :

curl "https://api.abuna.app/v1/apps/8ddhXCDW/events?type=notification.captured" \
  -H "Authorization: Bearer sk_test_..."

{
  "id": "01J9ZQ8E1F2G3H4J5K6M7N8P9Q",
  "type": "notification.captured",
  "environment": "test",
  "created_at": 1727600000,
  "data": {
    "customer_id": "Cu5tM8rA",
    "kind": "payment_received",
    "channel": "email",
    "recipient": "ana@example.com",
    "subject": "Receipt from My store: FCFA 5,000 paid",
    "text": "...",
    "sent": false
  }
}

Vérifiez ce qui a été envoyé

En mode Réel, listez vos messages avec GET/v1/apps/{appID}/notices. Filtrez par subscription_id ou par status : pending, sending, sent, failed ou withdrawn. En mode Test, la liste est toujours vide.

curl "https://api.abuna.app/v1/apps/8ddhXCDW/notices?subscription_id=x9QbL2sK" \
  -H "Authorization: Bearer sk_live_..."

Si un message ne peut pas être envoyé, Abuna essaie jusqu'à 5 fois sur environ 40 minutes, puis le marque failed. Voyez Notifications pour chaque champ.

E-mails à votre équipe

En mode Réel, les membres de votre équipe reçoivent leurs propres e-mails quand un abonnement démarre, qu'un paiement est reçu, qu'un paiement échoue, qu'un abonnement est annulé, ou qu'un client change de formule. Programmer une annulation pour la fin de la période payée, ou l'annuler, compte comme une annulation. Un changement de formule, c'est une mise à niveau qui prend effet, ou une rétrogradation programmée ou annulée. Chaque membre choisit ceux qu'il veut, et s'ils arrivent tout de suite ou une fois par jour, sous Notifications dans son profil. Un premier paiement ou une mise à niveau payée, c'est un seul e-mail, pas deux.

Un e-mail de paiement échoué ne part que lorsque le client n'a pas vu l'échec sur la page de paiement, par exemple quand un paiement échoue après qu'il l'a quittée. Un échec que le client voit sur la page de paiement n'envoie aucun e-mail, ni à lui ni à votre équipe.

Un renouvellement encore impayé à la fin de sa période payée, donc un abonnement past_due, apparaît dans le résumé quotidien de chaque membre qui a choisi Un paiement échoue, même s'il reçoit ses autres e-mails tout de suite.