Abonnement vs one-shot : ce que les données de paiement disent vraiment

2 tableaux de bord.

C'est le minimum si vous vendez du one-shot et de l'abonnement dans la même stack paiement.

Le problème, c'est que beaucoup d'équipes regardent encore un seul dashboard global.

Elles mélangent :

conversion checkout,

taux d'autorisation,

failed payments,

retries,

et revenu récupéré.

Puis elles concluent que "le paiement va bien".

Non.

Le one-shot et l'abonnement n'ont pas les mêmes vérités opérationnelles.

En one-shot, je veux surtout voir :

entrée checkout,

tentative,

autorisation,

completion,

fee par transaction.

En abonnement, je veux voir autre chose :

réussite au renewal,

causes d'échec,

performance du dunning,

Account Updater,

rechute au cycle suivant.

Si vous mettez tout dans la même vue, vous pouvez avoir un checkout propre et une récurrence qui fuit.

Ou l'inverse.

C'est pour ça qu'une stack paiement "unique" n'est pas automatiquement une stack bien pilotée.

Le bon setup ne commence pas par un deuxième PSP.

Il commence par deux lectures séparées du revenu :

encaisser l'achat,

puis protéger la récurrence.

Si vous voulez, je peux partager le mini schéma de dashboard que j'utiliserais pour séparer proprement one-shot et abonnement.