For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /fr/docs/modules/billing.md (or send Accept: text/markdown).
Facturation et accès
Séparez les événements de paiement des décisions d’autorisation.
Choisissez et testez votre service de paiement
La facturation gère les paiements. Les autorisations d'accès sont stockées séparément en tant que droits. Terminez la configuration du compte persistant, puis ouvrez /billing dans l'application Web en cours d'exécution pour voir l'interface du plan. Avec BILLING_PROVIDER=local, vous explorez le comportement local plutôt que de collecter de l'argent réel.
Choisissez un fournisseur de paiement pris en charge, suivez son guide de configuration, créez votre propre produit de test et votre prix, puis copiez les paramètres du serveur nommés dans apps/web/.env.local.. Enregistrez et redémarrez le serveur Web. Effectuez une extraction à l’aide des instructions sandbox de ce fournisseur, puis inspectez l’état d’accès à l’espace de travail après l’arrivée du webhook du fournisseur. Un webhook est le message signé du fournisseur adressé à votre serveur concernant un événement de paiement.
Une page de réussite ne débloque pas à elle seule des fonctionnalités. Si le paiement est terminé mais que l'accès reste inactif, vérifiez la livraison du webhook du fournisseur et le traitement des événements de votre serveur avant de répéter le paiement. Annulation du test et accès expiré également. Les achats par téléphone utilisent la configuration RevenueCat/magasin distincte, et non cette commande Web.
Facturation web
L'application Web prend en charge le fournisseur de facturation que vous sélectionnez avec BILLING_PROVIDER ; Stripe est une option. Ouvrir /facturation pour les forfaits Web et la gestion des abonnements. Suivez le guide du fournisseur sélectionné pour définir ses informations d'identification de serveur uniquement, ses identifiants de produit ou de prix et ses paramètres de vérification du webhook dans le test correspondant ou dans l'environnement en direct.
Autoriser avec les droits d’accès
Une redirection vers le paiement ne prouve pas que l’accès est actif. Le droit d’accès détenu par le serveur décide si un espace de travail peut utiliser une fonctionnalité payante. Vérifiez ce droit à la frontière de l’action, même si l’interface masque déjà cette action.
Vérifier le cycle de vie
Utilisez des événements de test pour vérifier l’activation, les mises à jour, l’annulation et le traitement des webhooks. Gérez les événements répétés sans effet indésirable et assurez-vous qu’un droit inactif bloque les opérations payantes. Les achats mobiles natifs restent une frontière d’intégration RevenueCat distincte.