The order timed out. Did the ERP receive it?
A timeout leaves a business question unanswered. Follow an order across commerce and ERP to see why reconciliation, clear states, and careful recovery matter more than a quick retry.
Consider a purchasing manager placing a routine replenishment order. In this hypothetical example, the storefront waits and an error appears. The buyer sees a failure. Somewhere behind the storefront, however, the ERP may still be processing the request. It may already have created the order. The distinction between what the buyer sees and what the ERP did is central to enterprise commerce.
A timeout tells one system that it did not receive an answer within the time allowed. It does not establish what happened in the other system. Treating those two statements as equivalent can turn a recoverable interruption into duplicate demand, a premature cancellation, or a confusing conversation with customer service.
The useful question is no longer simply whether an API call succeeded. It is whether the business can determine the order’s state and choose a next step with confidence. That question shaped a recent GCG assessment of commerce and ERP resilience. The architecture discussed here is design guidance; the assessment did not establish a deployed solution.
Two systems can tell different parts of the truth
The storefront may know that the buyer submitted an order and that an outbound request began. The ERP may know that an order was created. Between those facts sits an acknowledgement that could arrive late, be lost, or fail to reach the component waiting for it.
This is why a single status such as ‘Failed’ often carries too little meaning. Was the request rejected before processing? Did validation fail with a clear business message? Or did the connection end while the result remained unknown? Each condition calls for a different response.
A useful operating model separates the commerce order from its integration attempts. The order preserves the buyer’s intent and the information needed to support it. Each attempt records what was sent, when it was sent, and what evidence came back. A later successful reconciliation should clarify the order’s state without erasing the earlier interruption. Customer service needs the current answer; technical teams also need the path that led there.
Find the first order before creating another
Imagine the ERP created an order but its acknowledgement never reached commerce. Sending the same request again may create another order unless the receiving system can recognize it as the same business operation. A fast retry can therefore make the situation harder to resolve.
Recovery starts with a stable reference that can be carried across the integration. Where the ERP provides a suitable lookup, the integration can use that reference to investigate whether the order already exists. The matching rule must be deliberate: a loose match on customer and total is rarely enough to distinguish two legitimate purchases.
Duplicate protection and reconciliation solve related but different problems. Duplicate protection helps repeated submissions represent one intended operation. Reconciliation compares evidence across systems and resolves disagreement. Neither should be assumed merely because a queue or retry library is present. The integration design needs to establish what each platform supports, which system owns the reference, and how ambiguous results reach a person who can investigate.
A queue changes the conversation with the buyer
Moving ERP work behind a queue can separate the customer’s immediate acknowledgement from downstream processing. The storefront can confirm that it received the request while the integration continues. That can be a useful design, but it creates an obligation to explain what the acknowledgement means.
‘We received your order request’ and ‘Your order is confirmed in our order management system’ are different promises. The experience should use language that reflects the actual process, including any credit, pricing, availability, or approval checks that remain.
The operational work continues after the customer leaves the page. Someone needs to own pending requests, delayed acknowledgements, and exceptions that exceed the recovery window. Retry rules should account for transient interruptions, business rejections, and unknown outcomes separately. Queuing is therefore as much a service design decision as an infrastructure decision: it changes when the business makes a promise and how that promise is followed through.
Order SAMPLE-01
Current business state
Awaiting ERP confirmationAttempt evidence
- Separate the states
The commerce order exists while the ERP outcome remains unknown. - Read the evidence
A sent request and a missing acknowledgement do not establish a rejection. - Reconcile first
Look up the original reference before deciding whether another attempt is appropriate.
Read the evidence before reaching for Retry
Start with Order SAMPLE-01. Its status says “Awaiting ERP confirmation”, and the three evidence rows explain why: the request was sent, the acknowledgement was not received, and the ERP record has not been checked. That last row is the next piece of work. The sketch gives “Look up original reference” priority and holds back “Retry after reconciliation”. Notice how little the operator needs to infer. The screen does not turn a missing answer into a failed order. It points toward the missing evidence before offering another submission, which is the distinction to carry into an actual recovery design.
Give recovery a clear destination
An effective recovery screen answers a small set of connected questions: what did the buyer request, what did commerce record, what evidence exists in the ERP, and what action is appropriate now? The operator should not have to reconstruct that story from unrelated log entries.
An unresolved order can be visibly marked as awaiting confirmation, with its latest attempt, age, and investigation context available. A retry action can then be offered only when the workflow permits it. A confirmed business rejection may instead require a correction, while a matching ERP order may require updating commerce rather than sending anything again.
The most revealing design review follows one order through an interrupted acknowledgement. Ask the team to show the buyer’s message, the operator’s view, the evidence used for reconciliation, and the final resolution. If those pieces tell a consistent story, the integration is being designed around the business transaction and the people responsible for completing it.
Further reading: Microsoft’s retry pattern guidance.
Images are original conceptual illustrations, not photographs of a client project.