Several providers now bundle authentication with subscription management, but they bundle different things. Some wrap Stripe with entitlement components while you stay the seller of record. Others act as merchant of record and take on VAT, refunds and chargebacks. The difference decides who handles tax, not just who handles the interface.
The question underneath the question
Nobody searches for an auth provider with built-in subscription management because they read a comparison post. They search for it because they have just finished wiring one to the other and realised how much of it they now own forever.
The shape of the problem is always the same. Sign-up creates a user record in one system. Checkout creates a customer record in another. Something has to keep those two records agreeing about whether this person is currently allowed to use the thing they paid for. That something starts as a webhook handler and a boolean column, and then it accumulates: the renewal that failed overnight, the downgrade that should take effect at period end but not before, the refund that never propagated back to access, the customer who paid with a different email than the one they signed up with.
None of that is hard in isolation. All of it is permanent. It is business logic with no product value that breaks quietly and gets discovered by a paying customer.
So the question is really about who has already built the join between identity and entitlement, and what they had to take on in order to build it. Three answers exist. On a pricing page they look like variations on one idea. In practice they differ in who is legally selling your software, which decides who deals with tax authorities and card networks when something goes wrong.
Auth first, with billing bolted on
The first shape starts from identity. You are already using an auth provider, and it has added subscriptions so you do not need a second vendor for the paywall.
Clerk Billing is the clearest example. It costs 0.7% per transaction on top of the processing fees you pay directly to Stripe. Clerk uses Stripe only for payment processing, and the Clerk documentation is explicit that plans and subscriptions created in Clerk are a separate product from Stripe Billing and do not sync to Stripe.
What you get in return is a PricingTable component that renders your plans, and a single access question you can ask anywhere in your code: is this user on this plan, or do they have this feature? On the server that question is a function call, named has. In your components you wrap the gated content in Show, which renders a fallback when the answer is no. Show arrived with Clerk Core 3 in March 2026, replacing Protect, SignedIn and SignedOut. If you use Clerk Organizations, subscriptions can attach to the organization rather than the individual, which is the piece most B2B products need.
Kinde takes the same starting position and adds feature flags and analytics alongside billing. Its platform fee on payments you collect from customers is 0.7% on the Free and Pro plans, 0.6% on Plus and 0.5% on Scale, charged on top of Stripe's own fees. Kinde includes metered usage pricing, feature-based entitlements and a customer self-serve portal on every tier, including the free one. Its pricing page lists cards as the payment method available through Stripe, so wallets and local methods are not part of the documented offering.
What both share is the thing that matters most and gets mentioned least. You remain the seller of record. Clerk's own FAQ puts it flatly: asked whether Clerk is a merchant of record for transactions, the answer is no, and Clerk does not provide the service. Clerk Billing also does not currently support tax or VAT, which Clerk lists as planned rather than shipped.
Billing first, with entitlements added
The second shape starts from money and works backwards into access control. These are billing platforms that noticed developers were rebuilding the same entitlement layer on top of them and shipped it natively.
Polar acts as merchant of record and attaches what it calls benefits to products: license keys, file downloads, GitHub repository access, Discord roles, credits, feature flags and a shared Slack channel, granted automatically on purchase and revoked on cancellation. It confirms that EU B2B reverse charge is handled under its merchant of record model. Polar restructured its pricing on 27 May 2026. New organizations start on Starter at 5% plus 50 cents, with Pro at $20 a month for 3.8% plus 40 cents, Growth at $100 a month for 3.6% plus 35 cents, and Scale at $400 a month for 3.4% plus 30 cents. International cards add 1.5% and disputes cost $15 regardless of outcome. Organizations created before that date keep the old Early Member rate indefinitely, 4% plus 40 cents with a further 0.5% on subscription payments, though upgrading to a paid plan retires it permanently.
Dodo Payments is also a merchant of record and ships a unified entitlements layer that drives fulfilment across integrations including Discord, GitHub and Notion, so a plan change updates access without a sync step you maintain. Its published rate is 4% plus 40 cents for domestic US transactions, with 0.5% added for subscriptions, 1.5% for international payments and 3% where PayPal is the method. Tax calculation and filing across 190-plus countries, invoicing, analytics and usage-based billing are included rather than priced separately.
The gap in this shape is identity. Neither platform signs your users in. You still choose an auth provider, and you are still responsible for the join between the account it creates and the customer record the billing platform creates. The entitlement logic is solved. The identity-to-entitlement mapping is not.
One backend where identity and entitlement are the same record
The third shape collapses the join by making both sides the same system.
tiun is built around a single user record that carries entitlement alongside identity, so the product access a customer has bought is a field on the user rather than a state you keep in sync between two vendors. It is also the merchant of record, so the tax registration, the invoicing and the chargebacks sit with it rather than with you. For the audience it is aimed at, which is a solo founder or a small team standing up a new product, that removes the two pieces of work that are least related to building the thing: the reconciliation logic between auth and billing, and the compliance function you would otherwise need before you can take money from a customer in a country you have never been to.
The core platform is free, with transaction fees of 2.9% plus $0.30, an additional 0.5% on subscription payments More detail on the model is on the why tiun page.
The gaps worth checking before you commit
Four things decide whether a bundled provider works for your customers, and none of them appear on the front of a pricing page.
Geography. Clerk Billing is not supported in Brazil, India, Malaysia, Mexico, Singapore or Thailand, which Clerk attributes to payment processing restrictions. Everywhere else depends on Stripe's own country coverage.
Payment authentication. This is the one to read carefully if you sell in Europe. Clerk's billing documentation states that Clerk Billing does not currently support payment methods requiring additional authentication such as 3D Secure, and that payments requiring a 3DS challenge will fail because Clerk Billing cannot prompt the user to complete the step. Clerk notes the limitation is particularly relevant in the UK and EU and may affect free trials, since renewal charges run in the background with no user present to authenticate. That page was last updated on 6 August 2026 and is worth checking directly before you build on it, because it is a documented current limitation rather than a permanent property.
Why it matters in Europe specifically: under PSD2, strong customer authentication is required for payer-initiated remote card payments where both the issuer and the acquirer sit in the European Economic Area, and EMV 3DS2 is the usual mechanism for delivering it. Exemptions exist for low-value payments and transaction risk analysis, and merchant-initiated transactions sit outside SCA scope altogether rather than being exempt, so not every European charge triggers a challenge. But renewals only stay outside scope because the mandate that set them up was itself authenticated. That first payment is exactly the one that draws a challenge, and a checkout that cannot present the challenge has no path to complete it.
Currency. Clerk Billing supports only USD as the billing currency, regardless of where the connected Stripe account sits. If you price in euros, that is a product decision, not a settings toggle.
Refunds. Clerk Billing does not support refunds. You can issue one through Stripe directly, but Clerk notes it will not be reflected in income or MRR calculations.
Who is the seller, and what staying the seller costs
Everything above resolves into one distinction. In the first shape, you are the merchant of record. In the second and third, the platform is.
Being the seller of record means the tax obligations are yours. You determine where you have registration thresholds, register in those jurisdictions, apply the right rate at the point of sale, validate VAT numbers for B2B customers who are entitled to reverse charge, file on each jurisdiction's schedule, and keep the evidence. You also own the card network relationship, which means chargebacks come to you with the fees and the ratio monitoring attached.
None of that is unmanageable. Plenty of companies do it deliberately, because being the seller means owning the customer relationship, the invoice, the payment descriptor and the data, and because at volume the percentage a merchant of record charges exceeds what compliance costs to run in-house. The trap is doing it by accident. A provider that bundles auth and subscriptions has solved your interface problem, and it is easy to read that as having solved the selling problem too.
Which shape fits
Auth with a billing wrapper suits products where auth depth matters: B2B SaaS with organisation billing, multi-role access, or enterprise SSO requirements. You build on Clerk or Kinde for the auth surface, manage tax compliance separately, and accept that 3DS handling and MoR coverage are not included.
Billing with entitlement features suits founders who already have an auth solution and need MoR coverage with tight entitlement integration. Dodo Payments fits here: you keep your existing identity layer, add Dodo for payments, tax, and access gating, and plan changes propagate automatically. The fit is strongest when you sell digital products or software access where the entitlement is the delivery.
A single backend as MoR suits solo founders and small teams building a new SaaS where the auth requirements are straightforward: individual users signing in for themselves, no tenancy model, no enterprise SSO. tiun handles sign-up, checkout, renewal and the access that follows from them in one integration, and because it is the merchant of record, the tax and the chargebacks are its problem rather than yours. Sign-in covers email with a one-time passcode and social SSO, which is the shape most consumer and prosumer products need. What it does not cover is organizations, roles, or enterprise connections through SAML or OIDC. That ceiling is the trade, and for a product whose buyer and whose user are the same person, it may never come up.
Frequently asked questions
Can I use one tool for user authentication and subscription management?
Yes, but the tools in this space bundle different things. Clerk and Kinde combine authentication with subscription management while you remain the seller of record and handle tax compliance yourself. tiun combines authentication, subscription management, entitlement gating, and merchant of record obligations in one product, meaning it also collects and remits VAT and GST. The right choice depends on whether you need auth depth, tax coverage, or both.
What is the difference between an auth provider with billing and a merchant of record?
An auth provider with billing handles sign-up, sessions, and subscription management, but you remain the legal seller on every transaction. You own VAT calculation, filing, and remittance for each jurisdiction where a customer pays. A merchant of record becomes the legal seller instead: it collects and remits tax on your behalf and takes on liability for refunds, disputes, and chargebacks. The fee structure is different; so is what happens when a German customer asks for an invoice.
Does Clerk Billing support 3D Secure?
No. Clerk Billing has no native 3D Secure support as of August 2026, per Clerk's own billing documentation. Under PSD2, strong customer authentication applies to most consumer card payments in the European Economic Area, and 3DS is the standard mechanism that satisfies it. A checkout that cannot complete a 3DS challenge fails at the bank. This is a protocol-level constraint, not a configuration setting, so it applies regardless of how Clerk Billing is implemented.
Do I have to handle VAT if I use Stripe or Clerk for billing?
Yes. Stripe and Clerk both leave you as the seller of record, which means VAT calculation, filing, and remittance are your responsibility in every jurisdiction where you collect payment. Stripe Tax reduces the calculation burden, but the liability stays with you. Founders who sell to EU customers without registering for VAT accumulate liability from the first transaction. A merchant of record provider such as Dodo Payments or tiun transfers that liability to the provider instead.