So with DPM, to find out if there are any errors in the POST form, that form needs to be POSTed to Authorize.Net If there are any errors in that form, which could be as simple as invalid characters in an address field, then the transaction will fail and the failure code and reason will be POSTed back to the merchant's site.
Now, if this is an error that can be dealty with as a simple typo, i.e. a correctino to the form, then the form could be presented back to the user (the callback response can send the user back to the form, with an error message, and the POSTed data could even be retrived from the database if needed).
However, some errors are not easily recoverable. If authentication is positively denied, then we don't want to give the users another chance to enter details. We want to close off the transaction as failed, clear it from the session, and send the user back to the basket or cart.
So teh question is, how can the application tell what kind of failure this is? Is there a flag to say whether the failure is terminal? Or maybe there is a list of error codes that would result from simple correctable issues in the POST form? Or maybe nobody even handles errors nicely with DPM?
Just as an aside: on the sandbox system, I am seeing a form being presented to me by Authorize.Net when POSTing my site's form. I understand that is not how DPM works, and it won't do that in production. Or maybe it does and I've got a setting wrong?
Any advice?
-- Jason
Solved! Go to Solution.
โ02-05-2015 10:21 AM
You can display any of the error if you want, as it doesn't have any secure info.
A payment form is POSTed to the DPM end point, and that form may contain errors that can be corrected before the transaction can be approved or declined. So how can my application tell that this is the case?
Read the response reason code to see why it got declined.
fields name are here
โ02-10-2015 06:16 AM - edited โ02-10-2015 06:17 AM
Just looking at the docs, the main response codes are as follows:
1 This transaction has been approved.
2 This transaction has been declined.
3 There has been an error processing this transaction.
4 This transaction is being held for review.
Would it be safe to assume that 1 and 2 finish the transaction off, while 3 can be treated as incomplete or wrong details and the user can be given another shot at it?
โ02-05-2015 10:24 AM
So does anybody know? A payment form is POSTed to the DPM end point, and that form may contain errors that can be corrected before the transaction can be approved or declined. So how can my application tell that this is the case?
โ02-10-2015 05:08 AM
You can display any of the error if you want, as it doesn't have any secure info.
A payment form is POSTed to the DPM end point, and that form may contain errors that can be corrected before the transaction can be approved or declined. So how can my application tell that this is the case?
Read the response reason code to see why it got declined.
fields name are here
โ02-10-2015 06:16 AM - edited โ02-10-2015 06:17 AM
So if the status cames back to my relay page as "3" (ERROR then I can always send the user back to the payment form, pre-filled with what was submitted to to the relay page, and present the error message to the user?
Presumably this will work a number of times before Authorize.Net decides too many errors are enough and it should be declared a status "2" (DECLINE)?
โ02-10-2015 07:04 AM
It depend on the reason code for response code 3
Presumably this will work a number of times before Authorize.Net decides too many errors are enough and it should be declared a status "2" (DECLINE)?
It will keep trying.
โ02-10-2015 07:14 AM
So of those ~300 messages, there is no list of what can be reasonably presented back to the user to make corrections? I need to go through that list and decide what each one means, and which reasons can be fixed with some typos corrections, and which ones are really a no-go?
And Authorize.Net will keep retrying while I feed my big box of stolen cards in, until I find one that works?
โ02-10-2015 07:20 AM
So of those ~300 messages, there is no list of what can be reasonably presented back to the user to make corrections? I need to go through that list and decide what each one means, and which reasons can be fixed with some typos corrections, and which ones are really a no-go?
Yeah.
And Authorize.Net will keep retrying while I feed my big box of stolen cards in, until I find one that works?
That too, yes. Authorize.net do offer optional Fraud Detection Suite for a fees. One of them is
"Transaction IP Velocity Filter"
Note from the settings page
The Transaction IP Velocity Filter allows you to specify the maximum number of transactions allowed from the same Internet protocol (IP) address per hour. If your account receives more transactions from the same IP address in an hour than the threshold you set, all exceeding transactions received that hour will be flagged and processed according to the filter action selected below. Notes: IMPORTANT: If you submit Advanced Integration Method (AIM) transactions, in order to use this filter you must submit the customer IP address (x_customer_ip) with each transaction. If you select Authorize and hold for review as the filter action, once the transaction is held for review, we recommend you take action to approve or void the transaction within 72 hours.
โ02-10-2015 07:31 AM
The more gateways I use, and the more PHP code I inspect, the scarier the online payment world looks :-/ So long as I understand the limitations and potential flaws, then I can program around them, but so many off-the-shelf gateway plugins don't. Thanks for the info - it all helps in putting together a secure and robust gateway API.
โ02-11-2015 02:30 AM