On this page · 12 sections
- The licence is free. That is not the same as cheap
- Where the money actually goes
- The PHP 8.3 floor is the first thing to check
- WooCommerce 11.0 changed things developers need to know about
- What we build
- The stack we build on
- Our delivery process
- Why eCorpIT
- India-specific considerations
- FAQ
- How eCorpIT can help
- References
Summary. WooCommerce is used by 48.2% of all e-commerce systems W3Techs surveys and sits on 8.1% of all websites as of 17 August 2026, behind WordPress itself at 40.8%. The platform licence is $0 with no revenue share. The money goes elsewhere: WooCommerce quotes hosting at $25 to $350 a month for most stores, extensions at $29 to $299 a year each, and card processing around 2.50% to 2.90% plus 30 cents through WooPayments. In three published merchant cost breakdowns, payment fees were the largest single line every time, reaching $5.1 million a year on $300 million of revenue. And since WooCommerce 10.8, the server floor is WordPress 6.9 and PHP 8.3, which is a hosting decision before it is a development one.
The licence is free. That is not the same as cheap
WooCommerce's own pricing page is unusually direct about the model: $0 platform fee, 0% revenue share, and four cost buckets you control. Core platform free. Payments at your processor's rate. Hosting from $25 to $350 a month for most stores, scaling with traffic. Extensions at $29 to $299 a year each, bought individually.
Compare that with the alternatives on the same page. Shopify Basic is $29 a month and charges 2% per transaction if you use a third-party payment solution; Shopify Advanced is $399 a month with a 0.6% third-party gateway fee; Shopify Plus starts above $2,300 a month. BigCommerce Core is $29 a month with online revenue capped at $50,000. Adobe Commerce is quoted at $22,000 to $125,000 or more per year. Salesforce Commerce Cloud is quoted at 1% to 3% of gross merchandise value, which is the model that scales worst as you grow.
| Platform | Monthly platform and hosting | Fee for using a third-party gateway |
|---|---|---|
| WooCommerce | $0 platform fee, host of your choice | None |
| Shopify Basic | $29/month | 2% per transaction |
| Shopify Advanced | $399/month | 0.6% per transaction |
| Shopify Plus | $2,300+/month | 0.2% per transaction |
| BigCommerce Core | $29/month, revenue capped at $50k | 2% per transaction |
| Adobe Commerce (Magento) | $22k-$125k+/year | None |
The tradeoff is honest. You take on hosting, updates and security, and in exchange nobody takes a cut of your growth. That tradeoff only pays if the build and the run are done properly, which is the part a quote usually hides.
Where the money actually goes
WooCommerce publishes three merchant total-cost breakdowns produced by its agency partner StuntCoders, and they are more useful than any generic estimate because they are itemised.
| Merchant profile | Annual revenue | First-year total | Ongoing annual | Ongoing as % of revenue |
|---|---|---|---|---|
| Boutique luxury goods, Europe | $2M | ~$139,000 | ~$89,500 | 4.48% |
| Regulated medical retailer, Europe | $10M | ~$267,000 | ~$237,000 | 2.37% |
| Subscription coffee brand, US | $300M | $5,334,000 | $5,214,000 | 1.74% |
Read the composition, not just the totals. In the $2 million luxury store, initial development was $70,000 and payment fees were roughly $50,000 a year at an average 2.5%, while server hosting was $300 a year and premium plugins another $300. In the $300 million subscription business, hosting was $10,000 and plugins were still $300, against $5.1 million in payment fees. Software licensing is a rounding error at every scale. Processing rates are not.
That has a direct consequence for how a build should be scoped. Half a point negotiated off a processing rate at $10 million of revenue is worth $50,000 a year, which is more than most merchants spend on their entire development budget. WooCommerce imposes no penalty for changing gateway or running several at once, so gateway strategy is engineering work worth doing, not a procurement afterthought.
Nils-Fredrik Winther-Kaland, CEO of the WooCommerce agency partner Maksimer, puts the argument for the model this way on WooCommerce's pricing page: "WooCommerce offers unmatched control over both costs and capabilities. Unlike rigid SaaS platforms, we can tailor every part of the stack — only paying for the features the business truly needs."
The PHP 8.3 floor is the first thing to check
The WooCommerce server recommendations, which cover WooCommerce 10.8 and later, set the supported environment at WordPress 6.9 or greater, PHP 8.3 or greater with testing up to PHP 8.4, MySQL 8.0 or greater or MariaDB 10.6 or greater, HTTPS, and a WordPress memory limit of 256 MB or greater. WooCommerce notes that it still works with PHP 7.4 and MySQL 5.6, then says plainly that those versions have reached end of life and may expose the site to security vulnerabilities.
Set that against PHP's own support table. PHP 8.3 left active support on 31 December 2025 and gets security fixes only until 31 December 2027. PHP 8.4 leaves active support on 31 December 2026 and has security support to 31 December 2028. PHP 8.2 drops out of security support entirely on 31 December 2026.
So the minimum supported WooCommerce runtime is already a security-only PHP branch. A store built today on PHP 8.3 has a scheduled upgrade in its future, and a store still on 7.4 has an unscheduled incident in its future. We size the PHP upgrade during discovery rather than after a plugin breaks, and the same logic applies to any legacy PHP estate regardless of whether WooCommerce is involved.
WooCommerce 11.0 changed things developers need to know about
WooCommerce 11.0 shipped on 4 August 2026 with 551 pull requests from 89 contributors, one of the largest releases in recent history, and it requires a database update. It is backwards compatible, but "backwards compatible" and "safe to auto-update on a live store" are different claims.
The pre-release developer notes list 28 pull requests tagged for performance, caching or scalability. Product object caching is now on by default for new stores: variable products load roughly 9% to 12% faster on product pages, and bundle products process 6% to 12% faster during checkout. Large stores get an HPOS Orders-screen query optimisation for multi-status lists and empty-search counts.
Four changes deserve a regression test rather than a glance:
The Product Editor beta is fully removed, including the @woocommerce/product-editor package, its feature flag, editor routes and related extension points. Products and product data are untouched, but any extension that hooked those slots or routes will break.
The queried object on the Shop page now matches the WP_Post object of the Shop page rather than the WP_Post_Type for products, which changes what get_queried_object() and get_queried_object_id() return there. Theme code that branched on that is a likely casualty.
The product shipping class taxonomy became private in 11.0, and ReserveStock::reserve_stock_for_order() now defaults to a 60-minute hold when callers omit the duration. Both are the sort of quiet default change that shows up as a stock discrepancy three weeks later.
The internal dependency moved to Action Scheduler 4.0.0, which matters on any store running scheduled jobs at volume.
# Before any WooCommerce major update on a live store
wp db export pre-upgrade.sql
wp plugin update woocommerce --dry-run
wp wc update --user=admin # runs the database update explicitly
What we build
A WooCommerce engagement at eCorpIT is normally one of four things.
A new store build: information architecture, product data model, block-based checkout, a theme that is not a bought template bent out of shape, and the gateway integration. A replatform: moving off Shopify, Magento or a bespoke cart, where product, customer and order history all have to arrive intact and the URLs have to keep their rankings. A performance and cost rescue: an existing store that is slow, over-plugged, or paying for extensions it no longer uses. And ongoing engineering: a retained team that handles WooCommerce and WordPress core updates, extension conflicts, and the feature backlog.
The replatform is the one where quotes diverge most, because the redirect map and the data migration are the work; the theme is the visible part. Our SEO-safe replatform migration approach exists because stores routinely lose organic revenue in a move that looked technically clean.
The stack we build on
WordPress 6.9 or later, WooCommerce 11.x, PHP 8.4 where hosting allows and PHP 8.3 as the floor, MySQL 8.0 or MariaDB 10.6, and High-Performance Order Storage enabled rather than legacy post-table orders. Block-based checkout via the Store API where the store's requirements permit it, custom extensions written as proper plugins rather than theme functions, and object caching plus a CDN in front. Payment integration is chosen per market rather than defaulted.
For stores that need to feed other systems, the order and product endpoints usually become an integration project of their own, which is where our API development practice picks it up, and where stock or pricing data has to reconcile with an ERP, our ERP software development team.
Our delivery process
- Discovery, 1 week. Catalogue size and variant complexity, current PHP and MySQL versions, plugin inventory with a licence cost per plugin, payment volumes and current processing rate, and the traffic profile. This produces a cost model, not just a scope.
- Architecture and data model, 1 week. Product types, attributes and variations, tax and shipping logic, and the integration list. Getting the product data model wrong is the single most expensive mistake in a WooCommerce build.
- Build, 4-10 weeks. Theme, checkout, custom extensions, and gateway integration on a staging environment with a copy of real data. Automated checkout tests from the start, not at the end.
- Migration and launch, 1-3 weeks. Data migration with reconciliation counts, a redirect map validated before cutover, and a rollback plan that has actually been rehearsed.
- Run. Update cadence, staging-first testing of WooCommerce majors, and performance and cost review each quarter. Our software testing team runs the regression suite when a major like 11.0 lands.
Why eCorpIT
eCorp Information Technologies Private Limited was founded in 2021 and works from Gurugram, Haryana. We are CMMI Level 5 appraised, MSME certified, and ISO 27001:2022 certified, and we are a Shopify partner as well as an AWS, Microsoft and Google partner, which means replatform advice is not pushed one way by a single vendor relationship. Teams are senior-led and multi-disciplinary.
We give an engagement model rather than a rate card. Discovery is a fixed-price package that produces the cost model above. A store build is fixed-scope once the data model and integration list are signed. Ongoing work is a monthly retained team sized to the backlog; if you would rather hold the roadmap yourself and add engineers, our staff augmentation services page explains that route.
India-specific considerations
For Indian merchants, three things change the build. Payment: domestic gateways and UPI handling need to be integrated and tested against real flows rather than assumed, and the rate you negotiate matters more than the plugin you pick, because processing is the dominant cost line at every revenue level in the published breakdowns above. Tax: GST-compliant invoicing, HSN codes and place-of-supply logic belong in the data model from day one, not bolted on before an audit. Privacy: a store holds customer names, addresses, phone numbers and order history, so under the Digital Personal Data Protection Act 2023 that is personal data with retention and deletion obligations. We design WooCommerce stores aligned with DPDP requirements, including a defined retention period for order and customer records and a working deletion path.
FAQ
How eCorpIT can help
We start a WooCommerce engagement by building the cost model: catalogue and variant complexity, current PHP and MySQL versions, the plugin inventory with a licence cost against each one, and your actual processing rate against volume. That model usually finds more savings in the payment and hosting lines than in the build itself, and it makes the quote defensible. If you are planning a store build, a replatform, or a rescue on a store that has become slow and expensive, send us the current stack and revenue profile and we will come back with a scoped plan and an engagement model. Start at /contact-us/.
References
Last updated: 18 August 2026.
