Stripe doesn't issue merchant accounts in my country. I shipped a paid SaaS anyway.

This is the comment I was hoping for. Payoneer is the part I hadn't thought about — Polar pays out through Stripe Connect, which works here, but nobody has paid me yet, so "works" currently means "the dashboard says it will."

Two things I'd take from yours. The paperwork, not the fee, was the actual blocker, which matches mine exactly and is the part the fee-comparison threads always skip. And "MoR is the standard path, Stripe is the exception" is a better framing than the one I used: I wrote the post as though I were working around something, when in fact most of the world starts here.

Have you had a chargeback go through Paddle yet? That's the case I can't simulate, and the one I'd most like to know the shape of before it happens to me.

Which country, and which one did you land on? I picked Polar over Paddle and Lemon Squeezy mostly on how little ceremony it took to get a working checkout, and I've got no idea yet whether that holds up at any real volume — payouts, refunds, a chargeback. If you've been running yours a while, the part I'd want to know is what went wrong first.

You're right, and my interface doesn't cover it. It has exactly two methods: start a checkout, and open the portal where someone cancels. Refunds, chargebacks and dunning history aren't behind it — they're wherever Polar keeps them. I wrote that abstraction feeling rather pleased with myself about a migration that would be a config change, and it wouldn't be: I'd carry the charge call across and leave the entire billing relationship behind.

The 5472 detail is the part worth pinning for anyone reading this and reaching for Delaware. That's a filing most people meet after they've incorporated, not before.

Since you've actually run entities across six continents — when the day comes that moving is worth it, does anyone migrate the dunning history, or do you accept a hard cut and start the new system empty?

Two methods, and your sentence is almost exactly the shape they ended up: start a checkout, and open the portal where the entitlement actually lives. Everything provider-specific stayed behind its own handler.

The leak found me this week, though not at any of the four places you listed.

The interface exposed "configured: boolean". Both providers answered it honestly. What neither was ever asked, and what the abstraction had no vocabulary for, was whether a checkout would collect money - and production had been pointed at Polar's sandbox for weeks. Every observable step worked: real page, card accepted, redirect, webhook, workspace marked Pro. The health check reported billing healthy, because what it actually asserted was that a product id resolved.

So the third thing on the interface isn't a capability, it's a property: testMode. Which is the opposite of your advice - a wider interface - but the alternative was an abstraction that could not express the difference between working and pretending, in the one subsystem where that difference is the whole point.

Webhook semantics leaked exactly where you said. I kept them out of the interface and claimed the delivery at the door instead, keyed on the Standard Webhooks id for one provider and the event id for the other, duplicates dropped before dispatch. Both handlers happened to survive retries already, because every branch assigned absolute state rather than incrementing - but that was a property of what the branches did, not a guarantee, and one was already writing its audit row twice.

Proration and tax I have dodged rather than solved: one price, one currency, merchant of record handles the tax. That is where I expect it to actually break, and I don't expect it to break gracefully.

Partially, and not the part you're asking about.

What I keep independently is the subscription lifecycle: created, updated, cancelled, past due, revoked. Those arrive by webhook and land in my own events table against my own account id, so "when did this customer's plan change and why" is answerable without Polar.

Refunds and chargebacks are not in that set. I don't subscribe to those events and I don't store them, so today the honest answer is that I'd be reading Polar's records. Which is the same gap someone else put to me earlier in this thread, and it's still open — I conceded it, wrote it down, and have not fixed it.

The thing your question makes clearer is that the fix isn't "store more fields". A refund is a money-reversal event that my own records currently cannot represent at all, because the only money object I have is a payment that went one way. Adding the webhook without a place to put it would just be a log line.

Thanks, but I'll pass on the engagement.

The part of it I'd take for free, and I think you're right about, is being where the recommendation gets made rather than where the product sits. r/freelance and r/smallbusiness are where people describe this problem in their own words, and that's worth more to me right now than another landing page tweak.

I'm doing that by hand and badly, which is roughly the correct amount of effort for someone with zero customers.

Neither, and I think the honest answer is more useful than either would have been.

There are two independent checks, not one mechanism.

When a payment settles an invoice, every queued row for it flips to 'skipped'. That's bookkeeping, and it is not the guarantee. It isn't in a transaction with the payment write, so a crash between the two leaves rows queued, and payment can also arrive from a Stripe sync at any moment, including while a send is already in flight.

The guarantee is the second check: immediately before sending, the sender re-reads the invoice and compares the outstanding balance to zero. If it's settled, the message is marked skipped and nothing goes out, regardless of what the first check did or didn't do.

The rule I ended up with is that the check carrying the promise has to be the last thing before the irreversible action, not the first thing after the triggering event. Anything upstream of the send is an optimisation, because the world can change underneath it.

On Polar's VAT reporting granularity, I don't know, and I'd rather say that than quote their docs at you. Nobody has paid me, so I haven't seen a single remittance report. Your Stripe Tax plus manual filing crossover is a real number and mine is currently a guess.

There is a conversion, and it's a bigger line than I assumed until I sat down and read the whole fee schedule this week.

Polar pays out through Stripe Connect Express, and Korea is a supported country for that — which is the part that makes this work at all, since Korea is not a Stripe merchant country. But the currency handling is not free. Polar's published conversion is 0.25% inside the EU and up to 1% everywhere else, and Korea is everywhere else. On top of that, payouts cost 0.25% + $0.25, plus $2 for any month you take one.

So the honest answer to "preferred currency" is no. I price in USD, the customer pays on a card denominated in whatever theirs is, and there is a conversion in the middle I don't control or see itemised per sale.

If you're in the EU you get the good end of it at 0.25%, which is close enough to noise.

Worth flagging since you're the second person in this thread to ask a fee question: I've just posted a correction further up. I originally quoted the MoR premium as about 2.1 points, having taken the 5% + 50c headline as the whole fee. With the international-card surcharge, the payout fees and this conversion line, it's about 8.8% all-in on a $49 subscription rather than 5%. The conversion you asked about is one of the reasons my first number was wrong.

Good question, and the answer is a hard separation: Polar never touches anything a client sees.

Polar bills me — my subscription, my card, my receipt. The reminders go out through Resend from your own domain, with your name and your reply-to, so your client gets an email from you about your invoice. The pay link points at your own invoice page, or straight at Stripe's hosted page if the invoice was synced from there, because that's where your client's saved card already is.

That separation isn't a design flourish, it's the only version that works. The moment a chasing email arrives from some payments company your client has never heard of, it reads as a collections agency rather than as you following up.

The B2B-only checkbox is the sharpest thing in this thread and I hadn't priced it at all. I sell to freelancers, which sounds B2B and in the EU frequently isn't — a sole trader buying a tool can still be a consumer depending on how you read it. That's a question for my terms rather than my code, and I hadn't asked it.

Receipt-is-not-invoice I got for free by going MoR, which is your point exactly: tax remittance gets the headline and the paperwork is the actual purchase.

The other side of it is worth naming though. An MoR sells you out of those obligations by being the seller, which means the customer's relationship is with them, not you. I traded paperwork for distance from my own buyer, and I'm not sure I'd noticed I was making that trade.

This is the one I have no answer for, mostly because I have no payouts yet. But look where it lands: Nudge exists because matching a bank deposit against an invoice is unglamorous and gets done badly, and I built it without noticing I'd be on the other end of the identical problem with my own revenue.

Gross sales versus what actually hits the bank, net of refunds and fees and tax handling — that's the same shape as the thing my product does for its users. I should be running my own Polar payouts through it, which is a slightly embarrassing thing to realise in someone else's comment.

When you say the payout bridge has to be readable: is that a report the provider hands you, or something you rebuild yourself every month from two exports that don't line up?

Correcting my own number here, because I gave you a confident one and it was wrong.

I said the MoR spread was about 2.1 points plus 20c. I got there by taking 5% + 50c at face value and subtracting Stripe, without ever checking whether 5% + 50c was the whole fee. It isn't. Polar's pricing page has four more lines under it:

• +1.5% on non-US cards
• payouts: 0.25% + $0.25, plus $2 for any month you take one
• currency conversion: 0.25% inside the EU, up to 1% everywhere else — Korea is everywhere else
• $15 per dispute, won or lost

On a $49 subscription paid by a European card that lands at about 8.8%, against Stripe's 3.5%. So the spread is 5.3 points and roughly $2.58 per customer per month — $31 a year, not the $15 I told you. Which moves the crossover you asked about to somewhere around 16-32 paying customers rather than 50-70. Half of what I said, and I'd excluded the fixed $2/month payout fee, so at low customer counts it is worse still.

It doesn't change what I do, because I still can't get a Stripe merchant account. But you asked a numerical question and the number I gave back doesn't survive checking.

One update since you asked about pricing: it's $49/mo, and that is now the only paid plan. I retired the $129 Agency tier this week. Reading my own code, the only two things that actually gated a plan were autopilot and the open-invoice limit — and Agency matched Pro on both. Four of its five bullets described things I had not built. It was $129 for Pro with a different label.

Pricing first, since you guessed and you should have the real number: $49/mo Pro, $129/mo Agency, free tier capped at 5 open invoices. No €150 anchor anywhere — though €150 is not far off what one 45-day-late invoice costs in chasing time, which is the number the pricing is actually arguing with.

On the crossover, using your fee figures: the MoR spread is about 2.1 points plus 20c a transaction, so at $49/mo it's roughly $1.25 per customer per month, call it $15 a year. A US LLC runs $500-1,000/yr in registered agent, franchise tax and filings before an accountant touches the 5472. That puts the crossover somewhere around 50-70 paying customers — and it ignores that the entity hands the tax work in every country I sell into back to me, which is the thing I'm actually paying the spread to avoid.

So: not painful yet, and the point where it becomes painful is a point I'd be delighted to reach.

No. Not one, and I'm not going to dress that up.

Two accounts have signed up and both are mine. Every reminder that has gone out went out inside a sample workspace, where sending is simulated on purpose so a demo can never email a real stranger. So everything in that post is a claim about what the software does, not about money it has collected.

You've picked exactly the right test. Cancellation-on-payment is trivial to verify in a unit test and worth nothing until it survives a real invoice paid by bank transfer on a Saturday while Monday's reminder is already queued. That's the case I want and it's the one case I can't manufacture.

Which makes the honest ask here not "try my product" but this: if you have an invoice that's genuinely late right now, I'll set the sequence up myself and you can veto every message before it sends.