02-18-2015 01:12 PM
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:
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?
02-23-2015 03:10 PM
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.
02-23-2015 04:22 PM
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.