I spent a weekend a while back going through a client's Shopify statement line by line, trying to figure out where their margin was actually going. Product cost, shipping, ad spend, all the usual suspects. But the number that stood out wasn't any of those. It was the platform fees. Between the payment processor cut and the transaction fee Shopify tacks on for using a non-Shopify gateway, they were losing close to 5% of every single sale before a dollar of profit even entered the conversation.
If you've built or maintained an ecommerce store for any length of time, this probably isn't news to you. But it's worth actually sitting with the math, because most of us treat transaction fees as a fixed cost of doing business online, the same way we treat hosting or DNS. They're not. They're a design decision made by the platform, and there are architectures where that cost simply doesn't exist.
This post is aimed at developers and technical founders who want to understand what "no transaction fee" actually means under the hood, why some platforms charge it and others don't, and how to think about building or choosing a store architecture that keeps that money in your pocket instead of a platform's.
Why Transaction Fees Exist in the First Place
Let's start with the honest version of this, because a lot of ecommerce content either oversimplifies it or turns it into a sales pitch.
When you use Shopify Payments, Shopify is acting as your payment processor, and the fee you pay covers real card network costs (interchange, assessment fees) plus their margin. That's normal. Every processor, Stripe, PayPal, Square, charges something in that range.
Stripe's standard US rate is 2.9% plus 30 cents per transaction. PayPal runs closer to 2.99% to 3.49% plus a fixed fee depending on account type. None of that is a Shopify-specific tax. It's the cost of moving money through card networks.
Where it gets interesting is the second fee, the one that shows up if you don't use the platform's own payment processor. If you route payments through Stripe directly instead of Shopify Payments on a Basic plan, Shopify adds an extra fee on top, sometimes pushing your effective rate from around 2.9% to closer to 4.9%. That's not a card network cost. That's a platform charging you for the privilege of not using their in-house processor. It gets waived entirely on Shopify Plus, and shrinks a lot on higher-tier plans, but on the plans most smaller stores are actually running, it's real money.
Multiply either of these across a growing store's order volume, and you start to see why "no transaction fee" isn't just a marketing phrase for the platforms that offer it. It's a structurally different business model.
The Core Architectural Difference
Here's the part that actually matters for how you build things.
Hosted, closed platforms like Shopify make money two ways: subscription revenue and a cut of your payment volume. That second stream only exists because the platform sits directly in your payment flow, either as the processor itself or as a gatekeeper that taxes you for using someone else's.
Self-hosted and open architecture platforms typically don't sit in that position at all. You (or your ops team) configure Stripe, PayPal, Razorpay, or whatever processor makes sense for your market, and the platform has no mechanism to take a cut, because it was never designed to be the toll booth. You pay the processor's rate and nothing more.
This is a genuinely different piece of software architecture, not just a pricing toggle. A platform that's built to be payment-agnostic from day one usually has:
- An abstracted payment gateway layer, often with a plugin or adapter pattern, so any PCI-compliant processor can be wired in
- No central ledger that the platform itself needs visibility into for billing purposes
- Licensing or hosting-based monetization in
- stead of transaction-based monetization
If you're evaluating a platform and want to know whether "no transaction fees" is architecturally real or just a promotional plan tier, look at how payments are wired in. If the platform has to approve or whitelist your payment processor, that's a strong signal there's a toll booth somewhere, even if it's not obvious from the pricing page.
A Quick Look at What This Looks Like in Code
If you're integrating a payment processor directly into a self-hosted store, the flow is usually refreshingly boring, which is a good thing. Here's roughly what a Stripe checkout session creation looks like, stripped down to the essentials:
Nothing here has an ecommerce platform sitting in the middle taking a cut. It's your store's code, talking directly to Stripe's API. Whatever Stripe charges (2.9% plus 30 cents on a standard US card) is the entire cost. On a self-hosted platform, this is roughly the level of integration you're working with, whether it's built into the platform's admin panel or wired up custom.
Compare that to a hosted platform where the checkout flow is a black box you configure through a settings page, and where switching processors might mean losing features, changing your fee structure, or both. Neither approach is wrong. But one gives you visibility into exactly where your money goes, and the other asks you to trust a settings toggle.
Comparing the Options: A Developer's Checklist
Comparing the Options: A Developer's Checklist
If you're choosing a platform to build on, here's what I'd actually check, in roughly the order I'd check it:
- Where does payment routing happen, and who controls it? Is there an abstracted gateway layer, or is the processor baked into the platform's core in a way that only the platform's own processor gets full feature support?
- What's the actual API surface? Self-hosted and headless platforms vary wildly here. Some ship a genuinely well-documented REST or GraphQL API. Others technically have an API but it's an afterthought bolted onto an admin panel built for a browser, not a client. Read the API docs before you commit, not after.
- How is the platform licensed and hosted? Open-source with no license fee, source-available with a commercial license, or fully proprietary but self-hosted? Each has different implications for long-term cost and how much you can legally modify.
- What does multi-tenancy or multi-vendor support look like, if you need it? If you're building a marketplace or a multi-brand setup, this is not something you want to bolt on later. Check whether it's a first-class concept in the data model or something you'd have to fake with tags and workarounds.
- What's the realistic maintenance burden? Self-hosted means someone owns uptime, patching, and scaling. Be honest with yourself about whether that's your team, a hire, or a managed hosting provider you'll pay for. This isn't a reason to avoid self-hosting, but pretending it's free is how migrations go sideways six months in.
Where This Actually Saves Money (With Real Numbers)
Let's run through the numbers instead of hand-waving about savings, because "no transaction fees" only matters if you can see what it's worth at your actual volume.
Take a store doing $50,000 a month in sales. On a standard 2.9% blended processing rate, that's about $1,450 a month gone to card processing no matter what platform you're on, since that's the actual cost of moving money through Visa and Mastercard's rails. That part doesn't change.
What changes is the second layer. If that same store is on a hosted platform's lower tier and routing through a non-native processor, industry benchmarking on real Shopify P&Ls puts the effective blended rate closer to 4% to 4.9% once you account for the platform's own surcharge, BNPL pass-through fees, and currency conversion. That's the difference between $1,450 and roughly $2,000 to $2,450 a month, purely from platform-added fees on top of unavoidable processing costs.
Annualized, that's somewhere in the $6,000 to $12,000 range that a self-hosted, payment-agnostic setup wouldn't be paying at all.
At higher volume the gap widens in absolute terms, even though the percentage difference can shrink if you negotiate a better rate on an enterprise plan. The point isn't that hosted platforms are a ripoff. Their processing rates cover a real service. The point is that the extra layer some of them add for not using their in-house processor is a pure platform tax with no card-network cost behind it, and it's the first thing worth eliminating from your cost stack if you're already comfortable managing your own infrastructure.
Migrating Without Breaking Everything
If you do decide to move off a hosted platform, the failure mode I've seen most often isn't a bad platform choice. It's trying to do the whole migration in one shot over a weekend.
A saner approach looks something like this:
Inventory what you actually depend on first. Not just products and orders. Webhooks, third-party app integrations, custom checkout scripts, SEO redirects, everything that's quietly load-bearing. Write it down before you touch anything.
Stand up the new store as a parallel environment, not a replacement. Get product data, customer records, and order history flowing into the new platform via API or bulk import, and test the full purchase flow end to end before any customer sees it. This is also where you find out whether the new platform's API is as good as the docs claimed.
Handle redirects deliberately. Old product URLs, collection URLs, and blog URLs need 301s to their new equivalents, or you'll bleed search rankings you spent years building. This is unglamorous work and it's also one of the most common things teams skip under deadline pressure.
Cut over on a low-traffic window, and watch error rates closely for the first 48 hours. Payment webhooks are usually where things break first if something's misconfigured, so have logging in place before launch, not after something goes wrong.
Keep the old store's data exportable and accessible for a while after cutover. You will need to look something up from the old system at some point, whether it's a customer dispute or a tax question. Don't delete it out of tidiness.
None of this is specific to any particular platform. It's the same discipline you'd apply to any production migration, and treating an ecommerce replatform as "just" a content change rather than an infrastructure migration is usually where things go wrong.
Data Ownership Is an API Question, Not a Legal One
One more thing worth flagging for a developer audience specifically: a lot of "data ownership" discussion around ecommerce platforms gets framed as a legal or philosophical issue, when really it's an API question.
Can you pull your full order history, including line items and fulfillment status, through an API without hitting rate limits that make bulk export impractical? Can you get customer records out in a format you can actually reuse, or only as a CSV that drops half the fields you'd need to rebuild functionality? Does the platform's webhook system let you mirror data into your own database in near real time, so you're never fully dependent on their API being up?
Self-hosted platforms tend to score better here almost by default, since the database is sitting on infrastructure you control and you can query it directly if the API ever falls short. But it's worth actually testing this on any platform before you build a business on top of it, hosted or self-hosted. Spin up a trial account, hit the API, and try to pull a full data export the way you would if you needed to migrate away in a hurry. If that's painful in the trial, it will be worse once you have three years of production data.
When Self-Hosted Isn't the Right Call
I want to be straight about this instead of pretending self-hosting is universally correct, because it isn't.
If you're a solo founder validating an idea, or a small team without any DevOps capacity, the maintenance overhead of self-hosting will cost you more in time and stress than the transaction fees would cost you in money. Hosted platforms exist because "someone else handles the server" is genuinely valuable, especially early on when your time is better spent talking to customers than patching a Linux box.
The math tends to flip once you're managing real order volume, once you've got at least one person comfortable with servers or a budget for managed hosting, or once you need functionality (multi-vendor, deep API access, custom checkout logic) that a hosted platform's app ecosystem can't cleanly give you. That's usually also around the point where the platform-added fee layer on hosted platforms starts adding up to real annual money instead of rounding error.
Platforms Worth Looking At
If you're exploring this space, a few categories worth knowing:
Open-source, self-hosted: Platforms like WooCommerce (WordPress-based) and Medusa (Node.js, headless-first) let you run the full stack yourself with no licensing cost, though you're fully on the hook for hosting and maintenance.
Headless, API-first commerce engines: Built specifically to be consumed by a custom frontend rather than shipping their own storefront theme system. Good fit if you already have frontend engineering capacity and want full control over the customer-facing experience.
White-label, self-hosted platforms aimed at avoiding per-sale fees specifically: This is a smaller, more specific category, aimed at businesses that want the admin panel and storefront of a hosted platform but the cost structure of self-hosting. Wcart falls into this category, a self-hosted, white-label platform with headless-ready architecture and native multi-vendor support, built around not taking a cut of your sales. Worth a look if you want a more out-of-the-box starting point than a fully custom headless build, without the recurring per-transaction cost of a hosted platform's non-native-processor surcharge.
As with any platform choice, the right fit depends on your team's technical bandwidth, your growth trajectory, and how much of the stack you actually want to own versus rent. There's no universally correct answer here, just a set of trade-offs worth understanding clearly before you commit six months of engineering time to a migration.
Wrapping Up
Transaction fees aren't inherently evil. Payment processing is a real service with real costs, and Stripe, PayPal, and the card networks earn their cut moving money securely at scale. But the extra fee layer some ecommerce platforms add for not using their in-house processor is a different thing entirely: a business model decision, not a technical necessity.
If you're building or evaluating an ecommerce stack and you've got the technical capacity to own more of the infrastructure, it's worth actually running your own numbers the way I ran that client's statement. Pull your last twelve months of processing fees, separate the card-network cost from anything that looks like a platform surcharge, and see what that second number is actually worth to you over a year. For a lot of growing stores, it's a bigger number than the migration effort it would take to stop paying it.
Top comments (0)