When Your Storix Store Breaks: The First Hour

An incident is the moment money or trust is bleeding: payments failing for every buyer, a wave of fake cash-on-delivery orders, or a sign your customer list has leaked.

Panic makes people fix the wrong thing. Good response is mostly sequence: confirm, contain, tell the buyers, then learn. Print it for whoever is on shift when something breaks, because the first hour decides how much it costs you.

Minutes 1 to 5: confirm it

• Test from a second phone on mobile data, not office Wi-Fi. One device failing is not an outage.
• Open the order timeline and the shipment events. On the affected order, the timeline and the shipment's event feed show what Storix actually did and when — confirmation, shipment creation, courier events. Activity log and Audit log are coming soon during the pilot.
• Check the notifications the order already sent. Order confirmations and COD confirmation requests are recorded on the order, so you can tell a buyer exactly what reached them and when.
• Name it in one sentence — "card payments have failed for every customer since 2pm" — and give it one owner who decides and speaks.

Minutes 5 to 30: contain it

1. Switch off the failing payment method. Leave cash on delivery running so orders keep coming.
2. Slow a flood of fake orders. There is no "stop new orders" switch. In Customers → Customer restrictions, use Payment caps → Add rule: pick the method, count by Phone, Email or IP address, set Window (minutes) 1 to 10080 and Max attempts 1 to 10000. Refused attempts count too. Blocklist → Add to blocklist handles one phone, email or IP.
3. Two traps there. A number with country code 20 and the same number with a leading 0 count as two phones. And Checkout verification is only recorded today — checkout does not ask for or skip a phone code because of it.
4. Kill leaked credentials. An API key cannot be rotated: in Integrations → API keys click Revoke (it stops at the next call, and cannot be undone), then create a new key. A webhook secret is different — Rotate signing secret replaces it, and the old one dies instantly, including deliveries waiting to retry.
5. Get two-factor authentication on. You cannot turn it on for staff: ask each person to open their own My account page, then check that they did.
6. Keep refunds two-handed. Storix requires it: whoever requests a refund cannot mark it sent.
7. Undo the bad change. If the logs point to a setting someone flipped, flip it back and note the time.

Within the hour: tell the buyers

Silence is worse than the incident: buyers fill the gap with worse assumptions.

• Message only the buyers actually affected. Name the problem, what you are doing, and when you will update them.
• Never hide a double charge or a delay. Say the amount in EGP and a date you can keep. On a cash-on-delivery order you refund the money yourself — Bank transfer (IBAN), Vodafone Cash, InstaPay or Orange Cash — then confirm it on the order.
• If data may have leaked, say what and to whom, and keep one story: what you post publicly must match what you told buyers privately.

The same day: half a page

No blame, just facts: what happened and when, from the order timeline and shipment events; the root cause in one line, such as "a webhook secret was shared publicly"; and one fix, with an owner and a date.

Prepare before you need it

Add one velocity cap today, and walk one healthy order end to end while nothing is wrong, so you know what normal looks like.

Storix keeps the order timeline, velocity caps and two-person refund approval this runbook depends on; the Activity log and Audit log are coming soon during the pilot. Start your store.

This is general operational guidance, not legal advice. If customer data has genuinely leaked, ask a lawyer what you must report.

Related lessons

• Account security and two-factor authentication
• API keys and webhooks