Le prestataire de paiement ne gère-t-il pas tout ça tout seul ?

Il gère le paiement, les relances et la facturation. Il ne gère pas ce que votre application montre à un client en impayé, ni les vingt endroits où l'accès est vérifié. La frontière est là, et c'est de votre côté qu'elle casse.

Puis-je faire mes factures moi-même ?

Vous pouvez, et vous découvrirez les mentions obligatoires, la TVA selon le pays du client, les avoirs et la numérotation continue. Le portail du prestataire fait tout ça, et le client y met sa carte à jour lui-même.

Que se passe-t-il si mon serveur était éteint quand le prestataire a envoyé un événement ?

Si les retours sont seulement reçus, l'événement est perdu. S'ils sont journalisés et que l'application resynchronise périodiquement, l'état se corrige tout seul au passage suivant. C'est la différence entre une application qui dérive et une qui se rattrape.

Faut-il un essai gratuit ?

Ce n'est pas une question technique. Ce qui l'est : un essai est un état de plus, avec une date de fin, un rappel avant, et une conversion ou une coupure après. Décidez-le avant le cadrage, pas pendant le développement.

MVP de SaaS par abonnement : la première version

Le problème, nommé et chiffré

Vendre un abonnement, c’est facile le premier jour : le prestataire de paiement fournit un bouton, le client paie, une case passe à « vrai ». Ce qui se passe ensuite est ce qui casse.

L’abonnement a des états, la case n’en a qu’un. Un client en période d’essai, un client actif, un client dont la carte a été refusée hier, un client qui a résilié mais dont le mois court encore : quatre situations, quatre accès différents. Une case « est abonné » ne sait pas les distinguer, et c’est le code généré le plus courant sur ce type de produit. Le premier impayé montre le problème : le client garde l’accès, ou le perd d’un coup sans préavis.
Les retours du prestataire de paiement sont manqués. Le prestataire prévient votre application de chaque événement, un paiement réussi, un échec, une résiliation, par des appels qu’il faut recevoir, vérifier et traiter. Si votre serveur était indisponible à ce moment-là, l’événement est perdu et l’accès du client ne correspond plus à ce qu’il a payé. Personne ne le voit avant sa réclamation.
La règle d’accès est éparpillée dans l’interface. « Si abonné, afficher le bouton » répété dans vingt écrans, et vérifié dans le navigateur. Un plan de plus, et il faut retrouver les vingt endroits. Un client qui modifie la page, et il a l’accès sans payer.

Notre principe de conception

Le prestataire de paiement est la source de vérité sur ce que le client a payé. Votre application ne fait que refléter cet état, et elle doit pouvoir le redemander à tout moment plutôt que de dépendre d’un message qu’elle a peut-être manqué.

Ce qui fait la différence

Le mécanisme	Ce qu’il évite
Un état d’abonnement explicite, avec ses transitions	Le client en impayé qui garde l’accès, et celui qui le perd sans préavis
Réception des retours du prestataire, vérifiés, journalisés, rejouables	L’événement manqué pendant une indisponibilité, et l’accès incohérent avec le paiement
Synchronisation périodique avec le prestataire	La dérive silencieuse entre ce que le client paie et ce qu’il voit
Droits d’accès décidés côté serveur, en un seul endroit	La règle éparpillée dans vingt écrans, et l’accès obtenu en modifiant la page
Portail de facturation du prestataire, pas le vôtre	Les factures à produire, les mentions légales, la TVA, la carte à mettre à jour

Votre abonnement a-t-il des états ? Si le code dit « est abonné, vrai ou faux », la réponse est non. Décrivez votre produit, nous vous disons ce que ça implique.

Décrire mon projet

Les décisions à prendre avant de démarrer

Un plan, ou plusieurs

Un seul, pour la première version. Deux plans doublent les cas à tester, imposent la règle de changement de plan au milieu d’un mois, et ne vous apprendront rien que vingt clients sur un plan unique ne vous apprennent pas. Le second plan arrive quand des clients demandent ce qu’il contiendrait.

Essai gratuit, avec ou sans carte

Sans carte, plus d’inscriptions et moins de conversions ; avec carte, l’inverse, et un premier prélèvement qui surprend. La décision dépend de votre marché plus que de la technique, mais elle change ce qu’on construit : un essai sans carte est un état de plus, avec sa fin et son rappel.

Ce qui se passe à l’impayé

Combien de tentatives, sur combien de jours, quel accès pendant ce temps, et quand couper. Le prestataire propose une mécanique par défaut ; il faut la connaître et décider si elle vous convient. Un client qui perd tout le jour même d’un refus de carte ne revient pas.

Ce que nous livrons

Les comptes utilisateurs ; un plan et son essai, selon la décision ; le paiement récurrent par le prestataire, avec ses retours reçus, vérifiés, journalisés et rejouables ; l’état d’abonnement et ses transitions ; la synchronisation périodique ; les droits d’accès côté serveur ; le portail de facturation du prestataire intégré ; une administration qui montre l’état de chaque client et son historique de paiement. Un MVP standard. Hors première version : plusieurs plans, remises et codes, facturation à l’usage, équipes et multi-utilisateurs, connexion par un fournisseur d’identité d’entreprise, exportation comptable.

Questions fréquentes

Le prestataire de paiement ne gère-t-il pas tout ça tout seul ?: Il gère le paiement, les relances et la facturation. Il ne gère pas ce que votre application montre à un client en impayé, ni les vingt endroits où l'accès est vérifié. La frontière est là, et c'est de votre côté qu'elle casse.
Puis-je faire mes factures moi-même ?: Vous pouvez, et vous découvrirez les mentions obligatoires, la TVA selon le pays du client, les avoirs et la numérotation continue. Le portail du prestataire fait tout ça, et le client y met sa carte à jour lui-même.
Que se passe-t-il si mon serveur était éteint quand le prestataire a envoyé un événement ?: Si les retours sont seulement reçus, l'événement est perdu. S'ils sont journalisés et que l'application resynchronise périodiquement, l'état se corrige tout seul au passage suivant. C'est la différence entre une application qui dérive et une qui se rattrape.
Faut-il un essai gratuit ?: Ce n'est pas une question technique. Ce qui l'est : un essai est un état de plus, avec une date de fin, un rappel avant, et une conversion ou une coupure après. Décidez-le avant le cadrage, pas pendant le développement.

À lire ensuite