I\'m creating a RESTful API that will process a number of user interactions, including placing orders using stored credit cards.
In the case of a successful order, I
How about 424 Failed Dependency? The spec describes it as:
The method could not be performed on the resource because the requested action depended on another action and that action failed.
But there is also this definition:
Status code 424 is defined in the WebDAV standard and is for a case where the client needs to change what it is doing - the server isn't experiencing any problem here.
You can tell the client (or pretend) that you have internal actions which are supposed to create the order, and deduct the balance, and that one of those actions failed, albeit for perfectly valid reasons, and that's why the request failed.
As far as I can see, "action" is quite a broad term, and can be used in a variety of situations, including insufficient stock, insufficient credit, or warehouse party night.
Another option might be 422 Unprocessable Entity:
The server understands the content type of the request entity (hence a 415 Unsupported Media Type status code is inappropriate), and the syntax of the request entity is correct (thus a 400 Bad Request status code is inappropriate) but was unable to process the contained instructions.
For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.
Trying to request an item which is out of stock, or when you have insufficient credit, might be considered a mistake at the semantic level.
MozDev says this indicates a mistake on the client side, specifically: The client should not repeat this request without modification.
Loopback 4 uses 422 when input validation fails.
Arguably, insufficient stock or warehouse party night could be considered temporary states, so the request could be retried again later. That situation can be indicated by 503 Service Unavailable
The server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay.
The server MAY send a Retry-After header field to suggest an appropriate amount of time for the client to wait before retrying the request.