Comment fonctionne SubSovereign

Si vous vendez des abonnements dans une application, vous devez répondre à une question difficile, encore et encore : pour quels services cet utilisateur a-t-il réellement payé, en ce moment ? SubSovereign apporte une réponse fiable, sur votre propre infrastructure, sans prélever de pourcentage sur vos revenus. Cette page explique le concept avant de toucher à une ligne de code.

Le problème résolu

Les boutiques d'applications (Apple, Google, Amazon, Roku) gèrent chacune les paiements à leur manière, avec leurs propres reçus, règles de renouvellement et cas particuliers — essais gratuits, remboursements, mises à niveau, relances de facturation, partage familial. Faire en sorte que "cet utilisateur est-il Pro ?" fonctionne correctement sur toutes les plateformes et tous les appareils est un vrai défi. Et surtout, ne faites jamais confiance à l'application elle-même pour répondre : n'importe qui peut modifier le client et prétendre être un client payant.

SubSovereign est l'élément central qui gère cela correctement, afin que vous n'ayez pas à le construire et à le maintenir vous-même.

Le modèle mental

Il n'y a qu'une seule règle, et tout en découle :

L'application demande. Le serveur décide.

Votre application ne décide jamais si un utilisateur a accès — elle demande à SubSovereign, qui lui répond en fonction des reçus qu'elle a vérifiés directement auprès de la boutique. L'appareil de l'utilisateur n'est jamais la source de vérité.

Les composants

• Le tableau de bord — votre back-office web. C'est ici que vous enregistrez chaque application, créez vos niveaux d'accès (les offres que vous vendez, par exemple pro, premium), les liez aux produits que les utilisateurs achètent dans chaque boutique, et concevez votre mur de paiement. Vous y récupérez également votre clé API.
• Un SDK — une petite bibliothèque que vous intégrez à votre application (Android, iOS/tvOS, Roku, ou Web/React Native). C'est le canal de communication de l'application avec SubSovereign : vérifier l'accès, valider un achat, récupérer le mur de paiement, enregistrer le consentement.
• Le serveur — votre backend SubSovereign auto-hébergé. Il valide les reçus auprès de chaque boutique, stocke les droits d'accès, les met en cache pour des lectures rapides, et répond aux questions de l'application.
• Les boutiques — Apple StoreKit 2, Google Play Billing, Amazon IAP (Fire TV), Roku Pay, et Stripe (pour le web). SubSovereign communique avec toutes ces plateformes pour que votre application n'ait à en gérer qu'une seule.

Ce qui se passe réellement lorsqu'un utilisateur s'abonne

1. L'utilisateur clique sur S'abonner sur votre mur de paiement. Votre application exécute le processus d'achat via le système de facturation normal de la boutique (Google Play, StoreKit, etc.) — SubSovereign ne remplace pas ce processus.
2. La boutique fournit à votre application un reçu (un jeton d'achat). Votre application le transmet à SubSovereign via le SDK.
3. SubSovereign effectue la validation du reçu — il vérifie ce reçu directement auprès de la boutique, serveur à serveur. Un reçu falsifié ou rejoué est rejeté à cette étape.
4. Si le reçu est authentique, SubSovereign enregistre le droit d'accès de l'utilisateur — le niveau d'accès qu'il a désormais débloqué, sa date d'expiration et si le renouvellement est prévu.
5. Votre application demande "quels services cet utilisateur possède-t-il ?", SubSovereign répond à partir de ses enregistrements vérifiés (mis en cache pour plus de rapidité), et votre application débloque les fonctionnalités correspondantes.

Par la suite, à chaque lancement, l'étape 5 se répète : demander, et débloquer ce que la réponse indique. Les renouvellements, annulations et expirations sont reflétés automatiquement, car le serveur les suit.

Pourquoi l'auto-hébergement et la souveraineté comptent

SubSovereign s'exécute sur votre infrastructure (hébergement au Royaume-Uni/UE, votre base de données), et non sur le cloud d'un tiers. Cela signifie :

• Vous possédez les données de vos utilisateurs. L'historique des achats, les droits d'accès et les enregistrements de consentement résident dans votre base de données, sous votre contrôle — ce qui rend la conformité RGPD quelque chose que vous gérez, et non quelque chose dont vous espérez que le fournisseur s'occupe.
• Aucun pourcentage sur les revenus. Contrairement aux services hébergés qui prélèvent un pourcentage sur vos revenus d'abonnement, SubSovereign n'en prend aucun — vous conservez 100 % de ce que vos utilisateurs paient.
• Aucun verrouillage. Il s'agit de votre déploiement ; vous pouvez l'inspecter, l'étendre et le déplacer.

Ce que ce n'est pas

• Ce n'est pas un processeur de paiement. Les utilisateurs paient toujours via les boutiques d'applications (ou Stripe sur le web) ; SubSovereign vérifie et suit ces achats.
• Ce n'est pas un concepteur de mur de paiement imposé. SubSovereign fournit le contenu de votre mur de paiement (prix, fonctionnalités, durée d'essai) à distance, afin que vous puissiez le modifier sans mettre à jour l'application — mais c'est vous qui créez l'écran réel, exactement comme vous le souhaitez.

Prêt à développer ?

Rendez-vous sur Démarrage pour déployer le serveur et enregistrer votre première application, puis consultez le guide de votre plateforme : Android, iOS, Web / React Native, Roku, React, React Native, Flutter, ou le Composant Web.