Guide
Selling software without Stripe access
Written by someone with the problem: Stripe doesn't offer seller accounts everywhere, and if that includes your country, half the SaaS advice online dead-ends at "just add Stripe Checkout." Here's the path that works — merchant of record — with real numbers and the fine print vendors don't put in the hero section.
Fee figures below were verified against vendor pricing pages on 2026-08-25 with sources archived; re-check them the week you make any decision. Vendors change pricing without notice.
Why Stripe is unavailable where you are
Stripe supports businesses registered in a specific list of countries. Founders elsewhere typically discover this at payout setup, not signup — the form happily takes your email, then stops at the country dropdown. Nothing about your product changes; only your legal address is the problem. The fix isn't a workaround, it's a different legal structure: let someone else be the seller.
The merchant-of-record model, minus the marketing
A merchant of record (MoR) becomes the legal seller of your product. The customer buys from the MoR; the MoR handles card charges, sales tax/VAT collection and remittance, refunds, and some fraud loss; then it pays you your share. You trade roughly 5–10% of revenue plus payout costs for not touching raw card data, not registering for foreign sales tax, and — the point — selling at all without local Stripe access.
What the marketing glosses over: you still own your customer's entitlement. The MoR knows someone paid; it has no idea what that entitles them to inside your app. That part never leaves your database, and it's where most of the real engineering lives (more below).
The four MoR-style options compared
| Rail | Platform fee | Fine print | Payout leg | Watch out for |
|---|---|---|---|---|
| Lemon Squeezy | 5% + $0.50 | +1.5% international cards · +1.5% PayPal · +0.5% subscriptions | Bank payouts listed for a long list of non-US countries in their official docs | Mid-pivot to Stripe Managed Payments (invite-only); confirm a fresh store approval before building anything on it |
| Paddle | 5% + $0.50 | None published; optional +0.5% churn-recovery add-on | Accepts individuals worldwide except a short unsupported list; business registration waived for sole traders | Discretionary approval: passing review once is not a guarantee for future products |
| Payhip (free plan) | +5% | PayPal/Stripe still charge their own standard rates on top | Runs through YOUR PayPal/Stripe account — you carry payout mechanics and sales-tax compliance | No published seller-country eligibility list; viability depends on your PayPal receiving setup |
| Gumroad | 10% + $0.50 direct · 30% via Discover | — | Country-dependent; help center login-gated so availability could not be verified | Most expensive per sale and least verifiable payouts — avoided in our stack until proven |
Sources: Lemon Squeezy fees & supported-countries docs; Paddle pricing & country-support pages; Payhip pricing (archived); Gumroad pricing — all captured 2026-08-25, links preserved in our research archive.
What a sale actually nets: a worked example
On a hypothetical $129 one-time license, approximate platform take:
- Lemon Squeezy: $6.95 base (5% + $0.50); a typical international-card surcharge adds ~$1.94; a non-US bank payout adds another 1% (~$1.29). Roughly $10 total, ~7.8%.
- Paddle: $6.95 (5% + $0.50), no published surcharges. Payout legs go through bank/Payoneer-style corridors with their own small percentages — budget another ~1–2%.
- Payhip: $6.45 (5%) plus PayPal's standard processing on top, which varies by account and corridor — model it before trusting the headline 5%.
- Gumroad: $13.40 (10% + $0.50) before any payout costs — double the others for the same job.
These are arithmetic illustrations on verified fees, not quotes; your card mix, payout rail, and currency conversion decide the final number.
Where seat metering actually lives
Whichever rail you pick, it only ever answers "did money arrive?" Your
app owns the rest: what a seat means, when limits bite, what a
downgrade does to an over-limit org, and who may invite whom. None of
that exists in any MoR API. In our SvelteKit starter this boundary is
explicit — a BillingAdapter interface carries checkout and
webhook events into an internal billing service, seat limits are
enforced server-side when an invite is accepted, and swapping rails
touches one wiring file. The pattern matters more than the vendor:
keep every MoR-specific fact behind one interface and your rail choice
stays reversible.
Dunning and cancellation without Stripe primitives
Leaving Stripe means losing its built-in retry schedules and proration. With an MoR you get webhooks: charge failed, subscription updated, refund issued. Translate each into your own entitlement table and idempotently re-derive access from it on every request. Design for three failure modes from day one: webhook arrives twice, webhook never arrives (poll or grace period), and refund abuse (revoke fast, reinstate slower).
Checklist before you pick a rail
- Country eligibility for sellers like you (individual vs company) — read the unsupported/excluded list, not the homepage.
- Payout corridor to a bank you actually have, and its fee.
- Total cost per realistic sale, including surcharges — not the headline percentage.
- Platform-stability risk: is the company mid-pivot, and what happens to stores like yours?
- API fit for seats/licenses: does its data model map onto your entitlement logic, or fight it?
That checklist is implemented, not just described, in our multi-tenant SvelteKit starter — the billing seam is built so today's rail choice stays tomorrow's config change.
Join the waitlist
No spam, no drip sequence. One email when it’s real.