Choosing a payment provider - a practical case study
How I chose a payment provider for Wiretap
Wiretap is a lead intelligence tool. Customers tell it which competitors to watch and who their ideal customer is, and it emails them a fresh list of leads every morning. Somewhere between building the product and getting ready to charge for it, I had to pick how customers would actually pay.
My starting assumption was Stripe. It’s the default for a reason: the best developer experience in the category, the lowest headline fees, the biggest ecosystem, and every tutorial online assumes you’re using it. I didn’t have a specific complaint about Stripe. I just wanted to check whether the default was correct before building on top of it, so I looked at the alternatives properly instead of confirming what I already believed.
That check changed the decision. Here’s how.
Why this was worth a proper look
Most tooling choices are cheap to reverse. If I pick the wrong email provider, I switch it in an afternoon. Payments aren’t like that. Once you have paying customers, the payment system is touching money, taxes, invoices, and every card on file. Migrating it later is a real project, not a config change.
That asymmetry is the argument for spending real time on this decision once, up front, rather than defaulting and hoping. So instead of validating Stripe, I did a proper survey of the category.
Mapping the category
Six tools came up during the research, and they split into three groups that solve genuinely different problems.
| Group | What they do | Examples |
|---|---|---|
| Payment infrastructure | You are the legal seller; they move the money | Stripe |
| Merchant of Record (MoR) | They are the legal seller; you are their supplier | Paddle, Lemon Squeezy, FastSpring, 2Checkout/Verifone |
| Subscription management layer | Sits on top of a processor, adds billing logic | RevenueCat, Chargebee |
Two of the six dropped out immediately, and for reasons worth naming, because they’re the kind of “alternative” that looks relevant from a distance and isn’t up close:
- RevenueCat is built for mobile in-app purchases (App Store, Play Store). Wiretap is a web product. This wasn’t a contest RevenueCat was ever entered in.
- Chargebee solves billing complexity: proration, entitlements, usage tiers, enterprise contracts. Wiretap has one plan at one price. Chargebee would have been overhead with nothing to show for it.
That left the MoR group to sort through. FastSpring and 2Checkout are legitimate, older platforms, but weaker on developer experience than Paddle. Lemon Squeezy was the closest call: same MoR model, arguably nicer developer experience for a solo builder. It was ruled out for a different reason: Stripe acquired Lemon Squeezy, which leaves its long-term roadmap uncertain, and a billing provider is something Wiretap needs to still be relying on in three years.
So the real comparison came down to two options: Stripe vs. Paddle.
A false alarm: does Stripe Atlas lock me into Stripe?
Wiretap is incorporated as a US Delaware C-Corp through Stripe Atlas, chosen for cap table management and US entity credibility. That raised an obvious question: if the company itself was set up through Stripe, does that lock the payment processor to Stripe too?
No. Atlas is an incorporation service. It creates an ordinary Delaware C-Corp that’s free to use any payment processor. Atlas and Stripe’s payments product share a brand and nothing else. Worth stating plainly, because it’s a natural thing to assume and it isn’t true.
The detail that decided it
Here’s the fact that actually flipped the decision, and it didn’t start out looking like a payments question at all.
Wiretap’s customers are mostly US-based, and the product is B2B in mindset: it’s a sales tool for sales teams. But it’s priced at $49 a month specifically so an individual account executive or BDR can expense it, or just pay for it personally, without waiting on procurement approval.
That was a pricing decision. It turned out to also be a tax decision.
Here’s the mechanism. When a business buys a digital service in the EU, the reverse-charge rule applies: the buyer supplies a VAT number, self-accounts for the VAT, and the seller collects nothing. Simple. When an individual buys the same service, there’s no reverse charge. The seller has to collect VAT at the buyer’s local rate and remit it to that country. The UK, Australia, and Singapore have equivalent rules of their own.
The problem: at checkout, there’s no reliable way to tell which situation is happening. The same person, at the same company, in the same role, buying the same $49 subscription, is a B2B transaction if they put it on the company card and a B2C transaction if they put it on their personal Visa. Nothing about the product or the signup flow tells you which one occurred.
Which means the seller can’t just assume reverse charge applies. Left unmanaged, that’s a potential obligation to register for, collect, and remit consumer VAT in every country where a customer happens to live.
This is where Stripe and Paddle actually diverge:
- Stripe is not a Merchant of Record. Stripe Tax will calculate the correct rate at checkout, but Wiretap remains the legal seller. That means registering in each jurisdiction once it crosses an economic nexus threshold, filing returns there, and remitting the tax. Ongoing, recurring, professional-advice-shaped work.
- Paddle is the Merchant of Record. Paddle is the legal seller on every transaction. If the buyer supplies a VAT number, Paddle applies reverse charge. If not, Paddle collects the local VAT and remits it. Either way, there’s nothing left for Wiretap to do. Paddle pays Wiretap out as a supplier, after tax.
A pricing decision made months earlier, aimed at making the product easy to expense, had quietly created a tax exposure. The payment provider turned out to be the cheapest place to absorb it.
What the difference actually costs
Paddle is more expensive than Stripe, and that needs to be said plainly rather than glossed over. Rates checked against current published pricing:
| Stripe | Paddle | |
|---|---|---|
| Headline rate | 2.9% + $0.30 | 5% + $0.50 |
| Cost on a $49/month subscription | ~$1.72 | ~$2.95 |
| Difference | ~$1.23/customer/month |
At 100 customers, that’s roughly $150 a month. Against the cost of a tax accountant handling multi-jurisdiction VAT and sales tax filings, or the cost of getting it wrong, that’s cheap. At 10,000 customers, the same delta is around $15,000 a month, and at that volume the calculation genuinely flips: a dedicated finance function plus Stripe becomes the cheaper path, and switching becomes the right call. That’s a scale problem worth having, not a reason to plan for it now. Optimising the payment stack for 10,000 customers while building the first 100 is optimising for the wrong decade.
Checking the choice once more
Before committing, one more deliberate step: having landed on Paddle, I went back and re-examined the MoR field specifically, to check whether Paddle was the best option in that category or just the most familiar name.
Paddle held up on developer experience, documentation quality, breadth of tax coverage, and the durability and independence of the company. It also held up on being on its current-generation API (Paddle Billing) rather than the legacy one (Paddle Classic). This is the step that’s easy to skip once a decision already feels settled, and skipping it is how “I picked the best option” quietly becomes “I picked the first option that looked good enough.”