Skip to main content
Un renouvellement échoue quand le client refuse la demande de paiement, ne répond pas dans le délai, n’a pas le solde, ou n’a plus de méthode de paiement par défaut. Voici la séquence.

​
Le jour de l’échéance

1

L'abonnement passe past_due

Dès le premier échec, dans la même transaction que la tentative. Vous recevez payment.failed et subscription.past_due. La facture reste open avec lastPaymentError renseigné.
2

Les relances sont programmées

Trois tentatives automatiques, sur la méthode de paiement par défaut du client, relue à chaque fois :Chaque relance est une nouvelle demande sur le téléphone du client. attemptCount et nextAttemptAt sur la facture suivent le calendrier.
3

Un succès régularise

La facture passe paid, l’abonnement repasse active et vous recevez subscription.activated — c’est le seul chemin qui émet cet événement, avec retry-payment.
4

Après la troisième, rien

L’abonnement reste past_due, indéfiniment. Aucune annulation automatique, aucun passage en unpaid ou uncollectible. C’est à vous de décider : relancer à la demande, annuler, ou attendre.
Aucun e-mail n’est envoyé au client sur un échec de paiement, ni à la première tentative ni aux suivantes. Le seul e-mail qu’il a reçu est celui de la facture, trois jours avant l’échéance, avec son lien de paiement. Si vous voulez prévenir le client, faites-le depuis vos webhooks (payment.failed, subscription.past_due).

​
Cas particuliers

Un past_due prolongé laisse le client avec ses droits : rien dans Yabetoo ne les coupe. Si votre produit doit restreindre l’accès d’un client impayé, faites-le sur réception de subscription.past_due, et rendez-le sur subscription.activated.

​
Lire l’état d’un impayé

  • GET /v1/subscriptions/{id} : status: "past_due", currentPeriodEnd déjà avancé.
  • GET /v1/subscriptions/{id}/invoices : la facture open du cycle, avec attemptCount, nextAttemptAt, lastPaymentError.
  • GET /v1/invoices?subscription_id=sub_...&status=open : la même chose, paginée.