jka

Authorize.net Pending verification transactions

Recommended Posts

We recently turned on additional fraud detection parameters within Authorize.net. If the AVS etc doesnt match, there is a manual approval process within Authorize.net that happens before the transaction goes to settlement. 

when this happens the code sent back to CC by AIM is 4|1|253. The users get a response like the attached screenshot. This is very confusing with the "Red" background and the users end up trying couple of times. 

The normal approval code is 1|1|1. Obviously CC displays this "Your order has been received statement". Any chance this scenario can be handled in a user friendly way. A 2|1|2 is Card declined and thats fine, however this 4|1|253 should accept the order and move it to pending state.

Also the text is sent by AIM but CC sees it as a error with the text and background being counter intuitive.

Screen Shot 2017-08-02 at 12.58.21 PM.png

Edited by jka

Share this post


Link to post
Share on other sites

Thanks bsmither. I was on 1.0.0. I did a in-place update to 1.1.2. Hopefully this didnt break anything. Looks good on the front end control panel.

 

Share this post


Link to post
Share on other sites

I am getting the same error on some cards processed. This has been a recurring but random error.

Using Authorize.net v 1.1.2

openssl ciphers -v | awk '{print $2}' | sort | uniq
which returns

SSLv3
TLSv1.2
so I know the module and ciphers are current. Almost a certainty that fraud control is set to a high level with the card processor. 
I suspect the issue revolves around invalid customer input, like forgetting a middle initial or suffix in the name on the card.
 
Does a detail error show in CC somewhere? Admin and System log both return blank. Also, php error logs show no entries for this issue.

 

Share this post


Link to post
Share on other sites

The Authorize.net module, when using the AIM method (as opposed to the SIM method), uses CubeCart's "Request" set of functions. As such, there should be logged entries in CubeCart's admin Request Log.

 

Share this post


Link to post
Share on other sites

I have been busy on nonecommerce accounts for the past several months and not paying that much attention to CC. I should have known that. Thanks, bsmither that is exactly where the error is listed, it shows the transaction sent in, and the response. Code is  4|1|252|Your order has been received. Thank you for your business!

And, looking at the settings in authorize.net, I see the owner has transactions set to "Authorize Only", which I would be willing to guess is the cause of the errors. Since there appears to be no reason to only authorize then do a rerun and capture, I am going to help her out and just change the setting, we will see what happens.

Share this post


Link to post
Share on other sites

Ok, but still, the module is not coded to look past the first element being 1, 2, or 3. In the cases of this forum conversation, the result is 4 (without looking at the API docs, I will assume 4 is "Authorized" as opposed to 1 being "Approved").

So, I will say that the module has a setting for Authorize only, but there is no matching code on what to do when Authorize.net responds with that result.

Therefore, set the module to Authorize and Capture until the next version comes out.

Edited by bsmither

Share this post


Link to post
Share on other sites

Thank you. Very solid advice. You have gone so much deeper into this program than I ever will. My business has gone so much general sites using owner-friendly frameworks over the past few years, causing my ecommerce development to take a back seat.

 

 

Share this post


Link to post
Share on other sites

Just updated a customer to CC 6.1.11 and have the latest authorize.net extension, 1.1.3 installed, and set to authorize and collect.

In logs, return is: "4|1|252|Your order has been received. Thank you for your business!|etc."  and the red banner is back, still showing an amount due on the order. We stopped this problem using the recommendations in the Sept. correspondence, but with the upgrades it is back. Any suggestions other than disabling the Authorize.net module until various programmers can get together and resolve this issue.

screen-1.jpg.ddc3ad53566ec02df116601ec9355a81.jpg

Share this post


Link to post
Share on other sites

If Authorize.net is returning "4|1|252", then, based on earlier conversation, it seems the module is sending an "Authorize Only" request.

Please verify.

Also, try switching to Authorize Only, Save, then immediately switch back to "Authorize and Capture", Save.

 

Share this post


Link to post
Share on other sites

The Authorize AIM Developer's Guide (Oct 2015) says the '4' is "Held for Review". Maybe in your Authorize.net Account Settings Panel, there are conditions of the transaction not being met that prompts this response.

Still, CubeCart should not flag it as an error.

On the other hand, maybe so - but the response is up to the merchant. The docs say that the Merchant can change the textual response (defaults to "Your order has been received. Thank you for your business!") in the Merchant Account Settings Panel.

Edited by bsmither

Share this post


Link to post
Share on other sites

The account is definitely set for authorize and capture, and, as far as I know, was working properly set that way until this upgrade.

Just to be certain, I did set to authorize and back to authorize and capture, but did not process another test order.

The customer probably has the account set to approve but not bill until she goes in and marks as shipped. I have explained carefully and sent log copies and asked they contact there credit card processor, so we will see..

However, CC should be able to handle the notice without throwing up a red flag, causing the user to attempt to reprocess the card, thereby placing several orders.

Being able to change the color to yellow, with a notice that the card was authorized but will not be billed until the order is shipped would be nice.

Share this post


Link to post
Share on other sites

We can certainly modify the module's code.

But as I said, the Authorize AIM Developer's Guide (Oct 2015) says the '4' is "Held for Review". I surmise there is some reason Authorize.net determined that this transaction needs further review.

Someone will need to examine these "4|1|256" orders within the Merchant Account Settings Panel at Authorize.net to discover why Authorize.net flagged them as such.

Share this post


Link to post
Share on other sites

I don't know right now just what the issue is, but best guess is you are correct about the fraud detect. However, having my own card hang is not an issue with my account. It may be due to  actions my client has taken, or problems the client caused the processing company.  My client talked to Authorize.net for some unknown reason and relayed that the issue was not theirs, but mine. So we are back at having the client talk to the horse's mouth. I will try to convey your comments to my client, but I suspect that will cause another 1/2 dozen or so emails telling me why I need to fix it.

Thanks for all the time spent on this. I will update you with the outcome as soon as I can verify the changes.

 

 

Share this post


Link to post
Share on other sites

Interesting follow up. My client has talked to both authorize.net and her processor technical departments, and they both claim no responsibility, pushing the entire issue back on the  "programmer" and yet we both know the issue is in the set up either in the authorize.net or the processor control panel.

I know for certain this issue is in one of those control panels as I have 2 other accounts using cube cart and authorize.net with absolutely no issues.

However, IMO, we still need C C programmers to deal with the response of 4|1|256 in a more acceptable face to the customer using the cart to place an order.

Edited by Geotex
update

Share this post


Link to post
Share on other sites

At Authorize.net (account.authorize.net), view the AFDS settings.

Here are some code changes that will make CubeCart's response more friendly. Keep in mind, however, Authorize.net, probably because of AFDS, has NOT put this transaction in the batch. The money will NOT transfer from the customer to the merchant unless and until the Merchant has 'approved' this transaction.

In /modules/gateway/Authorize/gateway.class.php

From:
	private $_result_message;

To:
	private $_result_message;
	private $_result_status;

From:
			} elseif($results[0] == 3) {
				$status	= 'Error';
				$order->orderStatus(Order::ORDER_PENDING, $cart_order_id);
			}

			if($results[0] != 1) {
				$this->_result_message		= $results[3];
			}

To:
			} elseif($results[0] == 3) {
				$status	= 'Error';
				$order->orderStatus(Order::ORDER_PENDING, $cart_order_id);
			} elseif($results[0] == 4) {
				$status	= 'To Review';
				$order->orderStatus(Order::ORDER_PENDING, $cart_order_id);
			}

			if($results[0] != 1) {
				$this->_result_message = $results[3];
			}
			$this->_result_status = $results[1];


From:
		// Display payment result message
		if (!empty($this->_result_message))	{
			$GLOBALS['gui']->setError($this->_result_message);
		}

To:
		// Display payment result message
		if (!empty($this->_result_message)) {
			switch ($this->_result_status) {
				case 1:
				case 4:
					$GLOBALS['gui']->setInfo($this->_result_message);
					break;
				default:
					$GLOBALS['gui']->setError($this->_result_message);
			}
		}

I strongly urge that Authorize.net's actual message that is returned with a "Hold for Review" status be changed in the Authorize.net Merchant Account interface (account.authorize.net).

Edited by bsmither

Share this post


Link to post
Share on other sites

Thanks. I made a copy of the code.

I have not heard back from my client. However, we both know the cause of the problem. I am working to get that resolved, but will go ahead and try the code out to see if that can resolve the repeated processing attempts.

 

Share this post


Link to post
Share on other sites
On 10/12/2017 at 10:49 AM, Geotex said:

 

screen-1.jpg.ddc3ad53566ec02df116601ec9355a81.jpg

BSmither,

I get the same issue. I have enabled the Fraud Detection Suite with Authorize.net. I just noticed that I can change the Customer Response Text. However .... the issue with my customers is not the text which says "Your order has been received ......" Its the statement "the following errors were detected" as well as the "RED" background. This is not from AIM. How can we fix this in CC? The merchant gets a separate email from Authorize.net if the transaction is held for merchant approval. 

The red banner and error text causes my users to submit the order a few times because the error line text is misleading.

Share this post


Link to post
Share on other sites

Please make the code edits I have posted earlier.

If you have in fact done this, we need to troubleshoot a bit more.

Share this post


Link to post
Share on other sites

I have run into 2 additional issues with the use of authorize.net, and I know it is  because either the cart or the authorize.net module is not verifying the data prior to sending. Another issue is that if a response is delayed for whatever reason, more than one submit is permitted prior to getting a response.

I found the following 2 errors (both repeated, but only shown once here for example)

"3|1|5|A valid amount is required.||P|0||Payment for order #|0.00|CC|auth_capture||" (same time stamp, right after an approval, signifying multiple clicks to submit)

" 3|2|33|Credit card number is required.||" (just hit submit without checking or filling out any info on payment screen)

Both of these errors are allowed because there is no verification of input prior to submitting the order for payment to authorize.net (and probably any other payment, although not tested yet, that will follow today on my test cart). In other words, when you get to the screen to verity your cc, address, etc. you can just click on the green submit payment button, and off it goes.

Share this post


Link to post
Share on other sites
20 minutes ago, Geotex said:

I have run into 2 additional issues with the use of authorize.net, and I know it is  because either the cart or the authorize.net module is not verifying the data prior to sending. Another issue is that if a response is delayed for whatever reason, more than one submit is permitted prior to getting a response.

I found the following 2 errors (both repeated, but only shown once here for example)

"3|1|5|A valid amount is required.||P|0||Payment for order #|0.00|CC|auth_capture||" (same time stamp, right after an approval, signifying multiple clicks to submit)

" 3|2|33|Credit card number is required.||" (just hit submit without checking or filling out any info on payment screen)

Both of these errors are allowed because there is no verification of input prior to submitting the order for payment to authorize.net (and probably any other payment, although not tested yet, that will follow today on my test cart). In other words, when you get to the screen to verity your cc, address, etc. you can just click on the green submit payment button, and off it goes.

Running transactions on my test cart, which is a basic install, upgraded to latest version 6.1.12, shows there is no basic field verification of any data prior to submission from the form displayed at  "index.php?_a=gateway." I feel really bad that I assumed this was taken care of only because nothing should ever be released for production without at least basic form validation. Depending on the plug-in module to do this verification is not an acceptable alternative. 

Basic PayPal is okay because you get an immediate redirect to PayPal with a transfer of only order number and amount, never taking you to the input screen at "index.php?_a=gateway" for any other payment module.

Share this post


Link to post
Share on other sites

I would argue it is the plugin's responsibility to provide the form validation. I disagree with the core code providing specific and dedicated support for distinct plugins. But that's just me.

As I see it, the "Basic PayPal" takes the customer to PayPal's site to make payment. This most closely resembles Authorize.net's SIM method, whereas this situation is using the AIM method.

There are assumptions made prior to displaying the AIM form: the initial form is populated with basket billing address data. If the form is getting re-displayed with empty fields, then it must have happened after CubeCart discarded the basket after a successful transaction. The question is, what is causing the form to be re-displayed?

The gateway class code suggests the module should not call the process() function unless $_POST['cardNumber'] is set - presumably with a card number but could be anything.

Share this post


Link to post
Share on other sites

re: what causes the form to be re displayed? Any error returned from the cc processor.

re: SIM then, does not count as it goes directly to authorize.net for entering and checking the credit card information.

What we are dealing with here is forms that are in the cart environment prior to submission. Where ever they are generated from, and it appears they are part of each gateway module, looking at the authorize.net module and the generic credit card module I use for testing, I will look at a couple of other gateway payment methods, but I suspect I will find the same. 

And yes, the form is populated with order. price and basic customer info. However, everything except the total and order number is fully editable, and with virtually no skill, the price can also be fixed before submission, all with no verification whatsoever of any input before submitting the information to the payment processor.

We need at least validation of proper formation of credit card numbers, and at least verification that name, address parts of the form that need data are populated. This will go a very long way to increasing user satisfaction with the purchasing process, which is historically difficult when compared to swiping your phone near a payment device when checking out in a retail environment.

The submit block should also be deactivated until a return from the gateway since it appears the order total is reset to zero at least until the auth codes are returned and the page is refreshed.

This is in addition to the work you started to alter the response displayed to a customer, which from feedback I got from one user is still an issue.

Not having the full fraud detection suite active at authorize.net seems to have cleared up a lot of issues, but that is something we cannot depend on. Our merchants need all the protection that can get.

Edited by Geotex
sent before I finished

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now