- Most merchant of record platforms handle global tax and card payments fine. Developer tools need more: GitHub-native purchasing flows, sponsorship and donation models, seat-based and usage-based billing, and checkouts that do not break a developer’s trust with enterprise-grade friction.
- Polar.sh and Lemon Squeezy are purpose-built for the developer audience. Paddle and FastSpring serve B2B devtools with more contract flexibility. Stripe alone is not a merchant of record and leaves tax compliance entirely to you.
- Open-source maintainers, self-serve indie devtool founders, and B2B devtool companies have almost nothing in common in payment infrastructure requirements. Pick by buyer type first, then by billing model.
- The FintechSpecs DevTool Buyer Stack (introduced below) is a three-segment framework for matching your platform to your actual revenue motion, not a generic SaaS checklist.
- Total cost of ownership matters more than headline take rates. A 5% fee on $30K ARR stings differently than a negotiated 2.9% on $2M ARR with enterprise contract support.
The best merchant of record for developer tools depends on which developer you are selling to. For open-source maintainers taking sponsorships and one-time purchases, Polar.sh and GitHub Sponsors handle the workflow better than any general SaaS MoR. For self-serve devtool founders selling subscriptions globally, Lemon Squeezy and Paddle cover tax compliance and chargebacks without requiring a tax attorney. For B2B devtools with seat-based contracts and enterprise procurement, Paddle, FastSpring, and Stripe Billing with a tax layer come closest to the required feature set.
Why General MoR Platforms Underserve Developer Tools
Developer tools have a buying motion that no other software category shares. The buyer is often also the evaluator, the implementer, and the budget holder, sometimes all three at once. They discovered your tool on GitHub or Hacker News, tried the free tier in a terminal window, and now want to pay without leaving their workflow to fill out a procurement form.
General MoR platforms are built around the assumption that the seller has a marketing-to-sales funnel and a buyer who expects a checkout page. Developer tools break that assumption constantly. A CLI tool might collect payment through a one-line npm install prompt. An open-source library might monetize through GitHub Sponsors plus a paid tier on a separate domain. A devtool SaaS might bill per API call, per seat, or per workspace, sometimes all three depending on the plan.
Tax compliance, chargeback liability, and fraud handling are still table stakes. But the platforms that win in developer tools add GitHub integration, webhook-native purchase events, sponsorship and donation flows, and checkouts that a developer does not feel embarrassed to show their users. That narrows the field considerably. For a deeper look at how merchant of record differs from a standard payment processor, the merchant of record vs payment processor breakdown on FintechSpecs covers the liability distinctions that matter at tax time.
The FintechSpecs DevTool Buyer Stack: Three Segments, Three Different Requirements
Before comparing platforms, it helps to know which segment you are actually in. The wrong MoR choice usually comes from founders applying B2B SaaS logic to a developer-native revenue model, or vice versa.
Segment 1: Open-source maintainers. Revenue is a mix of sponsorships, one-time donations, and optionally a paid tier for hosted or pro features. The buyer is an individual developer or a small team. Payment amounts are often low (under $20/month), volume is modest, and the primary need is low-friction collection with minimal compliance overhead on the seller’s side.
Segment 2: Self-serve devtool founders. You have built a paid CLI, a developer API, a code editor extension, or a SaaS tool aimed at individual developers or small teams. Revenue is subscription-based, often monthly, and your global customer base makes VAT and sales tax non-trivial. Checkout conversion and chargeback protection matter. You want to ship features, not maintain tax tables.
Segment 3: B2B devtool companies. You sell to engineering teams at companies. Deals involve procurement approval, invoicing, net payment terms, seat or usage-based contracts, and occasionally legal review. This is where a standard consumer-grade MoR breaks down and you need enterprise contract support, quote-to-cash workflows, and audit-ready reporting.
Most of the platforms below fit one or two of these segments well. None fits all three equally. Pick your segment first.
Which Platforms Are Worth Evaluating?
| Platform | Best Segment | MoR Status | Billing Models | Headline Fee |
|---|---|---|---|---|
| Polar.sh | OSS maintainers, self-serve devtools | Yes | Subscriptions, one-time, sponsorships | 5% + payment processing |
| Lemon Squeezy | Self-serve devtools | Yes | Subscriptions, one-time, license keys | 5% + 50¢ per transaction |
| Paddle | Self-serve and B2B devtools | Yes | Subscriptions, usage, seats, enterprise | 5% + 50¢ (self-serve); custom enterprise |
| FastSpring | B2B devtools, legacy software | Yes | Subscriptions, one-time, bundles, seats | Custom (not publicly disclosed) |
| GitHub Sponsors | OSS maintainers | Partial (GitHub acts as intermediary) | Monthly sponsorships, one-time | 0% platform fee (Stripe processing applies) |
| Stripe Billing | B2B devtools (with tax add-ons) | No (you remain the merchant) | Subscriptions, usage-based, metered | 0.5% to 0.8% billing + 2.9% + 30¢ processing |
| Freemius | Self-serve WordPress/plugin devtools | Yes | Subscriptions, one-time, freemium | Custom (disclosed during onboarding) |
| Verifone (2Checkout) | B2B devtools, global software | Yes (2Sell/2Subscribe plans) | Subscriptions, one-time, global currencies | Custom (not publicly disclosed) |
| Gumroad | OSS maintainers, indie devtools | Yes | One-time, pay-what-you-want, subscriptions | 10% flat (as of their public pricing page) |
Polar.sh: Is It the Right MoR for Open-Source Monetization?
Polar is the only platform on this list built specifically around the open-source developer workflow. It connects directly to GitHub repositories, letting maintainers accept sponsorships, sell subscription tiers, and offer one-time purchases without leaving the GitHub context their users already trust. That GitHub-native integration is the product’s central design decision, not a feature tacked on later.
As a full merchant of record, Polar handles VAT and sales tax collection globally, so a solo maintainer in Germany selling to buyers in California does not need to register for US sales tax separately. The platform supports subscriptions and one-time purchases, and it allows benefit delivery automation, meaning a paid subscriber can automatically receive a license key, a private repository invite, or a Discord role without any manual work from the maintainer.
The 5% fee plus payment processing is competitive for the segment. Where Polar is weaker: it is not built for B2B contracts, does not support net payment terms, and its enterprise seat management is limited compared to Paddle. If your open-source project is generating meaningful commercial revenue from mid-market engineering teams, you will eventually hit Polar’s ceiling. At that point, the Stripe vs Paddle vs Lemon Squeezy vs Polar comparison covers the transition decision in detail.
Lemon Squeezy vs Polar: Which Should Indie Devtool Founders Choose?
Lemon Squeezy and Polar serve overlapping audiences but with different strengths. Lemon Squeezy is more polished for self-serve SaaS founders who want a complete storefront: subscription management, customer portals, license key generation, and discount codes, all without touching tax code. Its checkout is visually clean and converts well with non-developer buyers, which matters if your devtool has a mixed technical/non-technical audience.
Polar wins for any founder whose primary distribution channel is GitHub. If your product page is a README and your buyers find you through repository searches or Hacker News, Polar’s GitHub-native checkout and sponsorship model fits the buying motion more naturally than Lemon Squeezy’s storefront approach. Lemon Squeezy’s fee structure is 5% plus 50 cents per transaction, per their public pricing page, which is in line with Polar and slightly more expensive than Paddle at scale.
One practical difference: Lemon Squeezy has stronger affiliate and referral program tooling, useful if you want to run a partner or influencer channel within the developer community. Polar does not have a comparable affiliate system as of its current feature set. Choose Lemon Squeezy if your go-to-market involves any kind of partner distribution. Choose Polar if your audience is already on GitHub and you want zero-friction sponsorship plus paid tiers in one place.
Why Use Polar.sh Instead of Stripe for Developer Tools?
Stripe is not a merchant of record. That single fact changes the entire compliance picture. When you collect payments through Stripe directly, you are the merchant of record, which means you are responsible for calculating and remitting sales tax in every US state that has economic nexus rules, plus VAT in the EU, GST in Australia, and a growing list of other digital services taxes globally. A devtool doing $200K ARR across 40 countries faces a real compliance burden that Stripe Billing alone does not solve.
Polar, Lemon Squeezy, and Paddle take on that liability. They collect tax from the buyer, remit it to the relevant authorities, and issue compliant invoices. You receive net revenue. That shift is not just convenient, it removes a category of legal risk that has tripped up numerous small software businesses that grew faster than their compliance setup.
Stripe does offer Stripe Tax as an add-on, and it calculates and collects the right amounts automatically in many jurisdictions. But Stripe Tax still leaves remittance to you. You still need to file returns. An MoR handles the entire chain. For teams without a dedicated finance person, that difference is material. The tax compliance tools for SaaS companies using Stripe article covers the gap-filling options if you want to stay on Stripe and add compliance coverage rather than switching platforms.
Paddle: When Does It Make Sense for B2B Developer Tools?
Paddle holds a stronger position than Lemon Squeezy or Polar for devtool companies moving upmarket. Its billing infrastructure supports seat-based pricing, usage-based metering, pausing, and manual invoice creation, features that matter when you are selling to a 50-person engineering team with a procurement process. Paddle also has quote-to-cash support for larger deals, which puts it in a different category from the self-serve-only platforms.
On the self-serve side, Paddle’s pricing page shows 5% plus 50 cents per transaction for standard plans, matching Lemon Squeezy. At higher volumes, Paddle offers negotiated rates, which matters when you are crossing $500K ARR and the percentage fee becomes a real line item. FastSpring similarly offers custom pricing but tends to target more established software companies and has less modern API tooling compared to Paddle.
Paddle’s developer experience has improved significantly since its 2023 overhaul (now called Paddle Billing), with a cleaner REST API and better webhook event coverage. It still trails Stripe in raw API flexibility, but it covers the MoR compliance layer Stripe does not. For a B2B devtool that needs both clean API integration and full tax handling, Paddle is the most mature option in the middle of the market. Teams scaling past $5M ARR in developer tools should also review the fintech SaaS scale checklist to identify the billing infrastructure gaps that emerge at that stage.
FastSpring: Does It Still Make Sense for Developer Tools?
FastSpring has been around since 2005 and serves a more established software vendor profile than Polar or Lemon Squeezy. Its MoR coverage is genuinely global, it supports a wide range of currencies and local payment methods, and it has mature tooling for software license management and upgrade flows. For a desktop developer tool or a legacy B2B software product with an existing customer base, FastSpring is a credible option.
The weakness is developer experience. FastSpring’s API and documentation feel dated compared to Stripe or Paddle. Its checkout customization is limited, and its onboarding process takes longer than any of the self-serve platforms. FastSpring does not publish pricing publicly; the company does not disclose fees on its website, and you will go through a sales conversation to get numbers. That alone filters out most indie devtool founders who want to evaluate costs before a sales call.
FastSpring makes the most sense for devtool companies with $1M or more in annual revenue, existing enterprise relationships, and a need for strong customer support during payment disputes and compliance questions. It is not where you start. It is where you land if you outgrow Paddle and need a more managed relationship.
GitHub Sponsors: What It Actually Covers and Where It Stops
GitHub Sponsors is not a full merchant of record in the traditional sense. GitHub (owned by Microsoft) acts as the intermediary platform, but tax handling varies by country and the program is designed around voluntary sponsorship rather than commercial software sales. For open-source maintainers whose revenue is genuinely donation-like, GitHub Sponsors is the highest-trust channel because it lives where your users already are.
The 0% platform fee (GitHub waives its fee, though Stripe processing costs still apply) is genuinely attractive for low-volume maintainers. The limitation is that GitHub Sponsors is not a substitute for a commercial billing system. You cannot issue proper invoices for enterprise sponsors, you cannot gate software features behind a sponsor tier automatically, and you cannot handle the tax obligations of a company paying a commercial software license through the Sponsors mechanism.
The practical model for serious open-source monetization is GitHub Sponsors for community support, combined with Polar or Lemon Squeezy for any paid product tier. Using both in parallel is common and not redundant, they serve different buyer intents.
Freemius: The Right Choice for Plugin and Extension Developers
Freemius occupies a specific niche: WordPress plugins, IDE extensions, and other developer add-ons where the distribution channel is a marketplace (WordPress.org, JetBrains Marketplace, VS Code Marketplace) and the monetization happens separately. Freemius handles MoR compliance, subscription billing, license key delivery, and freemium-to-paid conversion flows that are specifically designed for the plugin upgrade path.
If you are building a WordPress plugin with a free version on WordPress.org and a paid version on your own site, Freemius is purpose-built for that exact workflow in a way that Lemon Squeezy or Paddle is not. Freemius does not publicly disclose its fee structure on its website; pricing is shared during the onboarding process. That limits comparison shopping, but the platform’s specificity to the plugin segment makes it hard to replicate elsewhere.
For VS Code or JetBrains extension developers, Freemius is less dominant. The JetBrains Marketplace handles its own payment processing and acts as the merchant of record for extensions sold there, so a third-party MoR is redundant for that distribution channel.
Gumroad: Still Relevant for Indie Devtool Monetization?
Gumroad’s 10% flat fee (as of their public pricing page) is the highest on this list, and that fact alone prices it out for any devtool with meaningful revenue. At $10K in monthly sales, Gumroad costs $1,000/month in platform fees before payment processing. Lemon Squeezy at the same volume costs $500 plus 50 cents per transaction.
Where Gumroad still makes sense is for very early monetization experiments: a $29 one-time tool, a PDF guide bundled with a CLI utility, a pay-what-you-want open-source companion product. The setup takes minutes, there are no monthly fees, and it works well for digital products with low transaction frequency. Once a devtool is generating more than a few thousand dollars per month, the math tips decisively toward Lemon Squeezy or Polar.
Verifone (2Checkout): Global Reach at the Cost of Complexity
Verifone, which acquired 2Checkout, is a global MoR with strong coverage in markets where other platforms struggle: Southeast Asia, Latin America, parts of the Middle East. For a devtool with significant revenue from outside North America and Western Europe, Verifone’s local payment method support and currency handling can justify the complexity of its platform.
Verifone does not publish pricing publicly. The platform is better suited to established software vendors than to early-stage devtool founders. Its checkout customization and API documentation do not match Stripe or Paddle, and onboarding takes longer than any self-serve platform. If your developer tool is genuinely global with a large share of revenue from emerging markets, it is worth a conversation with their sales team. For most North American devtool founders, it is not the starting point.
How Should B2B Devtool Companies Handle Seat-Based Billing?
Seat-based billing for B2B developer tools creates a specific problem: the buying unit is a company, not an individual, but individual developers within that company activate and use the product. You need to track active seats, handle mid-cycle additions, and issue invoices that a finance team can approve and code to a cost center. Most self-serve MoR platforms handle this poorly.
Paddle Billing supports seat-based pricing natively, with proration on mid-cycle changes and invoice generation. Stripe Billing combined with a metering layer (such as Lago or Orb) handles usage and seat metering more flexibly, though you remain the merchant of record and need Stripe Tax or a manual compliance layer. For devtools crossing into enterprise territory, the merchant of record platforms for enterprise SaaS with net terms comparison covers the contract and invoicing requirements in detail.
To make the fee math concrete, consider a hypothetical: a B2B devtool processing $80K MRR, with an average contract of $4,000 per year, 240 active company accounts, and buyers spread across 18 countries. Assuming Paddle’s standard 5% rate applies in full, that is $4,000 per month in platform fees, or $48K annually. At a negotiated rate of 2.9% , which Paddle does offer at sufficient volume, though the exact threshold is not publicly disclosed , the annual cost drops to roughly $27,800, a difference that funds a meaningful engineering sprint. These figures are illustrative; actual negotiated rates depend on volume, contract structure, and timing. The point holds: the headline fee matters less than the rate you can actually negotiate once you have the volume to ask.
Frequently Asked Questions
Should indie developers use Polar.sh or Lemon Squeezy?
Use Polar.sh if your product is distributed through GitHub and your buyers are developers who already sponsor open-source projects. Polar’s GitHub-native checkout and sponsorship model creates less friction in that context. Use Lemon Squeezy if you want a more complete storefront with affiliate tools, customer portals, and a checkout that works well for mixed technical and non-technical audiences. Both are full MoRs and handle global tax compliance. The decision is about distribution channel and buyer behavior, not features.
Why choose Polar.sh over Stripe or Paddle for a developer tool?
Stripe is not a merchant of record, so it leaves global tax compliance entirely on you. Paddle is a full MoR but is designed for SaaS companies with a web storefront, not for GitHub-native distribution. Polar handles tax compliance as an MoR while also providing GitHub-native purchasing, sponsorship flows, and benefit automation (private repo access, license keys delivered on payment). For an open-source or indie developer tool distributed primarily through GitHub, Polar removes two layers of work that Stripe and Paddle do not address.
What is the real cost difference between these MoR platforms at $20K MRR?
At $20K MRR, the fee gap between platforms is material. Gumroad at 10% takes $2,000/month in platform fees. Lemon Squeezy at 5% plus 50 cents per transaction takes roughly $1,000 plus transaction fees. Paddle at 5% plus 50 cents is similar. Polar at 5% plus processing is comparable. Stripe with Stripe Tax added keeps a lower blended rate but requires manual tax filing or a compliance service, which has its own cost. The real cost of Stripe for a global devtool at $20K MRR includes the compliance overhead, not just the processing fee.
Can open-source maintainers use a merchant of record for sponsorships?
Yes. Polar.sh is the most direct option: it handles both sponsorships and paid product tiers as a full MoR. GitHub Sponsors is not a traditional MoR and does not handle commercial invoicing or enterprise tax documentation reliably. If a company wants to sponsor your open-source project and needs a proper invoice for their accounts payable team, Polar is better positioned to generate that than GitHub Sponsors. Gumroad can technically handle this but its 10% fee is punishing for recurring sponsorship amounts.
Does Lemon Squeezy handle VAT for EU customers automatically?
Yes. Lemon Squeezy acts as the merchant of record and collects, reports, and remits EU VAT on your behalf. When a customer in Germany purchases through a Lemon Squeezy-powered checkout, the VAT is calculated at the correct German rate, collected from the buyer, and remitted by Lemon Squeezy directly. You receive the net amount. This applies to Polar and Paddle as well. The distinction from Stripe is important: Stripe Tax collects the right amount but you still remit it yourself, which requires either a filing service or in-house compliance work.
What MoR platform is best for a B2B devtool selling to enterprise engineering teams?
Paddle handles the mid-market segment (deals under $50K per year) better than any other MoR with developer-friendly tooling. For larger contracts with legal review, custom terms, and net-30 or net-60 payment terms, FastSpring or a Stripe-based custom billing setup with a dedicated finance layer is more appropriate. At enterprise scale, many devtool companies use Stripe Billing for contract management and add a tax compliance tool like Avalara separately, accepting that they remain the merchant of record in exchange for more billing flexibility.
Is Freemius still the best option for WordPress plugin developers?
For WordPress plugins specifically, Freemius remains the most purpose-built option. Its freemium conversion tooling, license key management, and upgrade flow design are built around the WordPress plugin lifecycle in a way that general MoRs like Lemon Squeezy or Paddle are not. The lack of public pricing is a friction point during evaluation, but for plugin developers already distributing on WordPress.org with a paid version, the workflow integration is worth the discovery cost. For IDE extensions sold outside a proprietary marketplace, the comparison shifts toward Lemon Squeezy or Paddle.
Which Platform Should You Actually Choose?
The FintechSpecs DevTool Buyer Stack points to a clear decision tree. Open-source maintainers should start with Polar for its GitHub-native flow and zero-configuration tax handling, adding GitHub Sponsors alongside it for community visibility. Self-serve devtool founders, especially those selling globally at any meaningful scale, should choose between Polar and Lemon Squeezy based on whether their distribution is GitHub-first or storefront-first. B2B devtools selling to engineering teams at companies should be on Paddle unless they are doing enough volume to justify a custom arrangement with FastSpring or a Stripe-plus-tax-layer setup.
The mistake most founders make is treating payment infrastructure as a commodity decision and picking whatever the last Hacker News thread recommended. Payment infrastructure for developer tools touches checkout conversion, global compliance, billing flexibility, and the trust signal your checkout sends to a skeptical developer buyer. Those are product decisions, not ops decisions. Getting the right payment infrastructure in place early prevents the kind of forced migration that burns engineering time later when you have more to lose.
One thing worth tracking as you scale: none of the MoR platforms above are free to leave. Migrating subscription data, customer records, and payment method tokens from Lemon Squeezy to Paddle, or from Polar to a custom Stripe setup, takes real engineering effort and often causes customer-facing disruption. The best time to choose carefully is before you have thousands of active subscribers. The second best time is now, using the segment framework above rather than defaulting to whatever requires the least setup today.
