Nearly every payments comparison argues about APIs and dashboards, which is the least important axis. The decision is really about who is legally responsible for sales tax and VAT, and how much of your life you want that to consume. Pick on merchant of record status first, fee percentage second, developer experience a distant third.
The one question that decides it
A merchant of record is the legal seller. When a customer in Berlin buys through Paddle or Lemon Squeezy, that company sold it to them and the receipt says so. They collect the VAT, hold the registration, file the return, and take the questions if a tax authority has any. You are selling to the merchant of record, and they pay you out on a schedule.
A direct processor is plumbing. Stripe moves money from a card into your bank account, and the sale is between you and the customer. The tax obligation is yours in every jurisdiction where you trigger one, and digital goods trigger them aggressively: EU VAT applies from the first euro of B2C sales with no local threshold, the UK has its own regime, and US sales tax is a per-state question with dozens of nexus rules that treat SaaS differently. Stripe Tax will calculate the right amount and track thresholds, which is useful, but calculation is not registration and it is not remittance. Someone still has to register in each jurisdiction and file returns forever.
So the trade is clear. A merchant of record takes a visibly larger cut and absorbs global registration, remittance, invoicing, and the paperwork that follows. A direct processor takes a smaller percentage and hands you a compliance obligation that grows with every country you sell into. The heuristic for small teams: default to a merchant of record until the fee difference is large enough to fund an accountant and the time to manage them. Doing your own tax is a recurring administrative job taken on in exchange for a few percent, and it only pays at real volume.
What billing actually involves
The visible part
A checkout page, a set of plans, upgrades, downgrades, cancellation. Every processor does this well, and evaluating on this list alone leads you to conclude, wrongly, that the options are interchangeable.
The part that breaks in production
Webhook delivery that retries, arrives out of order, and occasionally arrives twice. Subscription state drifting between processor and database, so your app thinks someone is on Pro and the processor stopped charging them in March. Proration on mid-cycle upgrades, arithmetic you should never write yourself. Failed payments and the dunning sequence that follows, the difference between recovering an expired card and losing a customer silently. Refunds, and whether access actually stops when one is issued. And the tax invoice with the VAT number a customer's finance team demands before they can expense you.
That second list is where most of the engineering time goes, and it is why a billing-complete starter kit is worth paying for. If you are still deciding whether a prebuilt kit makes sense, what a SaaS boilerplate actually includes sets the baseline: the value is concentrated in these unglamorous flows, not in the landing page.
The options, honestly characterized
Stripe
Stripe has the best API in the category, the widest ecosystem, more boilerplate support than everything else combined, and by a wide margin the most training data behind it, which matters if an agent writes your integration. If you need something unusual, whether metered usage, seat-based proration, marketplace payouts, or invoicing by bank transfer, Stripe has a documented way to do it.
The cost is that you are the merchant of record, so global tax is yours. Stripe Tax reduces the burden by calculating rates and monitoring thresholds, but you register, you remit, and you own the filings. For a US-only product selling to US businesses, that is manageable. For a solo founder selling consumer subscriptions in thirty countries, it is a second job.
Lemon Squeezy
Lemon Squeezy is a merchant of record with a deliberately simple setup, and it fits digital products, one-time license sales, and straightforward subscriptions. Hosted checkout, tax handled, invoices generated, selling the same day. For a first product priced as "pick a plan, pay monthly," it removes an entire category of work.
The cost shows up twice. The effective take per transaction is higher than a direct processor, the price of the tax service. And the billing model is less flexible: complex proration, usage metering, and unusual enterprise arrangements are awkward or unavailable. That head-to-head is the clearest illustration of this decision, so read Lemon Squeezy versus Stripe before you commit.
Polar
Polar is a merchant of record aimed at developer products, with a modern API, first-class handling of open source monetization, and a mental model built for small SaaS rather than large retail. If you sell a developer tool, a paid template, or a subscription to something you maintain in public, it fits without adaptation.
The cost is ecosystem age. Fewer boilerplates ship a Polar integration, fewer posts cover the corner cases, and there is less training data, so an agent writing Polar code leans harder on documentation and hallucinates more confidently than with Stripe. Survivable, but it changes how much you verify.
Paddle
Paddle is the merchant of record with the most enterprise maturity. It handles B2B invoicing, purchase orders, and the procurement requirements that appear when your customer is a company with a finance department rather than a person with a card. If you expect annual business contracts and do not want a tax practice, Paddle covers that best.
The cost is friction on the way in: an approval process, scrutiny of what you sell and how you present it, and an experience oriented toward established businesses rather than someone launching on a weekend. It is the least indie-friendly option here, which is fine if you are not indie.
RevenueCat
RevenueCat is a different category and exists for a specific reason: Apple and Google require their own in-app purchase systems for digital subscriptions sold inside a mobile app, and each takes its own cut. That leaves you with two purchase systems, two receipt formats, and two renewal models, plus whatever you use on the web. RevenueCat sits on top and gives you one entitlement API, so your app asks "does this user have Pro" and gets a consistent answer wherever they paid. If your product has a mobile app with subscriptions, you are probably using both RevenueCat and a web processor.
Pricing model before processor
You cannot pick a processor until you know what you are selling. Flat monthly subscriptions work everywhere. Per-seat plans need real proration and a way to sync seat counts as a team grows, which narrows the field. Usage-based billing narrows it sharply, because metering, aggregation, and mid-cycle billing on consumption are deep features some processors treat as core and others barely support. One-time license sales are the easiest case, and the one where a merchant of record is most obviously worth it.
Declare the pricing model early, before any billing code, because switching from flat plans to seats or usage after launch means migrating live subscriptions rather than changing a config value. Model the numbers first: run your expected volume, average price, and fee percentage and see whether the merchant-of-record premium costs a rounding error or a salary. The free tools section has a pricing calculator to start from.
What generated billing code gets wrong
Billing is the second-worst place for unreviewed generated code, behind auth, and it fails for one reason: the happy path demos perfectly. A checkout that works looks identical to one that works and handles retries correctly.
The failure patterns are predictable. Webhooks treated as reliable and ordered, when they retry, duplicate, and arrive out of sequence, so a subscription update processed after a deletion resurrects a canceled plan. No idempotency key, so a webhook delivered twice grants two months of credits. Subscription state read from the client, where a browser-supplied value decides what the server unlocks. And the most common one: access granted at checkout rather than on webhook confirmation, so a payment that later fails, gets disputed, or is refunded leaves a provisioned paid account behind.
One sentence prevents all four. Entitlement is derived from processor state stored in your database, written by an idempotent webhook handler, and nowhere else. The checkout redirect is a UI event, not a source of truth. The client never decides the plan. Every handler is safe to run twice, and unknown event types are logged rather than silently dropped.
Write that rule into the brief your agent reads, because it is exactly what a model will not infer from context. Our AGENTS.md templates include billing rules in that form, and the AGENTS.md generator produces a project-specific file so the constraint exists before the first webhook handler does.
Testing the money path properly
The minimum suite is five scenarios, all runnable in test mode. A real purchase through to provisioned access. A webhook replayed twice, verifying the second delivery changes nothing. A failed payment, verifying access is restricted where your dunning policy says. A cancellation, verifying access ends when you promised. And a resubscribe by a previously canceled customer, where most implementations discover they created a duplicate customer record.
This is the highest-value test suite in a SaaS codebase and the one most likely to be missing, because it is tedious and nobody asks for it. It pays for itself the first time a refund does not revoke access and you learn it from your bank statement rather than your logs.
To evaluate a candidate kit, ask your coding agent to explain how subscription state stays in sync with the processor, then open the files and check the answer. You want a webhook handler that is the single writer of entitlement state, idempotency handled explicitly, and no path where the client's word is taken for a plan. The agent-ready boilerplate checklist covers running that interrogation across a whole codebase.
How to pick a boilerplate on payments
Kits differ far more on billing depth than on auth. Almost every kit has a working login. Far fewer have a billing layer that survives a real customer base. The differentiators, roughly in order of how often they are missing: proration on plan changes, seat-based plans with mid-cycle member changes, usage metering, a customer portal for card updates and cancellation, and invoice access. A kit that ships all five saves you more work than the rest of the repository.
Check which processor the kit assumes, because a Stripe-shaped kit and a merchant-of-record-shaped kit differ on who owns tax and where invoices come from, and converting one into the other is not a config change. The Agent-Ready category lists kits scored on structure, the best Next.js boilerplates roundup gives stack-specific shortlists, and the best payments for Next.js roundup narrows to processors with maintained integrations.
Frequently Asked Questions
Should I use a merchant of record or Stripe directly?
Use a merchant of record until insourcing tax handling is genuinely cheaper than the fee difference, and be honest that insourcing costs more than an accountant's invoice: registrations in multiple jurisdictions, filings that never stop, and your own attention. The threshold lands past the point where you have consistent revenue, a finance firm on retainer, and enough volume that a few percentage points is a real line item. Below that, the premium buys time. One nuance: if you sell only to businesses in your own country, the direct-processor burden is far smaller and Stripe becomes reasonable much earlier.
Can an AI agent build my Stripe integration?
It can wire checkout competently, because that path is well documented and heavily represented in training data. The webhook and entitlement layer is different: it needs the pattern specified up front and verified by a test, because the correct implementation and the broken one look identical when you click through them. Give the agent the rule explicitly, then verify with a replayed webhook rather than a manual purchase. Left to infer the design, an agent will grant access at checkout, the most common billing bug there is.
What is the most common billing bug in a new SaaS?
Granting access at checkout instead of on webhook confirmation. The redirect back from a hosted checkout page means the customer completed a form, not that money settled, so refunds, disputes, and failed later charges all leave paid access in place. The correct flow: checkout redirects to a page saying the account is being set up, the webhook writes the entitlement, and the app reads it from your database. It costs almost nothing on day one and is unpleasant to retrofit once real customers hold accounts in the wrong state.
Do I need usage-based billing on day one?
Almost never. Usage pricing adds metering, aggregation, mid-cycle invoicing, and a customer-facing usage display that people will dispute, and few products need it before they have found their pricing. The cheap way to leave the door open is to record the events you would eventually bill on, in your own database, with a timestamp and an account ID, while charging a flat rate. That gives you months of usage data to design pricing against, and if you never adopt usage pricing you still have the analytics.
How much do payment fees actually matter?
Far less than founders think at small scale. On low volume, the gap between a direct processor and a merchant of record is small in absolute terms and easily outweighed by a week spent on tax registration or a single missed VAT filing. The percentage dominates once the absolute cost of that gap exceeds what hiring out the compliance work would cost, at which point migrating becomes worth the disruption. Until then, optimize for the flows above, because a broken dunning sequence loses more revenue than any fee schedule.
