Payment Service Provider (Stripe) vs. Merchant of Record (Paddle): The SaaS Founder's Guide

Published on 2026-08-14

When scaling a SaaS product internationally, founders (including me) usually hit a sharp operational wall around payments, cross-border tax compliance, and local merchant entities.

The choice isn't just about picking Stripe vs. Paddle. It's an architectural and operational decision between two fundamentally different financial models: Payment Service Providers (PSPs) and Merchants of Record (MoRs).

1. Core Structural Difference

The primary distinction comes down to legal ownership of the transaction and where financial liability sits.

PSP Flow

flowchart LR
    C["Customer"] --> P["Payment Processing Tech (PSP)"]
    P --> E["Your Legal Entity
(Seller on Record)"]
    E --> T["You handle Tax, VAT, Disputes"]
      

MoR Flow

flowchart LR
    C["Customer"] --> M["Merchant of Record
(Legal Reseller / Seller)"]
    M --> R["Handles Tax, VAT, Chargebacks, Risk"]
    M --> Y["Payout to Your Entity"]
      

• Payment Service Provider (PSP): Acts as a technical rails partner. They process money from the buyer's account to yours. You remain the seller/merchant of record and retain responsibility for applicable tax obligations such as Value Added Tax (VAT), Goods and Services Tax (GST) or sales tax, for disputes and chargebacks, and for your own PCI obligations. The scope of PCI compliance depends on how you integrate the PSP.
• Merchant of Record (MoR): Acts as a legal reseller of your software. The MoR buys the software license from you instantly at checkout and resells it to the end customer. The MoR is the legal seller/reseller in the transaction, taking on tax remittance, chargeback management, and local regulatory adherence. What the customer actually sees on their card statement is a separate question, determined by the MoR's descriptor configuration.

2. PSP vs. MoR Comparison

3. Deep-Dive Tradeoffs

Option A: Payment Service Provider (Stripe, Adyen, Braintree)

The Build-Your-Own-Stack Approach

Pros:

• Unit Economics at Scale: Standard percentage processing fees are lower.
• Granular Control: Total ownership over the checkout UI, subscription engine, retry mechanisms, and customer billing data.
• Direct Relationships: Clean branding on card statements and direct payouts.

Cons & Hidden Costs:

• Nexus and Filing Burden: Selling globally can mean registering for indirect taxes across many jurisdictions (US states, EU, UK, Canada, Australia). How heavy this gets scales with how much of your revenue is cross-border B2C; a B2B book under reverse charge is a much lighter load than a self-serve consumer one.
• SaaS Stack Bloat: You will often need to layer on tools like TaxJar/Anrok/Avalara for tax calculation, a subscription engine (e.g., Chargebee/Recurly), and fraud tools.

Option B: Merchant of Record (Paddle, Lemon Squeezy, FastSpring, Polar)

The Offloaded Compliance Engine

Pros:

• Offloaded Transaction-Tax Compliance: Cross-border sales tax, VAT, and GST calculation and filing on your sales move to the MoR. Note this is not zero tax work: you still handle accounting for payouts, revenue recognition, reconciliation, product tax classification, and corporate income tax on your own business.
• Rapid International Expansion: Sell into most markets without establishing a local merchant entity or local acquiring in each one. Availability is not unlimited, though; sanctions, export controls, prohibited product categories, payment-method coverage and the MoR's own risk policies all constrain where you can actually sell.
• Operational Simplicity: Single consolidated payout, handled chargebacks, and built-in subscription management.

Cons:

• Higher Direct Take Rate: The headline percentage is higher to cover the tax compliance and risk exposure. Economics vary by provider, so treat the ~5% figure as a reference point rather than a market rate; some price differently, including tiered or subscription components.
• Less Customization: Custom enterprise billing arrangements, bespoke invoicing flows, or high-touch merchant descriptor configurations can be constrained by the MoR's platform boundaries.
• The MoR Sits Between You and Your Customer: This is the tradeoff founders underrate. The MoR is commercially interposed in the relationship, which touches who issues the invoice, who sets the terms of sale, how refunds and renewals work, which payment methods and discounts are available, what customer data you receive, and how revenue recognition falls out. Paddle's terms, for instance, give it authority over the final retail price charged to the buyer. Migrating away later is a commercial and data problem, not just an integration swap: the card tokens live in the MoR's acquiring setup and are generally not portable, so leaving means pushing your subscriber base through a re-checkout and losing a slice of it on the way. Investors rarely care at seed, but in late-stage or acquisition diligence this surfaces as a quality-of-revenue question: who is your customer's contractual counterparty, and what does it cost to take the relationship back? The fair counterweight is that an MoR also removes a diligence red flag, because unregistered VAT liabilities across many jurisdictions are a classic M&A escrow fight, and "the MoR handled that" is a clean answer.

4. How to Choose: Decision Framework

flowchart TD
    Q1{"Where are your customers?"}
    Q1 -->|"Single Country / US-only"| Q2{"B2B or B2C SaaS?"}
    Q1 -->|"Global / Multi-Region"| Q3{"B2B or B2C SaaS?"}
    Q2 -->|"B2B"| A1["PSP + Tax Tool"]
    Q2 -->|"B2C"| A2["PSP or MoR"]
    Q3 -->|"Mostly B2C"| A3["Pure MoR"]
    Q3 -->|"Enterprise B2B"| A4["Hybrid / PSP + Reverse Charge"]
      

Choose an MoR if:

1. You sell B2C software or self-serve B2B globally: Managing micro-registrations for VAT/GST in 30+ countries manually will destroy engineering and accounting velocity.
2. You have a lean engineering/finance team: You prefer paying a higher percentage to avoid hiring external tax advisors or building dedicated billing infrastructure.
3. Speed to market matters: You need to start taking cross-border subscription payments instantly.

Choose a PSP if:

1. You are purely domestic or operate in a single currency union (e.g., US-only or localized EU).
2. Your customer base is overwhelmingly B2B with valid tax IDs: A predominantly B2B base materially reduces indirect-tax collection complexity where valid VAT IDs and reverse-charge rules apply. It does not eliminate global tax compliance: you still deal with customer location evidence, VAT ID validation, invoicing requirements, domestic B2B sales, US sales tax, and GST regimes in Canada, Australia and elsewhere. The EU rules are also moving, with ViDA (VAT in the Digital Age) changes phasing in from 2027.
3. You process high volume ($10M+ ARR): The gap between a ~3% PSP cost and a ~5% MoR fee represents substantial capital that easily funds dedicated in-house tax ops and tool integrations.

5. The European Case: Running a PSP Setup from an EU Entity

If you go the PSP route from an EU company (my case), the compliance work you take on is concrete and well-defined. Here is what it looks like in practice.

flowchart TD
    S["Sale"] --> W{"Where is the buyer?"}
    W -->|"EU"| B{"Valid VAT ID?"}
    W -->|"US"| US["No VAT
Assess state sales-tax nexus"]
    W -->|"Non-EU"| ROW["Determine local indirect-tax rules
(GST/VAT thresholds vary)"]
    B -->|"Yes (VIES validated)"| RC["No VAT charged by you
Invoice states reverse charge applies"]
    B -->|"No (consumer)"| T{"Cross-border EU B2C
over EUR 10,000/year?"}
    T -->|"No"| SK["Charge your home country VAT rate
File domestically as usual"]
    T -->|"Yes"| OSS["Charge buyer's local VAT rate
File one quarterly Union OSS return"]
      

How it works under EU tax law:

• EU B2B sales: You collect the buyer's VAT ID at checkout and validate it instantly via VIES (VAT Information Exchange System). If it is valid, you charge no VAT and the invoice states that the reverse-charge mechanism applies; the customer accounts for VAT in its own jurisdiction. Worth being precise here: this is not a "0% VAT" or zero-rated supply, it is a shift of who accounts for the tax.
• EU B2C sales: There is a EUR 10,000 annual threshold covering cross-border intra-EU B2C supplies of telecommunications, broadcasting and electronically supplied services together with intra-EU distance sales of goods. Below it, home-country VAT rules can continue to apply. Above it, destination-country VAT generally applies, and Union OSS (One Stop Shop) is the simplification that lets you register once with your home tax authority, charge local rates (e.g., 19% Germany, 21% Spain) and file one consolidated quarterly return instead of registering in every member state. Note this is a threshold on qualifying cross-border sales, not on all your EU revenue.
• US sales: The US has no VAT, so there is nothing to charge, but you must monitor each state's economic nexus rules. Thresholds are state-specific and change; many sit around $100,000 in sales into that state, some also count transactions. Tools like Stripe Tax track this for you.
• Rest of world: Do not assume "non-EU means no indirect tax." Australia, New Zealand, Canada, the UK, Norway, Switzerland, Japan, Singapore and many others have VAT or GST regimes with their own registration thresholds for foreign digital sellers. Each market you sell into meaningfully needs its own determination.

The part that changes the math: your EEA (European Economic Area) rate does not apply to US cards. On an EU Stripe account a non-EEA card is currently 3.15% + €0.25, with a further 2% where currency conversion is required. Charge in dollars and settle in euros and you are at roughly 5.15% - and note what that number is: pure payment processing, before you have paid for a tax engine, nexus tracking, fraud tooling or dispute handling. Paddle's 5% + 50¢ is its all-in price including all of those. When raw processing alone reaches the MoR's total fee, the PSP margin advantage on that revenue is not thinner, it is gone. So the advantage is real on EEA cards and absent on converted US card volume, which happens to be the same revenue that carries the nexus tracking burden. If you sell mostly into the US from an EU entity, run this calculation with your own card mix before assuming PSP is the cheaper architecture.

Best for: Pure B2B SaaS, where reverse charge already does most of the work, and SaaS whose revenue is concentrated in EEA cards, where the retained margin comfortably covers compliance software and an accountant who knows cross-border VAT. Past roughly $1M ARR that trade is usually worth making; building genuine in-house tax operations rather than buying tools and an advisor is a later problem, closer to the $10M mark in the framework above.

6. It Does Not Have to Be One or the Other

The PSP vs. MoR framing assumes you pick one and live with its tradeoffs everywhere. That assumption is starting to break.

Portable billing layers like Clink, and modern payment routing setups more generally, let a SaaS product run both at once: direct PSP connections for the high-volume home market where you already have the tax registrations and want the margin, with international long-tail sales routed automatically through an MoR that absorbs the compliance work.

The strongest evidence that this is where things are heading is that Stripe now sells the MoR model itself. Managed Payments is Stripe's merchant-of-record product, and it operates at the transaction level: you can apply it to specific markets or products while the rest of your traffic stays on your normal Stripe setup. The either/or is dissolving from inside the incumbent PSP.

On price, do not mistake it for an undercut: the Managed Payments fee is 3.5% on top of standard Stripe processing fees, which on an EEA card lands around 5% + €0.25 - roughly Paddle's all-in rate. What Stripe is selling is not a cheaper MoR but a composable one: MoR economics only on the transactions you choose, native to an integration you already run.

So the useful question is not "which provider is cheapest?" but "what is my total cost of commerce per segment of revenue?" For a PSP that means processing fees plus billing infrastructure, tax engine, registrations, filings, fraud tooling, disputes, reconciliation, FX and the engineering time to hold it together. For an MoR it means the headline fee plus whatever accounting and operational overhead remains, plus the strategic cost of the MoR sitting between you and your customer. Those two totals do not resolve the same way for every slice of your revenue, and section 5's card math is a concrete example of why.