A brochure site that breaks for an afternoon is embarrassing. A store that breaks for an afternoon has a number attached to it, and your client will work that number out before you have finished apologising. That is the real difference between the two kinds of client site, and it is why taking on a WooCommerce build or retainer deserves a different conversation, a different contract and a different way of working than the marketing sites most agencies cut their teeth on.
This post walks through the risks that are specific to stores, what tends to go wrong in practice, and what you can put in place before you say yes.
Why a store changes your exposure
On a normal WordPress site, the worst outcome of a bad update is usually a broken layout or a contact form that goes quiet. On a store, the same update can stop orders, charge customers twice, send the wrong tax amount to the wrong region or quietly fail to email order confirmations. Some of those reach the client’s customers before anyone at the agency notices.
Three things make stores harder than they look:
- The data never stops changing. Orders, customers and stock levels are written to the database all day. A backup from this morning is already out of date by lunch, and restoring it throws away real orders.
- More moving parts talk to outside services. Payment gateways, shipping rate lookups, tax calculations, inventory sync and email services all depend on accounts, keys and webhooks your team may never have set up.
- Customers carry the damage. A broken blog page annoys a visitor. A failed payment loses a sale and sometimes a customer, and the complaint lands with your client, who passes it to you.
If you already run client work through a structured outsourcing setup, the store sites are the ones where that setup gets tested. Our overview of how agencies outsource WordPress work covers the general arrangement; the rest of this post is about the parts that are different for shops.
The risk register: what actually goes wrong
It helps to write the risks down as a short list per store, with an owner next to each. Here are the ones that come up again and again.
1. Updates that break checkout
WooCommerce itself, the theme, the payment plugin and any checkout add-ons all update on their own schedules. Most of the time they work together. Occasionally a template override in the theme falls behind the plugin, or an add-on that changes the checkout fields stops working with a newer version. The front of the shop looks fine; the order button does nothing.
What to agree: updates on a store are tested on a staging copy first, and someone places a test order end to end before the change goes live. If the client does not have staging, that is the first thing to fix. Our sibling post on a staging and approval routine for client sites goes into the detail.
2. Restores that wipe out orders
The instinct when something breaks is to roll back. On a store, rolling the database back to last night’s copy deletes every order, customer account and stock change since then. Some of those customers have already paid.
What to agree: a written rule that the database on a live store is never restored wholesale without the client’s explicit approval, and that file-level rollbacks are tried first. Agree too who takes backups, how often, and where they are stored, because the answer on a store is different from a brochure site. The post on who is responsible for client backups has wording you can adapt.
3. Payment gateway accounts nobody can reach
The site connects to a gateway with keys from an account that belongs to the client, or to a former staff member, or to the developer who built the shop. When the gateway asks for a new verification step or rotates its keys, nobody at the agency can log in, and payments stop until the right person is found.
What to agree: the client owns the gateway account in their own business name, the agency has a separate user if the gateway allows it, and the login details are recorded in the client’s password manager rather than in someone’s inbox.
4. Tax and shipping settings that drift
A client adds a new product range, a new shipping zone or starts selling to a new region, and changes a setting themselves. The numbers at checkout are then wrong in a way that nobody notices for weeks. When it surfaces, the question is whether the agency was supposed to be checking.
What to agree: tax and shipping rules are the client’s business decisions. The agency configures what it is told, in writing, and does not advise on what the client owes. If a US client asks you whether they should be charging sales tax in a particular state, the honest answer is that it is a question for their accountant, not their web team.
5. Security incidents with card data in the picture
Most WooCommerce stores send customers to the gateway’s own hosted fields or page, so the card number never touches the server. That is a good setup, and it is worth checking each store actually uses it. But an attacker who gets into the site can still inject a script into the checkout page that copies what customers type. That kind of incident is far more serious than a defaced homepage, and it may carry notification duties for your client.
What to agree: who monitors the store for unexpected file changes, who is called first if something looks wrong, and that the agency does not decide on its own what to tell the client’s customers. If it happens, specialist cleanup is the right call; see the page on repairing a compromised WooCommerce store for what that work involves.
6. Performance under load
A sale, a newsletter or a social post sends more visitors than usual, and the cheap hosting plan the client picked years ago cannot cope. Cart pages are hard to cache, so stores feel this sooner than other sites.
What to agree: the client tells you before a planned promotion, and you are clear in writing that hosting capacity is something they choose and pay for.
Questions to ask before you take on a store
Whether it is a new build or an existing shop a client wants you to look after, these questions are worth asking in the first call. The answers tell you how much risk you are inheriting.
- Which payment gateway does the store use, and whose name is the account in?
- Does checkout use hosted payment fields or a redirect, or does the site handle card details directly?
- Which plugins touch checkout, cart, pricing, subscriptions or stock?
- Is there a staging copy of the store, and does it have test-mode payment keys?
- How are backups taken now, how often, and has anyone ever restored one?
- What other systems does the store sync with: accounting, warehouse, marketplaces, email marketing?
- Who on the client’s side changes products, prices, tax or shipping settings?
- When is the store busiest, and are there any dates when nothing should be touched?
- Has the store ever had a security problem, and what was done about it?
If the answers to the first four are vague, budget time for an audit before you agree a retainer. The sibling post on auditing an existing client site before you promise anything lays out how to run one.
Contract and scope wording that protects you
You do not need a separate contract for stores, but you do need a few lines that a brochure site agreement would not carry. These are plain-language examples, not legal wording, and they should go past whoever reviews your contracts.
- “We test plugin and theme updates on a staging copy before applying them to the live store. The client agrees that updates will not be applied directly to the live store except for urgent security fixes.”
- “We will not restore the live store’s database to an earlier copy without the client’s written approval, because doing so removes orders placed since that copy was taken.”
- “Tax rates, shipping rules and product pricing are set by the client. We configure them as instructed and do not give tax advice.”
- “The payment gateway account is owned and managed by the client. We need user access to it for troubleshooting.”
- “The client will let us know in advance of any planned sale or campaign expected to bring unusual traffic.”
Each one answers a question that otherwise gets argued about after something has gone wrong.
Day-to-day habits for store retainers
Paperwork only helps if the routine behind it matches. A few habits make store work much calmer.
Place a real test order on a schedule
Not just after updates. A periodic test order through the live checkout, using a low-value product or a gateway test mode where the client permits it, catches problems with emails, webhooks and stock that no monitoring tool will see.
Watch the order emails, not only the site
Order confirmation emails failing is one of the quietest store problems. The site works, payments go through, and customers start writing in asking whether their order was received. A periodic check that confirmation and admin emails are arriving is cheap insurance.
Avoid the busy hours
Ask the client when they sell most and keep changes away from those windows. With a team working across a large time difference, that often works in your favour: changes can happen while the client’s customers are asleep, as long as someone checks the result before the morning rush.
Keep a store-specific note for each client
Gateway, test keys location, checkout plugins, known quirks, who to call at the client. When a problem arrives, the person handling it should not have to rediscover any of that. A short record like this belongs in the wider site notes covered in the post on keeping runbooks for every client site.
Telling the client what you will and will not cover
Stores make clients nervous in a way brochure sites do not, which is fair: their income runs through it. The most useful thing you can do early is tell them, plainly, where the edges of your responsibility sit. A short email at the start of the relationship works better than a clause they never read.
Something like: “Here is how we look after the store. We test updates on a copy before they reach the live shop, we place test orders to make sure checkout still works, and we keep an eye on order emails. Tax, shipping rates and prices are your decisions, and the payment gateway account stays in your name. If something does go wrong with checkout, contact us straight away and we will treat it as urgent. Please let us know ahead of any big sale so we can avoid making changes that week.”
That email sets expectations, gives the client something to point to later, and shows that you have thought about their business rather than only their website.
If you hand store work to a partner
Everything above applies with one more layer: the partner needs to know the rules you have agreed with the client. Pass on the no-database-restore rule, the busy hours, the test order process and who at the agency approves changes. Ask the partner to confirm in writing which store they are touching and what they changed after each job, and check that their notes match what you agreed with the client.
If you would rather have a team that already works this way look after the stores in your portfolio under your name, our white label WooCommerce support for agencies page explains how we handle it.
Next in this series: Client Asks If Their Site Is ADA Compliant: What to Say
