Retail Apps During a Cyberattack: What Should Still Work?
Plan which retail app features remain usable during an outage, how to label uncertain orders, and how customers can safely check status or recover.
A retail app does not have to offer every feature during a cyberattack or a service disruption. It does need to make clear what is available, what cannot be confirmed, and what customers should do next. Reports of an attack and a gradual return of online ordering make this a practical product-design question, not just an infrastructure concern. The app may be reachable while checkout, inventory, payment confirmation or fulfilment systems are not. Retail leaders should decide in advance which functions can safely continue, which must pause, and how order status and recovery options will be presented without implying certainty the systems cannot provide.
Choose functions by safety, dependency and customer value
Start with a dependency map, not a feature list. For each app journey, identify the services and data it relies on: identity, product catalogue, pricing, inventory, basket, payment, order management, fulfilment and customer support. Then classify each function as safe to continue, read-only with a freshness warning, or unavailable until a required dependency is restored. Product browsing may use a cached catalogue, for example, but the app must not present old stock or prices as confirmed. Account access or saved details should remain available only if the supporting identity and data services are considered trustworthy.
Apply a higher bar to actions that create commitments or expose sensitive information. If the app cannot reliably establish whether an order was accepted, it should not invite customers to submit the same order again. If payment or order systems are unavailable, disable the affected action and explain why rather than silently accepting a request that cannot be processed. A useful decision test is: can the app verify the action, preserve its integrity, and show a dependable result? If any answer is no, make the function read-only or pause it. This approach gives engineering and operations a shared basis for graceful degradation.
- Inventory every app function and its upstream dependencies; mark each safe, read-only with a timestamp, or paused.
- Define explicit stop conditions for checkout, account changes and other actions that cannot be verified end to end.
Make order status truthful, specific and time-aware
During an outage, customers need to distinguish between a request that was never sent, one that is still being processed, and one that the retailer has confirmed. Use named states with operational meaning, such as “Order received,” “Confirmation pending,” “Confirmed,” and “Action required.” Do not label an order “failed” merely because the app timed out: the backend may have accepted it. Conversely, do not show “confirmed” based only on a local button tap. Status should come from the system of record that owns the order, with a time of last update when information may be delayed.
Give each status a clear next step and explain what it means in plain language. “Confirmation pending” should tell customers not to place another order yet, identify when to check again if that interval is known, and provide an accessible support route. If a confirmed order cannot be changed or cancelled during the disruption, say so and describe how to request help. Use in-app notices and relevant push messages to point back to the order detail page, rather than sending a notification that lacks context. Keep messages consistent across app, website and support channels, so customers do not receive conflicting explanations.
- Show the status source or last-updated time when data may be stale; distinguish “not confirmed” from “not placed.”
- Avoid automatic retry of purchase requests unless the operation is designed to prevent duplicate orders.
Design recovery before restoring every feature
Recovery is a sequence of controlled capabilities, not a single “back online” switch. Establish who can declare a service available, what checks must pass, and how teams will monitor order creation, confirmation and fulfilment after restoration. Reconcile requests made around the outage against the authoritative order and payment records before encouraging customers to retry. If an order’s outcome remains uncertain, route it to a defined review or support process. A customer-facing recovery notice should state which functions have returned, whether any orders need attention, and where to find current status; avoid promising that all data is complete until it has been checked.
Test the degraded and recovery journeys before an incident. Include interrupted checkout, delayed confirmation, stale catalogue data, duplicate taps, app restarts, expired sessions and a customer returning through a notification. Verify that error states preserve useful information without exposing data, that support teams can see the same status as customers, and that changes to order state are auditable. A hypothetical acceptance test could submit a checkout request, interrupt the response, then reopen the app: it should show an uncertain state, avoid creating a second order on retry, and update only when the order service confirms the result. That test turns a continuity principle into a release criterion.
- Agree restoration gates with engineering, security, retail operations and customer support, including an owner for unresolved orders.
- Exercise outage-to-recovery tests and document customer messages for each status transition.
Retail continuity is not a promise that every app function will survive an attack. It is a deliberate boundary between actions the business can verify and actions it must pause, supported by understandable status and safe recovery paths. Map dependencies, define the states customers will see, and test ambiguous outcomes such as a timed-out checkout before launch. These decisions belong in product requirements and operational runbooks together. When an outage occurs, the app can then remain useful without guessing whether an order succeeded or asking customers to take a risky second action.