# Clerk Billing Explained: Pricing, Limits and When to Use Something Else > How Clerk Billing works, what the 0.7% fee really costs on top of Stripe, the tax, currency and 3DS limits to know, and when a Merchant of Record is the better fit. - **Author**: Ayush Agarwal - **Published**: 2026-09-25 - **Category**: Billing, SaaS - **URL**: https://dodopayments.com/blogs/en/clerk-billing --- Clerk Billing is a subscription layer bolted onto Clerk's authentication product. It gives you prebuilt pricing table and checkout components, plan-based feature gating through the `has()` helper, and subscription state that lives on the same user object as your auth session. It costs 0.7% of billing volume on top of Stripe's own 2.9% plus 30 cents, and it is included on every Clerk plan. The pitch is real. If you already use Clerk for auth, wiring up paid plans becomes an afternoon instead of a sprint, because the thing that usually takes the time, reconciling "who is this user" with "what have they paid for", is already solved. The limits are equally real, and several of them are the kind that surface after launch rather than during evaluation. Clerk Billing does not support tax or VAT, it is USD only, it has no 3D Secure support, and Clerk is explicitly not a Merchant of Record. This guide covers what it does well, what it costs in total, and the specific situations where you should reach for something else. All figures below were verified against Clerk's own pricing page and billing documentation in September 2026. ## What Clerk Billing Actually Is Clerk started as authentication: sign-in, sign-up, sessions, organisations, and user management. Billing extends that model so a subscription becomes another property of the user or organisation you already have. Three pieces make it up. - **Prebuilt UI components.** A `PricingTable` component renders your plans, and checkout is handled inside Clerk's flow rather than a redirect you build. - **Feature gating via `has()`.** You define plans and features in the Clerk dashboard, then check entitlement in code against the session, without a separate entitlements service. - **Unified user and subscription state.** The subscription lives with the user record, so there is no join between your auth database and your billing provider. Underneath, payments run on Stripe. Clerk is explicit that Clerk Billing only uses Stripe for payment processing, and that plans and subscriptions created in Clerk are not synced to Stripe Billing. That last detail matters more than it sounds and we will come back to it. ## What Clerk Billing Costs | Item | Cost | | --- | --- | | Clerk Billing fee | 0.7% of billing volume | | Stripe processing | 2.9% + $0.30 per transaction | | Clerk Free (Hobby) | $0, 50,000 monthly retained users | | Clerk Pro | $25 per month, $20 billed annually, 50,000 MRUs included | | Clerk Business | $300 per month, $250 billed annually | | MRU overage, 50k to 100k | $0.02 per MRU per month | | MRU overage, 100k to 1M | $0.018 per MRU per month | | MRU overage, 1M to 10M | $0.015 per MRU per month | Two things are worth understanding here. **The 0.7% stacks.** It is not an alternative to Stripe's fee, it is added to it. A $50 monthly subscription costs $1.45 in Stripe processing plus 35 cents to Clerk, so roughly 3.6% all in. That is competitive with Stripe Billing, which also charges 0.7% of billing volume on its pay-as-you-go plan, and cheaper than assembling the same thing yourself if you value the integration time. **Clerk bills on MRU, not MAU.** A Monthly Retained User only counts if they return at least 24 hours after signing up, which Clerk calls "First Day Free". For a product with heavy trial traffic that never converts, this is materially cheaper than per-MAU pricing, and it is one of the genuinely well-designed parts of Clerk's model. ## The Limits You Need to Know Before You Build This is the section that should drive the decision, because most of these are not visible until you are in production. ### No tax or VAT support Clerk's documentation states plainly that Clerk Billing does not currently support tax or VAT, and that these are planned for future releases. It also states, in answer to its own FAQ question, that Clerk is not a Merchant of Record. Both halves matter. Not supporting tax means Clerk will not calculate or add VAT at checkout. Not being a merchant of record means the legal obligation to register, file, and remit sits with you in every jurisdiction where you cross a threshold. For a US-only B2B product that is a manageable gap. For anyone selling to consumers in the EU or UK, it is a compliance problem from the first sale, because there is no registration threshold for non-resident sellers of digital services. ### USD only Clerk Billing supports USD and no other billing currency. If you want to price in euros, pounds, or rupees, or show local currency at checkout to protect conversion, Clerk Billing cannot do it today. ### No 3D Secure Clerk's docs state that 3DS is not supported and that payments requiring a 3DS challenge will fail. This is the sharpest limitation on the list. In the UK and EU, Strong Customer Authentication means a meaningful share of card payments will be challenged. A checkout that fails those payments does not degrade gracefully, it simply loses the sale, and the failure looks like a card problem rather than a platform limitation. If you have European customers, this alone is usually disqualifying. Our explainer on [how 3D Secure works](https://dodopayments.com/blogs/3d-secure-3ds-payment-authentication) covers why the challenge fires and what it protects. ### Country restrictions Clerk Billing is not supported in Brazil, India, Malaysia, Mexico, Singapore, or Thailand. Elsewhere it depends on Stripe's own coverage. ### Usage-based and per-seat billing are not shipped Clerk lists usage-based and per-seat billing as coming soon. If you are building an AI product that meters tokens or credits, or a B2B tool that charges per seat, the billing model you need is not available today. Plan around what exists, not what is announced. For the patterns involved, see our guide to [implementing usage-based billing](https://dodopayments.com/blogs/implement-usage-based-billing). ### Refunds happen outside Clerk There is no refund flow in Clerk. You issue refunds in Stripe, and they will not be reflected in Clerk's MRR reporting. That means your revenue numbers drift from reality unless you reconcile manually. ### Subscriptions do not sync to Stripe Billing Because Clerk uses Stripe purely as a processor, the plans and subscriptions you define in Clerk do not exist as Stripe Billing objects. If you later want to migrate to Stripe Billing directly, or to any tool that reads Stripe subscription data, that data is not sitting there waiting for you. ## When Clerk Billing Is the Right Choice It is a genuinely good fit when all of the following are true. - **You already use Clerk for authentication.** The integration advantage only exists if the auth dependency is already paid for. - **You sell in USD to customers outside the 3DS-heavy markets.** Realistically, US-first products. - **Your pricing is flat-rate recurring plans.** No metering, no seats, no hybrid. - **Someone owns tax compliance already,** or your volume is below the thresholds that create obligations. - **You want to ship paid plans this week** rather than build a billing service. For a seed-stage US B2B SaaS on Clerk selling three flat plans in USD, Clerk Billing is close to the fastest correct answer available. ## When to Use Something Else ### If you sell internationally The combination of no tax support, no VAT calculation, USD only, and no 3DS makes Clerk Billing a poor fit for international consumer sales. Each of those is individually workable. Together they mean a European customer may not be able to pay you at all, and if they can, you are accruing an unregistered VAT liability. A [merchant of record](https://dodopayments.com/blogs/what-is-a-merchant-of-record) solves the whole cluster in one move, because the provider becomes the legal seller, calculates and remits tax under its own registrations, and runs a checkout that handles SCA properly. ### If you meter usage AI products that bill on tokens, credits, or API calls need metering that Clerk has not shipped. Building it yourself on top of Clerk means you are running a billing service anyway, which removes the reason to use Clerk Billing in the first place. ### If you need multi-currency pricing Showing a customer a price in their own currency is one of the highest-leverage conversion changes available to a global SaaS product. USD-only pricing leaves that on the table. See our guide to [multi-currency pricing for global SaaS](https://dodopayments.com/blogs/multi-currency-pricing-global-saas). ### If you need clean revenue reporting Refunds that do not flow back into MRR will cause finance friction quickly. Any platform where refunds and revenue live in the same ledger avoids this. ## Clerk Billing Compared | Capability | Clerk Billing | Stripe Billing | Dodo Payments | | --- | --- | --- | --- | | Fee on top of processing | 0.7% | 0.7% pay-as-you-go | 0.5% for subscriptions | | Merchant of Record | No | No, unless Managed Payments | Yes | | Tax calculated and remitted | No | Calculation sold separately | Included, 190+ countries | | Currencies | USD only | Multi-currency | 80+ currencies at checkout | | 3D Secure | Not supported | Supported | Supported | | Usage-based billing | Coming soon | Supported | Included | | Refunds in-platform | No, via Stripe | Yes | Yes, $1 per refund | | Auth included | Yes | No | No | The honest framing: Clerk Billing is not really competing with billing platforms. It is competing with the two days you would otherwise spend wiring Stripe Checkout to your user table. Judged on that, it is good value. Judged as a billing platform for a global product, it has gaps that are documented rather than hidden, which is to Clerk's credit. ## A Practical Migration Path If you start on Clerk Billing and outgrow it, the move is more work than a typical billing migration because subscriptions do not exist as Stripe Billing objects. Plan for three things. 1. **Export entitlements, not just subscriptions.** Your source of truth for "who can access what" lives in Clerk's plan and feature model. Map it explicitly before you move. 2. **Re-collect payment methods or migrate them in Stripe.** Cards live in your Stripe account, so this is usually manageable, but subscription schedules will need recreating. 3. **Keep auth on Clerk.** There is no requirement to move authentication just because you move billing. Clerk remains a strong auth product, and pairing it with a dedicated billing provider is a normal end state. For the patterns involved, our guide to [better-auth with Dodo Payments](https://dodopayments.com/blogs/better-auth-dodo-payments) shows how an auth provider and a payments provider compose without either owning the other, and the [webhooks documentation](https://docs.dodopayments.com/developer-resources/webhooks) covers keeping entitlement state in sync. ## FAQ ### How much does Clerk Billing cost? Clerk Billing charges 0.7% of billing volume, and it is included on every Clerk plan including the free Hobby tier. That fee is on top of Stripe's processing, which is 2.9% plus 30 cents for US cards, so the realistic all-in cost on a $50 subscription is about 3.6%. Clerk's own auth pricing is separate: free up to 50,000 monthly retained users, then $25 a month for Pro with overage from $0.02 per MRU. ### Is Clerk a Merchant of Record? No. Clerk's documentation answers this directly and states that Clerk does not provide that service. It also states that Clerk Billing does not currently support tax or VAT, though both are described as planned. In practice this means you remain the legal seller, and registering, filing, and remitting VAT, GST, or sales tax is your responsibility in every jurisdiction where you cross a threshold. ### Does Clerk Billing support 3D Secure? No. Clerk's documentation states that 3DS is not supported and that payments requiring a 3DS challenge will fail. This matters most in the UK and EU, where Strong Customer Authentication causes a meaningful share of card payments to be challenged. If you have European customers, this is usually the single strongest reason to use a different billing path. ### Can Clerk Billing handle usage-based pricing? Not today. Clerk lists usage-based and per-seat billing as coming soon rather than shipped. Current support covers recurring subscriptions for both individual users and organisations, with monthly and annual intervals and mid-cycle upgrades applied immediately. If you need to meter tokens, credits, or API calls now, you will need a billing provider that already supports metering. ### Should I use Clerk Billing or a merchant of record? Use Clerk Billing if you already run Clerk for auth, you sell flat-rate plans in USD, your customers are mostly US-based, and you want paid plans live quickly. It is an excellent shortcut for that specific shape of product. Use a merchant of record if you sell internationally, need multi-currency pricing, need 3DS to work, meter usage, or do not have anyone who owns indirect tax compliance. Those are structural gaps in Clerk Billing rather than temporary ones, and a merchant of record closes all of them at once. --- - [More Billing articles](https://dodopayments.com/blogs/category/billing) - [All articles](https://dodopayments.com/blogs)