Hey — I saw your message this morning, the screenshot of someone asking "how do I pay you for this" in your app's support inbox. Congratulations, genuinely. That's the moment a side project stops being a demo. It's also the moment a hundred small decisions you've been able to postpone all show up on the same Tuesday. You asked me to just tell you what to do. I'm going to do that, but I want to walk you through why first, because the "why" is what stops you from having to ask me again in three months when it's Lemon Squeezy instead of Stripe, or subscriptions instead of one-time.
The decision you're actually making
You framed this as "which payment provider should I use," but that's really two decisions stacked on top of each other. First: do you want to be the merchant of record, or do you want someone else to be? Second: what's your billing shape — one-time purchase, subscription, or usage-based? Get the first one wrong and you'll spend a weekend six months from now registering for VAT in a country you've never visited. Get the second one wrong and it's an annoying migration, not a legal one, so it's the less scary of the two.
Being the merchant of record means you are the one selling the thing, legally. You collect the money, you're responsible for figuring out sales tax and VAT in every jurisdiction your customers live in, and you file for it. Stripe will happily calculate that tax for you (Stripe Tax), but calculating isn't remitting — you still have to register and file in each place you cross a threshold. A merchant of record service like Lemon Squeezy or Paddle takes that whole problem off your desk: they're legally the seller, they collect and remit tax everywhere, and they pay you the net. You give up a slice of margin for it.
| Option | Who's the seller | Typical take rate | Tax handling | Best for |
|---|---|---|---|---|
| Stripe (direct) | You | ~2.9% + $0.30/txn, +0.5% for Stripe Tax | You register and file, Stripe just calculates | You expect to scale past a few thousand a month and want lower fees long-term |
| Lemon Squeezy | Lemon Squeezy | ~5% + $0.50/txn | Fully handled, they're the seller of record | Solo builder, first product, don't want to think about tax at all |
| Paddle | Paddle | ~5% + fees vary by region | Fully handled, more enterprise-leaning | SaaS with subscriptions and some invoicing needs |
| PayPal | You | ~3.5-4.5%, buyer-friendly disputes | You handle it | Customers who trust PayPal specifically, not a default choice |
For where you are right now — one customer, a simple product, no idea yet whether this becomes a business — I'd point you at Lemon Squeezy or Paddle over raw Stripe. The extra two points of fee is cheap insurance against becoming an accidental tax filer in a state you've never set foot in. You can migrate to Stripe direct later, once the volume justifies the switch and you've got the stomach for the paperwork. Nobody migrates payment providers for fun, but it's a solvable Tuesday, not a solvable year.
I made this mistake myself on an earlier project — went straight to Stripe because "everyone uses Stripe," collected a few hundred dollars a month from a handful of European customers, and then got a very polite but very confusing email about VAT MOSS registration eighteen months later. It cost me an accountant's afternoon and forty minutes of pure panic googling "do I owe the Netherlands money." Not catastrophic. Also entirely avoidable.
Before you touch the live keys
Whatever you pick, don't wire it up in production mode first. Every one of these providers has a test/sandbox mode with fake card numbers that trigger specific outcomes — successful charge, declined card, requires 3D Secure, insufficient funds. Run through all of them before you touch a real key. The failure paths are the ones you'll actually hit in week one, and they're much less fun to debug live with a real person's card attached.
In your build chat, be explicit that you want this staged: ask for the integration wired to test mode first, with a clearly visible banner or flag so nobody — including future-you — accidentally charges a real card while testing. Then have a second, deliberate step where you swap in live keys. Two prompts, not one, even though it'd be faster to just say "add payments" and let it guess which mode. The friction is the point.
You also need to decide what happens when a webhook fires and your server is down, or slow, or the event arrives twice. This isn't a hypothetical — it happens in the first week, reliably. The events you actually need to handle, at minimum:
checkout.session.completed(or the equivalent) — grant access, this is the moment the customer becomes a customerinvoice.payment_failed— for subscriptions, decide now whether that's an instant lockout or a grace period, because "instant lockout" is a genuinely bad first impression for a card that just had a temporary hiccupcustomer.subscription.deleted— someone cancelled, revoke access at period end, not immediately, unless your terms say otherwise- A refund event — decide once, in writing to yourself, what your refund policy actually is, before the first refund request forces you to decide it live
Idempotency matters more here than almost anywhere else in your app. If a webhook arrives twice — and it will, providers retry on any non-200 response — you cannot grant access twice or, worse, double-charge internal state. Store the event ID and check you haven't processed it before you act on it.
The pricing question you're avoiding
You mentioned in your message you weren't sure whether to charge $9/month or a one-time $49. I don't think either is wrong, but notice what you're actually avoiding: the conversation with the customer about what the recurring value is. A one-time price is easier to say yes to and easier for you to build (no dunning, no failed-renewal handling, no cancellation flow). A subscription is a bet that you'll keep improving the thing enough that people don't churn — which is a real commitment, not just a checkbox in a pricing page. If you're not sure you'll still be actively working on this in six months, a one-time price is the more honest offer. You can always add a subscription tier later once there's something ongoing to subscribe to.
One more thing, and then I'll let you get back to it: put a real refund and cancellation policy on the page before you take the first dollar, even if it's three sentences. Not because anyone's going to sue you over a $9 charge, but because writing it forces you to actually decide it, and "I'll figure it out when someone asks" is how you end up making a policy decision in the middle of an angry email instead of a calm afternoon.
Go wire up the sandbox first. Text me when you've run a fake declined card through it — that's the version of "it works" that actually matters.
