Design the billing and entitlement platform for an app with iOS, Android and web subscriptions and a backend API.

Core idea: one entitlement service, many payment sources. Each store is an ingestor that turns its own events into a normalised internal event (GRANTED, RENEWED, GRACE, EXPIRED, REVOKED, with an external transaction id, product mapping, price and period). For Apple: a notifications endpoint (verify the JWS and chain, deduplicate by notificationUUID, enqueue, return 200), client-submitted transaction JWS verified on arrival (so the user sees access instantly), and a scheduled reconciliation job that calls the Server API for subscriptions whose state looks stale. Google Play (Real-time developer notifications plus the Play Developer API) and web (Stripe or similar webhooks) get the same treatment. Map store purchases to your user with appAccountToken (Apple) and obfuscated account ids (Google), and handle the case where the purchase arrives before the account exists (a pending claim table).

Storage and reads. Keep an append-only event log (the audit trail and the way to replay after a bug) and a projection table of current entitlements per user (tier, expiry, source, grace flag), derived by a pure function of the events as in the earlier questions and rebuildable at any time. Clients read the projection through your API (cached, short TTL), and still derive from StoreKit locally for instant UX; the server wins on conflict. Handle: duplicate and out-of-order events (idempotency keys, source timestamps), refunds and revocations (and consumable clawback policy), family sharing, price changes and consent, cross-platform double subscriptions (offer to cancel one), account deletion and privacy (keep what tax and fraud rules require), key rotation for the App Store Server API keys and webhook certificates, rate limits and backoff on API calls, environment separation (sandbox never grants production features), and observability (webhook lag, verification failures, mismatches between client and server state, MRR and churn reports built from the event log). Failure modes to design for: Apple outage (serve cached entitlement, extend a grace window), a bad deploy that mishandles one event type (replay from the log), and a flood of renewals at month end (queue and scale consumers). Nothing here needs a specific vendor, and a managed layer such as a subscription-management service can replace the ingestors if the build cost is not worth it; the trade-off is control and fees versus time.