Une lettre à quelqu'un sur le point de facturer son premier client

Salut — j'ai vu ton message ce matin, la capture d'écran de quelqu'un demandant "comment est-ce que je te paie pour ça" dans la boîte de support de ton appli. Félicitations, sincèrement. C'est le moment où un projet perso cesse d'être une démo. C'est aussi le moment où une centaine de petites décisions que tu as pu reporter surgissent toutes le même mardi. Tu m'as demandé de te dire simplement quoi faire. Je vais le faire, mais je veux d'abord t'expliquer pourquoi, parce que le "pourquoi" est ce qui t'évitera de devoir me redemander dans trois mois, quand ce sera Lemon Squeezy au lieu de Stripe, ou des abonnements au lieu d'un achat unique.

La décision que tu prends réellement

Tu as présenté ça comme "quel prestataire de paiement dois-je utiliser", mais ce sont en réalité deux décisions empilées l'une sur l'autre. Premièrement : veux-tu être le vendeur officiel (merchant of record), ou veux-tu que quelqu'un d'autre le soit ? Deuxièmement : quelle est la forme de ta facturation — achat unique, abonnement, ou à l'usage ? Si tu te trompes sur la première, tu passeras un week-end dans six mois à t'enregistrer pour la TVA dans un pays où tu n'as jamais mis les pieds. Si tu te trompes sur la seconde, c'est une migration ennuyeuse, pas juridique — donc la moins effrayante des deux.

Être le vendeur officiel signifie que c'est toi, légalement, qui vends le produit. Tu encaisses l'argent, tu es responsable de déterminer la taxe de vente et la TVA dans chaque juridiction où résident tes clients, et tu dois les déclarer. Stripe calculera volontiers cette taxe pour toi (Stripe Tax), mais calculer n'est pas reverser — tu dois quand même t'enregistrer et déclarer dans chaque endroit où tu dépasses un seuil. Un service de type merchant of record comme Lemon Squeezy ou Paddle t'enlève complètement ce problème : ils sont légalement le vendeur, ils collectent et reversent la taxe partout, et ils te paient le net. Tu cèdes une partie de ta marge en échange.

Pour la situation où vous en êtes actuellement — un client, un produit simple, aucune idée pour l'instant si cela deviendra une entreprise — je vous orienterais vers Lemon Squeezy ou Paddle plutôt que Stripe brut. Les deux points de frais supplémentaires sont une assurance bon marché contre le fait de devenir accidentellement redevable de taxes dans un État où vous n'avez jamais mis les pieds. Vous pourrez migrer vers Stripe direct plus tard, une fois que le volume justifiera le changement et que vous aurez le courage d'affronter la paperasse. Personne ne migre de fournisseur de paiement pour le plaisir, mais c'est un problème résoluble en un mardi, pas en une année.

J'ai fait cette erreur moi-même sur un projet précédent — je suis allé directement chez Stripe parce que « tout le monde utilise Stripe », j'ai collecté quelques centaines de dollars par mois auprès d'une poignée de clients européens, puis j'ai reçu dix-huit mois plus tard un e-mail très poli mais très déroutant à propos de l'enregistrement VAT MOSS. Cela m'a coûté une après-midi de comptable et quarante minutes de panique pure en cherchant sur Google « dois-je de l'argent aux Pays-Bas ». Pas catastrophique. Mais entièrement évitable.

Avant de toucher aux clés de production

Quoi que vous choisissiez, ne le branchez pas d'abord en mode production. Chacun de ces fournisseurs dispose d'un mode test/bac à sable avec des numéros de carte factices qui déclenchent des résultats spécifiques — paiement réussi, carte refusée, 3D Secure requis, fonds insuffisants. Testez-les tous avant de toucher une vraie clé. Ce sont les scénarios d'échec que vous rencontrerez réellement la première semaine, et ils sont bien moins agréables à déboguer en direct avec la carte d'une vraie personne engagée.

Dans votre chat de construction, précisez explicitement que vous voulez procéder par étapes : demandez que l'intégration soit branchée en mode test d'abord, avec une bannière ou un indicateur bien visible pour que personne — y compris vous-même plus tard — ne débite accidentellement une vraie carte pendant les tests. Puis prévoyez une deuxième étape, délibérée, pour basculer sur les clés de production. Deux instructions, pas une, même s'il serait plus rapide de simplement dire « ajoute les paiements » et de laisser deviner quel mode utiliser. Cette friction est voulue.

Vous devez aussi décider ce qui se passe quand un webhook se déclenche alors que votre serveur est en panne, lent, ou que l'événement arrive deux fois. Ce n'est pas hypothétique — cela arrive dès la première semaine, systématiquement. Les événements que vous devez au minimum gérer :

• checkout.session.completed (ou l'équivalent) — accordez l'accès, c'est le moment où le client devient réellement un client
• invoice.payment_failed — pour les abonnements, décidez dès maintenant si c'est un blocage instantané ou un délai de grâce, car un « blocage instantané » fait vraiment mauvaise impression pour une carte qui a simplement connu un incident temporaire
• customer.subscription.deleted — quelqu'un a annulé, révoquez l'accès en fin de période, pas immédiatement, sauf si vos conditions indiquent le contraire
• Un événement de remboursement — décidez une fois pour toutes, par écrit pour vous-même, quelle est réellement votre politique de remboursement, avant que la première demande de remboursement ne vous force à la décider en direct

L'idempotence compte plus ici que presque partout ailleurs dans votre application. Si un webhook arrive deux fois — et cela arrivera, les fournisseurs relancent en cas de réponse non-200 — vous ne devez pas accorder l'accès deux fois, ni, pire, débiter deux fois l'état interne. Stockez l'identifiant de l'événement et vérifiez que vous ne l'avez pas déjà traité avant d'agir.

La question de tarification que vous évitez

Vous avez mentionné dans votre message ne pas être sûr de facturer 9 $/mois ou un montant unique de 49 $. Je ne pense pas que l'un ou l'autre soit une erreur, mais remarquez ce que vous évitez réellement : la conversation avec le client sur la valeur récurrente réelle. Un prix unique est plus facile à accepter et plus facile à construire pour vous (pas de relances d'impayés, pas de gestion des renouvellements échoués, pas de flux d'annulation). Un abonnement est un pari que vous continuerez à améliorer le produit suffisamment pour que les gens ne partent pas — un vrai engagement, pas juste une case à cocher sur une page de tarifs. Si vous n'êtes pas sûr de travailler encore activement sur ce projet dans six mois, un prix unique est l'offre la plus honnête. Vous pourrez toujours ajouter un palier d'abonnement plus tard, une fois qu'il y aura quelque chose de continu à proposer.

Une dernière chose, et je vous laisse y retourner : mettez une véritable politique de remboursement et d'annulation sur la page avant d'encaisser le premier dollar, même si ce n'est que trois phrases. Pas parce que quelqu'un va vous poursuivre pour un débit de 9 $, mais parce que l'écrire vous force à réellement la décider, et « je verrai ça quand quelqu'un demandera » est la meilleure façon de finir par prendre une décision de politique en plein e-mail furieux plutôt que dans une après-midi calme.

Allez brancher le bac à sable en premier. Envoyez-moi un message quand vous aurez fait passer une fausse carte refusée dedans — c'est cette version de « ça marche » qui compte vraiment.