The order saved, the payment worked, and checkout showed an error

The worst class of checkout bug is the one that happens after the order is created. The customer sees a failure, does not trust it, and either abandons or pays twice.

The symptom

Checkout returns a parse error, as though the server sent something that was not valid data. Meanwhile the order is sitting in the admin, complete and paid. The failure is not in taking the order; it is in telling the browser the order was taken.

The cause on a multilingual site

Bot-protection widgets issue a token bound to the address that requested it. On a site where each language lives in its own path, the visitor browses the translated checkout while the token was issued against the canonical one. Validation then fails at the point where the response is assembled — late, after the order has been written — and the response body comes back empty, which the browser reports as malformed data.

It is difficult to spot because every individual component is behaving correctly. The widget validates properly. The order pipeline works. Only the combination fails, and only in the translated path, which is exactly the path your own testing skips.

Fixing it

• Take the widget off checkout entirely. Checkout is the worst place for it: the traffic reaching that step is overwhelmingly real, and the cost of a false rejection is a lost order.
• Or make it path-aware, so the token is issued and validated against the same address the visitor is actually on.

The wider point

Test checkout in every language on the live site, with a real card, before you consider it working. Multilingual bugs concentrate at exactly the steps nobody re-tests after the first language passes, and a checkout that only works in your default language is a checkout that only works for the customers you already had.