The one word that coincided

Nothing here is wrong. Each set is internally sensible and each is documented. They simply have no reason to agree, and anything that talks to more than one of them has to pick a vocabulary and translate into it at the boundary.

If a provider returned stages named in a scheme that shared no word with yours, you would find out within an hour. Nothing would advance, every record would read as unrecognised, and the first order anybody watched would make it obvious.

A vocabulary that overlaps partially does not do that. It behaves correctly for exactly the stages where the words happen to coincide, and silently wrongly everywhere else - and which of those you notice depends entirely on which outcomes you happen to see first.

Take a provider whose terms are NEW, PENDING, EXCHANGE, WITHDRAW, DONE, EXPIRED and EMERGENCY, read by a system whose own stages are new, waiting, confirming, exchanging, sending and finished, with failed, refunded and expired as endings.

One word matches: expired. So an order that times out is recorded correctly, lands in the set of endings, stops being asked about, and reads properly in every report.

An order that succeeds comes back as DONE - a word that system has never heard of. It is not an ending, so the record is re-checked indefinitely. It is not one of the stages a progress display knows, so the bar a customer is watching stops moving on an exchange that has in fact completed. And none of it raises an error anywhere, because nothing has failed; a string simply arrived that nothing was looking for.

A second provider uses overdue for a payment window that closed without funds. Read literally that sounds like something still in progress - late, but pending. It is an ending: that exchange is over.

Stored untranslated it sits outside the set of endings forever, gets re-asked on every pass, and is reported as unresolved about transfers that finished days earlier. The cost is not a wrong number on a screen; it is a queue of work that never empties, about exchanges that are not waiting for anything.

The same provider has a stage for a late payment, a wrong amount, or an amount outside the limits - the customer has to choose between continuing at a new rate and taking a refund.

There is no honest equivalent for that in a six-stage vocabulary. It is not finished and it is not failed, and mapping it to either would be wrong in the direction somebody acts on: one tells them their money is gone, the other tells them it arrived. Leaving it untranslated keeps it out of the endings, which is exactly right - it keeps being asked about, because it genuinely has not ended.

Translating at a boundary does not mean forcing every term into a slot. Some of them are telling you something your own vocabulary cannot say.

Translate at the boundary, for every provider, including the ones that look like they already speak your language. The exception is invisible precisely while the coincidence holds, and the thing that reveals it is a successful outcome - which, on a quiet service, can be the rarest event you have.

It is the same shape as an absence and a refusal: two different answers that arrive looking identical, where the cost is paid by whoever reads the record afterwards and believes it.

The status vocabularies above are the providers' own documented sets, read on the date here. The stage names they are mapped onto are the ones this app stores and draws, which are visible on any exchange in progress. No order was created for this piece.