Vs Cashier (Stripe, Paddle) & Lemon Squeezy
Picking the billing layer for a new Laravel app? If you've reached for Laravel Cashier
before, Vatly will feel immediately familiar — a Billable trait, subscribed(),
subscription()->swap(), a wired-up webhook endpoint. The difference is what sits behind
the API: Vatly is a Merchant of Record, so it is the legal seller and handles VAT,
invoicing, and payment compliance for you — and it's Europe-first, operating under EU
jurisdiction.
This page is an honest, side-by-side look at how vatly-laravel stacks up against the
Cashier-style packages you might otherwise reach for —
Laravel Cashier (Stripe),
Laravel Cashier (Paddle), and
Lemon Squeezy for Laravel — gaps included.
At a glance
| Cashier (Stripe Billing) | Cashier (Paddle) | Lemon Squeezy | Vatly | |
|---|---|---|---|---|
| Composer package | laravel/cashier | laravel/cashier-paddle | lemonsqueezy/laravel | vatly/vatly-laravel |
| Billable trait | Laravel\Cashier\Billable | Laravel\Paddle\Billable | LemonSqueezy\Laravel\Billable | Vatly\Laravel\Billable |
| Merchant of Record | No — you are the seller | Yes | Yes | Yes (full) |
| Entity / jurisdiction | You (wherever you're registered) | Paddle, UK | Lemon Squeezy, US (Stripe-owned) | EEA / EU jurisdiction |
| Who remits VAT/sales tax | You (Stripe Tax only calculates) | Provider | Provider | Provider |
| Customer stored as | columns on the billable model (stripe_id, …) | customers table (paddle_id) | lemon_squeezy_customers table | vatly_id column on the billable model + vatly_* tables |
| Checkout | Stripe Checkout (hosted) / Elements | Paddle.js overlay / inline (client-side JS) | Lemon.js overlay / hosted URL | Vatly-hosted redirect (+ guest claim) |
| Webhook route | /stripe/webhook | /paddle/webhook | /lemon-squeezy/webhook | /webhooks/vatly |
| Coupons / promo codes | Yes | Yes | Yes | On the roadmap (workaround below) |
| License keys | No | No | Yes | On the roadmap (rarely needed for SaaS) |
| Refunds & chargebacks | wire it yourself | events | events | first-class models + events |
| Trials, swap, grace/resume | Yes | Yes | Yes | Yes |
Two takeaways:
- With
laravel/cashier, you're the seller of record. It runs on classic Stripe Billing, so you register for VAT, file, and remit in every market you sell into — the compliance and the liability sit with your company. (Stripe's own Merchant-of-Record product, Managed Payments, is a separate, US-based service you'd integrate instead — not the Cashier subscriptions you're building on.) - So the real difference between MoRs is jurisdiction. Paddle is UK, Lemon Squeezy and Stripe are US, Vatly is EEA — your seller-of-record entity and customer data stay under EU law. That, not the API, is the reason to choose one over another.
The developer experience
For a greenfield app, Vatly is your only biller — so you use the plain Billable trait, and
the code reads like Cashier:
use Vatly\Laravel\Billable;
class User extends Authenticatable
{
use Billable;
}
// Start a subscription — redirect to Vatly's hosted checkout
$checkout = $user->subscribe()
->toPlan('subscription_plan_7Hd9Kf2Lm')
->withTrialDays(14)
->create();
return redirect($checkout->links->checkoutUrl->href);
// Gate features on subscription state
if ($user->subscribed()) {
// …
}
$user->subscription()->swap('subscription_plan_other');
$user->subscription()->cancel(); // Vatly decides immediate vs. grace
$user->subscription()->resume(); // while on the grace period
// One-off purchase
$user->checkout()->create(
items: [['id' => 'one_off_product_3Qb8Wz1Yt', 'quantity' => 1]],
redirectUrlSuccess: route('billing.success'),
redirectUrlCanceled: route('billing'),
);
// Receipts — hosted invoice URLs, no PDF plumbing
foreach ($user->orders as $order) {
echo $order->invoiceUrl();
}
No VAT logic, no tax tables, no invoice templates, no client-side checkout widget to embed — the checkout is a server-side redirect, like Stripe Checkout. See Subscriptions and Checkouts for the full surface.
Feature parity, and what's still on the roadmap
Vatly covers what a SaaS needs to start selling: subscriptions with trials, plan swaps, cancellation with grace and resume, one-off purchases, hosted checkout, refunds and chargebacks, and — because it's a Merchant of Record — VAT, invoicing and tax compliance handled for you. A few capabilities you may use elsewhere aren't in the box yet. Here's the honest picture, and how to bridge it.
| Capability | Vatly today | Notes |
|---|---|---|
| Subscriptions, trials, swap, grace, resume | ✅ | Full lifecycle, Cashier-shaped API |
| One-off / multi-item checkout | ✅ | checkout()->create(items: …) |
| VAT, invoicing, tax remittance | ✅ | Handled — it's the point of a MoR. With Cashier (classic Stripe Billing) this is your job. |
| Refunds & chargebacks | ✅ | First-class models + events (more than most provide) |
| Test / live segregation | ✅ | Every record carries testmode; key prefix selects the mode |
| Coupons / promo codes | 🔜 Roadmap | Until native codes land, model a promo as a dedicated subscription_plan_… at the discounted price and point that cohort at it. A couple of extra plans in the dashboard — not a blocker for launching offers. |
| License keys | 🔜 Roadmap | Vatly is built for SaaS, where entitlement follows subscription state — subscribed() is your license check. Per-seat keys for downloadable/offline software (Lemon Squeezy's signature feature) aren't here yet. If you ship license-activated desktop binaries, that's the one workflow to keep elsewhere for now. |
The shape of the trade is deliberate: Vatly does the compliance-heavy core that's genuinely hard to build — being the seller of record, VAT across the EU, invoicing, disputes — and is filling in the conveniences (coupons next) in the open. For a subscription SaaS selling into Europe and the world, there's enough here to launch today.
Why teams choose Vatly
A Merchant of Record makes the tax burden disappear — it becomes the legal seller, so VAT, invoicing and remittance stop being your problem. The real question is whose entity you hand that to, and that's where Vatly stands apart:
- Europe-first, by design. EEA-based, EU jurisdiction, customer data kept in Europe. The other MoRs sit in the UK (Paddle) or the US (Lemon Squeezy, Stripe Managed Payments) — jurisdiction is the one axis that genuinely separates them, and the reason Vatly exists.
- No exposure to US policy. Your seller-of-record relationship and your customers' data stay under EU law — a clean answer when an enterprise buyer, or your own board, asks where they sit.
- One familiar API. The Cashier-shaped surface means there's little to learn and little to rewrite.
You Just Ship.
Next steps
- Starting fresh → Getting started wires up the trait, config, migrations and webhook in a few minutes.
- Already running another provider → Migrating from Cashier shows how to add Vatly beside your current biller and migrate customers over gradually.
- Reference → Configuration · Customers · Checkouts · Subscriptions · Orders · Webhooks
Compared against, at time of writing: Laravel Cashier (Stripe) · Laravel Cashier (Paddle) · Lemon Squeezy for Laravel. Their method names and table layouts follow those packages' current releases — verify against the version you have pinned before relying on a specific signature.