Agreed. What else would you use 400 for? I don't see how sending back 400 is going to hurt.

The payoff of using 400 is you can watch your 400 rates with almost no effort (HTTP is well established and there's many many tools out there.) If you somehow start accidentally munging the card number sometimes or if your card processor starts doing wacky stuff you'll see a spike in 400 rates.

If it was really that troubling that declined cards are expected, I would personally at least want to see 200 come from the internal API and 400 go out to the client.

And if your "intermediate devices" start doing goofy stuff to 400's then you've got bigger problems... 4xx's shouldn't be taking nodes out of prod. That's wack.

In my opinion 404 should really mean the API endpoint doesn't exist and therefore the requested action did nothing. Using HTTP for business logic is like using ethernet frames with parts of IP. It is another level, HTTP is just a transport. 404 - not found, 5xx server problem, 301 - endpoint is now elsewhere etc. HTTP is for browser pages but you are actually making API requests using your JSON(or urlencoding or whatever)-based application protocol.

> 4xx's shouldn't be taking nodes out of prod. That's wack.

Welcome to AWS, where this is actually part of standard procedure (at least Elastic Beanstalk does this, not sure if it’s actually Elastic Loadbalancer under the hood).

Don't you love it when all configured backends/origins for a service are marked unhealthy through healthchecks, Amazon's load balancers route traffic to all origins.

I mean, the alternative is routing it nowhere. Might as well throw it at the wall and see if it sticks.

>What else would you use 400 for?

400 is "bad request"; you might use it if the request body was not valid JSON.