Selling software without Stripe access

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

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

1. Country eligibility for sellers like you (individual vs company) — read the unsupported/excluded list, not the homepage.
2. Payout corridor to a bank you actually have, and its fee.
3. Total cost per realistic sale, including surcharges — not the headline percentage.
4. Platform-stability risk: is the company mid-pivot, and what happens to stores like yours?
5. 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.