What is Strent?

Strent tells your app which plan each of your customers has in Stripe, so you can sell subscriptions without writing or running webhook code.

Stripe charges your customers. Strent keeps track of which plan each one has. Your app decides what they can use.

01

Charges your customers

Stripe

Your plans and prices, its payment page (Checkout), and its plan management page (Customer Portal) stay in your Stripe account.

02

Keeps track of what is active

Strent

Receives Stripe's messages about every change (webhooks) and answers your app's access checks. You write no webhook code.

03

Decides what they can use

Your application

Your code maps each user to a Stripe customer and each plan to what it unlocks.

How apps usually do this

When a user subscribes, Stripe records the subscription in your Stripe account, not in your app. To know who paid, an app usually keeps its own copy of each customer’s subscription and updates it from webhooks: messages Stripe sends to an address on your server whenever something changes, such as a payment, a plan change, or a cancellation. You write the code that receives them, keep it running, and keep the copy correct.

What stays hard without Strent

Writing that code is easy now: a coding agent can write a first webhook handler in an hour. The work that keeps costing comes after:

• Keeping access correct over time, as customers subscribe, change plans, fail to pay, and cancel.
• Confirming a purchase when the customer comes back from paying. Stripe sends the customer back to your app before its webhook may arrive, so your copy can still say they have not paid.
• Explaining why access changed when a customer or your support asks.

Strent does that work. Each webhook makes Strent read the customer’s current subscriptions from Stripe, reads that fail are retried on their own, and every customer is re-read from Stripe once a day, so a missed change is corrected within about a day. Strent Admin shows each customer’s current plan, the next change already scheduled in Stripe, and when Strent last read the customer.

Your plans stay in Stripe. Works with any login and any database.

You create your plans and prices in your own Stripe account, and Strent reads them from there, so there is no second list of plans to keep in sync. Strent needs only the ID Stripe gives each customer, not your users’ accounts, so it works with whatever signs your users in: Supabase Auth, Auth.js, Better Auth, Firebase, or your own login. Your app stores only that ID for each user, in whatever database it already uses, and needs no billing tables.

What your server asks Strent

Your server asks about one customer at a time, by Stripe customer ID, through the Node.js SDK, Strent’s library for calling it from your code:

Question	SDK call
Does the customer have an active subscription?	customers.hasActiveSubscription
Do they have this product? Which products and prices are active?	activeItems.hasProduct, activeItems.list
What does their plan grant, including limits?	entitlements.has, entitlements.retrieve
What should their billing page show, including a scheduled change?	customers.retrieveBillingState
Read this customer from Stripe again now, as on the Checkout return	customers.refresh

“Active” means subscriptions Stripe marks active, trialing (in a free trial), or past_due (the latest payment failed). You declare entitlements per Stripe product in your code and the SDK resolves them; Strent stores no mapping. The HTTP API has the three operations the SDK builds on: active_items/list, customers/retrieve_billing_state, and customers/refresh.

Access checks ask Strent, not Stripe, so checking access never waits on a call to Stripe, but Strent is a service your app depends on. The SDK reuses a confirmed answer for less than 5 minutes, and during an outage it can serve a saved one less than 1 hour old; it never caches a denial. Positive reuse and fallback explains the limits and how to turn them off.

What stays with Stripe and your app

Stripe charges your customers and hosts Checkout, its payment page, and the Customer Portal, where customers change or cancel their plan. Strent only reads your customers’ subscriptions, with a read-only Stripe key, and never moves money. Your app:

• Creates a Stripe customer for each user and stores its ID; the guide ships the code.
• Decides which of your users, and which parts of your app, each purchase covers.
• Cuts off access sooner after a failed payment, if you want that: Strent keeps reporting access while Stripe marks the subscription past_due.

The shortest accurate explanation

Strent tells your app what the customer bought. Your app decides who can use it.

Who it is for

Strent fits a developer or small team adding subscriptions to a SaaS for the first time, whether they write the code or a coding agent writes it for them, with:

• Stripe Billing, tiered plans or add-ons, and plans that stay in Stripe.
• A login that does not already handle billing: Supabase Auth, Auth.js, Better Auth, Firebase, a custom login, or Clerk without Clerk Billing.
• Server code that runs on Node.js: the SDK is Node.js only.

It is not the right fit for:

• Pricing by usage or credits, such as per API call or per AI token.
• Plans managed outside Stripe, or a merchant of record outside Stripe: a company that sells on your behalf and handles sales tax for you. Stripe Tax and Stripe Managed Payments keep plans in Stripe Billing, so they do not rule Strent out.
• An app builder that already handles Stripe payments for you.
• Server code that doesn’t run on Node.js.
• A team whose own subscription sync already works.
• Checkout, invoicing, collecting failed payments, or payments in general: Stripe handles those, not Strent.