Customers do not see integrations. They see a confirmation email that never arrived, a delivery date that changed twice, a statement that disagrees with their own records, or a polite reminder to pay an invoice they settled last week. To them, these are failures of the business. The fact that they began as a rejected message between two systems, three days earlier, is invisible and irrelevant to the person on the receiving end.
For the business, though, that invisibility is the problem. Integration errors tend to be discovered at the customer's end, by the customer, and traced back only after a complaint has been escalated. This article follows five common integration failures from the point where they begin to the point where a customer notices, and then describes how to shorten that journey so the business finds the fault first.
Why customers feel integration errors first
Inside a business, an integration error usually looks like a small thing: a record that did not transfer, a message that was refused, a field that arrived empty. Nothing crashes. The receiving system simply works with what it has, which is less than it should have. Because the failure is quiet, nobody inside the business has a reason to look at it.
The customer, by contrast, is the one person who compares what the business says with what actually happened. They compare the order confirmation with the delivery, the quote with the invoice, the statement with their bank. Any disagreement between two of your systems becomes visible at that moment. In effect the customer becomes the monitoring system, and they are a poor one: they notice late and they do not report faults politely.
Five patterns, from error to complaint
1. The message that never arrived
What happens inside: a new order, booking or application is rejected by the receiving system because a required value is missing or malformed, and the rejection is logged but not reported.
What the customer sees: silence. They placed an order and heard nothing, or booked a service and nobody turned up. The first contact from the business is often an apology. The problem of failed messages going unnoticed is explored in why failed integration messages sit unnoticed.
2. The message that arrived twice
What happens inside: a connection times out, the sender is unsure whether the message was received, and sends it again. The receiver processes both.
What the customer sees: two deliveries, two invoices or two charges. Microsoft's description of the idempotent consumer pattern explains why this happens: most message brokers guarantee at-least-once delivery, which means the same message can legitimately be delivered more than once, and it is impractical to guarantee exactly-once delivery across a distributed system. The durable solution, it says, is not to eliminate duplicates but to make the receiver process them correctly. It lists the effects of failing to do so as duplicate records, double-charging a customer and other unwanted effects. The related article on how to design retries without creating duplicate work goes into detail.
3. The message that arrived late
What happens inside: a batch run is delayed, or a queue backs up, and a change reaches the receiving system hours after it should have.
What the customer sees: out-of-date promises. An item shown as in stock has already sold, or a payment made in the morning still triggers an overdue reminder in the afternoon. See why paying customers still get overdue invoice reminders and online channels selling stock the warehouse no longer has.
4. The message that arrived wrong
What happens inside: a field is mapped to the wrong place, a unit or currency is misread, or a status is interpreted differently by the two systems. Nothing is rejected; the wrong value is simply accepted.
What the customer sees: a wrong price, address or quantity. This is the most damaging pattern because nothing flags it. The wrong data looks like right data until a person compares it with the original.
5. The process that stopped halfway
What happens inside: a business operation spans several steps in several systems, such as reserve stock, take payment, create the shipment, and one of the later steps fails after earlier ones have succeeded.
What the customer sees: a charge with no order, or an order that cannot be fulfilled. Microsoft's compensating transaction pattern addresses exactly this case. It notes that in a multi-step operation spread across systems, a failure part-way through may require undoing the work from the completed steps, that this logic is specific to the application, and that some steps cannot be reversed at all. It recommends defining the points of no return and arranging for a human to decide in ambiguous or high-impact cases. For a business, the practical question is: for each multi-step process, who finds out when it stops partway, and what is the agreed way to put it right?
Close the gap between failure and discovery
The aim is for the business to learn about each of these failures before the customer does. Four practices make the biggest difference.
- Check outcomes, not only errors. Technical monitoring asks whether a connection is up. Customer-protecting monitoring asks whether the thing that should have happened did happen: orders received equal orders acknowledged, payments received equal statuses updated. This gap is described in why integration monitoring misses business completion.
- Give every record a stable identity. A reference that survives retries lets the receiving system recognise a repeat. Stripe's documentation on idempotent requests describes the idea: the caller supplies a unique key, the server saves the result of the first request made with that key, and any repeat with the same key returns the same result, so a connection error can be retried without performing the operation twice. You do not need Stripe to apply the principle. An order number checked before creating an order does the same job.
- Reconcile regularly. A daily or weekly comparison between two systems, such as orders placed against orders in fulfilment, catches the wrong-data and late-data patterns that error handling cannot see.
- Treat the first customer complaint as evidence. A complaint about a duplicate or a missing confirmation is rarely a one-off. Ask how many other customers were affected, and look back through the same period.
The effect of silent failures on operations more broadly is the subject of how silent automation failures damage operations.
Prepare what staff say and do
Even with good monitoring, some errors will reach customers. The difference between a minor irritation and lost trust is often how fast and how clearly the business responds. A short, written response plan helps.
- Give front-line staff a way to flag "possible system fault" and route it to a named person, not a general mailbox.
- Provide a plain-language script: what to tell the customer, what to promise and what not to.
- Decide in advance who may issue a credit, cancel a duplicate or reissue a document.
- Record each incident in one place with its cause, so repeated causes become visible.
Customers who are asked to repeat their details after a system fault are especially frustrated, which is why why customers are asked to repeat their details is worth reading alongside this.
An illustrative example
Consider a hypothetical Johannesburg medical-equipment supplier. Customers began complaining about duplicate invoices. The cause was a timeout between the order system and the accounts package: on slow afternoons the order system gave up waiting, resent the order and the accounts package created a second invoice. Credits were issued by hand each month. A fix needed only two changes. The order number became a unique check in the accounts package, so a repeat was ignored, and a daily report compared orders sent with invoices created and flagged any mismatch to the accounts supervisor by ten each morning. Complaints about duplicates stopped, and the monthly credit-note clean-up disappeared.
The shift in mindset
If customers are your first alarm, your integrations are effectively unmonitored. Moving the alarm earlier does not require expensive tools. It requires choosing the customer-visible outcomes that matter most, checking them automatically, and agreeing in advance who acts when a check fails.
Sources and further reading
- Idempotent Consumer Pattern - Azure Architecture Center (last verified 10 October 2026)
- Idempotent requests - Stripe API Reference (last verified 10 October 2026)
- Compensating Transaction Pattern - Azure Architecture Center (last verified 10 October 2026)
Related Mellorca reading
- What to Check Before Rebuilding a Broken Integration
- How to Handle Failed Integrations Without Losing Work
- When an Integration Platform Makes Sense—and When It Does Not