Stripe vs Paddle vs Lemon Squeezy: Choosing Payments for a Laravel SaaS
By Annu Gupta··8 min read
When you compare Stripe vs Paddle vs Lemon Squeezy for your Laravel SaaS, it's tempting to open three pricing pages and pick the lowest percentage. I'd hold off on that. For a SaaS, this is mostly a tax and responsibility decision, and the question underneath it is simple: who legally sells your product, you or the provider?
Below I'll explain the difference between a payment processor and a merchant of record, what each option means for sales tax and VAT, which Laravel package goes with each provider, and how I'd choose.
Payment processor vs merchant of record
If you only take one idea from this post, make it this one, because everything else follows from it.
A payment processor moves money for you, and you stay the seller. Your company name is on the invoice. You're responsible for charging the right sales tax or VAT, registering where you need to, filing returns, and handling refunds and disputes.
A merchant of record (MoR) resells your product instead. The customer buys from the MoR, which charges the tax, pays it to the tax authorities, deals with disputes and then pays you what's left.
| Payment processor | Merchant of record | |
|---|---|---|
| Legal seller | You | The provider |
| Sales tax and VAT | You calculate, collect, register and file (tools can help) | The provider handles it |
| Name on the customer's invoice | Your company | The provider |
| Control over checkout and data | High | Lower: you work inside their rules |
| Product types allowed | Broad | Usually software and digital products only |
| Typical cost | Lower headline fees, plus your own tax work | Higher headline fees that include the tax work |
Neither one is better across the board. A processor gives you control. An MoR takes a whole category of compliance work off your plate.
Stripe: the flexible payment processor
Stripe is a payment processor with lots of building blocks. There's Stripe Billing for subscriptions, Stripe Checkout for hosted payment pages, a customer portal, and Stripe Tax, which calculates and collects tax on your transactions. If you're wondering whether Stripe Tax makes Stripe a merchant of record, it doesn't. You're still the seller, so registering with tax authorities and filing returns are still your job.
Stripe has also introduced Managed Payments, its own merchant-of-record option for digital products. It's newer, so before you plan around it, check Stripe's documentation for the countries and features it currently supports, and check that your Laravel package works with it.
I'd lean towards Stripe when you want full control over checkout, when you sell to businesses who expect your company on the invoice, or when you already have an accountant handling tax registrations.
Paddle: merchant of record for software
Paddle is a merchant of record. It resells your software, handles sales tax and VAT in the countries that require it, and deals with payment disputes. Instead of individual card payments landing in your account, you receive payouts.
One thing to watch for: Paddle's current platform is called Paddle Billing. The older platform, Paddle Classic, uses a different API, and Laravel's package has a separate major version for each. New projects should use Paddle Billing.
Paddle suits you well if you're selling internationally from day one and would rather not handle tax registrations in many countries yourself.
Lemon Squeezy: merchant of record, now part of Stripe
Lemon Squeezy is also a merchant of record, and it's popular with indie developers because it's simple to set up. Stripe acquired Lemon Squeezy in July 2024, and both have kept running since. Lemon Squeezy handles sales tax on your digital products and gives you hosted and overlay checkouts, discount codes and a customer portal.
Since it's now owned by Stripe, which also offers Managed Payments, read Lemon Squeezy's latest announcements before you commit, so you know where the product is heading.
Laravel packages for each provider
All three have a maintained Laravel package, and they share the same idea. You add a Billable trait to your billable model, start a checkout, and let webhooks keep your local subscription tables in sync.
| Stripe | Paddle | Lemon Squeezy | |
|---|---|---|---|
| Package | laravel/cashier | laravel/cashier-paddle | lemonsqueezy/laravel |
| Maintained by | Laravel | Laravel | Lemon Squeezy |
| Trait | Laravel\Cashier\Billable | Laravel\Paddle\Billable | LemonSqueezy\Laravel\Billable |
| Webhook route | /stripe/webhook | /paddle/webhook | /lemon-squeezy/webhook |
| Checkout style | Redirect to Stripe Checkout | Overlay or inline via Paddle.js | Hosted page or overlay |
| Supports Laravel 13 | Yes | Yes (2.x for Paddle Billing) | Yes |
Whichever package you use, its webhook route has to be excluded from CSRF protection, and it verifies webhook signatures once you set the signing secret. If you want a full Stripe walkthrough in a multi-tenant app, see adding Stripe billing to a Laravel SaaS.
Checkout with Inertia
The checkout style matters more than usual in an Inertia app, because Inertia visits are XHR requests. It's an easy detail to miss.
Stripe Checkout and Lemon Squeezy's hosted checkout both redirect to another domain. For those, return Inertia::location($url) so the browser does a full page visit instead of an XHR one.
Paddle's overlay is different, because it runs inside your page through Paddle.js. Cashier Paddle's examples use Blade (@paddleJS and a paddle-button component). In an Inertia app you load Paddle.js yourself and pass the checkout options from the server as a prop:
$checkout = $tenant->subscribe($priceId, 'default')
->returnTo(route('billing.show'));
return Inertia::render('billing/Show', [
'paddleCheckout' => $checkout->options(),
]);Then, when the user clicks "Subscribe", your component calls Paddle.Checkout.open() with those options.
Stripe vs Paddle: tax and compliance in practice
Tax is where the difference really shows. The rules vary by country, but a few questions will help you see what you're signing up for.
Start with where your customers are. Many countries and US states tax digital services and set their own thresholds, so selling worldwide means keeping track of many sets of rules. Then think about who they are. Business customers often expect a VAT-compliant invoice from your company and may need to enter a tax ID, while consumers care much less about whose name is on the invoice.
It also depends on what help you have. With a processor, an accountant or a tax service does the registrations and filings. With an MoR, that work is already part of the deal. And check what you sell: MoRs only accept certain product types, so read their acceptable use policies before you build anything.
This is not tax advice. Please talk to an accountant who knows the countries you sell in.
Fees: compare the whole cost
Don't compare headline percentages on their own, and don't trust fee numbers in blog posts either, including this one. Fees change, and they differ by country, currency and payment method. Look at each provider's current pricing page, then add the costs that don't appear there:
- Currency conversion and international card surcharges
- Dispute and chargeback fees
- Payout fees and payout schedules
- Your time, or an accountant's, for tax registration and filing
- Separate tax calculation products, if you use a processor
A merchant of record usually costs more per transaction and less in admin work. Estimate both sides using your expected revenue and where your customers are.
Stripe vs Paddle vs Lemon Squeezy: how to choose
| If you... | Consider |
|---|---|
| Want full control over checkout, data and invoices | Stripe |
| Sell mostly to businesses in one country | Stripe |
| Sell globally and want tax handled for you | Paddle or Lemon Squeezy |
| Want the most battle-tested Laravel integration | Stripe (Cashier) or Paddle (Cashier Paddle) |
| Sell physical goods or services outside software | Stripe |
| Want to launch quickly as a solo developer | A merchant of record |
If I were a solo developer selling software worldwide, I'd start with a merchant of record and accept the higher fee, because the tax work is the part that's hardest to do alone. A team selling to businesses in one country with an accountant already on board has less reason to pay for that, and Stripe's control starts to win.
Either way, keep billing behind your own service class. Your app then asks "is this workspace subscribed?" instead of calling a provider's API directly, and a later switch stays contained.
Switching providers later
You can switch, but it's rarely painless. Customers usually have to enter their payment details again, since card data can't always be moved between providers, and every active subscription has to be recreated. So if you're unsure, try to decide before you have paying customers. It also helps to get your pricing and plan structure clear before you set up products in any dashboard.
Frequently asked questions
What is the main difference between Stripe and Paddle?
Stripe is a payment processor, so you stay the seller and handle tax registration and filing yourself. Paddle is a merchant of record: it resells your product and takes care of sales tax, VAT and disputes for you.
Does Laravel Cashier support Paddle?
Yes, through a separate package Laravel maintains, laravel/cashier-paddle. Version 2.x works with Paddle Billing, and version 1.x is for the older Paddle Classic platform.
Is there an official Laravel package for Lemon Squeezy?
Lemon Squeezy maintains lemonsqueezy/laravel, which gives you a Billable trait, checkouts, subscriptions and webhook handling. It isn't part of Laravel's own Cashier family, though.
Can I use more than one payment provider?
You can, but each provider keeps its own customers and subscriptions, so your app has to remember which provider each account uses. I'd stick with one provider until there's a clear reason to add a second.
Payments and SaaS Laravel
SaaS Laravel doesn't include billing or any payment provider, and that's on purpose, so you can use Stripe, Paddle, Lemon Squeezy or whatever fits your market. What the kit does give you are the pieces billing sits on: a central App\Models\Tenant model that can become the billable model, a module-based architecture where a billing module fits in next to the others, and a workspace status you can hook up to subscription events. The Laravel SaaS starter kit buyer's guide covers what the kits do and don't include.