Entitlements, not receipts | Faceless AI - Dataspheres AI

The mental shift With in-app purchase, the app asks the store, "did this device buy the subscription?" and trusts a signed receipt. When you sell on the we...

The mental shift With in-app purchase, the app asks the store, "did this device buy the subscription?" and trusts a signed receipt. When you sell on the web, the app must instead ask your own backend, "does this logged-in account have an active entitlement?" Access is tied to the account, not to the device or a store receipt. The entitlement server The minimal system has three parts: Payment webhooks: your backend listens to Stripe or Paddle events — subscription created, renewed, canceled, refunded — and updates the account's entitlement record. Entitlement store: a table mapping an account to its current plan, status, and expiry. An entitlement check: the app authenticates the user, then calls your API, which returns the current entitlement, ideally as a signed token the app can cache for a short time. Buy versus build You can build this, or you can use a service such as RevenueCat that unifies entitlements across web purchases and any remaining in-app purchases behind one API. That is especially useful in Route A, where a single user might have bought through Apple on one device and through your website on another, and you want one answer to "are they subscribed?" The lesson is architectural, not brand-specific: entitlements are your source of truth, and receipts are just one way they get created. Educational material, not legal or tax advice. App-store rules and the underlying court cases are changing month to month in 2026 — always confirm the current terms in Apple's and Google's own developer documentation before you ship, and get professional advice for your jurisdiction.