The best Clerk and Stripe combination, and when to skip it
Clerk plus Stripe is two vendors and three jobs. Which combination fits which app, what the seam between them costs you to own, and when a bundled backend is the better call.
In short
Clerk plus Stripe is two vendors and three jobs. Auth knows who the user is, Stripe knows who paid, and the layer deciding what a paying user can actually do is the one you end up owning. Take the pairing when your pricing is flat and stable. Skip it when quotas, credits or metered usage are the product.
The reflex answer to "how do I charge for this" is Clerk plus Stripe, and it holds up until the first customer downgrades mid-cycle. Clerk knows who the user is. Stripe knows who paid. The part in between is yours: you write it, and then you own it for as long as the product exists.
The short answer
Take the pairing if you are selling seats at a price that does not move. The integration is short, and each vendor stays replaceable: swap one and the other never notices.
Skip it if what you sell is measured rather than counted: credits, API calls, per-run charges, per-workspace quotas. In that shape the glue between the two vendors stops being an afternoon of webhook handling and becomes a reconciliation job you own for the life of the product.
And if you are picking a stack from scratch rather than migrating off one, the first question is not which two vendors. It is whether you want to own the seam between them at all.
The seam you end up owning
A card declined at 2am is the whole problem in one event. Stripe knows within seconds. Your auth vendor does not, because in the two-vendor shape nobody tells it. Your app does not either, until a webhook lands and something in your database changes.
So you write a webhook receiver. Then a plan-state table, because reading subscription status from Stripe on every request is too slow. Then gating checks that read that table. Then a reconciliation job, because webhooks get missed and a customer sitting on a plan they stopped paying for is a bug nobody reports.
None of that is difficult. All of it is yours forever, and none of it was in the estimate. We put building auth alone at 3 to 6 weeks. The seam is smaller than that, and unlike auth it never finishes.
Key takeaway
Auth is identity. A processor is money movement. The layer that turns "this person paid" into "this workspace can create another project" is the one you end up owning, and it is where the maintenance actually lives.
Two ways to combine them, and they are not the same decision
Both shapes work. They differ in one thing, which is where your plan catalog lives, and that is what sets the price of leaving.
The first shape is the one most people mean: auth vendor for auth, Stripe Billing for subscriptions, your app in the middle holding plan state. You own the webhooks. In exchange, your plan catalog lives in Stripe, where most tools you will ever buy can read it, and leaving either vendor is a bounded piece of work.
The second shape is a billing layer sold by the auth vendor, pitched as riding on top of your own Stripe account and buying away the webhook work by holding the plan catalog for you. The question to ask before you take that trade is where the catalog physically lives, because if the vendor holds it and Stripe never sees it, the saving on day one is a bill on the day you leave: a catalog Stripe never saw is one you recreate by hand, subscription by subscription. If it is mirrored into your Stripe account, the trade is close to free.
Clerk Billing is the second shape, and Clerk's own docs answer the question without being asked: "Clerk Billing is a separate product from Stripe Billing; Plans and Subscriptions made in Clerk are not synced to Stripe." Your Stripe account moves the money and holds nothing else. The plan catalog and every subscription against it live in Clerk, which is exactly what makes the webhook work disappear, and exactly what you rebuild if you leave. Clerk charges 0.7% of billing volume for that, on top of processing. Its answer on metered billing is equally direct: "Not yet, but usage-based billing is a top priority on our roadmap." (Verified 10 September 2026.)
So pick by how permanent your pricing is. Selling the same three plans in two years? Take the convenience. Expecting to keep changing what you charge for, and how, and to whom? Hold the catalog where the most tools can read it, and pay the webhook tax.
Where each fits
| Feature | BuildBase | Clerk + Stripe |
|---|---|---|
| Vendors on the critical path | One instance, 20 modules | Two, plus the glue code you write between them |
| Entitlement state | Feature flags with workspace, user and audience targeting; toggles without a deploy | A table in your database, kept in sync by your webhooks |
| Quotas and credits | Credit ledgers, per-plan quota limits, overage billing, balance alerts | Whatever your processor records, mapping it to in-app limits is your code |
| Webhook handling | Delivery logs, retries and HMAC verification, 5-minute max age | Yours to build, monitor and replay |
| Stripe account | Your own keys, per organization; we take no cut of revenue | Your own account |
| Auth methods | Eight: email/password, Google, LinkedIn, GitHub, Microsoft, magic link, passkeys, OAuth 2.0 | Email code, email link, SMS code, password, passkeys, social OAuth connections, enterprise SSO and Web3 wallets |
| SSO against a customer identity provider | We do not ship SAML | Yes. One enterprise connection included on Pro and Business, $75/mo for each one after |
| Free tier | None. Launch is $49/mo, after a 7-day trial with no card | Hobby is free to 50,000 monthly retained users. Pro is $25/mo |
Our side of that table is not a pitch, it is the constants file. Launch is $49 a month and includes 25,000 monthly active users, 1,000 workspaces, 10 GB of storage and 3 team seats. Grow is $99 with 100,000 users and 8 seats. Scale is $199 with 500,000 and 50.
Storage is the only quota that bills over, at $0.10 per GB. Everything else is a hard allowance, on purpose, so nobody gets a surprise invoice. Yearly is ten months for twelve. (Verified against the published plans 9 September 2026.)
One row matters more than any of the price rows: you connect your own Stripe keys, per organization. We are not a merchant of record and we take no percentage of what you bill. Clerk Billing takes 0.7% of billing volume, and Stripe Billing takes the same 0.7% if you run subscriptions through it directly, so the two-vendor route costs a slice of revenue whichever way you assemble it. That is the axis worth checking hardest, because a percentage of revenue is the one line on a bill that grows with your success rather than your usage. At $50,000 billed in a month it is $350, and it keeps going.
Where the pairing genuinely wins
Where Clerk wins
Four things, and none of them are small.
We do not ship SAML. If a buyer's security review asks you to authenticate their staff against their own identity provider, we are not on the shortlist. Nothing about a roadmap helps a deal you are trying to close this quarter, so treat our answer as no. Clerk answers yes: enterprise connections over SAML or OIDC, one included on Pro at $25 a month and $75 a month for each one after. That is the clearest reason on this page to keep auth with a specialist.
Two vendors means two independent replacements. If billing stops working for you, you swap billing. Auth never notices. A bundled backend gives you one vendor, one release cadence and one outage window, and buying it is a bet that it stays good at both halves.
We have no free plan. Entry is $49 a month, with a 7-day trial that never asks for a card. Still $49. Clerk's Hobby tier is free to 50,000 monthly retained users, which is more free users than most products ever reach. Before you have revenue that is the number that decides, and it does not decide our way.
Our SDK covers a fixed list of web frameworks: Next.js, Vite, React Router / Remix, TanStack Start, Express, NestJS, Fastify, Hono and Astro. If you are outside that list, this is a hard stop rather than a trade-off.
When to skip both
Your invoice line decides this, not your architecture diagram.
"5 seats x $20" and the two-vendor split is fine. Seats change rarely, and a stale entitlement is the kind of bug a human spots before a customer does.
"1,847 API calls" or "312 credits consumed" and you should look harder. Every request now has to check a balance, decrement it, and hold up when two of them land at once. That check cannot cross a vendor boundary on every call, so it lives in your database, which makes your database and your billing vendor two copies of one number. Reconciling two copies of a number that moves thousands of times a day is the job. A bundled backend deletes the job by keeping one copy.
That is what our credits and billing modules are for: ledgers, per-plan limits on any metric, overage, and metered usage synced to Stripe from the same place that enforces the limit. Our own defaults are written down rather than discovered in production: permissions refresh hourly, and a webhook signature older than 5 minutes is rejected.
The other signal is how many products sit on one account. One product with one pricing model? Two vendors is a fine trade, and the glue stays small enough that one engineer holds all of it in their head. Five products sharing one identity and one balance is five copies of that glue, drifting apart at different speeds.
If you are already on Clerk
Do not rip it out because a post told you to. Migrating auth is the highest-risk change you can make to a live product, and "we consolidated our vendors" is not a feature any customer noticed.
The honest trigger is pricing pressure or a shape change: you are moving from seats to usage, or you have started writing reconciliation jobs, or the entitlement table has grown a special case per plan. If none of that is true, the pairing is doing its job.
Worth reading alongside this: Clerk vs BuildBase for the head-to-head with figures, Clerk alternatives for which complaint each option actually fixes, and the real cost of Clerk plus Stripe plus Lago plus Knock for what the stack costs once it is four vendors instead of two.