Transaction fees rarely appear in the comparison a first-time seller runs. Monthly subscription prices sit side by side, the cheapest wins, and the real cost surfaces months later as a percentage skimmed from every sale. An ecommerce platform charges in more places than its pricing page suggests. Understanding where those places are changes which option looks cheapest.
The choice splits along one line that matters more than features: hosted convenience against self-managed control. Hosted services handle servers, security, and payments in exchange for recurring fees and constrained flexibility. Self-managed software gives you the code and the database while handing you the maintenance. Additionally, a third group sits between them, offering managed infrastructure for open software. Each model suits a different seller, and none of them is best in general.
This article covers five truths that decide the outcome: how fees actually accumulate, what the models really trade away, which platform fits which seller, how migration risk differs, and what to verify before committing. Consequently you should finish with a shortlist of one rather than a comparison of many. The criteria are stated openly so you can reach a different conclusion when your circumstances differ.
A note on method: this article names specific platforms, and the criteria below are applied identically to every one of them. A platform is included because it fits a described situation, not because it is popular.
1. What an Ecommerce Platform Really Costs
Cost arrives through four channels, and only one appears in the headline. The subscription is visible. Transaction fees on each sale are visible if you look. Payment processing charges sit with the gateway rather than the platform. Meanwhile app subscriptions accumulate quietly as you add functionality that the base product omits. For a store at modest volume, the subscription is often the smallest of the four. Therefore comparing subscriptions alone compares the least significant number.
1.1 How Ecommerce Platform Fees Accumulate
Transaction fees deserve the closest attention because they scale with success. A percentage taken from every order costs little at ten sales a month and a great deal at a thousand. Hosted platforms typically waive their own transaction fee when you use their in-house payment processing, and charge one when you do not. Consequently the fee structure quietly steers you toward their gateway. That steering is not necessarily bad, though it becomes expensive when the in-house gateway does not support your market or currency.
Application costs form the second accumulating channel, and they surprise sellers most. Base plans deliberately omit common needs such as advanced shipping rules, subscriptions, multi-currency display, or detailed reporting. Each gap is filled by a paid application, often billed monthly per store. Furthermore, three or four such applications can exceed the platform subscription itself. Before choosing, list the functions your store genuinely requires and check which are included. In fact, that single list changes the ranking more often than any other exercise here.
1.2 Modelling Two Years of Store Costs
A short model settles the cost question better than any published comparison. Estimate your monthly order count and average order value, even roughly. Multiply the order value by the platform’s transaction percentage, then by the order count, to get the monthly fee drag. Add the subscription and your expected application costs. Additionally, add payment processing separately, since that charge follows you across platforms. The resulting figure is your true monthly cost, and it frequently reorders a shortlist entirely.
Run the model twice, at your current volume and at three times that volume. The comparison between those two runs reveals which platform scales in your favour. Hosted services with percentage fees grow more expensive as you succeed, while self-managed software holds costs roughly flat and shifts the burden to maintenance time. Therefore a platform that wins at launch can lose badly at scale. Knowing the crossover point in advance lets you plan a migration deliberately rather than discovering the need under pressure.
| Cost channel | Who charges it | Scales with | Easy to overlook? |
|---|---|---|---|
| Subscription | Platform | Plan tier | No, it is the headline |
| Transaction fee | Platform | Every order | Yes, stated as a percentage |
| Payment processing | Gateway | Every order | Often confused with the above |
| Applications | Third parties | Features added | Yes, accumulates silently |
| Theme and setup | Third parties | One-off, sometimes recurring | Partly, appears at launch |
2. Hosted Versus Self-Managed Ecommerce Platform
The hosted model sells time back to you. Servers, updates, security patching, and payment compliance become someone else’s responsibility, and you pay a recurring premium for that transfer. Self-managed software reverses the arrangement: the licence costs nothing, and you supply the operations. Neither is inherently better, because the right answer depends on what your time is worth and how much control your product needs. Consequently the comparison should start with your own situation rather than with feature tables.
2.1 Shopify: The Hosted Standard
Shopify defines the hosted category and holds the largest ecosystem around it. Its appeal is speed to launch: a working store with payments, shipping rules, and a checkout can exist within a day, without touching a server. The application marketplace is the deepest available, which means almost any requirement has an existing solution. Consequently sellers who want to spend their attention on products and marketing rather than infrastructure find the trade acceptable.
On specifics, plans are tiered by features and reporting depth rather than by traffic. Transaction fees apply when you use an external payment gateway instead of the in-house one, and that difference is the largest single cost variable. Themes are purchased once, and the checkout is controlled by the platform rather than by you. Furthermore, the storefront language is proprietary, which shapes how deeply you can customise. Our practical notes on running a Shopify store cover the operational side.
This platform suits sellers whose priority is launching and iterating quickly, particularly with physical products and standard checkout needs. The main trade-off is that percentage fees and application subscriptions grow with the store, and the checkout stays outside your control. Therefore high-volume sellers with thin margins eventually feel the drag. In contrast, for a store finding its market, the speed of launch usually outweighs a cost curve that only matters after the store succeeds.
2.2 WooCommerce: Control at the Cost of Time
WooCommerce turns a WordPress site into a store, and the core plugin costs nothing. That structure appeals to anyone already publishing content, because the store and the blog share one installation and one audience. You own the database, the templates, and the checkout, which removes the ceiling that hosted platforms impose on customisation. Additionally, there is no percentage taken from your sales by the software itself.
The costs move rather than disappear. You supply hosting capable of running a store, which is more demanding than a blog because cart and checkout pages cannot be cached the same way. Extensions for shipping, subscriptions, or bookings are typically paid annually. Meanwhile updates, backups, and security become your responsibility or your host’s. Furthermore, performance depends heavily on configuration rather than on the platform, which rewards attention and punishes neglect more than a hosted service does.
This option suits content-led sellers, anyone with unusual product or checkout requirements, and stores where percentage fees would bite hardest. The trade-off is real and should not be minimised: you are accepting an operations workload, and neglecting it produces slow, insecure stores. Consequently it fits sellers with some technical comfort or a budget for maintenance. For someone who wants to avoid all of that, the hosted model is the honest recommendation despite its fees.
3. Which Ecommerce Platform Fits Which Seller
Matching works better than ranking, and four seller profiles cover most cases. The first is testing an idea with few products and no technical support. The second is a content publisher adding products to an existing audience. The third is a growing store where fees have become material. Meanwhile the fourth is an enterprise-adjacent seller with complex catalogues or regulatory needs. Each profile points to a different answer, and moving between profiles is the normal reason stores migrate.
3.1 Testing an Idea Versus Scaling One
A seller testing an idea should optimise for speed and reversibility, not for cost efficiency at scale. The question worth answering is whether anyone will buy, and answering it quickly matters more than saving a percentage. Hosted platforms win decisively here because a store can exist in hours. Additionally, monthly billing means abandoning a failed test costs almost nothing. Therefore the fee structure that looks expensive on a spreadsheet is often the cheapest route to the only information that matters early.
Scaling reverses those priorities. Once orders are predictable, percentage fees become a permanent tax on a known revenue line, and the arithmetic starts favouring owned infrastructure. The crossover point varies with margin rather than with revenue alone. A store with thin margins on high volume reaches it far earlier than one with high margins on low volume. Consequently the model from section one should be revisited annually. When self-managed costs fall below hosted costs including your own time, migration becomes rational rather than ideological.
3.2 Other Ecommerce Platform Options Worth Knowing
Three further options serve narrower situations well. BigCommerce resembles the hosted model but omits its own transaction fee across plans, which suits higher-volume sellers who still want infrastructure handled. Square Online serves sellers whose business is primarily physical, because inventory synchronises with in-person sales. Meanwhile Ecwid embeds a store into an existing site of any kind, which suits someone who does not want to rebuild what already works. Each of these solves a specific problem rather than competing broadly.
Regional payment support deserves separate weight in any of these choices, and it is routinely underestimated. A platform that cannot settle in your currency, or whose gateway does not operate in your market, fails regardless of every other strength. For sellers in the Arab region specifically, checking gateway availability before anything else prevents wasted evaluation. Furthermore, local payment habits matter as much as availability. A store that cannot offer the payment method buyers expect will convert poorly even when everything technical works correctly.
4. Migration Risk Across Ecommerce Platform Choices
Every store eventually considers moving, so the cost of leaving belongs in the decision to arrive. Migration difficulty varies enormously between models, and the difference is structural rather than a matter of provider goodwill. What transfers cleanly is data: products, customers, and orders export in standard formats almost everywhere. What does not transfer is everything built on top, including theme code, application configurations, and the accumulated search visibility of your URLs.
4.1 What Transfers and What Does Not
Product catalogues, customer records, and order histories move reliably through comma-separated exports. Reviews sometimes move, depending on whether they live in the platform or in a third-party application. Meanwhile theme work never transfers, because storefront languages differ completely between platforms. Application logic must be rebuilt with whatever equivalents exist on the destination. Consequently the practical migration cost is proportional to how much custom work sits above the data layer, not to the size of the catalogue itself.
URL structure is the risk most sellers discover too late. Platforms impose different path patterns for products and collections, so a migration usually changes every product address. Without a complete redirect map from old paths to new ones, the search visibility built over years disappears at launch. Therefore plan the redirect map before the migration rather than after it. In fact, that single document determines whether a technically successful move is also a commercially survivable one.
4.2 Reducing Lock-in From the Start
Three habits at launch lower the cost of any future move substantially. Register the domain with an independent registrar so it never depends on the platform account. Export your customer and order data on a schedule and store it somewhere you control. Additionally, resist deep customisation until the store has proven demand, because every custom feature is work you may rebuild later. None of these habits limits what you can do now, and together they convert a potential trap into an ordinary decision.
Email lists deserve particular protection because they are the asset least tied to any platform. A store’s subscriber list should live in an email service you control rather than only inside the store software. When it does, a migration inconveniences your operations without threatening your relationship with customers. Consequently the list becomes the one asset that survives every platform change intact. Building it from the first month is the cheapest insurance available against decisions you have not yet had to make.
5. Verifying an Ecommerce Platform Before You Commit
Most platforms offer a trial, and most sellers waste it exploring the interface. A trial is better spent testing the three things that cannot be judged from documentation: whether your payment method works, whether your product structure fits, and whether the checkout behaves as your buyers expect. Consequently a structured trial of a few hours produces more certainty than weeks of comparison reading. The table below turns that into a sequence you can follow directly.
| Check | How to test it | What failure looks like |
|---|---|---|
| Payment gateway | Connect your intended gateway during the trial | Not available in your country or currency |
| Product structure | Create your most complex product with all variants | Variant limits or awkward workarounds |
| Checkout flow | Place a full test order as a customer | Forced account creation or missing local fields |
| Shipping rules | Configure your actual zones and rates | Rules require a paid application |
| Data export | Export products and customers to a file | Export is partial or locked to a higher plan |
5.1 Running a Useful Trial
Begin the trial with your hardest product rather than your simplest. A product with several variants, conditional shipping, or unusual tax treatment exposes limits that a plain item never reveals. Set it up completely, including images, options, and inventory rules. Additionally, place a genuine test order through the full checkout, because that path surfaces friction no feature list mentions. When both tasks complete without workarounds, the platform genuinely fits. When either requires a paid application, add that cost to your model before deciding.
Test the export function before the trial ends, since it is the cheapest insurance you will ever buy. Exporting your products and customers confirms that your data can leave, and it reveals whether the export is complete or restricted to higher plans. Furthermore, keep the exported file. It becomes the baseline for any future migration and proves the format you will be working with. Sellers who skip this step often discover the limitation at the exact moment they most need it to work.
5.2 Getting the Best Results After Launch
Launch performance depends more on configuration than on platform choice. Compress product images before uploading, since photography is the heaviest element of nearly every store. Limit applications to those that earn their monthly cost, and audit them quarterly. Additionally, keep the checkout as short as your payment provider allows, because each extra field reduces completion. These steps apply identically across every option in this article, which means the effort survives any later migration.
Measurement should follow the same discipline as any other site. Google’s Core Web Vitals apply to stores as much as to publishers, and product pages frequently fail on layout stability because of late-loading images and banners. Track the three field metrics monthly and treat sustained decline as a signal to investigate. Consequently your optimisation effort follows evidence rather than intuition. For a store, that discipline shows up directly in completed checkouts rather than only in ranking positions.
Conclusion: The Ecommerce Platform That Fits You
Five truths reduce to one decision. Fees accumulate through four channels, so model two years rather than comparing subscriptions. Hosted convenience and self-managed control are a genuine trade, not a hierarchy. Your seller profile points at the answer more reliably than any ranking. Migration risk lives in customisation and URLs rather than in data. Finally, a structured trial answers what documentation cannot. An ecommerce platform chosen this way rarely needs revisiting within its useful life.
Do the arithmetic before the trial. Take your expected monthly orders and average order value, apply each platform’s transaction percentage, and add subscriptions plus the applications you know you need. Then run a trial on the two that survive. The whole exercise costs an afternoon and replaces months of second-guessing. Afterwards, put your attention into products and traffic, where the returns dwarf any remaining difference between these options.
