A maintenance window over the weekend, a release change that takes longer than planned, an incident in the provider's data centre: the leading ERP goes down, and in many integrations the shop goes down with it. That is not a law of nature but a default that emerges when every stock, price and credit enquiry is served synchronously from the ERP and any missing answer is treated as an error. The cost is measurable: 57 percent (Uptime Institute, 2026) of the operators surveyed put their last major outage at more than 100,000 US dollars, one in five at over a million. For retail and wholesale there is an added factor, because the online channel carries a firm share of revenue: online accounts for 13.5 percent of total retail revenue (HDE Online-Monitor 2026). This article describes neither a retry pattern nor a monitoring strategy, but the operating concept for the emergency: what the middleware keeps on hand, which decisions it makes on its own without an ERP answer, and how the restart runs so that nobody has to clean up by hand afterwards.
Key takeaways
- Fallback mode does not begin with the incident but long before it. The middleware holds the last valid state of stock, prices, customer terms and credit limits, and marks every value with an age stamp so that shop and customer know how fresh the information is.
- Availability is calculated conservatively during the blind phase. A safety margin on the last known stock level costs a few orders; overselling costs trust and rework. For context, the average cart abandonment rate already sits at around 70 percent (Baymard Institute).
- Orders are accepted and buffered, not rejected. Commercially the shop responds with a confirmation subject to availability; technically a disrupted interface signals the state with 503 Service Unavailable and a Retry-After header (RFC 9110).
- The restart needs ordering and duplicate protection: orders per customer in the sequence they arrived, idempotency keys against double posting, and afterwards a reconciliation of the differences between mirror and ERP.
- Defining RTO and RPO per data type makes fallback mode measurable. BSI Standard 200-4 supplies the key figures from the business impact analysis, including the minimum business continuity objective MBCO as a deliberately reduced level of service (BSI Standard 200-4).
What an ERP outage really costs a shop
The bill arrives in three parts, and the most visible part is rarely the largest. First there is the revenue from the hours in which nobody could order. Then comes the rework: enquiries arriving by phone and email, orders keyed in by hand, stock corrections and credit notes. Last comes the loss of trust among regular customers who, in B2B, have wired their procurement to your channel. The order of magnitude is considerable: in the current survey, 57 percent (Uptime Institute, 2026) of respondents put their last major outage above 100,000 US dollars, and one in five above a million US dollars. In German B2B commerce this meets a market that reached around 509 billion euros in 2024 and grew by 7 percent (ECC Köln) - downtime here hits volume that cannot simply be made up later.
What is striking is how much of this is organisational. Around 60 percent (Uptime Institute, 2019) of respondents believed that their most recent significant downtime incident could have been prevented with better management, processes or configuration. Applied to interface integration, this means the difference between a shop that stands still during an eight-hour maintenance window and one that keeps selling rarely lies in the technology. It lies in whether someone decided beforehand what should happen without an ERP answer. Anyone who does not make that decision leaves it to the default behaviour of the library that executes the call - and that default reads: throw an exception, abort the page.
The blind phase: what the shop still knows without the ERP
We call the blind phase the period between the loss of ERP responses and the confirmed restart. What matters is what is available locally during that time. In a directly coupled architecture the answer is sobering: almost nothing, because every piece of information is passed straight through. In an architecture with middleware, by contrast, there is a complete mirror of the sales-relevant data, maintained anyway for caching and load distribution. A missing mirror is more often a data problem than a technical one: 60 percent (Bitkom) of companies say they exploit the potential of their own data only to a small extent or not at all. If you run several company codes, the mirror should be separated per entity - which is where the article on several ERP entities on one shop comes in, because otherwise the terms of the wrong entity apply in fallback mode. The same rule holds for inventory management integration as for any large ERP.
Stock levels
Last confirmed stock per article and warehouse, plus a timestamp and a safety margin for the duration of the blind phase.
Prices and terms
Mirrored customer price lists, tiers and discounts. They change less often than stock and therefore age more slowly.
Credit limits
Limit, open items and payment terms from the last successful retrieval, deliberately set conservatively rather than generously.
Tax codes
Last confirmed code per customer and delivery country, including the validated VAT ID with its check date.
Order buffer
Durable queue for accepted orders, with arrival sequence, customer reference and an idempotency key.
Status information
Last known order and delivery status, visible in the customer account as a state from a stated point in time.
Last valid values with an age stamp instead of empty fields
A cached value without an age marker is more dangerous in fallback mode than no value at all, because it feigns currency. Every mirrored record therefore gets two additional fields: the time of the last confirmation by the ERP and the source of that confirmation. From both, the shop can form an understandable statement, for example that the stock level dates from this morning. That is more honest than a number without context and, in our experience, better than an error message. What matters is the grading by data type: a price that has not been confirmed for four hours is usually uncritical, a stock level of the same age is not. How far stock levels drift apart depends on the warehouse structure; the article on inventory synchronisation across several warehouses describes the mechanics in normal operation, which in fallback mode only runs one way.
Show the age, do not hide it
check ERP health every 15 seconds
if 3 checks in a row fail:
mode = FALLBACK, record start time
stock = last valid value minus safety margin
price = last valid value, show age in the shop
credit = conservative rule from the mirror
order = accept, put in queue, status "handover pending"
if 5 checks in a row succeed:
mode = RESTART
replay queue per customer in arrival sequence
send an idempotency key with every order
start reconciliation: stock, price, credit limit, tax code
mode = NORMAL, log duration and follow-upSafety margin on availability
During the blind phase the shop sells against a frozen stock level. Every order reduces the mirrored value, but goods receipts, transfers and orders from other channels remain invisible. A margin on the displayed quantity therefore belongs in the design, and its size depends on turnover rate, the length of the blind phase and the number of other sales channels. The effect of such deliberately reduced operating modes is well known from operations: a staged fallback level lifts the availability perceived by the customer above that of the individual services behind it, because the failure of one building block no longer ends the entire purchase. To put the targets in perspective, even 99.9 percent availability allows 8.76 hours of downtime per year in theory (BSI Standard 200-4) - enough for a maintenance window that costs a full selling day without fallback mode.
- Grade the margin by turnover: fast movers get a noticeably higher margin than articles with few movements per week. A flat percentage across the whole assortment gets both groups wrong.
- Let the margin grow over time: after one hour of blind phase the mirror is still reliable, after eight hours it is not. A margin that rises with the age of the value reflects that without anyone intervening.
- Convert pack sizes cleanly: a margin applied to the wrong unit of measure looks arbitrary. How sales, storage and order units relate to each other is covered in the article on units of measure and pack sizes.
- Set a lower bound: below a residual quantity, the article is switched to enquiry-only in fallback mode instead of being freely orderable. That protects exactly the positions where overselling causes the most trouble.
Credit limit and tax determination without an ERP answer
Two checks in the B2B checkout depend particularly closely on the ERP, and both abort the purchase if nothing is prepared. The first is creditworthiness. Without an answer on limit and open items, purchase on account disappears, and with it, in many assortments, the bulk of revenue. The conservative rule is: purchase on account remains possible as long as the order value does not exceed a threshold derived from the mirror, for example the last known available credit less a buffer and capped at a maximum amount per customer per day. Anything above that is accepted but flagged as requiring approval. The mechanics of the check in normal operation are described in the article on the credit limit check in the B2B checkout; in fallback mode it is not the logic that changes but the data source and the threshold.
The second check is tax determination. Whether a delivery is invoiced with the German tax rate, as an intra-Community supply or under the reverse charge procedure is normally decided by the ERP based on customer master data, delivery country and validated VAT ID. If that answer is missing, the reliable fallback is the last confirmed code per customer and delivery country together with its check date. If the current order deviates from it - a different delivery country, a new delivery address, a first-time order - the order is accepted and flagged for commercial review instead of inventing a tax decision. The details of determination are covered in the article on tax determination in the B2B shop. For fallback mode, what counts above all is that the invoice is only generated after the restart.
| Situation in the checkout | Hard ERP dependency | Fallback rule |
|---|---|---|
| Stock display | Error message or empty field | Last value with age and margin |
| Price determination | Cart calculation aborts | Mirrored customer price list |
| Credit limit | Purchase on account unavailable | Approval up to the conservative threshold |
| Tax code | Checkout aborts | Last confirmed code per customer |
| Order acceptance | Order is rejected | Acceptance with a confirmation subject to review |
| After the incident | Customer reorders or does not | Queue replays in an orderly way |
Accept and buffer orders instead of rejecting them
The queue is the heart of fallback mode. An accepted order is stored durably before the customer sees the confirmation page - not in memory and not in a process that disappears on the next restart. Every entry carries the time of arrival, the customer reference, a business idempotency key and the data state on which it was based. Technically, the incident calls for the right answer to the outside world: 503 Service Unavailable with Retry-After for calling systems, while the customer in the browser sees a normal confirmation page (RFC 9110). How a queue is properly safeguarded, which error classes exist and when a message belongs in the dead letter queue is covered in detail in the article on error handling in interfaces.
Just as important as the technology is the wording of the order confirmation. It should confirm the order but explicitly reserve confirmation of availability and name a point in time at which the final confirmation will follow. Formulations such as "your order has been received and will be confirmed once availability has been checked" are commercially sound and avoid promises the operation cannot keep later. Binding delivery dates do not belong in that email at this stage. That the effort pays off is shown by buying behaviour: for 53 percent (Bitkom) of customers, shipping and delivery are among the decisive criteria when choosing a shop. Anyone who provides for this phase properly in API development saves case-by-case clarification later on.
The restart: ordering, duplicate protection, reconciliation
The restart is where most fallback concepts fail, because in the calm of planning it looks harmless. Three rules decide the outcome. First, ordering: orders from the same customer must be handed over in the sequence in which they arrived, otherwise credit limits and number ranges are applied in the wrong order. Second, throttling: an ERP that has only just come back up cannot take a burst of several thousand orders. Third, duplicate protection. A timeout does not tell you whether the ERP created the order; a substantial share of failures in service-oriented architectures is transient and therefore repeatable - but only if the receiver is idempotent. The patterns for this are described in the article on idempotency and retry strategies.
After the replay comes reconciliation, and it is not a formality. Mirror and ERP are compared for stock, prices, credit limits and order status; every deviation is logged and assigned to an owner. Typical findings are articles whose stock was sold in another channel during the blind phase, price changes that were maintained in the ERP but not transferred, and orders that look like duplicates but carry different idempotency keys. At the end there is a report with the duration of the blind phase, the number of buffered orders, the number of deviations and the time to complete reconciliation. How to make these figures permanently visible is covered in the article on observability for interfaces. Because Gartner expected around 80 percent (Gartner 2020) of B2B buying interactions to take place in digital channels by 2025, the status channel to the customer is part of the restart and not an appendix to it.
Fallback mode is a decision, not an accident
Shop announcements and plannable maintenance windows
A planned maintenance window is the easier case, because everything can be prepared. The mirror is refreshed shortly before it starts, the fallback switch is set by hand instead of via the health check, and the notice text is already in the shop. Three-stage communication has proven itself: an announcement in the customer account a few days beforehand, an unobtrusive banner during the window with the start and expected end, and a short message after reconciliation to every customer whose order was buffered. The text should describe what still works, not what is missing. The same sequence applies to unplanned incidents, with an automatic trigger. If the middleware sets the mode itself, it should also leave it itself - but only after several successful checks in a row, so that a briefly flickering ERP does not switch back and forth between operating modes.
RTO, RPO and the emergency drill for the interface
- Name the critical data types: assess stock, price, credit limit, tax code and order status individually. Each data type gets its own tolerable outage time, because an old price weighs differently from an old stock level.
- Define RTO and RPO: the required recovery time and the maximum tolerable data loss per data type are the central key figures from the business impact analysis (BSI Standard 200-4). Without them, fallback mode remains a matter of taste.
- Describe the fallback service level: what the shop should deliver in fallback mode is the MBCO (BSI Standard 200-4) - for example catalogue, cart and order acceptance, but no live availability and no immediate invoice.
- Build the mirror and the queue: extend the existing transfer with durable storage, age stamps and idempotency keys. As a rule this is an extension of API development and not a new system.
- Automate the restart: define replay, throttling, duplicate protection and reconciliation as a documented flow, so that the restart does not depend on individual people being present.
- Drill regularly: two exercises a year are usually enough: one announced during a maintenance window, one unannounced in the test environment. We include the drill in the free system analysis and record duration, buffer volume and deviations.
An unrehearsed fallback mode is an assumption. Only the drill shows whether the mirror is complete and the restart works without anyone calling out instructions.
Sources and Studies