So I have a ticket booking system.

I have ticket booking request on api, from my application we call payment service.

If failed on first attempt we proceed by adding message on queue for handling payment later. And proceed with issuing ticket to customer.

From queue we retry payment with payment api 10 times in 10 minutes if no success we add some status to that ticket booking record and by offline mean get money from customer.

Problem: We are getting many such booking due to credit card frauds.


I have a solution in mind, I will not proceed with issuing ticket in payment fail , instead I want to return something different http code to client. like everything else except payment is success.

And while processing message from queue if it fails after 10 attempts I want to inform client this transaction is failed.

If pass let client know to proceed with issuing ticket

Question: Does this solution have technical feasibility ?

  • do you not get a different fail message from the bank when a credit card fails due to fraud rather than lack of funds etc?
    – Ewan
    Jul 16, 2018 at 10:40
  • they give generic decline message, that is the pain
    – VedantK
    Jul 16, 2018 at 10:42
  • I think your solution makes some scenes. It's also good in your first API which responses ticket booking request returns http code 202 (developer.mozilla.org/en-US/docs/Web/HTTP/Status/202) to indicate the client that the request has been accepted, but there's further long-time process happening. Another thing worth considering is a fraud detection service (could be COTS ones), since the bank doesn't provide such function in their response code.
    – ivenxu
    Jul 16, 2018 at 23:40

4 Answers 4


The HTTP return codes are designed to deal with the HTTP protocol, not every possible Request/Response.

Rather than selecting an obscure code that can, maybe, be interpreted, roughly, as what you want it to, if you squint at it. Simply return more information in the response body

200 OK
    "userCreation" : "Passed",
    "ticketReservation" : "Passed",
    "paymentProcessing" : "Failed"
    "orderStatus" : "PendingPayment"
  • Yes. See also Greg Burghardt's answer below, which you can still do with a detailed response body. Jul 16, 2018 at 22:25
  • yup, just check your js framework of choice, proxies, routers etc counts it as a success and doesn't do anything special and or crazy
    – Ewan
    Jul 16, 2018 at 23:20

Returning a 202 Accepted response is a good fit here.

From Wikipedia:

The request has been accepted for processing, but the processing has not been completed. The request might or might not be eventually acted upon, and may be disallowed when processing occurs.

This status is reserved for cases like this where things are going fine right now, but some out of band processing is going on and the client should check back later.

All kinds of "out of band" processing can occur. Like optimizing images or video after uploading them, or, as in your case, processing a credit card payment.


You could introduce another object in your system, a ticket-purchase-request.

When the user tries to buy a ticket, you immediately create one of these objects (and a return from the create a cooresponding ID).

Then the caller can monitor the status of the this request, with calls to GET /ticket-purchase-request/{ID} using the ID returned before. He can read back in teh status that its still being validated by the credit card company, or that its failed.

I'm NOT sure why you would ever want to automatically retry the credit card request? If it failed, and you are saying that's because of fraudulent requests, I see no reason to try again. The only reason to retry would be if a transient error (network connection or server busy for example) caused the credit card running to fail. You need to look at the status code returned by the credit card company (if they say declined dont retry).


I have a solution in mind, I will not proceed with issuing ticket in payment fail , instead I want to return something different http code to client. like everything else except payment is success.

When in doubt, think about how it works in your web browser.

Most of the time, we -- the consumers of a web site -- don't pay any attention at all to the status-code that is returned by the server. What we look at is the payload.

The audience for the status-code? The generic components (browsers, proxies, caches) that use the meta data provided to support generalized capabilities.

Jim Webber said it this way

The web is not your domain, it's a document management system. All the HTTP verbs apply to the document management domain.

The same is true of the status codes. They are meta data about the documents, with standardized semantics that allow generic components to do clever things: throwing up a login dialog because authentication is required, automatically invalidating cached representations, invalidating bookmarks....

So Ewan has the right idea: you put the information the consumer needs into the document. Define the media-type and schema in such a way that you can cover the necessary use cases. When replying to a request, compute the correct document to send first, then consider what information should be lifted into the meta data.

This isn't some trick pattern to work around an unusual use case -- this is the way HTTP APIs are supposed to work all the time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.