WooCommerce or custom e-commerce: architecture, extensions, checkout and cost over time

The choice of e-commerce platform is often made on two things: upfront cost and familiarity with WordPress. Legitimate criteria, but incomplete. What decides the life of an online shop over the next three years is something else: how standard the sales process is, how many extensions will be needed to adapt it, how it integrates with the rest of the business and what it will cost to maintain.

The three routes

• WooCommerce: e-commerce inside WordPress, full control, a huge extension ecosystem, maintenance on you.
• Hosted platform: infrastructure managed by the provider, recurring fees, customisation within the platform's limits.
• Custom: catalogue, cart and checkout written for the specific process, often with a modern front end and dedicated services for payments and shipping.

WooCommerce: where it works and where it gets complicated

WooCommerce is a solid choice for small and medium catalogues, standard sales flows and when editorial content matters as much as products. With high-performance order storage (HPOS) orders no longer live in the generic posts table, and on suitable hosting with a persistent object cache it handles substantial volumes.

It gets complicated in three situations:

• extension build-up: subscriptions, customer-group pricing, bundles, shipping rules, advanced filters. Each adds code, queries and dependencies, and updates become delicate;
• search and filtering on attributes: on large catalogues, metadata-based filters get slow without a dedicated search engine;
• non-standard processes: bookings with shared resources, configurators, B2B sales with complex rules. In these cases I check whether the model and the extensions cover the required rules before proposing customisations or an alternative.

When custom pays off

Custom makes sense when the sales process is the product: bookings with real availability, rentals, subscriptions with special logic, configurators, B2B flows. The data model is designed around the process, reliable providers handle payments and shipping, and the front end is fast because it does not carry the weight of a generic CMS. The upfront cost can be higher; the comparison over time must include development, licences, maintenance, infrastructure and support for both solutions.

Checkout, technically

Checkout is where orders are lost. The choices that matter:

• guest checkout when compatible with the service and the shop's requirements;
• total costs visible early, shipping included;
• few fields, with correct autocomplete and clear validation;
• payment methods suited to the audience: cards, digital wallets, PayPal, local or instalment methods;
• mobile performance: no third-party scripts blocking interaction on the payment page.

Payments

In Europe, card payments fall under the scope of strong customer authentication (SCA) and must handle its exemptions and exclusions where they apply. With hosted payment forms or provider components (Stripe and similar), card data never touches the site, authentication is handled by the provider and the PCI DSS scope can shrink depending on the integration. This does not remove the merchant's obligations or the site's security checks. The order status is updated from the provider's webhooks, not from the browser returning to the confirmation page.

Integrations

Management system, e-invoicing, couriers, CRM. This is where many shops become fragile: you must decide which system is the source of truth for products, prices and stock, and design the integration with queues, idempotency and reconciliation.

How to decide

1. Is the sales process standard or specific?
2. How many extensions would WooCommerce need to cover it, and who maintains them?
3. Which systems must the shop talk to?
4. Who runs the shop day to day, and with what skills?
5. What is the three-year total cost, not just the upfront one?

The most common mistakes in choosing

• Choosing on upfront cost: a WooCommerce shop with twenty extensions on yearly licences can cost more over three years than a lean custom solution.
• Underestimating integrations: the link with management and invoicing systems is often the most complex part of the project, and should be estimated first.
• Bending the process to the platform: giving up an important sales rule because "the plugin doesn't do it".
• Overlooking who runs the shop: a powerful platform that is awkward for whoever uploads products and handles orders gets used badly.
• Ignoring mobile performance: slow product pages and checkout cost orders every day.
• No data plan: products, customers and orders must be able to migrate if the platform ever changes.

The best choice is almost always the simplest one that covers the real process without forcing it.

Payment events: duplicates and arrival order

The endpoint checks the provider's signature on the original body of the request before trusting its content. The event is recorded durably, with a unique identifier, and processed so as to tolerate repeated deliveries. A simple "already exists?" check with no constraint in the database is not enough when two requests arrive together.

The logic must not assume the order of the events. Before confirming the order I check the payment status, amount, currency and link to the internal order, also handling asynchronous payments and refunds. The success response to the provider comes after the durable acceptance of the event; slow operations can continue in a queue.

The test covers double delivery, timeouts, a non-existent order and a payment still being processed. The return of the browser to the confirmation page does not by itself authorise shipping.

Reference: receiving and handling webhooks, Stripe.

My take

I use WooCommerce when it is the right choice: for Olio Intini I built a multilingual WordPress site with an integrated online shop, a straightforward purchase path and a design identical to the one supplied by the client. A clear catalogue, a standard flow, important editorial content: ideal WooCommerce territory.

But when the process is unusual, I prefer to write it. In the Altura Vela management app, built in Nuxt.js, Stripe payments are part of an application built around how the school works, not an adapted plugin. And I see more and more WooCommerce shops weighed down by dozens of interdependent extensions: there the problem is not WooCommerce, it is the accumulation, the same one I describe in Custom or ready-made WordPress themes and plugins.

In any case, before choosing I always ask to see how an order is handled today, from arrival to dispatch: that is where you see which platform is needed.

Why work with me

Since 1999 I have been writing code for the web: more than 300 projects delivered and, for many years, work with more than 30 agencies, from Rome and remotely. I build WooCommerce shops and custom e-commerce, with careful checkouts, payments through certified providers and integrations designed to last.

If you need to choose a platform for your shop, get in touch: in a call of about 20 minutes we look at your sales process. The service is in E-commerce and online shops.