For a store operator without a developer: describe the fault so it can be fixed on a copy

Tell us where the order or the money stops

A store has a chain: the shopper finds a product, chooses an option, gets a shipping method, applies a discount, pays, the payment is confirmed, an order appears, an email goes out, and another system hears about it. A fault is one link in that chain. Saying where it stops is the most useful thing you can send: no shipping for one country, a code refused, a payment taken but the order unpaid, renewals late, an order that never reached the warehouse system. Those are different faults with different fixes.

• Name the platform and the link that breaks.
• Give two or three redacted examples with order numbers, not customer details.
• Say what changed just before it began.

Keep a copy, a test route and a baseline

Nothing should be tried on live orders. A copy of the store, payments in test mode, customer email turned off, and a short list of the journeys that must work are the three things that make a fix safe and checkable. If you do not have a copy, your host or platform support can usually say how to make one; if the platform has a development store, that is a safe place to prove a repair.

• Never send logins, payment keys or customer records in a first message.
• Write the expected result for each journey before anything is tested.

Choosing between a single fix, a standing check and a recovery

If one link is broken and everything else works, a single bounded fix is the right size. If you keep updating plugins or running a sync and are afraid of the next break, a standing check either tests your checkout journeys on a copy before your monthly update window or compares your orders and stock every week and explains up to two separate causes of any gap a month. Repairs stay separate jobs. If several links broke after one event and fixing one reveals another, a recovery project works through them against a checklist until the whole journey passes. Prices on our pages are published test prices that nobody has yet responded to, and payment follows agreed checks and your sign-off.

What to expect from the first reply

You should get a plain statement of whether the problem fits a fixed job, what is needed before any access, what a staging test will show and which parts only you or your host can change. We say when a cause sits with a payment provider, a host or a vendor, because no fixed job can fix those. Nothing starts before scope, price and terms are agreed in writing.