Stripe also now offers its own merchant of record option, called Managed Payments, for digital products sold through Stripe Checkout or Payment Links. It covers sales tax, VAT, and GST in more than 80 countries, plus fraud, disputes, and transaction-level support, but it does not work with Stripe Connect, embedded payment components, or subscriptions created outside Checkout. Check its current fee and country list on Stripe's site before relying on it.

How do the fees compare in 2026?

Here is the plain arithmetic on one $20 per month subscription, using only the list prices above. This is an example calculation, not data from a Luminix Studio project.

Two things this table shows. First, the fixed 30 or 50 cents hurts most on cheap plans, so a $5 plan loses a much bigger share than a $50 plan on every provider. Second, Stripe looks cheaper per transaction, but the gap is roughly two points of revenue, and the cost of tax registrations and filings in several countries can easily be more than that for a small team.

When should a startup choose a merchant of record?

Choose Paddle, Lemon Squeezy, or Stripe Managed Payments when most of these are true:

1. You sell software or digital products to consumers or small businesses in many countries.
2. You have no finance person and do not want to track VAT, GST, and US state sales tax thresholds.
3. Your plans are priced high enough that a 5% + 50¢ fee is acceptable.
4. You want refunds, failed payment emails, and billing questions handled by someone else.

A merchant of record is usually the faster path to a real launch for a small global SaaS. You trade a bit of margin for not having a tax project.

When is Stripe on its own the better choice?

Choose Stripe as a processor when:

1. You are building a marketplace or platform. If you pay out to sellers or creators, you need Stripe Connect, and merchant of record tools generally do not cover that model.
2. You sell physical goods or services, not only digital products. MoR providers focus on digital goods.
3. You need a fully custom checkout, such as embedded payment fields inside your own UI, or unusual billing logic like invoice items and one-off charges mid-cycle.
4. You mainly sell B2B in one or two countries where you are already registered for tax. Then the tax work is small and the lower fee wins.
5. Volume is high. At high revenue, two points of margin is real money, and you can afford a finance team or tax software.

How hard is it to switch providers later?

Harder than people expect, mainly because of saved cards. Card details live in the provider's vault, so moving active subscribers usually means a data migration that the old and new providers both have to support, or asking customers to re-enter their card. Plan for that cost when you choose.

You can make switching easier by keeping your app's billing logic provider-agnostic from day one:

• Store your own subscriptions table and let webhooks update it. Your app checks that table, never the provider's API, to decide what a user can access.
• Keep provider IDs in their own columns so a second provider can live next to the first.
• Process every webhook idempotently, because all three providers can retry and resend events.

How do you set up billing webhooks in a Next.js app?

Here is a small, provider-agnostic schema for Postgres or Supabase.

create table subscriptions (
  id uuid primary key default gen_random_uuid(),
  user_id uuid not null references auth.users(id),
  provider text not null check (provider in ('stripe','paddle','lemonsqueezy')),
  provider_customer_id text not null,
  provider_subscription_id text not null,
  plan text not null,
  status text not null,            -- active, trialing, past_due, canceled
  current_period_end timestamptz,
  updated_at timestamptz not null default now(),
  unique (provider, provider_subscription_id)
);

create table billing_events (
  provider text not null,
  event_id text not null,
  received_at timestamptz not null default now(),
  primary key (provider, event_id)  -- makes retries safe
);

Each provider signs its webhooks differently. Always verify the signature against the raw request body before you trust the payload.

Stripe (App Router route handler, using the official SDK):

// app/api/webhooks/stripe/route.ts
import Stripe from "stripe";

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

export async function POST(req: Request) {
  const body = await req.text(); // raw body, not req.json()
  const signature = req.headers.get("stripe-signature") ?? "";

  let event: Stripe.Event;
  try {
    event = stripe.webhooks.constructEvent(body, signature, process.env.STRIPE_WEBHOOK_SECRET!);
  } catch {
    return new Response("Invalid signature", { status: 400 });
  }

  if (await alreadyProcessed("stripe", event.id)) return new Response("ok");

  if (event.type.startsWith("customer.subscription.")) {
    const sub = event.data.object as Stripe.Subscription;
    await upsertSubscription({
      provider: "stripe",
      providerSubscriptionId: sub.id,
      providerCustomerId: String(sub.customer),
      status: sub.status,
    });
  }
  return new Response("ok");
}

Paddle sends a Paddle-Signature header shaped like ts=...;h1=.... The h1 value is an HMAC-SHA256 of ts:rawBody using your webhook secret. Lemon Squeezy sends an X-Signature header, an HMAC-SHA256 hex digest of the raw body using your signing secret. A shared helper covers both:

// lib/billing/verify.ts
import crypto from "node:crypto";

function safeEqual(a: string, b: string) {
  const ab = Buffer.from(a);
  const bb = Buffer.from(b);
  return ab.length === bb.length && crypto.timingSafeEqual(ab, bb);
}

export function verifyPaddle(rawBody: string, header: string, secret: string) {
  const parts = Object.fromEntries(header.split(";").map((p) => p.split("=")));
  if (!parts.ts || !parts.h1) return false;
  const expected = crypto.createHmac("sha256", secret).update(`${parts.ts}:${rawBody}`).digest("hex");
  return safeEqual(expected, parts.h1);
}

export function verifyLemonSqueezy(rawBody: string, header: string, secret: string) {
  const expected = crypto.createHmac("sha256", secret).update(rawBody).digest("hex");
  return safeEqual(expected, header);
}

alreadyProcessed inserts into billing_events and returns true if the primary key already exists. upsertSubscription writes to your own table. Your pricing page, paywall, and feature flags then read only from subscriptions, so a provider change touches the webhook routes and checkout links, not the rest of the app.

What should you check before you launch billing?

1. Run a full test purchase, upgrade, downgrade, cancel, and failed payment in the provider's sandbox or test mode.
2. Confirm every webhook route verifies signatures and survives a replayed event.
3. Check prices display in the currencies your customers expect.
4. Make sure invoices or receipts show the right seller name. With a merchant of record, that is the MoR, so tell customers in your checkout copy.
5. Read the provider's prohibited and restricted products list. MoR providers review your business before payouts start, so apply early.
6. Write down who answers billing emails: you or the provider.

How does Luminix Studio help startups set up global billing?

Luminix Studio builds web and mobile apps, and the AI automations around them, for startups worldwide. When we scope an MVP that charges money, we settle the merchant of record question in the first week, build billing around your own subscriptions table with verified, idempotent webhooks, and keep the provider swappable. If you are choosing between Stripe, Paddle, and Lemon Squeezy for your product, or want billing built properly the first time, see luminixstudio.com.