[mytailorisrich]

The API provider should have documented the change ahead of time. However they were still returning an error, even if a new error, when the payment failed.

There should be a catch-all for errors and that should certainly not default to 'success'.

Now, if the API provider really did change the API to return something new that is not an error this is indeed trickier. In general good design is to check specifically for success and to deem everything else a failure, which avoids this sort of surprise.

[trinovantes]

At the bottom of the thread, there was another company that assumed anything non-successful is a failure (but there was a new success state) which resulted in customers retrying and getting charged multiple times

It seems the safest option is whenever there is a new API state, a major version bump is needed

[mytailorisrich]

This is still the saner thing to do. There can obviously be 'smart' failures: e.g. Report and block if something unknown is reported to acknowledge the fact that an 'unknown' condition requires to be urgently looked into while preventing further problems.

I also find it rather hilarious that the author of the thread then tries to shift the 'blame' to "growth!"...