API de paiements récurrents

Ce qui passe sur le fil

• Où elle se situe

  Au-dessus de l’API de paiement, pas à côté. Un plan produit des débits, et chaque débit est un paiement ordinaire avec les mêmes états, les mêmes codes d’erreur et les mêmes règlements que le reste du compte.

• Ce que vous envoyez

  Un plan : montant, intervalle, essai ou frais d’installation, politique de relance et jeton à facturer. Puis un abonné rattaché. La référence nomme chaque champ et précise ce qui est figé à la création.

• Ce qui revient dans le temps

  Des événements, pas une valeur de retour. Renouvellement réussi, renouvellement échoué, relance réussie, changement de plan, fin d’abonnement : chacun arrive en webhook, et qui ne lit que la réponse de création ignore tout après le premier cycle.

Quand l’utiliser

• Des revenus qui se répètent

  Tout débit qui revient selon un calendrier appartient ici, plutôt qu’à un traitement planifié qui appelle l’API de paiement et réimplémente mal les relances.

• Les plans de versements

  Un nombre fixe de débits égaux après un acompte, courant en santé et en services professionnels, est un calendrier avec une date de fin plutôt qu’un abonnement ouvert.

• Des plans qui changent

  Montées, descentes et pauses en cours de cycle exigent prorata et piste d’audit. Les deux s’héritent plus facilement qu’ils ne se construisent, et c’est là que la facturation maison diverge du grand livre.

Mettre en œuvre API de paiements récurrents

Ce qui échoue, et comment vous l’apprenez

• Relancer un refus définitif selon le calendrier

  La séquence de relance vise les refus temporaires. Un compte fermé échoue identiquement aux jours 3, 7 et 14, chez un émetteur qui a déjà refusé.

• Annuler au premier échec

  La plupart des renouvellements échoués tiennent à une carte expirée ou réémise, pas à un départ. Mettre fin à l’abonnement au premier refus transforme un paiement récupérable en perte.

• Un état de plan qui n’existe que chez vous

  Si votre base dit actif et le moteur dit annulé, le client vit ce que lit votre produit. Faites dériver votre état des événements plutôt que de ce que vous avez écrit à la création.

• Aucune trace de consentement

  Un débit récurrent contesté se défend avec l’autorisation recueillie à l’inscription. Ne pas la conserver transforme un litige ordinaire en litige indéfendable.

Sandbox par rapport à la production

• Des cycles sans attendre un mois

  Le sandbox permet d’observer un plan mensuel sur plusieurs renouvellements d’un seul trait : c’est la seule façon pratique de tester le recouvrement sans attendre le calendrier réel.

• Des échecs à la demande

  Une carte de refus documentée rattachée à un plan produit un renouvellement échoué et la séquence de relance qui suit : le chemin de récupération s’affirme au lieu de s’espérer.

• Les résultats de mise à jour sont simulés

  Le sandbox peut montrer une carte rafraîchie sauver un renouvellement. La récupération réelle dépend de la participation du réseau et de l’émetteur : voyez-y une preuve de traitement, pas un taux à planifier.