Séparer les deux usages de Stripe
La facturation de l’abonnement à Reylin n’est pas la connexion d’analyse des clients. Un compte marchand partagé peut contenir des services sans rapport entre eux. Choisissez un périmètre de produits sélectionnés, ou choisissez explicitement une analyse de tout le compte uniquement lorsque celui-ci relève intégralement du projet. Aucune métadonnée cliente ne peut établir l’admissibilité d’un produit.
La politique de lancement réservée au propriétaire est non facturable et n’autorise actuellement que l’analyse des clients en mode test. La collecte en production reste soumise à une validation et à une autorisation distinctes.
Liste de vérification de la connexion
- Utilisez un espace de travail de propriétaire vérifié et une origine de site approuvée, pas la démo synthétique partagée.
- Confirmez le compte du prestataire et le mode test ou production avec des identifiants faisant autorité avant d’enregistrer une connexion.
- Choisissez le périmètre de produits immuable du projet avant d’ingérer des paiements. Un changement de périmètre exige un projet distinct, pas la réécriture d’anciens encaissements.
- Configurez l’endpoint webhook exact et le secret de signature via un circuit sécurisé et approuvé de gestion des identifiants. Ne collez jamais de clés dans un guide, un article, la console du navigateur ou une conversation.
- Confirmez la vérification de signature du corps brut et la transmission, puis examinez séparément la réussite du paiement et celle de l’attribution.
Décisions pour les produits sélectionnés
Les lignes de Checkout ou la répartition canonique des paiements de facture fournissent des preuves de produit faisant autorité. Chaque ligne incluse doit être résolue et appartenir à l’ensemble de produits choisi. Un paiement entièrement sans rapport est exclu ; les preuves mixtes, ambiguës, manquantes ou non prises en charge sont mises en quarantaine. Aucune répartition proportionnelle du revenu n’est devinée.
Le montant de l’encaissement reste le montant payé faisant autorité, y compris pour les paiements de facture partiels ou remisés pris en charge. Il n’est pas remplacé par une somme de lignes. Les contrôles de preuve portent sur le compte, le mode, l’identité et la devise.
Remboursements et revenus récurrents
L’admissibilité d’un paiement accepté est figée. La suppression ultérieure d’un produit n’invalide pas un remboursement partiel légitime. Un remboursement reçu avant son paiement peut conserver la décision vérifiée concernant le parent sans réduire les encaissements nets avant l’arrivée de ce paiement. Seul l’état de remboursement réussi soustrait de l’argent.
La découverte et l’actualisation des abonnements appliquent la même politique de produit. Le MRR contractuel est brut, avant remises et taxes, et séparé par devise ; ce n’est ni une prévision de trésorerie ni un modèle complet de facturation par paliers ou à l’usage. Les états non pris en charge ou périmés ne sont pas comptés comme des revenus valides.
Limites historiques et validation en production
La reprise bornée d’événements du prestataire ne peut recréer des visiteurs jamais suivis, et la disponibilité de l’historique du prestataire est limitée. Les événements exclus font progresser la couverture de l’import sans compter comme paiements importés. Les preuves non résolues restent en attente.
Les tests synthétiques locaux couvrent événements en double, exclusions de périmètre, produits mixtes, remboursements partiels, renouvellements de facture et séparation des devises. Ils ne prouvent ni les permissions réelles d’une clé restreinte, ni la compatibilité de version d’API, ni la transmission des webhooks, ni la reprise opérationnelle. Effectuez ces contrôles avant de connecter des données de production.
Cette documentation décrit le code et ses limites ; elle ne confirme pas une connexion active. Les exemples techniques conservent leurs identifiants d’origine.