SubSovereign
All guides

How SubSovereign works

If you sell subscriptions in an app, you have one hard question to answer, over and over: what has this user actually paid for, right now? SubSovereign answers it — reliably, on your own infrastructure, without taking a cut of your revenue. This page explains the idea before you touch any code.

The problem it solves

App stores (Apple, Google, Amazon, Roku) each handle payments their own way, with their own receipts, renewal rules, and edge cases — free trials, refunds, upgrades, billing retries, family sharing. Getting "is this user Pro?" right across all of them, on every device, is genuinely hard. And you must never trust the app itself to answer it: anyone can modify a client and claim to be a paying customer.

SubSovereign is the piece in the middle that gets this right, so you don't have to build and maintain it yourself.

The mental model

There is one rule, and everything follows from it:

The app asks. The server decides.

Your app never decides whether a user has access — it asks SubSovereign, and SubSovereign tells it, based on receipts it has verified directly with the store. The user's device is never the source of truth.

The pieces

  • The dashboard — your web back-office. Here you register each app, create your access levels (the tiers you sell, e.g. free, premium — names you choose, separate from store product IDs), link them to the products users buy in each store, and design your paywall. You also get your API key here.
  • An SDK — a small library you drop into your app (Android, iOS/tvOS, Roku, or Web/React Native). It's the app's phone line to SubSovereign: check access, validate a purchase, fetch the paywall, record consent.
  • The server — your self-hosted SubSovereign backend. It validates receipts with each store, stores entitlements, caches them for fast reads, and answers the app's questions.
  • The stores — Apple StoreKit 2, Google Play Billing, Amazon IAP (Fire TV), Roku Pay, and Stripe (for web). SubSovereign speaks to all of them so your app speaks to one.

What actually happens when a user subscribes

  1. The user taps Subscribe on your paywall. Your app runs the purchase through the store's normal billing flow (Google Play, StoreKit, etc.) — SubSovereign doesn't replace that.
  2. The store hands your app a receipt (a purchase token). Your app passes it to SubSovereign through the SDK.
  3. SubSovereign performs receipt validation — it checks that receipt directly with the store, server to server. A faked or replayed receipt is rejected here.
  4. If it's genuine, SubSovereign records the user's entitlement — the access level they've now unlocked, when it expires, and whether it will renew.
  5. Your app asks "what does this user have?", SubSovereign answers from its verified record (cached for speed), and your app unlocks the right features.

From then on, every launch just repeats step 5: ask, and unlock what the answer says. Renewals, cancellations, and expiries are reflected automatically because the server tracks them.

Why self-hosted and sovereign matters

SubSovereign runs on your infrastructure (UK/EU hosting, your database), not a third party's cloud. That means:

  • You own your users' data. Purchase history, entitlements, and consent records live in your database, under your control — which makes GDPR compliance something you have, not something you hope a vendor is doing for you.
  • No revenue share. Unlike hosted services that take a percentage of your subscription revenue, SubSovereign takes none — you keep 100% of what your users pay.
  • No lock-in. It's your deployment; you can inspect it, extend it, and move it.

What it is not

  • It's not a payment processor. Users still pay through the app stores (or Stripe on web); SubSovereign verifies and tracks those purchases.
  • It's not a paywall designer you're stuck with. SubSovereign serves your paywall's content (prices, features, trial length) remotely so you can change it without an app update — but you build the actual screen, exactly how you want it.

Ready to build?

Head to Getting started to stand up the server and register your first app, then pick your platform guide: Android, iOS, Web / React Native, Roku, React, React Native, Flutter, or the Web Component.