Encaisser le premier paiement, c'est une après-midi de travail. Ce qui prend du temps, et ce qui fait perdre des clients quand c'est bâclé, c'est tout ce qui vient après : la carte qui expire, la formule qui change au milieu du mois, la résiliation, le remboursement, la facture qu'on vous réclame.
Un abonnement n'est pas un paiement répété, c'est un état : à chaque instant, votre application doit savoir si ce client a le droit d'entrer, et pourquoi. Cet état-là ne vit pas dans votre base, il vit chez Stripe, et le seul moyen fiable de le suivre est d'écouter ce que Stripe raconte plutôt que de croire ce que le navigateur affiche.
Je ne fais pas que brancher la bibliothèque : deux de mes propres applications encaissent en production avec ce mécanisme, et une troisième le vend comme socle à d'autres développeurs. Les erreurs de ce terrain-là, les accès accordés sur une page de retour que l'utilisateur peut fermer, les webhooks rejoués deux fois, les impayés qui ne coupent rien, je les ai payées avant de vous en parler.
Page de paiement hébergée par Stripe, mensuel et annuel, période d'essai, retour propre côté application : aucun numéro de carte ne traverse votre serveur, ce qui vous laisse dans le questionnaire de conformité le plus léger plutôt que dans un audit PCI en règle.
Signature vérifiée à chaque appel, paiement confirmé, facture payée, prélèvement refusé, abonnement modifié ou résilié : chaque événement met l'état à jour. Reçu deux fois, il ne produit qu'un seul effet, et Stripe peut rejouer trois jours sans rien casser.
Essai, actif, impayé, suspendu, résilié en fin de période : chaque état dit ce que le client voit encore. Changement de formule au prorata, annulation à échéance, réactivation, et le portail Stripe pour que le client change sa carte et récupère ses factures sans vous écrire.
Numérotation, TVA, historique téléchargeable, et le format structuré quand vos clients sont des entreprises : j'ai écrit un moteur Factur-X et PEPPOL conforme à la norme EN 16931, vérifié en intégration continue contre les validateurs officiels allemand et européen.
Boilerplate SaaS pour Symfony
Boilerplate commercial pour lancer un SaaS Symfony sans réinventer l'infrastructure : authentification (magic links, 2FA), facturation Stripe & Lemon Squeezy, multi-tenant avec équipes et rôles, dashboard admin (MRR, churn), chat IA en streaming. Suite de tests qui rejoue des cycles de facturation complets depuis des webhooks signés, PHPStan au niveau maximum sans aucune dérogation.
SaaS · organisation du foyer
Application de répartition équitable des tâches ménagères en famille : PWA installable, notifications push, abonnements Stripe et répartition des points entre membres du foyer.
Assistant juridique par IA
Plateforme privée d'aide à la constitution de dossiers juridiques, assistée par IA : journal de faits horodatés avec pièces, assistant répondant à partir du dossier (RAG), contrôles de confidentialité granulaires. Hébergement en France, données chiffrées.
Non, et il vaut mieux ne pas le faire. La saisie se passe sur une page hébergée par Stripe : votre serveur ne voit jamais un numéro de carte, il reçoit un identifiant de client et un identifiant d'abonnement. C'est ce qui vous maintient dans le questionnaire d'auto-évaluation le plus simple au lieu d'un audit de conformité complet, et c'est aussi ce qui évite d'avoir à répondre un jour de la fuite d'un fichier de cartes.
Cela se décide sur la TVA, pas sur la technique. Avec Stripe, le vendeur c'est vous : vous collectez la TVA de chaque pays où vous vendez et vous la déclarez. Avec Lemon Squeezy, c'est la plateforme qui est le vendeur officiel et qui porte cette charge, contre une commission sensiblement plus élevée. Je sais brancher les deux, et le socle SaaS que je vends les gère derrière la même interface : le choix reste réversible.
Stripe retente automatiquement selon un calendrier que l'on règle, l'abonnement passe en impayé et votre application le sait dans la seconde. Restent deux décisions qui vous appartiennent et que je pose noir sur blanc avant d'écrire la moindre ligne : au bout de combien de jours l'accès se restreint, et ce qui reste visible ensuite. Un compte qu'on coupe brutalement ne revient pas ; un compte qui passe en lecture seule revient souvent.
Si vous facturez des entreprises françaises, oui, au moins pour la réception : à partir du 1er septembre 2026 toute entreprise doit être en mesure de recevoir une facture au format structuré, l'obligation d'émettre arrivant selon la taille de l'entreprise. Concrètement, cela veut dire des factures conformes à la norme EN 16931 plutôt qu'un PDF envoyé par e-mail. C'est un sujet que j'ai déjà traité en code, mais votre calendrier exact se confirme avec votre expert-comptable, pas avec moi.
Oui, c'est même le cas le plus courant, et la partie technique est la plus rapide : une table d'abonnements, un point d'entrée pour les webhooks, une page d'état et le portail client. Le vrai travail est ailleurs : décider ce que l'abonnement ouvre exactement, ce qu'un compte gratuit garde, et ce qu'il advient des données de quelqu'un qui arrête de payer. Tant que ces règles ne sont pas écrites, aucun code ne peut être juste. Et sur une application dont plus personne ne s'occupe, la reprise du projet existant puis la montée de version Symfony passent avant : le paiement se branche sur un socle tenu, jamais sur un socle abandonné.
Mon tarif de référence est de 650 € par jour. Un tunnel d'abonnement complet se chiffre le plus souvent au forfait, après un cadrage court : ce qui fait le prix, ce sont vos règles (les formules, le prorata, ce qui se coupe et quand), pas le branchement de Stripe, qui est la partie la mieux balisée du travail.
Décrivez vos formules en quelques lignes : ce qu'elles ouvrent, à qui vous facturez, et où vous en êtes aujourd'hui. Je réponds sous 24 h, avec un avis franc sur ce qui peut se régler dans le tableau de bord Stripe sans écrire une ligne de code.