The article
An online store can stop selling without a single error on the screen. The product pages open, the cart fills up and the "Pay" button works, but after a change on the payment provider's side, paid orders no longer reach your admin. Sometimes the first to notice is a customer asking where the order is. Ecommerce website maintenance services exist for that gap: someone looks after the parts that take money before a customer finds the problem.
I have been building software for 18 years, and my team has built payment flows on Stripe, an in-app wallet and an ordering app for restaurants. Below is what store maintenance covers with us, how a proposal is put together, what drives the cost, and a test order to run after every update, whoever maintains your store.
Ecommerce website maintenance services: the short version
| What | How it works |
|---|---|
| What we look after | Checkout and payments, Stripe included; catalog, search and filters; updates of the platform, extensions and libraries; https certificates and the server setup |
| How it starts | You send the store's address and what it runs on; we review the platform, the extensions, the checkout and the hosting |
| Price | Quoted after the review, as a monthly price you see before you sign anything |
| A store another team built | Yes, once we have reviewed its code and setup |
| New features | From the same developers, estimated before work starts |
| A website we build | The $29 a month plan, billed annually ($348): hosting, https, updates and fixes |
What breaks in an online store
Four parts of a store need watching, and each one costs sales in its own way.
- The checkout. It depends on more parts than any other page: the cart, discounts, shipping, tax, the payment provider and the emails that follow. A break anywhere costs sales until someone notices.
- The payment provider. Providers change their APIs and their rules on their own schedule, and they retire old versions. An integration that worked at launch can stop confirming payments after a change on their side.
- Extensions. Each one updates on its own schedule. An outdated extension puts customer data at risk, and two freshly updated ones can conflict.
- Catalog speed. A category page with dozens of product photos is heavy by nature. If the photos are not sized for a phone and loaded as the shopper scrolls, buyers go back to the search results.
The last one is easy to check yourself. In October 2026 I measured the five company pages on the first page of Google for this search; four of them sell website maintenance in general, not only for stores. Three of the five use the browser's own lazy loading on none of their pictures (21, 81 and 90 of them), and one has no link preview picture at all. Five pages are a small sample, but if the companies Google shows for store upkeep skip it on their own pages, check your catalog: run a category page through PageSpeed Insights on the mobile tab, and it shows how long the page takes to appear and which images slow it down.
What our ecommerce maintenance services cover
Maintenance of an ecommerce website, as we do it, starts from the parts that take money.
- Checkout and payments, Stripe included. The payment integration is kept current when the provider changes its API or its rules, and the path from the cart to the confirmation email is part of what we look after.
- Catalog, search and filters. The pages buyers browse, and the search and filters that lead them to a product.
- Updates of the platform, the extensions and the libraries, when they need them.
- Certificates for https and the server setup behind the store.
- Answers from developers who know the store from the inside, so a question about an order goes to someone who can read the code.
The developers who maintain a store can also build for it. A new checkout flow or a feature is development, estimated before work starts; upkeep keeps what you have taking money.
How we build what takes money
"Taking care of payments" means little until you see the code behind it. Three projects of ours show the details that matter.
- On Somatic Reset, a booking site with prepayment, a payment is trusted only after a signed webhook from Stripe and a fresh read of that payment from Stripe itself. Slots are reserved under a lock, so two people cannot pay for the same hour. Stripe Checkout holds a session for at least 30 minutes while the product needed 10, so a background worker closes the session through the API and frees the slot only after Stripe confirms it.
- In Tarot Fans, money moves both ways: clients top up and pay, experts earn and withdraw. A wallet with Stripe underneath keeps every balance and transaction straight.
- In Mutualz, a restaurant app, orders, loyalty points and user activity are tracked end to end between the app, the restaurant and the backend, so nothing is lost on the way.
The common rule: a store should believe the payment provider, not the browser. A customer who closes the tab at the wrong moment must not leave you with a paid order you never see, or an order marked as paid that never was.
How it starts: from the store's address to a proposal
- The store's address, and what it runs on, if you know.
- The review: the platform, the extensions, the checkout and the hosting.
- The proposal: the fixes that protect sales first, then the regular updates, with a monthly price.
- Upkeep: updates and fixes as the store needs them.
The review answers one question: what could stop the store from taking money, and how soon. It covers four things.
- The platform: its version, and whether that version still gets security fixes.
- The extensions: which are outdated, which do the same job twice, which were changed by hand.
- The checkout: the path from the cart to the payment and the confirmation email, including how the store learns that a payment went through.
- The hosting: the server setup and the certificates behind the store.
What a good proposal names
An ecommerce website maintenance proposal should read like a list of risks in the order of what they would cost you. Ours puts the checkout and the payments first, because a broken checkout loses money every hour it stays broken; the regular updates come after them. Whatever company you ask, check that its proposal names:
- which parts of the store are covered, and which are not;
- how an update is tested before it reaches the live store;
- who has access to the store, the hosting and the payment provider, and whose name those accounts are in;
- how fast they respond, and what costs extra;
- what you get if you leave.
What drives ecommerce website maintenance cost
We do not publish one package price for stores, because stores differ in platform, catalog and integrations: two stores with the same number of products can need very different care. The maintenance cost of an ecommerce website moves with these.
| What | Why it changes the work |
|---|---|
| The platform | A hosted platform updates its own core; a store on its own code needs every update made and tested by developers |
| Extensions | Each one updates on its own schedule and can conflict with the others |
| Custom code | Only people who read it can change or update it safely |
| Integrations | Payments, shipping, tax, inventory and a CRM each change their APIs on their own cycle |
| The catalog | Search, filters, imports and thousands of photos each need care |
| Traffic peaks | A sale or a season needs the server ready before it starts |
| How often you change things | Regular new features are development, not upkeep, and are estimated on their own |
So our ecommerce website maintenance packages are priced after the review, as one monthly price you see before you sign. If you compare ecommerce maintenance packages sold by the hour, ask how many hours a typical month uses and what happens when they run out.
The test order: run it after every update
This is the check I would want from whoever maintains a store, us included. It needs no developer and takes about a quarter of an hour. Run it on a copy of the store in your payment provider's test mode, or on the live store with a real order that you refund.
- Open the store on your phone, over mobile data.
- Search for a product by its name.
- Open a category, apply a filter and change the sort order.
- Add two products to the cart, change a quantity, remove one.
- Apply a discount code that works, then one that has expired.
- Enter a delivery address you serve and check the shipping cost and the tax.
- Pay: with the provider's test card in test mode, or with a real card on the live store.
- Check the confirmation page and the confirmation email, including the spam folder.
- Find the order in the admin, with the right items, total and address.
- Check that the stock of those products went down.
- Refund the order, and see the refund both in the admin and in the payment provider's dashboard.
- If you track sales in analytics, check that the purchase was recorded.
If any step fails, the update is not finished, whoever made it. Keep the list next to the admin login, and give it to anyone who touches the store.
Plan updates around your sales calendar
Updates and big sales do not mix well. Three habits keep them apart:
- finish platform and extension updates well before a big sale, then change only content until it ends;
- run the test order after the last update, and again on the morning the sale starts;
- keep security fixes going in all the same: a known hole does not wait for your calendar.
Card data and the accounts behind the store
The safest card number is the one your store never sees. When the payment provider's hosted checkout or hosted fields take the card, your systems only handle tokens, and that is how we build payment flows. Which PCI DSS validation applies to your store is a question for your payment provider or your compliance advisor; the technical side we prepare is described on PCI DSS.
Before anyone maintains the store, check whose name the accounts are in: the domain, the payment provider, the platform or the hosting, and the analytics. They should be your company's. A developer, us included, should work in them with a role you can remove.
A store another team built
We maintain stores built by other teams once we have reviewed the code and the setup. If something has to change before we can maintain it, we say so first. The review is also the moment to learn what nobody wrote down: which extensions were changed by hand, which scheduled jobs run at night, which integration has no owner.
A small catalog may not need a store platform
If you sell a handful of products, you may not need a store platform at all. A small catalog fits on our $499 website, and payments on the site add $500. A store with hundreds of products is its own project, with its own estimate. For the websites we build, upkeep is the $29 a month plan, billed annually ($348), described on website maintenance.
When the store needs more than upkeep
Maintenance keeps what you have working. If your store runs on a hosted platform with a theme you never change and no extensions, the platform's own updates may be all it needs; maintenance pays off once a store has extensions, custom code or integrations. A new checkout flow, a marketplace or an app is development: see custom web development. If the store is really a web application, with accounts and dashboards, see web app maintenance. Order data you cannot lose belongs in a cloud backup that is restored in tests, not only made.
Send us the address of your store and what it runs on. You get a maintenance proposal once we have seen the store, and the first call and the rough estimate are free. Everything else we look after is under IT support.
