If a transaction returns with a Response Code = 4 ("held for review"), will that transaction be included in the daily batch? My guess is that it won't be included in a batch until the transaction is either approved or declined.
I read somewhere that only eCheck transactions can generate a Response Code = 4. Can one of the moderators confirm this statement.
Tipically, how long will it take for a transaction to switch from a RC=4 to RC=1 or 2? I assume it cannot switch to RC=3, error. In order to find out if a transaction held for review is approved or declined, I need to monitor the details of that transaction until I get a Response Code equal to 1 or 2.
Finally, can a transaction that came back with Response Code = 3, error switch to a Response Code 1 or 2? Or once it generate an error, the host stops trying to process the request and it will never be approved or declined, in which case my application must initiate a new transactions?
In general, the response code of 4 indicates a manual review by the merchant is required due to their Advanced Fraud Detection Suite settings in their gateway account.
Merchants have 5 days to manually review the transaction before we decline it. After a manual review, the transaction is settled during the transaction cut off time for the batch for settlement.
When a transaction gets an error with a response code of 3 the status cannot change.
Thanks for your clarifications. Always very helpfull to explain us the ins and outs of the Authorize.Net system. Now, just so that I can understand well enough to explain to our clients, what setting in the Advanced Fraud Detection Suite can cause a transaction to be held for review? Past chargebacks or returns issued on the same payment profile?
The review is done, I assume on the merchant's Web Portal. What considerations should be looked at during the review? Or what criteria will it be used by the merchant to aprove or decline the transaction? From the merchant's point of view, as long as the bank account linked to the payment profile has money, the transaction shuld be approved. I can't think of too many scenarios pertaining to my client's business model that would generate such transactions "held for review".
When configuring your AFDS filters, you can choose different filter actions as described here. Choosing the 'Authorize and hold for review' and 'Do not authorize, but hold for review' will let you manually review the transaction before taking any action. The merchant has complete control over these. The merchant can set any of the AFDS filters to hold for review.