When Two Suppliers Blame Each Other: Who Is Actually Responsible?

Frequently asked questions

• Why do suppliers blame each other instead of fixing things?

  Usually because each of them can see only their own side of the boundary and each is genuinely correct about it. Your agency can demonstrate that it sent a valid request. The payment provider can demonstrate that it responded correctly to what it received. Both statements can be true while the customer still cannot check out, because the fault lives in the space between the two systems, which neither of them is contracted to examine, monitor or own. Nobody assigned it, so nobody is looking at it.

• Is somebody lying to me?

  Rarely, and assuming so makes the situation worse rather than better. Each supplier is looking at their own logs, which show their own behaviour, and reaching an honest conclusion from incomplete information. Treating it as bad faith puts both parties on the defensive and makes them less willing to share the detail that would actually resolve it. Each of them can see only up to their own edge. Treat it as a visibility problem first, and you get cooperation instead of defensiveness.

• Who is responsible when an integration fails?

  Whoever your contract says, which in most cases is nobody, because the contracts were signed separately and neither mentions the other supplier. That gap is not an accident of bad drafting so much as the normal outcome of buying two things at two different times. That gap is the normal outcome of buying two things at two different times rather than a drafting failure. The practical answer is that you are responsible, because the accountability was never assigned to anybody else.

• How do I break the standoff quickly?

  Get both suppliers into the same conversation at the same time, and insist on evidence rather than assertion. Ask each to show the request they sent and the response they received, with timestamps, for one specific failing transaction. Two accounts of the same event placed side by side usually resolve within an hour what weeks of relayed messages could not, because either one account is wrong or both are right and the boundary is the problem.

• Why does relaying messages between suppliers not work?

  Because you are acting as a translation layer between two technical teams while understanding neither side fully, and detail gets lost at every hop. Each round trip takes a day, and each supplier answers the question they think you asked. Getting both parties in one room removes the translation layer entirely, along with the delay it introduces and the detail it loses. It is the single highest-value hour available to you.

• What if a supplier refuses to join a call with the other?

  Treat that as information and say so plainly. A supplier confident that their side is working has no reason to avoid demonstrating it to a technical audience. Reluctance usually means either that they are less certain than they sounded, or that the conversation would surface something they would rather raise with you privately first. Either possibility is worth knowing about early.

• What evidence should I ask for?

  One specific failing case, identified by a timestamp or a reference number, traced end to end. What was sent, what was received, what was returned, and what the receiving system did with it. Vague statements about things working on their side are not evidence. A request and response pair for one named transaction is evidence, and it is very hard to argue with. Refuse summaries and ask for the actual exchange.

• What if both suppliers produce evidence that they are right?

  Then you have located the problem, which is progress. The fault sits at the boundary, in something neither is examining: a timeout, an encoding difference, a field that means one thing to one system and something else to the other, a retry that arrives twice. Somebody now has to own the space between the two systems, and deciding who is the next thing to settle. That is a commercial conversation rather than a technical one.

• Who should own the boundary?

  Somebody, named, and it matters less who than that the choice is explicit and paid for. Usually it is whichever supplier built the integration, or whichever has the broader view of the system. What does not work is leaving the boundary unassigned and relying on goodwill, because goodwill is plentiful when things are easy and runs out precisely when a problem becomes difficult and expensive.

• Should I appoint one supplier as the lead?

  Where you have several suppliers on one system, yes, and it should be a paid role rather than an assumed one. Nominating a technical lead with responsibility for the whole picture, including other people's parts, gives you a single point of accountability. Expect to pay for the role, because it is genuine work, and expect the arrangement to fail quietly if you do not. Unpaid coordination gets performed badly by whoever is least able to refuse it.

• Does accountability transfer to my suppliers?

  Not entirely, and this is worth understanding rather than resenting. UK national cyber security guidance makes the point directly in a security context: an organisation relying on third parties remains accountable for the protection of its essential functions regardless of who operates them. The same logic holds commercially. Your customers hold you responsible for a checkout that does not work, and they have no relationship with your payment provider and no interest in your contracts.

• What should the contract say to prevent this?

  Name the other suppliers, define whose responsibility the interface between them is, and state what happens when a fault cannot be attributed. Also state who leads investigation and what cooperation each party owes the other. Four clauses, none of them exotic or expensive to draft, and almost never present, because each contract was written as though it were the only agreement you had.

• How do I add this to existing contracts?

  At renewal, or through a short side agreement all parties sign that covers cooperation and escalation only. You will get less than you want and more than you have. All of it is far easier to agree while nothing is currently broken, which is precisely why it is worth raising during a calm period rather than in the middle of an incident when positions have hardened.

• What is a reasonable cooperation clause?

  That each supplier will participate in joint investigation of faults affecting the shared system, provide relevant logs and evidence on request within a stated time, and not withhold cooperation pending resolution of any commercial dispute. That final clause matters more than it appears, because a commercial disagreement is exactly the moment cooperation tends to stop and exactly the moment you most need it to continue.

• Should one supplier be able to see the other's work?

  To the extent needed to investigate faults, yes, and it needs saying explicitly and in writing from you. Suppliers frequently cannot share logs or access because nobody authorised it and they are being careful. A written statement from you authorising them to share diagnostic information with each other for fault investigation removes an obstacle that everybody assumes is contractual when it is simply unaddressed.

• What if the fault is genuinely nobody's?

  It happens more often than people expect, particularly with third-party services outside everyone's control. Somebody still has to fix it, so the question becomes commercial rather than moral: who is best placed, what will it cost, and who pays. Argue about the commercial question instead of about fault, because the fault question can genuinely have no answer while the question of who fixes it always does.

• How much should I be paying for this coordination?

  Something, and most businesses pay nothing and expect it anyway. Coordination between suppliers is real work that somebody performs, and if it is not funded it gets done badly by whoever has the least ability to refuse. Either pay a lead supplier to do it properly, or accept that you are doing it yourself and allocate your own time honestly rather than being surprised by how much it consumes.

• Can I do the coordination myself?

  You can if you have someone with enough technical understanding to tell a real answer from a plausible one. Without that, you become a message relay, which adds delay without adding judgement. If nobody internally can play that role, buy it from a lead supplier or buy it independently. What does not work is leaving the position empty and assuming somebody will step into it.

• Should I bring in an independent third party?

  It is worth considering when the standoff has persisted, because neither supplier can be neutral about whose fault it is. An independent technical review can look at both sides without a commercial interest in the answer. Tell your suppliers openly that you are doing it and why, because surprising people with an auditor rarely improves anybody's willingness to help, and you still need them afterwards.

• How long should I let a standoff run?

  Not more than a week or two before changing the process rather than repeating it. If two rounds of relayed messages have not produced a resolution, a third will not either. Escalate to a joint session with evidence, and if that does not settle it, bring in an independent view. The failure mode in these situations is almost always excessive patience rather than haste.

• Does this only happen with integrations?

  Integrations are where it is most visible, and it happens anywhere responsibility is split. A site that is slow, with a separate hosting provider, developer and content team. An app that crashes, with one team on the front end and another on the backend. Any boundary between two contracts is a place where a fault can sit unclaimed indefinitely, with everybody involved behaving entirely reasonably throughout.

• Is using fewer suppliers the answer?

  Sometimes, and it is a real trade rather than an obvious improvement. One supplier means one point of accountability and less coordination, and it also means more concentration risk and less specialist depth. The better framing is not to minimise the number of suppliers but to make sure every boundary between them has somebody's name written against it in a contract.

• How do I avoid this on a new project?

  Ask at procurement, before signing anything, who owns the interface between this and the systems it must talk to. Ask each candidate supplier how they handle a fault they believe is on somebody else's side. The answers vary enormously between suppliers and are highly predictive of what actually happens later, and it is a question almost no buyer thinks to ask before signing.

• What does a good answer to that question sound like?

  Specific and unenthusiastic. We investigate first and establish what we sent and received, we join a call with the other party, and we keep going until it is attributed even where it turns out not to be ours. A supplier who says faults are always resolved amicably has not thought about it. One who immediately describes the boundary as somebody else's has told you their default.

• Should I test the integration before going live?

  Thoroughly, and specifically test the failure paths rather than only the one where everything works. Most launches exercise the happy path exclusively. What happens when the other system is slow, returns an error, or is unavailable entirely? Most integration disputes concern behaviour under failure rather than under normal conditions, precisely because normal conditions were the only ones anybody exercised before launch.

• What is the most common technical cause?

  Assumptions about the boundary that were never written down. One side expects a field that the other sends only sometimes. One treats a timeout as a failure while the other treats it as pending. One retries and the other processes the retry as a second transaction. None of these is a bug in either system considered alone, which is exactly why each supplier can honestly report that their side is fine.

• How do I document the boundary properly?

  Write down what is exchanged, in what format, what each field means, what happens on each kind of failure, and what the expected timings are. Then have both suppliers confirm it in writing. It is a modest document and it turns a category of dispute into a checkable question, because now there is a shared statement somebody is demonstrably not matching.

• Does this cost me money even when it gets fixed?

  Almost always, and the cost is rarely counted properly. Both suppliers bill for investigation time in parallel on the same problem, your own people spend days coordinating instead of working, and the fault persists for customers throughout. That total is usually considerably larger than what it would have cost to assign the boundary properly at the outset, which is the whole argument for assigning it at the outset.

• Can you help resolve a standoff?

  We can act as the independent technical view, which means looking at both sides of the boundary without a commercial interest in the answer and telling you plainly where the fault sits. That starts from around AED 4,000 with us and produces a written finding both suppliers can see. Final pricing depends on scope, and these are our own figures rather than a market survey.

• What should I do today if I am in one?

  Put both suppliers on one call this week and ask each to walk through a single named failing transaction, showing what they sent and what they received. Do not accept summaries. That one session, with actual evidence in front of everybody at once, resolves a large share of these standoffs outright and reveals the genuine boundary problem in most of the rest.