Showing results for 
Search instead for 
Did you mean: 

What do you do after a DECLINE?

Okay, I just need to check I have this workflow right, because end users are driving me mad.


I have a system where users log on and pay invoices. They can pay full invoices, partial payments for multiple invoices - whatever they like. It uses Authorize.Net DPM.


Now, when they get to the payments page, they enter their credit card details and personal details (pre-filled from their account) and the form gets POSTed to Authorize.Net.


The callback thing happens and the result is logged. Now:


  • if the result is 3 (ERROR) then the user is sent back to the form with the supplied error message, and are able to make corrections and try again (perhaps take an invalid character out of their name, or complete a mandatory field).
  • If the result is 1 (ACCEPTED) or 2 (DECLINED) then the user is taken to a final page showing them the result. If accepted, then the invoices are paid off, if not, then nothing is paid off. The payment session is then cleared down.

So the problem is, many users are being declined because they are entering incorrect details, such as a wrong CVV. They are complaining that their payment is not being accepted. Now my question about the workflow is, if a user is DECLINED, does it make sense to clear down the payment session and make them start again. If this were an e-commerce shop, they would be sent back to the basket and have to chose the payment options again. To me, a DECLINED result does NOT mean I should give them the payment form (to enter CC details) again and say, "give it another go". Or is that acceptable?


What dp you think?



Hi jasonjudge,


When using DPM, generally you are expected to be passing in x_relay_always=true. This parameter removes the differentiation in behavior that you are seeing and redirects for any transaction status. The decision of whether or not to direct the customer to the payment form is really up to each individual merchant.

I can't tell you what you should do, but I can recommend that if you choose to redirect them to the payment form you can also prepopulate it with all of the data that you received in the relay response so that they don't have to start over.




Administrator Administrator

Hi Joy,


Thanks for the response. When I get an ERROR response in the relay, then I do send the user back to the payment form, with the data that was posted to the relay URL, so that part of the process works fine.


What I was looking for, was some opinion on how far back a user should generally be taken if we get a decline - whether they are back to the same pre-populated form to enable the user to try a different credit card, or whether that tight a loop is generally discouraged and the user should be taken a step further back, perhaps to the cart rather than the payment form.


You are right that it is 100% in the merchant site's control. What I ended up doing, was to take the user to a "your card has been declined" page, and close down the payment transaction, but keep the cart open. The "cart" in this paricular case is a bunch of invoices the user has chosen to make some payment on. On that page, the user is given the choice to go back to their invoices page, which also discards the cart on the way, or to try again perhaps with a different credit card, which starts a new payment transaction but using the existing cart (i.e. the chosen list of invoices and the amounts the user has chosen to pay on them).


I think that works, and does not leave the user going round in circles by being taken back to the payment form on every possible decline.


-- Jason