Paiement pour solo founder : Stripe, Paddle, Lemon Squeezy ou WeChat Pay ?

Avertissement : ce texte ne constitue pas un conseil fiscal, juridique, de création de société, de change ou d’éligibilité. Pour le Merchant of Record, la VAT/GST/sales tax, les structures nationales ou étrangères et les versements, consultez les conditions des services et des professionnels qualifiés.

Votre pricing.ts définit starter_monthly, pro_yearly, lifetime_license et wechat_one_time, mais la base ne possède qu’un champ is_paid. Le webhook checkout.session.completed arrive et le client revient par success_url, pourtant entitlements reste vide. Le problème ne vient pas du bouton de paiement : produits, commandes, abonnements et droits ne sont pas reliés.

Avant de choisir un service, il faut répondre à cinq questions : que vendre, comment facturer, à qui vendre, qui porte la transaction et les taxes de vente, et qui accorde l’accès après paiement ? Stripe, Paddle, Lemon Squeezy et WeChat Pay ne sont pas quatre boutons équivalents. Leurs responsabilités se situent à des niveaux différents.

Définir le modèle de vente avant le service de paiement

Un achat unique repose sur la commande et la livraison. Un abonnement SaaS implique tout le billing lifecycle. La facturation à l’usage exige aussi des données d’utilisation traçables. Modélisez d’abord ces choix dans products, prices et les tables locales.

Trois points comptent :

• Un produit unique demande surtout commande, livraison, remboursement et renvoi, sans cycle d’abonnement complet.
• Un SaaS récurrent a besoin d’une table subscriptions avec current_period_start/end, cancel_at et status. La consommation impose des usage_events auditables.
• WeChat Pay est un moyen de paiement et un système marchand, pas un Merchant of Record mondial ni une plateforme de SaaS billing.

Les capacités de Stripe Billing, Paddle Billing et WeChat Pay évoluent. Avant l’intégration, revérifiez région du compte, mode produit, moyens de paiement, version d’API et conditions.

Un Merchant of Record ne supprime pas toutes les responsabilités

Le Merchant of Record, ou MoR, est le vendeur officiel d’une transaction. Paddle et Lemon Squeezy utilisent ce modèle pour les produits numériques éligibles et gèrent dans ce cadre paiement, taxes de vente, remboursements ou litiges. Cela réduit le travail fiscal et opérationnel mondial, sans supprimer les obligations relatives à l’impôt sur le revenu, à la structure, à la conformité produit, aux données et à la comptabilité.

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

Avec Stripe, le marchand reste généralement vendeur officiel. Stripe Tax aide à calculer sales tax, VAT et GST et propose des outils de surveillance et d’enregistrement, mais ne transforme pas automatiquement Stripe en Merchant of Record. Enregistrement, déclaration et responsabilité dépendent du territoire et de la transaction.

Ne choisissez pas un MoR selon un seuil de revenus fixe. Comparez plutôt ces dimensions :

La limite contractuelle et fiscale dépend de la structure, du territoire, du produit et du client. Une page marketing présente un positionnement ; elle ne remplace ni les conditions ni un avis professionnel.

Choisir Stripe, Paddle, Lemon Squeezy ou WeChat Pay

Si vous voulez des abonnements et WeChat Pay, séparez d’abord les problèmes. Cycle d’abonnement, paiements mondiaux et paiement en Chine continentale peuvent utiliser des services différents. La présence d’un moyen de paiement ne garantit pas chaque région de compte, mode Checkout ou paiement récurrent.

Les documents officiels confirmaient au 18 juillet 2026 :

• Stripe Checkout propose page hébergée, page intégrée et composants combinables. Les moyens disponibles dépendent de la région, de la devise et du mode Checkout.
• Les webhooks Paddle sont livrés au moins une fois. Sans réponse 200 en cinq secondes, Paddle réessaie. Les événements peuvent être dupliqués ou désordonnés ; utilisez event_id pour dédupliquer et occurred_at pour l’ordre.
• Lemon Squeezy liste Cards, PayPal, Apple Pay, Google Pay, Alipay, WeChat Pay, Cash App Pay et bank debits. Les abonnements n’acceptent actuellement que Cards, Apple Pay, Google Pay et PayPal.
• Le flux H5 de WeChat Pay exige création de commande côté serveur, callback et requête active de statut. Le retour navigateur n’est pas une preuve suffisante.

Frais, moyens, cycles de versement, pays et politiques évoluent. Pour le budget final, ouvrez les pages de prix et les contrats du jour plutôt que de recopier un ancien pourcentage.

Le webhook est la frontière de synchronisation des droits

Deux échecs fréquents :

1. checkout.session.completed arrive et success_url est visité, mais entitlements n’est pas mis à jour et le client payant reste bloqué.
2. Le même événement entre deux fois dans webhook_events et le handler émet deux licences.

Ces erreurs viennent du fait qu’une requête HTTP ou une page de succès est traitée comme vérité métier finale. Les événements peuvent être dupliqués, retardés ou désordonnés. Certains états exigent aussi une requête ou un événement ultérieur.

Principes de conception d’un endpoint webhook

Les règles d’exploitation sont simples :

• Le webhook ou callback est l’entrée de synchronisation. success_url affiche le traitement sans accorder les droits.
• Vérifiez d’abord la signature, puis stockez l’événement brut ou les champs requis dans webhook_events. Déplacez le travail complexe vers un job asynchrone.
• Une contrainte unique assure l’idempotence. Enregistrez event_id, source, occurred_at, processed_at, status et payload_hash.
• Pour l’ordre, comparez heure de l’événement, mise à jour de l’objet ou version d’état, jamais uniquement l’heure d’arrivée.
• Exécutez régulièrement une reconciliation, interrogez commande ou abonnement et conservez une reprise manuelle.

Tables de commandes, abonnements, droits et événements

Ne copiez pas tous les objets d’une API dans les tables locales. Définissez les champs stables nécessaires au contrôle d’accès, puis conservez les ID fournisseur pour requêtes et reconciliation.

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

Stratégies de synchronisation des droits

La documentation officielle de provisioning Paddle recommande un lean cache pour la plupart des applications. Passez au state mirror seulement si des requêtes locales plus riches sont nécessaires. Les clés Lemon Squeezy exigent aussi de valider produit et client côté application et de relier l’instance au modèle de compte et d’appareil.

Points d’intégration propres à chaque service

Ces points définissent une première limite de mise en œuvre sans remplacer la documentation complète des services.

Intégrer Stripe

Un jeune SaaS peut commencer par Checkout hébergé et Customer Portal plutôt que maintenir un formulaire de carte. Stripe Billing gère abonnements, factures, facturation à l’usage et revenue recovery. Stripe Tax est un outil de calcul et de processus fiscal, pas un Merchant of Record.

Produits et prix doivent correspondre aux droits locaux : product_id représente le produit ou paquet d’accès, price_id le tarif mensuel, annuel, par seat ou usage. Ne laissez pas seulement is_paid sur users.

Le tutoriel Next.js de panier et paiement Stripe présente Checkout Session, endpoint webhook et traitement de commande.

Intégrer Paddle

Vérifiez qu’un tutoriel vise Paddle Billing et non Paddle Classic. Leurs API, webhooks, Paddle.js et modèles Product/Price diffèrent.

Paddle Checkout affiche la caisse, mais l’application reste responsable du provisioning. La plupart n’ont besoin que de customer, subscription, status, price, product et scheduled change pour décider l’accès. Créez un state mirror seulement si les opérations exigent les données complètes.

Dans les deux cas, mettez le cache à jour par webhook et lancez une reconciliation. Un Merchant of Record ne dit pas automatiquement à l’application qui peut utiliser quelle fonction.

Intégrer Lemon Squeezy

Lemon Squeezy est un point de départ pour produits numériques, licences et abonnements assez simples. Il fournit Merchant of Record, checkout, abonnements, usage-based billing, webhooks et License Keys. Vérifiez frais et portée dans le store plan et la documentation actuels.

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

Après activation, stockez l’instance ID et vérifiez store_id, product_id, variant_id et customer. Une clé d’un autre produit ou revendue ne doit pas donner directement le droit Pro.

Pour un abonnement WeChat Pay, vérifiez séparément les moyens récurrents. La documentation liste WeChat Pay et Alipay, mais les abonnements n’acceptent que Cards, Apple Pay, Google Pay et PayPal.

Limites de WeChat Pay

WeChat Pay convient aux paiements en Chine continentale et dans WeChat, mais n’est ni un Merchant of Record mondial ni un cycle de SaaS billing complet. Le marchand doit gérer état de commande, signature du callback, requêtes, remboursements, reconciliation, factures et droits.

H5, JSAPI, Mini Program et Native sont des scénarios de paiement, pas des systèmes d’abonnement. En H5, le backend crée la commande et transmet h5_url au frontend. Après le retour du navigateur, il interroge encore la commande et applique le callback à celle identifiée par out_trade_no.

Vérifiez droits produit, entité marchande, domaines, frais et paramètres API dans la documentation marchande WeChat Pay actuelle.

Étape suivante : transformer le bouton en machine à états testable

Après le choix des services, découpez l’intégration en tâches vérifiables :

1. Créez orders, subscriptions, entitlements et webhook_events, puis usage_events pour la consommation.
2. Implémentez signature, idempotence, désordre, réponse rapide et reprise pour chaque webhook ou callback.
3. Faites interroger l’état local par la page de succès au lieu d’écrire is_paid=true.
4. Ajoutez des tests de requête, reconciliation, remboursement, renouvellement échoué et reprise manuelle.
5. Dans la sandbox, renvoyez les événements et inversez les mises à jour. Les droits ne doivent être ni doublés ni annulés à tort.

Pour l’hébergement backend et la base de données, poursuivez avec le guide pratique Supabase Edge Functions et les articles backend et base de données de cette série. La fin n’est pas le retour réussi de la page de paiement : commandes, abonnements et droits doivent converger vers le bon état malgré doublons, retards, désordre et remboursements.