Store Platform, Simple Seller or Hosted Checkout?
Selling three digital files and running a 900-product catalogue are different problems, and the plugin categories that solve them are genuinely different. Most painful WordPress stores are a full platform installed for a job that needed a checkout link.
The catalogue size and the order model decide this, not the feature list. Ecommerce plugins for WordPress split into three categories that look interchangeable on a pricing page and are not.
| Category | Built for | The cost |
|---|---|---|
| Full store platform | Real catalogues, physical goods, tax and shipping | Weight, extensions, ongoing maintenance |
| Lightweight seller | Digital downloads, a few products, simple pricing | Hits a ceiling on complex catalogues |
| Hosted checkout embed | One product, a booking deposit, a donation | Checkout lives on someone else's domain |
The trap runs in both directions. Installing a full platform to sell four PDFs gives you a dozen database tables, a cron schedule and a template hierarchy you will maintain forever. Starting with a hosted embed for a catalogue that is about to grow means rebuilding the store in a year, without your order history.
Full store platform
Choose this when any of the following is true: you sell physical goods, you need tax calculated by destination, you need shipping rates and labels, you have variable products, or you need order management inside WordPress rather than in a third-party dashboard.
The strength of this category is the extension ecosystem. The weakness is the same thing. Every extension hooks the same checkout, and a store with twenty of them is a store where nobody can say why the checkout broke. Before adding one, ask whether a setting or a template change would do.
If you go this way, the first hour matters — installing WooCommerce properly, then setting up shipping rules and tax before importing anything. Bulk catalogues belong in a CSV import rather than manual entry; see importing products with CSV. And pick a theme that already understands product templates, per themes for ecommerce, because retrofitting product layouts onto a brochure theme is where most of the custom CSS debt comes from.
Lightweight seller
Purpose-built for digital products: files, licences, memberships-adjacent access. These plugins skip shipping, warehouses and complex tax jurisdictions entirely, and they are dramatically simpler to run because of it.
Evaluate on:
- File delivery — expiring links, download limits, and whether files sit outside the web root.
- Licence or access control, if you are selling software or gated content.
- Tax on digital goods, which is jurisdiction-dependent and easy to get wrong.
- Refund workflow, because digital refunds still need revoking access.
- Reporting you can reconcile against the payment processor.
Hosted checkout embed
The smallest category: a button or embedded form that hands the buyer to a payment provider's own checkout. No orders table, no cart, almost no maintenance, and the provider carries the compliance burden of the payment page.
It suits single products, deposits, event payments and donations. It stops working the moment you need a cart with multiple items, order status, customer accounts or stock control. Be honest about which of those you will need within a year.
What to test regardless of category
- Complete a real purchase with a real card, then refund it.
- Buy on a phone, on mobile data, not on office wi-fi.
- Buy while logged out, and again as a returning customer.
- Force a payment failure and see what the buyer is told.
- Check the confirmation email arrives outside your own domain.
- Check what the cart and checkout pages weigh compared with a normal page.
- Clear the cache and repeat step one — stale checkout markup is a classic.
Steps four and five catch more real revenue loss than any conversion optimisation. A checkout that silently fails, or an order confirmation that lands nowhere, looks fine in testing and costs you every time.
Performance and caching
Stores are the hardest thing on WordPress to keep fast because the pages that matter most cannot be served from cache. Confirm your cache excludes cart, checkout and account pages, and that nothing is caching a logged-in customer's session — see choosing a cache plugin for how the exclusions work.
If checkout misbehaves after a change, treat it as a conflict investigation rather than a settings problem; WooCommerce checkout not working walks through the usual causes.
The decision
Count your products, then count the things that make an order complicated: shipping, tax by region, variations, stock, subscriptions. Zero of those and under five products means a hosted embed or a lightweight seller. Any two of them means a full platform, and you should plan for the maintenance rather than being surprised by it. Whatever you choose, take a backup before the first order, not after.
Frequently asked
- No, and it is usually the wrong choice. A single product or a handful of digital downloads is served better by a lightweight seller or a hosted checkout embed, which avoids the tables, cron jobs and templates a full platform adds to every page.
- Cart, checkout and account pages cannot be cached like normal pages, and stores add session handling plus product queries on top. The fix is page-level cache exclusions and fewer extensions, not a stronger caching plugin.
- Product titles, prices and images usually export as CSV and migrate acceptably. Orders, customer accounts, subscriptions and coupon history rarely do, which is why the platform decision matters far more after your first hundred orders than before.