A user subscription management backend
for developers

SubTru is a subscription management backend for web or mobile apps that take payments through Stripe, Apple, and/or Google. SubTru receives the subscription events these providers send (Stripe webhooks, Apple App Store Server Notifications, and Google Play Real-Time Developer Notifications), verifies them, deduplicates them, orders them, and normalizes them to keep an accurate subscription status for each one of your users.

To get the subscription status of a user, configure your provider to send subscription events to SubTru, and then, call the SubTru API access check endpoint from your app. This allows you to check what level of access a user should have to your product. Since the access check endpoint is a simple HTTP GET request, it only takes a few lines of code to implement. Your provider accounts and purchase flow stay yours, with no SDK or paywall lock-in.

RevenueCat can be a good fit when you want a full, mobile-first, in-app purchase platform. SubTru is for web or mobile products that want a simpler and more flexible way to manage their users' subscriptions.

At its core, SubTru is a REST API that uses plain HTTP to ingest subscription events from Stripe, Apple App Store, and Google Play, and gives you the subscription status of your users through an access check endpoint. With SubTru, there is no client SDK to ship, no paywall system to adopt, and no need to move your purchase flow into another platform.

Your provider accounts stay yours. If you remove SubTru later, you change your webhook destinations and replace one API call.

Clerk Billing can be a good fit when you already use Clerk for authentication and want billing managed inside the Clerk platform. With Clerk Billing, you define Plans and Features in Clerk, payments are processed through Stripe, and access checks use Clerk's auth helpers and components.

SubTru is independent of your authentication provider and works across Stripe, Apple App Store, and Google Play. SubTru ingests subscription events from those providers and gives your backend one access check endpoint, so it works with any auth setup, whether you sell through Apple App Store, Google Play, or Stripe. It is not limited to Stripe-billed Clerk apps.

With SubTru, you keep control over your own purchase flow and pricing pages. The access check is a plain HTTP GET request, so there is no billing SDK to adopt and no need to tie subscription access to one auth platform.

If you want full control over your subscription infrastructure from the start and don't mind taking on the risks and challenges of building and maintaining webhook processing and accurate subscription state over time, building things yourself might make sense.

Even with one provider, subscription handling can get complicated. You have to verify webhooks, handle retries, deduplicate events, track lifecycle changes, process failed renewals, and decide exactly when users should keep or lose access. With Stripe, Apple App Store, and Google Play, that work multiplies, and maintenance never stops as the providers change things.

SubTru handles supported lifecycle processing. Your app gets one access check API endpoint that returns the current subscription state of a user on demand. Since integrating with SubTru in your code is only a simple GET HTTP request, it only takes a few lines of code to implement and is simple to replace if you ever decide to build your own subscription handling infrastructure in the future.

You can call provider APIs, but they don't give you an access answer. They return provider-specific subscription data, and your app still has to interpret cancellations, grace periods, payment retries, refunds, and expiration dates to decide whether a user should have access.

Stripe, Apple, and Google all built their subscription systems around server-side events, not on-demand polling. Their docs recommend handling renewals, failed payments, refunds, and cancellations through Stripe webhooks, Apple App Store Server Notifications, and Google Play Real-Time Developer Notifications. Without that, your subscription state drifts out of sync with what the provider knows.

Provider APIs are built for billing data, not repeated access checks on every app request. SubTru ingests supported provider events to keep state current and exposes an access check your app can safely call on every request. See its guide to how subscriptions work in SubTru.

A user's subscription should typically grant access to something when it is active, trialing, canceled but still paid through the end of the billing period, or in a grace period after a failed renewal. A user might lose access to a product if their subscription expired, entered account hold, or was revoked by the provider. Refund handling varies by provider.

SubTru turns subscription status, billing dates, provider subscription events, and product rules into one access decision your app can trust.