Payments · Last reviewed September 28, 2026

Merchant of Record vs Payment Processor for SaaS Founders

A payment processor (classic Stripe Payments) moves money while you remain merchant of record: you own sales tax, VAT, and GST registration, collection, filing, and remittance where you have obligations. A Merchant of Record (MoR)—Paddle, Lemon Squeezy, Polar, and Stripe Managed Payments—becomes the seller to the end customer for covered checkouts and typically remits covered indirect tax inside its MoR model. In 2026 public bands, US Stripe cards commonly price near 2.9% + $0.30; classic MoRs often headline near 5% + $0.50; Managed Payments adds 3.5% on top of standard Stripe processing. Pick by liability, effective global fee, and how much tax ops you want in-house.

Merchant of record vs payment processor: quick ownership table

Takeaway: The core difference is who is the legal seller on the checkout and who remits covered sales tax / VAT / GST—not which logo sits on your marketing site.

For vendor-by-vendor fees inside this split, use the dated table in Stripe vs Paddle vs Lemon Squeezy and the indie ladder in Paddle vs Lemon Squeezy vs Polar.

What a payment processor actually does

Takeaway: A processor is payment rails plus risk tooling—you keep the seller-of-record hat unless you buy a separate MoR product.

With a classic processor setup (Stripe Payments is the common SaaS default), the platform authorizes and settles card (and other) payments, provides APIs, fraud signals, and payouts. Your company is usually the merchant named on the customer relationship for tax and consumer-law purposes. Stripe Tax can calculate and help collect tax amounts, but public Stripe materials still frame filing and remittance liability as remaining with the business when you are not on an MoR product.

That model is powerful when you want full control of checkout UX, pricing experiments, enterprise invoicing, and your own tax registrations. It also means nexus, VAT OSS (or local VAT), and state sales-tax calendars stay on your compliance calendar. Cross-border context for US SaaS teams is covered in VAT OSS for US SaaS companies.

Operationally, processor stacks also keep you closer to raw payment data for cohort analysis, custom dunning, and marketplace or multi-party payouts. The tradeoff is predictable: every new country or US state with nexus is another registration, return calendar, and potential notice. Teams that underestimate that ops load are the ones who later migrate to MoR after a painful VAT letter—not because MoR is magically cheaper, but because the fully loaded cost of DIY finally exceeded the MoR premium.

What a merchant of record actually does

Takeaway: An MoR resells (or otherwise stands in as seller) so it can collect and remit covered indirect tax—and that risk shift is why headline fees exceed raw processing.

Paddle and Lemon Squeezy market themselves as Merchants of Record for software and digital products: the platform sells to the buyer, collects payment, and handles much of the global indirect-tax workflow inside its offering. Polar documents the same MoR model with a public fee ladder. You receive net proceeds under a commercial relationship with the MoR. Coverage still depends on product category, customer location, and the vendor’s current tax footprint—always read the current coverage docs, not a blog summary alone.

Stripe’s Managed Payments is an MoR path inside the Stripe ecosystem: Stripe states that Managed Payments adds 3.5% per successful transaction to your standard Stripe processing fees and includes global indirect tax handling as merchant of record for eligible flows. Compare that hybrid to classic MoRs in Stripe Managed Payments vs Paddle.

MoR contracts still deserve legal review. You are granting the platform rights to sell your product, set certain checkout and refund behaviors, and appear as the merchant to end customers. Reserve policies, prohibited-product lists, and chargeback cooperation clauses are not boilerplate trivia. If your category is edge-case (regulated data, marketplace splits, physical goods bundles), confirm eligibility in writing before you announce a migration on social media.

2026 fee and responsibility table (dated public bands)

Takeaway: Compare effective rate on your mix of domestic vs international volume—not sticker percentage in isolation—and separate “calculates tax” tools from “remits as MoR.”

Fees change. Recheck Stripe pricing, Managed Payments, Paddle pricing, Lemon Squeezy fees, and Polar MoR fees before you commit a migration.

Stripe Tax vs merchant of record remittance

Takeaway: Stripe Tax is a calculation and collection helper on a processor path; it does not, by itself, turn Stripe into your Merchant of Record.

Founders often conflate “tax amount appears on the invoice” with “someone else filed and remitted.” On a classic Stripe setup, enabling Stripe Tax improves accuracy and checkout UX, but registrations, returns, and remittance remain your (or your advisor’s) job unless you move those checkouts onto an MoR product such as Managed Payments or a third-party MoR. That distinction drives most “why is MoR more expensive?” conversations: you are buying liability shift and ops, not just a payment API.

Decision tree: which model fits your stage

Takeaway: Start from customer geography and ops capacity; only then pick a logo.

1. Mostly US / simple B2B, strong finance ops: Processor (Stripe) + disciplined tax tooling often wins on domestic unit economics. Keep a written nexus/VAT calendar.
2. Global self-serve SaaS, lean team: Classic MoR (Paddle, Lemon Squeezy, or Polar) can beat DIY registrations when international share is material and you lack in-house tax ops.
3. Already deep in Stripe, want MoR without rip-and-replace: Evaluate Managed Payments eligibility, product tax codes, and the +3.5% overlay versus leaving the Stripe stack.
4. Enterprise net terms / heavy custom contracts: Confirm whether the MoR supports invoicing, PO workflows, and your deal desk—or keep processor + your own tax stack for those SKUs.
5. Hybrid is allowed: Some teams keep enterprise on processor invoicing and put self-serve global checkout on an MoR. Document which SKUs use which seller of record so accounting stays coherent—see also deferred revenue for SaaS in QuickBooks.

When NOT to use a Merchant of Record

Takeaway: Skip MoR when the fee premium does not buy liability you actually need, or when product/checkout constraints break your motion.

• Nearly all volume is domestic and you already run sales-tax software plus a CPA process that works.
• Your product category or pricing model is outside the MoR’s supported catalog.
• You need statement descriptors, refund policy, or marketplace economics the MoR will not allow.
• You are optimizing purely for the lowest domestic processing rate and will staff tax ops.
• A sales-led enterprise motion depends on your entity issuing invoices under negotiated MSAs—validate MoR invoicing before switching the whole stack.

Customer experience, invoices, and statement descriptors

Takeaway: MoR checkouts often show the platform (or platform-ruled naming) on cards and invoices—plan support macros and brand expectations before go-live.

Processor path: customers usually see your brand and reconcile invoices against your entity. MoR path: buyers may see Paddle, Lemon Squeezy, Polar, or Stripe MoR naming depending on product rules. That is not automatically bad—it can reduce card confusion in some markets—but your support team needs clear language for “Why does my bank show X?” Refunds, disputes, and tax invoices follow the MoR’s playbook, so train CS before you flip traffic.

Migration notes if you switch later

Takeaway: Migrations fail on subscriptions, tax history, and dual-running periods—not on the first test charge.

• Inventory active subscriptions, trials, and coupons; map proration and dunning differences.
• Decide whether historical tax filings stay under your entity while new checkouts move to MoR (common) and document the cutover date.
• Re-test tax-inclusive vs exclusive display, VAT ID capture, and B2B reverse-charge flows if you use them.
• Update Terms, privacy, and checkout disclosures to match the actual seller of record.
• Keep finance close: payout timing, reserve policies, and revenue recognition inputs can all shift.

How Stripe, Paddle, Lemon Squeezy, and Polar map to the models

Takeaway: Treat “Stripe” as a family of products in 2026—classic processing, Tax add-ons, and Managed Payments MoR are not the same liability story.

Stripe Payments is the processor default most founders start with. You keep seller-of-record status; you can layer Billing, Tax, Radar, and invoicing. That stack is excellent for product-led growth when engineering owns checkout and finance owns nexus calendars.

Stripe Managed Payments flips eligible checkouts into an MoR relationship with Stripe. The public pricing signal is an additional 3.5% on standard processing, framed as including global indirect tax handling for those flows. Eligibility, tax codes, and Checkout/Payment Links constraints matter—do not assume every SKU can flip with a flag.

Paddle is a classic SaaS-oriented MoR with all-in Checkout pricing publicly listed at 5% + 50¢, with custom paths for under-$10 products and invoicing. Founders often pick Paddle when they want MoR plus mature subscription and B2B billing options without building tax registrations first.

Lemon Squeezy (Stripe-owned as of prior years, still operating as its own MoR product) documents a 5% + $0.50 platform fee plus stackable surcharges for international cards, PayPal, and subscriptions. It remains popular for indie and productized digital goods; model the surcharges explicitly on international-heavy mixes.

Polar publishes a transparent ladder: free Starter at 5% + 50¢, then Pro / Growth / Scale with lower variable rates plus monthly fees. That ladder is useful when you can forecast monthly sales and decide whether a paid plan’s breakeven beats Starter. Full indie comparison: Paddle vs Lemon Squeezy vs Polar.

Worked fee intuition (not a quote)

Takeaway: A 2-point headline gap can disappear—or widen—once international cards, tax tooling, and dispute ops enter the model.

Suppose you process mostly US cards on Stripe at roughly 2.9% + 30¢ and later enable Stripe Tax (separate fee per Stripe’s Tax pricing). Your remittance work still sits with your team. Move the same global self-serve volume to a 5% + 50¢ MoR and you pay a higher variable rate but drop many registration and filing cycles for covered sales. Now overlay Managed Payments’ +3.5% on Stripe processing: for some mixes it lands between DIY processor+tax-ops and a full third-party MoR—especially if you want to keep Stripe’s developer surface.

None of those comparisons replace a spreadsheet with your average order value, refund rate, % international, and % enterprise invoices. Build that sheet before you sign an annual MoR or rip out Checkout.

Accounting and compliance checklist before you choose

Takeaway: Payments model changes touch revenue recognition, customer master data, and tax notices—not only checkout conversion.

• Write down the seller of record for each major SKU and channel (self-serve vs sales-assisted).
• Confirm how payouts arrive (gross vs net of tax) and how your bookkeeper will reverse-map MoR statements.
• Align deferred revenue and recognition policy with whoever issues the customer invoice—see deferred revenue for SaaS in QuickBooks.
• Update privacy/terms/checkout copy so customers know who they contract with for that purchase.
• Ask counsel whether consumer-cancellation or local e-commerce rules change when the MoR is the seller.
• Keep corporate income tax, R&D credits, and entity filings on a separate track—MoR does not absorb them.

For the broader stage map (formation → tax → security), use the SaaS founder compliance checklist and Start here.

FAQ: merchant of record vs payment processor

Is a payment processor the same as a merchant of record?

No. A processor moves payment; you typically remain the seller of record. An MoR becomes the seller for covered checkouts and usually remits covered indirect tax.

Does Stripe Tax mean Stripe remits my VAT and sales tax?

Not on the classic processor path. Stripe Tax helps calculate and collect; remittance stays with you unless you use an MoR product such as Managed Payments for eligible transactions.

Are Paddle and Lemon Squeezy merchants of record?

Yes—both market MoR models for supported software/digital products. Confirm current coverage and product eligibility on their sites.

Is Polar a merchant of record?

Yes. Polar documents MoR fees publicly (Starter 5% + 50¢ and paid ladders). See our Paddle vs Lemon Squeezy vs Polar comparison.

What is Stripe Managed Payments in this comparison?

Stripe’s MoR offering that adds 3.5% on standard processing for eligible checkouts, with Stripe handling covered indirect tax as merchant of record. Details: Managed Payments vs Paddle.

When should a SaaS founder avoid a merchant of record?

When domestic unit economics dominate, you already run tax ops well, or MoR constraints break enterprise invoicing / product eligibility.

Who appears on the customer’s credit card statement?

Processor path: usually your brand/entity rules. MoR path: often the MoR’s naming rules. Always test live descriptors in each target country.

Does using a MoR handle my corporate income tax?

No. MoR addresses seller-of-record and many indirect-tax workflows for covered sales. Corporate income tax, transfer pricing, and entity filings remain yours.

Bottom line for SaaS founders

Takeaway: Processor = control + you own tax; MoR = higher headline fee + remittance shift for covered sales—model both with your real geography mix.

In 2026 the menu is wider than “Stripe vs Paddle”: Managed Payments and Polar sit beside classic MoRs. Re-price twice a year, keep one source of truth for seller of record, and map payments into the broader stack with the SaaS founder compliance checklist.

Next step

Read the fee deep-dive Stripe vs Paddle vs Lemon Squeezy, then Stripe Managed Payments vs Paddle if you are torn between Stripe-native MoR and a classic MoR. When you want the stage map for the whole compliance stack, return to Start here and the tools hub.