WooCommerce Developer | Checkout, B2B Pricing & Performance

A WooCommerce store carries a burden a content site does not: every performance problem is a conversion problem, every checkout bug is lost revenue, and the database grows continuously whether or not anyone is maintaining it.

Checkout and payments

Checkout is where the money is and where the complexity concentrates. Payment gateway integration including 3D Secure and Strong Customer Authentication, saved payment methods, subscriptions and recurring billing, multi-currency, and the failure paths that matter more than the happy path.

The situation to design for is a payment that succeeds at the gateway while the callback to your site fails. Without idempotency and reconciliation you get duplicate charges, orders that never appear, or stock decremented twice. This is the part of e-commerce work that separates a store that mostly works from one you can trust.

Tax, shipping and B2B

Rules that seem simple until they meet reality: tax by jurisdiction with digital goods treated differently from physical, VAT number validation for B2B EU sales, shipping zones with weight and dimension-based rates, and free shipping thresholds interacting with discounts in ways nobody intended.

B2B stores add another layer — customer-specific pricing, tiered quantity discounts, quote requests instead of direct purchase, purchase order payment, and account hierarchies where a buyer orders on behalf of an organisation. WooCommerce handles all of this, though rarely without custom work.

Performance with a large catalogue

WooCommerce stores everything in the WordPress post tables, which works well until it does not. The pressure points at scale:

Product metadata. Attributes and variations stored as post meta produce queries that do not scale linearly with catalogue size.
Order history. Years of orders in the same tables as content. High Performance Order Storage helps considerably and is worth migrating to.
Cart and session data. Written on nearly every request; on a busy store this becomes the bottleneck and belongs in Redis.
Faceted filtering. Layered navigation over a large catalogue generates expensive queries. Elasticsearch handles this far better — see Search & Performance.
Uncacheable pages. Cart, checkout and account pages cannot be page cached, so their query behaviour matters disproportionately.

Product data and integrations

Stores of any size need product data flowing in from somewhere — an ERP, a PIM, a supplier feed — and orders flowing back out to fulfilment and accounting. Import pipelines that handle partial failure without corrupting the catalogue, stock synchronisation that does not oversell during the sync window, and reconciliation that catches drift between systems.

Migrations and platform decisions

Migrating a store means moving products, variations, customers, order history, reviews and URLs, with redirects for every changed product and category path. Order history in particular is often underestimated: customers expect to see purchases from years ago, and accounting may require it.

On whether WooCommerce is the right platform — it is strong where you want full control, have unusual requirements, or are already running WordPress. For very high order volumes with straightforward requirements, a hosted platform may cost less in engineering time than it saves in fees. I would rather say that before a build than after one.

Common questions

How many products can WooCommerce handle?

Tens of thousands with proper attention to indexing, object caching, High Performance Order Storage and search offloaded to Elasticsearch. The number itself is less important than the shape of the catalogue — products with many variations and attributes create far more load than the same count of simple products. Default hosting and configuration will struggle well before the platform does.

Our checkout occasionally creates duplicate orders. Why?

Almost always a payment callback handled without idempotency: the gateway retries a webhook it thinks failed, or the customer refreshes during processing, and the handler runs twice. The fix is idempotency keys on order creation plus a reconciliation job comparing gateway transactions against orders. It is worth fixing properly rather than patching the symptom, because the same gap causes missing orders too.

Should we move from WooCommerce to Shopify?

It depends on where your costs actually sit. Hosted platforms remove infrastructure and maintenance burden but constrain customisation and charge transaction fees. If your requirements are ordinary and you are spending significant developer time on upkeep, moving may be cheaper overall. If you have unusual pricing, integration or content requirements, that constraint will bite quickly. Worth analysing rather than assuming.

Can you improve conversion rate?

I can remove the technical obstacles to it — checkout speed, mobile behaviour, payment failures, unclear error handling on forms — and these often matter more than they get credit for. Design, pricing and merchandising decisions are outside what I do, and anyone promising conversion improvements from technical work alone is overselling.

Do you handle PCI compliance?

The standard approach keeps card data entirely off your server by using a gateway with hosted fields or a redirect, which keeps you in the simplest compliance scope. I build to that pattern and can advise on what your scope actually is, but formal certification involves your payment provider and, above a certain volume, a qualified assessor.