An online store needs hosting that handles transactional database writes without stalling, keeps a shopper's session alive for the whole visit, serves HTTPS on every page, never caches the cart or the checkout, and holds headroom for the traffic your own promotions create. Payment handling matters most, and the answer there is to keep card data off your server entirely.
Most ecommerce hosting requirements lists get written by whoever is selling the plan at the top of the page, so they read as a case for buying more. The real list is shorter and stranger than that. A store does a handful of things a brochure site never does, and those few things are what decide whether the plan holds up. The rest is ordinary hosting.
What a Store Demands That a Brochure Site Does Not
A content site is almost entirely reads. Somebody requests a page, the server hands back the same bytes it handed the last visitor, and if a cache sits in front of the application the database barely gets touched at all. That model breaks the moment there is a cart.
Every add to cart is a write. So is every stock decrement, every coupon validation, every abandoned order row that your platform creates hopefully and then cleans up later. Those writes land in the same tables that your storefront reads from, which is where the trouble starts if the tables are not built for it.
Check the storage engine before anything else. On MySQL or MariaDB you want InnoDB, which locks the individual rows a transaction touches, rather than the older MyISAM, which locks the entire table while a write completes. A store on MyISAM works fine in testing and then queues every shopper behind one order during a rush. You can see which you have in a single query:
sql
SELECT table_name, engine FROM information_schema.tables
WHERE table_schema = DATABASE();
Anything still on MyISAM should be converted. One ALTER TABLE per table, and it is the cheapest reliability improvement available to most self-hosted stores.
The other half of that choice is rollback. An order is a multi-step operation: reserve the stock, write the order, charge the card, send the confirmation. If it dies halfway through, you want the incomplete transaction reversed rather than a half order sitting in the table. InnoDB does that. MyISAM does not.
Sessions Are the Requirement Nobody Checks
A session is how the server remembers that the anonymous browser asking for the checkout page is the same one that added three items twenty minutes ago. Lose it and the cart empties. The shopper does not email you about it. They leave.
PHP stores sessions as files on local disk by default, which is fine on one machine and quietly wrong everywhere else. Move to a second application server, or let a cleanup job run with an aggressive expiry, and those files stop being where the next request looks for them. Check session.save_handler and session.gc_maxlifetime before you launch rather than after the first complaint.
For a single-server store, file sessions on persistent local storage are acceptable. Beyond that, move them into the database or into a shared cache such as Redis, and make sure whatever you choose survives a restart. Most platforms support that with a configuration change and no code.
One more thing kills sessions, and it is embarrassing when it happens: an inconsistent host name. If a shopper starts on example.com and the checkout link sends them to www.example.com, the session cookie scoped to the first name is not sent to the second. Pick one canonical host, redirect the other to it, and never link the wrong one internally.
Why the Checkout-Only Certificate Died
The old advice was to buy a certificate for the payment page and leave the rest of the site on HTTP. Following that now breaks things. Browsers refuse to send a cookie marked Secure over plain HTTP, refuse to load subresources from HTTP on an HTTPS page, and mark unencrypted pages as unsafe in the address bar.
So: one certificate, every page, no exceptions. Set your session cookie with the Secure and HttpOnly attributes, and set SameSite=Lax unless your payment provider posts back to your site cross-site, in which case that one cookie needs different handling. MDN's Set-Cookie reference is the practical description of what each attribute does.
Certificate class matters less than store owners expect. Domain validation does the job for a consumer store, because no browser has surfaced a visual difference between classes for years. If you sell to enterprise buyers whose procurement team reads certificate details, that is the one case where a validated organization name earns its cost, and the certificate options differ mainly in what the issuer checks before signing.
Keep Card Data Off Your Server
This is the requirement that changes more than any hosting feature you could buy.
If card numbers pass through your server, even briefly, even unstored, your server falls inside the scope of the PCI Data Security Standard, and the validation work grows accordingly. If your payment provider collects the card directly, through a hosted payment page or through fields iframed in from the provider's own domain, that scope shrinks sharply. Identical store on identical hosting, a different burden, entirely because of where the card number goes.
Take the second route. Every mainstream provider offers it, the integration is no harder, and the reduction in what you are answerable for is larger than any security product you could bolt onto a server.
There is a real trade-off, and it is not compliance. Hosted fields give you less control over the checkout's appearance, and a redirect to the provider's page costs some conversion. Weigh that against being the party who has to explain a card breach. Everything else on the server still needs the ordinary website security basics, because outsourcing the card does not outsource the rest of the site.
If You Cache the Checkout, You Will Show Somebody Else's Cart
Full-page caching is the single largest performance win available to a PHP store, and it is also the fastest way to destroy one. The cache does not know that the page it stored contains a cart total, a logged-in name, and a form token. It just stores bytes and serves them to the next person.
Four paths must never be served from a full-page cache: the cart, the checkout, the account area, and whatever endpoint your platform uses for cart fragments. Every serious caching layer supports exclusions by path and by cookie presence, so the rule to configure is straightforward. Bypass the cache for those URLs, and bypass it for any request carrying a cart or login cookie.
The subtle failure is the form token. Most platforms embed a one-time token in checkout forms to prevent cross-site request forgery. Cache the page, serve the same token to a thousand people, and the submissions fail validation with an error message that names nothing useful. If your checkout started rejecting valid orders on the day you turned on a caching plugin, you have found it.
Everything else should still be cached hard. Category and product pages carry most of the traffic, and they are safe. Server-side acceleration such as Memcached or a Varnish layer sits under the same rule, and on Hepsia the web accelerator tools are switched on per site, so your exclusions have to be set deliberately rather than assumed.
My position: skip any caching plugin that advertises how little configuration it needs. A store needs the configuration. The plugin that hides it from you is the one that will cache your checkout.
How Big Does the Plan Need to Be?
Average traffic is not a useful number for a store, because stores do not fail on average days. They fail on the day the newsletter goes out.
Work from your own order pattern instead. Take your busiest hour of the last year, not your busiest day. Divide the orders in that hour by your conversion rate to get sessions, then estimate concurrency from how long a session lasts. Suppose you took sixty orders in the hour after a promotional email and convert at two percent: that is three thousand sessions in an hour, and if the average session runs six minutes you have around three hundred people on the site at once. That is the number to size against, and it is usually far above what a monthly average would have suggested.
Then ask what created that hour. A promotional email, a paid campaign, a seasonal deadline: all of those are things you schedule. A store whose peaks are self-inflicted is in a good position, because you can warn your host, keep a campaign away from a maintenance window, and pre-warm caches before the send.
A store also settles the question of whether hosting is worth paying for. Free hosting has no place under a checkout, and the case for paid hosting is strongest where money changes hands. Then translate your peak into the units a plan page uses: what hosting plan specifications mean covers how concurrent processes, memory, and inode counts map onto real load.
Ecommerce Hosting Requirements, in One Table
| Requirement | Why a store needs it | What to check |
|---|---|---|
| InnoDB tables | Row-level locking and transaction rollback under concurrent orders | Query information_schema.tables for the engine |
| Durable sessions | A lost session is an emptied cart | session.save_handler, and one canonical host name |
| HTTPS on every page | Secure cookies and mixed content both require it | Certificate covers www and apex, HTTP redirects |
| Cache exclusions | A cached checkout serves stale carts and dead form tokens | Cart, checkout, account, and cart-fragment paths bypass |
| Peak headroom | Failures happen during your own promotions, not on average days | Busiest hour, not busiest month |
| Off-server card handling | Shrinks what you are responsible for during an audit | Provider-hosted fields or a hosted payment page |
| Tested restores | An order table is the one thing you cannot recreate | Restore into a scratch database, read the last order |
That last row is not padding. A store's database is the only asset on the server that does not exist anywhere else, and the guide to backing up a website makes the case that a backup you have never restored is a hope rather than a plan. Restore one before you need to.
What Each Store Platform Leans On
The platform you run decides how much of the list above you have to solve yourself.
WooCommerce inherits WordPress's requirements and adds sustained database writes on top, so it wants concurrent process capacity rather than a starter tier. It also depends on WordPress's pseudo-cron, which fires only when somebody visits, so a quiet store can find its order emails and stock syncs running hours late. Set up a real scheduler to call wp-cron.php on an interval.
OpenCart and PrestaShop are conventional PHP applications with modest appetites, and both run comfortably on shared or semi-dedicated hosting at an ordinary catalog size. BestPaidHosting publishes per-application pages for OpenCart and PrestaShop, which is where to check the current specifications rather than trusting a number in an article.
Magento is the outlier. Do not self-host it unless somebody on your team administers servers as part of their job: it expects a search service, a message queue, Composer-based deployment, and a cache tier, and it wants root access to configure them properly. A store that picks Magento for the feature list and then runs it on shared hosting has bought a maintenance problem rather than a platform.
Hosted platforms remove the list by taking your server away. Reasonable answer. The cost is that customization stops where the vendor's settings page stops.
Where to Start
Run the storage engine query. It takes ten seconds and it is the requirement most likely to be quietly wrong on an older store.
Then work down the table: confirm the certificate covers both host names, list your cache exclusions and test them by adding an item to the cart in a private window, pull your busiest hour out of last year's order data, and check where your payment provider actually collects the card. None of that is a purchase. Only once it is settled does plan size become the interesting question, and by then you will know which number you are sizing against.