Skip to main content
Un abonnement active est facturé d’avance, à chaque currentPeriodEnd, pour la période qui commence. Le mécanisme tient en deux rendez-vous quotidiens, tous deux à 11 h heure de Brazzaville (UTC+1).

​
J-3 : la facture est émise et envoyée

Trois jours avant currentPeriodEnd, Yabetoo :
  1. génère la facture du cycle à venir (billingReason: "subscription_cycle", période [currentPeriodEnd, currentPeriodEnd + intervalle]) et la finalise — elle reçoit son numéro ;
  2. l’envoie par e-mail au client, avec un lien de paiement vers la page hébergée ;
  3. émet invoice.finalized.
La période de l’abonnement, elle, ne bouge pas : c’est le jour J qui l’avance. Le client peut régler cette facture depuis le lien, à tout moment avant l’échéance. Dans ce cas vous recevez invoice.paid tout de suite, et le jour J ne demandera rien.
Le rappel ne part pas pour un abonnement dont l’annulation est programmée avant la fin de la période (cancelAt ≤ currentPeriodEnd).

​
Jour J : la période avance et le paiement est demandé

Le cron quotidien prend tout abonnement active dont currentPeriodEnd est passé, et pour chacun, dans une seule transaction :
1

Avancer la période

currentPeriodStart ← ancien currentPeriodEnd, currentPeriodEnd ← + intervalle. C’est fait avant de demander le paiement, et jamais reculé en cas d’échec — c’est ce qui rend la facture du cycle unique.
2

Retrouver ou créer la facture du cycle

Celle de J-3 si elle existe, sinon une nouvelle. Le solde client (avoirs) est imputé : amountDue = total − appliedBalance. Si elle est déjà paid, tout s’arrête ici — rien n’est demandé.
3

Demander le paiement

Une intention de paiement est créée pour amountDue, et une demande est poussée sur la méthode de paiement par défaut du client — relue à ce moment, pas celle de la création. L’appel attend la réponse opérateur.
4

Succès

Facture paid, paidAt posé. Événements : invoice.paid, payment.completed, subscription.updated (avec les nouvelles bornes de période).
5

Échec ou pas de méthode par défaut

Facture open, lastPaymentError renseigné. L’abonnement passe past_due, payment.failed et subscription.past_due sont émis, et le calendrier de relances démarre. Voir Paiements échoués.
Il n’y a pas de prélèvement. À chaque échéance, le client reçoit une demande sur son téléphone et doit l’approuver. Un client qui ne répond pas dans le délai est un cas nominal : c’est pour lui que la facture est envoyée à J-3 avec un lien, et que les relances existent.

​
Ce que vous recevez

invoice.paid et payment.completed peuvent arriver deux fois pour un même renouvellement réussi (deux chemins internes les émettent). Dédupliquez sur data.invoiceId / data.orderId.

​
Lire où en est un abonnement

  • currentPeriodEnd : la borne de ce qui a été facturé. Sur un abonnement past_due, elle est déjà avancée.
  • La dernière facture paid (GET /v1/subscriptions/{id}/invoices) : jusqu’où le client a payé.
  • statistics.nextPaymentDate et statistics.nextPaymentAmount sur le détail : la prochaine échéance et son montant (remise appliquée, hors taxe).

​
Le premier cycle

Il diffère selon la porte d’entrée : Les cycles suivants sont tous des subscription_cycle et suivent le mécanisme ci-dessus.