Paiement récurrent : organiser échéances et accès

Décrire la période vendue

Commencez par une règle lisible : quelle prestation couvre chaque échéance et à quelle date commence la période suivante ? Une équipe peut facturer un accès mensuel, une maintenance ou un volume de travail convenu. Ces situations n’ont pas les mêmes conséquences si le règlement arrive en retard. Stockez l’identifiant du contrat, celui de l’échéance et les dates de couverture. Évitez d’utiliser uniquement la date de la transaction pour déduire la période, surtout après un changement d’offre ou une régularisation manuelle.

Facturation à l’usage et abonnements — Soon

Séparer consentement et disponibilité technique

La possibilité de demander des paiements futurs dépend de la solution choisie, des moyens de paiement et des conditions applicables au compte marchand. Vérifiez ces points directement avec le PSP et votre équipe compétente. Une carte déjà utilisée ne suffit pas à décrire l’accord du client. Conservez la référence de l’autorisation dans le système prévu à cet effet et préparez un parcours clair pour modifier ou arrêter le service. Ce travail doit précéder toute promesse d’abonnement automatique dans votre interface.

Intégration et API

Créer une échéance distincte de la transaction

Une échéance commerciale peut exister avant qu’une tentative de paiement soit lancée. Elle peut ensuite avoir plusieurs événements techniques, sans devenir plusieurs ventes. Par exemple, l’abonnement de novembre reste une seule obligation même si le client doit mettre à jour son moyen de paiement. Utilisez des références distinctes pour le contrat, l’échéance et la tentative. Une demande technique répétée après un délai réseau doit reprendre la stratégie d’idempotence documentée, afin de ne pas créer une nouvelle opération par accident.

Page de paiement hébergée

Décider du traitement des résultats incertains

Définissez les états que vos équipes peuvent comprendre : échéance à régler, résultat en attente, paiement confirmé ou examen nécessaire. N’inventez pas une réussite parce que le client est revenu sur une page de confirmation. Les notifications serveur et la consultation du statut permettent de suivre le résultat indépendamment du navigateur. Si une opération reste incertaine, vérifiez-la avant de lancer une autre demande. L’automatisation doit respecter cette incertitude, plutôt que masquer le problème par une succession de tentatives non contrôlées.

Relier le règlement au droit d’accès

Le service doit savoir quelle période peut être activée et quelle règle appliquer lorsqu’une échéance n’est pas réglée. Définissez une procédure de contact, une éventuelle période de tolérance et le traitement d’un arrêt. Il s’agit de décisions commerciales à formaliser dans votre propre cadre, pas de paramètres à déduire d’un webhook. Assurez-vous qu’un événement reçu deux fois ne prolonge pas deux fois l’abonnement. Gardez une trace de la décision pour que le support puisse expliquer l’état de l’accès.

Choisir les outils selon leur périmètre réel

OrsunPay fournit une couche d’intégration entre vos comptes PSP, des statuts de paiement et des notifications signées. Le module complet de billing marchand est prévu, mais il n’est pas disponible aujourd’hui. Ne l’assimilez donc pas à un moteur d’abonnement déjà opérationnel. Vos contrats PSP restent les vôtres et les frais logiciels sont facturés séparément. Évaluez le système qui gère réellement le calendrier, les documents et les accès, puis raccordez le paiement à ce système.

• Attribuer un identifiant stable à chaque échéance.
• Documenter les modifications d’offre et les arrêts.
• Tester une notification répétée et une réponse retardée.
• Nommer le responsable des échéances en attente.
• Vérifier les fonctions récurrentes avec le fournisseur concerné.

Sources

• Documentation Stripe sur les webhooks
• Documentation Mollie sur les paiements