Paddle vs Polar.sh pour les abonnements AI et la facturation à l'usage

J'ai donc construit ce petit SaaS appelé GrandpaCAD. L'idée est simple : mon grand-père adore l'impression 3D mais déteste les logiciels de modélisation complexes. Avec GrandpaCAD, tu décris simplement ce que tu veux, et une IA génère un modèle 3D. Simple.

Pour facturer ça, j'avais besoin d'abonnements plus une facturation à l'usage pour les crédits AI. Facile, non ? Faux.

Pourquoi ne pas simplement utiliser Stripe ?

Tout le monde me pose cette question. Écoute, je viens de Slovénie. Ici, chaque facture doit être "vérifiée fiscalement". Ça veut dire s'intégrer avec une API gouvernementale documentée dans un PDF de 119 pages. Non, je rigole pas. C'est un cauchemar bureaucratique de certificats, de signatures personnalisées, et de douleur.

Pour éviter cette galère, j'avais besoin d'un "Merchant of Record" (MoR). Ils gèrent toutes les conneries de taxes et de facturation pour toi. Paddle est le grand nom dont j'ai entendu parler pendant des années, donc j'ai commencé par là.

Mon voyage de 5 jours en enfer avec Paddle

Je vais accorder ça à Paddle : leur documentation est fantastique. Leur "Setup checklist" et "Go-live checklist" sont vraiment utiles. J'avais l'impression d'être entre de bonnes mains.

Mais ensuite j'ai essayé d'implémenter la facturation à l'usage.

J'ai passé 4-5 jours à me battre avec leur système, et je n'ai simplement pas pu le faire fonctionner de manière raisonnable. Les webhooks étaient un bordel complexe. Mais le vrai problème était bien pire.

La facturation à l'usage de Paddle est fondamentalement cassée.

Voilà le problème : quand un utilisateur annule son abonnement, Paddle... pardonne simplement toute l'utilisation qu'il a accumulée. Pouf. Disparu.

Leur doc suggère une "solution" : quand un utilisateur clique sur ton bouton "annuler", tu déclenches d'abord une facturation immédiate pour son utilisation, et ensuite tu annules l'abonnement.

D'accord, mais qu'en est-il du portail client ? Paddle donne aux clients un portail accessible par email pour gérer leur abonnement. S'ils annulent là-bas, t'as aucun contrôle. Tu peux pas injecter ta logique "facture-les d'abord".

Donc, n'importe quel utilisateur pourrait :

1. S'inscrire.
2. Utiliser une tonne de crédits AI coûteux.
3. Annuler via le portail client juste avant la date de facturation.
4. Ne rien payer pour l'utilisation.
5. Recommencer.

C'est pas un petit bug ; c'est une faille qui attend de détruire ton business. Pour un SaaS AI où l'utilisation coûte vraiment de l'argent, c'était inacceptable.

Voici Polar.sh

Frustré et à court de temps, j'ai cherché des alternatives et je suis tombé sur polar.sh. C'est un acteur plus récent, et j'étais un peu sceptique. Mais putain, quelle différence.

Voici un aperçu rapide de mon expérience :

• Simplicité : Avec Polar, j'ai géré toute la logique d'abonnement avec un seul webhook onSubscriptionUpdated. C'était propre et simple. Paddle donnait l'impression de nécessiter toute une constellation de webhooks pour faire la même chose.
• Facturation à l'usage : Ça marche tout simplement sur Polar. Pas de failles bizarres. Tu rapportes l'utilisation, ils la facturent. C'est tout. C'est exactement ce à quoi tu t'attends.
• Expérience développeur : Polar a des intégrations pour différents frameworks. J'utilise better-auth, et ils avaient une bibliothèque helper pour ça qui rendait les choses encore plus faciles.
• Coût : Polar.sh est 20% moins cher que Paddle. C'est pas rien.

Les inconvénients d'un nouveau venu

C'est pas tout rose. On voit que polar.sh est le nouveau sur le marché. J'ai rencontré quelques bugs bizarres.

La bonne nouvelle ? Leur équipe est incroyablement réactive sur Discord. La mauvaise nouvelle ? Leur équipe est incroyablement réactive sur Discord. Ça veut dire que quand j'ai googlé mes bugs, j'ai rien trouvé. Les solutions étaient enfouies dans des conversations Discord. Je préférerais largement trouver les réponses dans des docs publiques plutôt que de devoir demander sur un serveur de chat, mais bon, au moins j'ai eu mes réponses rapidement.

Les problèmes du nouveau venu

Au cours des derniers mois, j'ai rencontré plus de problèmes que j'aimerais souligner :

• Il y a plusieurs incohérences et comportements non documentés dans l'API. J'ai passé beaucoup de temps à essayer de comprendre. Par exemple, un abonnement avec utilisation mesurée se comporte différemment qu'un simple abonnement. Surtout dans le cas où l'utilisateur veut d'abord recharger des crédits puis passer à un abonnement. L'abonnement mesuré réinitialisera leurs crédits, le non-mesuré non. Et il y a plusieurs cas comme ça.
• Le sandbox semble marcher assez mal - j'ai jamais reçu les crédits qui m'ont été accordés suite à l'achat d'un abonnement. Je sais pas si c'est un problème uniquement du sandbox, mais j'ai tellement galéré à l'implémenter que j'ai mis les mises à jour de tarification en pause jusqu'à ce qu'ils règlent ça. Je peux simplement pas développer quand les choses marchent différemment à chaque fois. Et puis 10 minutes plus tard j'ai reçu les crédits ?
• Les liens de checkout changent les comportements de la plateforme. Pour une raison quelconque, quand j'ai fait un checkout en utilisant le lien généré via le dashboard, j'ai obtenu des résultats différents de quand j'ai fait un checkout en utilisant les liens générés par mon intégration.
• Gros point pour les gens qui prévoient de vendre en Europe : Tu peux pas définir de tarification TTC. Ça veut dire que tes utilisateurs verront probablement un prix "100.00 € + TVA" et non un "120.00 €" comme ils s'y attendraient. Ça peut être assez ennuyeux quand les gens voient un prix sur la page de tarification et un autre sur la page de checkout.

Le verdict

Après avoir perdu une semaine avec Paddle, j'ai intégré et fait fonctionner Polar.sh en un jour.

Paddle est peut-être une plateforme mature avec d'excellentes docs, mais pour mon cas d'usage - la facturation à l'usage pour un SaaS AI - il a un défaut fatal. Leur système permet aux utilisateurs d'éviter facilement de payer pour l'utilisation mesurée, ce qui est simplement inacceptable.

Polar.sh, malgré sa jeunesse et ses aspérités occasionnelles, fait bien les fondamentaux. Leur implémentation de la facturation à l'usage est solide, l'expérience développeur est meilleure, et c'est moins cher.

Si tu construis un SaaS avec facturation à l'usage, épargne-toi la migraine. Jette un œil sérieux à polar.sh. C'est pas parfait, mais ça marche là où ça compte.

Edit : Depuis, j'ai voulu mettre à jour l'intégration de tarification et j'ai tellement galéré que j'ai dû la mettre en pause jusqu'à ce que leur équipe résolve certains problèmes. L'un d'eux est documenté dans cette issue github