I finished implementing our payment integration today. It took two weeks of focused work — and honestly, several months of on-and-off evaluation before that. For something that should be a solved problem in 2026, choosing a payment provider turned out to be one of the most time-consuming decisions of this entire project.
And there's a good reason for that. A payment provider isn't something you swap out casually. In my previous company, I went through two billing migrations — from manual invoicing to a custom solution to Billwerk. And that was just bank transfers and direct debit, not even credit cards. Each migration was a massive undertaking where everything could go wrong, and your entire revenue depends on it going smoothly. Credit card subscriptions make it even harder — you can't just move card details from one provider to another. Once you're locked in, you're locked in.
So getting this right the first time mattered. A lot.
The Early Temptation
When I started building Filently, Stripe was the obvious first instinct. It's the industry standard. Every tool integrates with it — CRM platforms, analytics tools, referral systems, customer support software. For a solo founder trying to move fast, that ecosystem is a genuine multiplier. And there's something else: customers know Stripe. Seeing a familiar checkout experience builds trust. That matters when you're asking people to pay a new, unknown product.
Back then, I was also using Kinde for authentication, which had basic subscription support built in. The idea of auth and billing in one place felt perfect. But Kinde isn't a Merchant of Record — meaning they don't act as the legal seller on your behalf, handling taxes, compliance, and remittance across jurisdictions. You still have to deal with all of that yourself. And Kinde's subscription features had clear limitations on top. I dropped that path fairly quickly.
Then I stumbled across Creem — an EU-based Merchant of Record with low fees. I honestly don't remember exactly how I found them. Probably through some Google search or an AI recommendation while researching MoR options. It sounded promising. I bookmarked it and moved on to more pressing things.
That was the right call. Payment integration is one of those tasks that feels urgent but isn't — not until you're actually ready to charge people. I had bigger problems to solve first: the document processing pipeline, the Google Drive integration, the security audit. Payment could wait.
Round Two: The BetterAuth Factor
Fast forward to February 2026. We'd migrated from Kinde to BetterAuth for authentication a while back. Now I needed to actually implement payments.
My first instinct was pragmatic: check what BetterAuth has plugins for. Plugin available? Great, that provider goes on the shortlist. I didn't dig into plugin details or compare their feature sets — the mere existence of a plugin meant faster integration, and that was enough to filter by. The list included Stripe, Creem, Polar, Dodo Payments, and a couple of others like Automn Billing and Commet — though those last two didn't match what we needed.
So I narrowed my evaluation to providers with BetterAuth plugins, plus Paddle as an outside option. Stripe's plugin, being the most established provider, I assumed would be the most robust. The plugin advantage seemed like a clear differentiator across the board.
The reality was different.
When the Plugin Advantage Disappears
I started with Creem. EU entity, lowest fees of the Merchant of Record options (3.9% + $0.40), and that BetterAuth plugin. On paper, perfect.
The plugin had a compatibility issue with the latest SDK version. Creem's team fixed it within a day — credit to them. But the deeper problem was architectural. I found myself constantly working around the plugin: reading from its internal collections, needing subscription data it didn't expose, bending my domain logic to fit its assumptions. It didn't feel right.
After a few days of friction, I made a decision: own the integration code myself. Write the webhook handlers, the subscription tracking, the checkout flow. It's maybe two to four days of work, but you understand every line. You don't debug someone else's abstraction when something breaks at 2 AM.
Back to Stripe?
The Creem integration friction made me reconsider Stripe. Stripe has a BetterAuth plugin too, and I'd assumed it would be more mature given Stripe's ecosystem. If the plugin worked well, the whole MoR question might become secondary — Stripe's integrations with analytics tools, referral platforms, and basically every SaaS tool out there would more than compensate. And if the plugin didn't work? Well, I was already writing integration code myself, so at least Stripe's ecosystem would still pay off.
But the math hadn't changed.
A typical $29 subscription through Stripe Payments + Billing + Tax comes out to roughly 4.45% + $0.30. That's practically identical to what Merchant of Record providers charge. And Stripe isn't a Merchant of Record — the entire tax compliance burden stays with you.
I evaluated what that actually means for a Swiss company selling internationally: Non-Union OSS registration in the EU, quarterly VAT filings and remittance in every applicable jurisdiction, ongoing monitoring of tax thresholds. I looked at Quaderno as a compliance partner. The numbers were sobering: around €600 for OSS setup, $49/month for the tool, roughly €100/month for a filing service. That's about €150/month in fixed costs before earning a single euro.
For a company that hasn't launched yet, spending €150/month on tax compliance to save maybe $0.40 per transaction doesn't make sense. The ecosystem advantages are real — analytics integrations, referral tools, the brand recognition on checkout — but at our price point and stage, the MoR benefits outweigh them clearly.
The option stays open. If we ever reach the volume where managing our own tax compliance is cheaper than paying MoR fees, Stripe will be there. But that's a problem for future me.
What About Polar?
I should mention Polar, because it came close.
Between Creem and Polar, Polar had the stronger product. Native usage metering with a credits system — exactly what I'd need for document packs and potential overage billing, something Paddle doesn't offer natively. Clean B2B checkout with proper business fields. Decent analytics.
Two things killed it. First, no PayPal support. That limits customer payment options in a way I wasn't comfortable with.
Second, and more importantly: their privacy posture didn't work for a Swiss company handling EU customer data. US-only data hosting. No standalone Data Processing Agreement available. No published subprocessor list. When I asked their support directly about DPA availability, the response was essentially "reach out when you're in production." GDPR requires a DPA before processing begins, not after. That lack of transparency was a dealbreaker.
A Late Contender: Dodo Payments
I'd initially dismissed Dodo Payments as primarily focused on the Indian market. But toward the end of my evaluation, I took another look. Their scope and compliance documentation were actually more solid than I'd expected, and they have a BetterAuth plugin too. In a different constellation — maybe if the Paddle integration hadn't gone so smoothly — Dodo might have been a real contender.
Why Paddle
After the Creem friction, I tried Paddle. No BetterAuth plugin — which had originally been the main argument against it. But since I was writing the integration myself anyway, that no longer mattered.
The integration was smooth. Official Node.js SDK with proper webhook signature verification. A Next.js Starter Kit with a full subscription lifecycle reference. Paddle.js for client-side checkout that keeps users on our site. Good documentation.
What sold me was the combination of maturity and the migration argument. Paddle is the most established Merchant of Record for SaaS — over 6,000 companies, $1.4 billion valuation, 40% year-over-year growth. If I'm going to be locked into a payment provider, I'd rather be locked into the market leader than a smaller player that might pivot, get acquired, or change their terms.
Their compliance documentation sealed it: a proper, downloadable Data Processing Addendum covering EU and UK GDPR, a dedicated GDPR readiness page, a separate Data Sharing Addendum. For a Swiss company, this isn't nice-to-have. It's table stakes.
They also include ProfitWell analytics — MRR, ARR, churn, retention cohorts, benchmarking against 30,000+ companies. With any other provider, that's an additional tool and an additional cost.
The trade-off is price. At 5% + $0.50, Paddle is the most expensive option per transaction. On a $29 subscription, that's about $1.95 — roughly $0.40 more than Creem would have been. But zero compliance overhead, included analytics, and multi-currency support make that math work at our stage.
What I Learned
Looking back, two things stand out.
First: the migration risk drove this decision more than anything else. It's easy to get caught up comparing transaction fees and feature lists. But the real question is: can I live with this choice for years? Payment provider migrations are painful, expensive, and risky. Choosing a mature, stable provider — even at a higher price — is the safer bet when you can't easily switch later. That's why Stripe was so tempting (nobody gets fired for choosing Stripe) and why Paddle ultimately won (the most established MoR, unlikely to disappear).
Second: plugins are attractive because they promise to save time. And sometimes they do. But for anything that touches your core business logic — and payment is about as core as it gets — the abstraction can cost you more than it saves. You trade a few days of integration work for an ongoing dependency on someone else's assumptions about how your business should work. The BetterAuth auth plugins I use are great. But there's a difference between a plugin that handles a well-defined, standardized flow (OAuth) and one that tries to model your subscription logic. The latter needs to match your domain, and it rarely does perfectly.
Where Things Stand
The implementation is done. I'm waiting for Paddle to review and approve our account, which is the last step before we can actually process payments. Once that's through, we're ready for launch.
Two weeks of work. Four providers evaluated seriously. One decision I'm confident about — because this time, getting it right mattered more than getting it done fast.
On to the next thing.
I'm building Filently — an AI-powered tool that automatically organizes your documents into Google Drive. If you're curious about the journey or want to try it when we launch, you can follow along on Medium or check out filently.com.
Top comments (0)