Post by deevooneh » Tue Jun 21, 2011 12:00 pm

I have the Fraud Detection Suite (FDS) enabled with Authorize.net and with this option when transaction are "Authorized and hold for review" or are processed but trigger a suspicious transaction alert, the customer is not issued a receipt and an order status is not given to the customer. I want to set these orders as Pending, but still issue the customer a receipt. How can I fix this?

Also is there a way to resend a receipt if a customer did not get it?

Newbie

Posts

Joined
Wed Jun 08, 2011 3:34 am

Post by rwenve » Tue Mar 27, 2012 5:53 am

Has anyone figured this one out? My client is also using Fraud Detection Suite (FDS) and while it holds the transactions for approval, it doesn't seem to send the orders back to OC or OC doesn't know that orders are supposed to come back? After approving the transaction with Authorize.net the orders "disappear" - are there some settings on either side dealing with batch transfers or something we are missing?

Newbie

Posts

Joined
Wed Feb 08, 2012 5:40 am

Post by johndovar » Fri Mar 30, 2012 2:50 pm

same problem here , I don't receive the order in admin but I do receive the log in authorize.net account
Strange.

Newbie

Posts

Joined
Thu Nov 10, 2011 12:46 pm

Post by Qphoria » Sat Mar 31, 2012 7:21 am

If someone can work with me on this, I will need ftp access to add some debugging and see what the message code is. I'd guess that the module is looking for a simple pass ... if anything else, assume fail.. so we would need to add pending when the order comes back as hold for review.

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by johndovar » Sat Mar 31, 2012 12:34 pm

I'm willing to help you fix it . I will help you out. Check your pm for the ftp access ok.

Newbie

Posts

Joined
Thu Nov 10, 2011 12:46 pm

Post by scanreg » Tue May 15, 2012 12:58 am

the fraud detection suite has lots more response codes to factor in

would be cool though if the authorize.net module on the cart side could customize cart behavior on a per-customer basis using the fraud detection system responses

what i mean is that say you set the Amount Filter in FDS to $2,500.00 and set it to hold this amount for review

however, what if you have a few customers who normally place orders larger than $2,500.00 but have a long history doing this, thus these customers are more trusted

when auth.net sends back the suspicious code for those particular customers, the order would just come through normally, but for other customers, they would receive an email or order status of 'pending review' or something

in other words, there could be switches for each customer that could tailor how the fds settings would be handled on the cart side for specific customers to help keep legit orders flowing that otherwise fall into the default dfs settings

Active Member

Posts

Joined
Thu May 06, 2010 12:15 am

Post by scanreg » Sat Jul 28, 2012 9:41 pm

can you do a simple decline if the fraud detection suite labels a transaction as suspicious?

Active Member

Posts

Joined
Thu May 06, 2010 12:15 am

Post by yachzo » Wed Nov 07, 2012 1:13 am

This could drive people away from using opencart. I assumed FDS was taken into consideration until I got a large order that failed because I was using the fraud detection suite and the customer had a apartment # on their shipping address and not on their billing. I had FDS set to 'Authorized and hold for review' for mismatched shipping & billing address. I would definitely love a fix for this!

Newbie

Posts

Joined
Mon Dec 12, 2011 4:44 am

Post by scanreg » Fri Jan 25, 2013 3:43 am

yachzo wrote:I had FDS set to 'Authorized and hold for review' for mismatched shipping & billing address. I would definitely love a fix for this!
does opencart recognize all of the FDS response codes?

would love to have the option to not-authorize-but-hold-for-review cuz an auth.net rep told me that you can later enable that transaction if you want to (goes through normal authorization then)

thanks

Active Member

Posts

Joined
Thu May 06, 2010 12:15 am

Post by yachzo » Tue Feb 12, 2013 5:21 am

Nope. I had to turn off my FDS settings so that orders with slight address mismatches would go through although I know that will end up biting me in the end.

I tried changing this on line 136:

Code: Select all

if ($response_info[1] == '1' ) {
to:

Code: Select all

if ($response_info[1] == '1' || $response_info[253] == '1') {
thinking that would allow "authorized but held for review" orders go through, but unfortunately I don't know what the hell I am doing :-\

A table of AFDS Response Reason Codes is listed below:

250 - AFDS blocked IP address
251 - AFDS filter triggered; transaction declined per filter settings
252 - AFDS filter triggered; transaction held for merchant review
253 - AFDS filter triggered; transaction was authorized but is held for merchant review
254 - Transaction declined after manual review of AFDS filters

anyone?

Newbie

Posts

Joined
Mon Dec 12, 2011 4:44 am

Post by scanreg » Fri Feb 15, 2013 3:46 am

wow, it would be super great if the FDS stuff could be smoothed out

thanks for looking into this

Active Member

Posts

Joined
Thu May 06, 2010 12:15 am

Post by exit15 » Fri Jun 19, 2015 4:31 am

Due to increase fraud activity on my website I decided to enable Authorize.net FDS only to realize that when an FDS transaction filter is triggered the customer never reaches the "success" page, no email confirmation is sent out, and in the admin area, the order is held "missing orders" status.

The whole idea with FDS filters is that the merchant has a chance to review the transaction behind the scene and decide to either process or cancel. If the customer is not moved to the success page, and if no email confirmation is sent (with the standard pending status), the customer is bound to assume that her transaction was never accepted and go shop elsewhere.

The filter actions AU.net allow us to choose a response from this list:
  • Process as normal and report filter(s) triggered.
    Authorize and hold for review.
    Do not authorize, but hold for review.
    Decline the transaction.
I believe that the first three actions should result in a standard "pending" order within opencart.
Can this be achieved by modifying the AU module within opencart? I believe yachzo suggested something to that effect but did not get an answer.

Two years later, this is still a problem both on 1.5.6 and 2.0.3.1 -- please help

New member

Posts

Joined
Sun Mar 03, 2013 2:05 am


Post by sternyy » Fri Apr 14, 2017 12:01 am

Bump. We are having the same issue. We need orders to still be submitted to the admin and customer. Then a different "on hold" status for our CS to review.

Newbie

Posts

Joined
Fri Dec 16, 2016 12:49 am
Who is online

Users browsing this forum: No registered users and 5 guests