ZC orders with no Authorize.net processing??

[phatkodi]

This is a very strange issue. So far I found the following...

Some ZC orders come through and state credit card payment method with no card number, type etc...

No Authorize.net transaction info either declined or approved. Just nothing.

No debug info in cache for AIM also just not there. So it doesn't even attempt to contact Authorize.net

Majority of orders work fine only a small number has this happen and it appears random.

I am using 1.3.8 with super orders module. Here is my curltest.php info

CURL Test Page
This page is intended for testing CURL behaviour. You should be accessing this page via CURLTEST.PHP running on YOUR server.


You submitted the following fields and data:
Array
(
[field1] => This is a test
[statuskey] => ready
)
Data validation
Good
Other Info

Array
(
[url] => "http://www.zen-cart.com/testcurl.php"
[content_type] => text/html
[http_code] => 200
[header_size] => 139
[request_size] => 174
[filetime] => -1
[ssl_verify_result] => 0
[redirect_count] => 0
[total_time] => 0.123527
[namelookup_time] => 0.115204
[connect_time] => 0.116012
[pretransfer_time] => 0.116035
[size_upload] => 0
[size_download] => 2140
[speed_download] => 17324
[speed_upload] => 0
[download_content_length] => 0
[upload_content_length] => 0
[starttransfer_time] => 0.123507
[redirect_time] => 0
)


Any ideas what this could be. I think it may be card or user specific as one user it does it everytime they order. I am still investigating that though.

[DrByte]

Sounds like you have the Offline Credit Card module enabled, and that's what people are using to place orders. Since that module never contacts the gateway, payment is never received with it. That module is intended for processing cards manually through your own console.
If you want to use the Authorize.net module, click Remove on the other module(s) you're not using.

[phatkodi]

Sounds like it me too and Maybe your right, but I don't understand how that could happen since it is not enabled in the pay modules and it is only for happening for some users. I will login as one of the users in question and see if that is an available option. Thanks

[kiddo]

If this was just in the past few days and otherwise OK, it -might- have something to do with authorize.net having had a fire in their Seattle datacenter this past weekend. I haven't seen what you describe, but did have some other problems with sites using AIM.

[phatkodi]

Ok I just logged in as on of the users that this just happened to yesterday. I placed an order using all there same info except I used 4111111111111 and it declined my card which I verified in the cache directory through the AIM log. So it using the AIM module and not the Offline CC which has been disable from day one. Also would the offline CC module not show any cc info in the ZC order details page, as this is the case in the anomally.

[phatkodi]

Thanks for the news, I didn't know that had happened. This has happend only to two of my customers actually. The first was about 2 or 3 weeks ago and it happen to that customer twice back to back which is interesting. I thought is was a fluke so I didn't look into it really. The second was yesterday night and it has my attention now.

Seems to me that if there was a communication error with authorize, then ZC would decline the order but maybe I assume to much... :)

[phatkodi]

Ok here is what I have found...

I do have super orders 2.0 installed which slightly modifies the orders.php class by adding the following code.

// BEGIN Super Orders edit
// add CC data as a line item to SO payment system
if (zen_not_null($this->info['cc_type']) || zen_not_null($this->info['cc_owner']) || zen_not_null($this->info['cc_number'])) {
require(DIR_WS_CLASSES . 'super_order.php');
$so = new super_order($insert_id);
$so->cc_line_item();
}
// END Super Orders edit

Other then that the order.php and ordertotal.php classes are stock 1.3.8 Zencart along with checkout_process and the AIM module

I have found that on the abnormal orders the cc_type, cc_owner, cc _number and cc_cvv info is not being recorded in the orders table. cc_method is recorded however and shows the AIM module as it should. All other data is being recorded as usual. Again this happens on a random basis. I have not found a way to consistently generate this anomaly. Could this be _SESSION related and why isn't any error being thrown out, instead it lets the customer complete the order as if everything was fine...I am stumped...Any help would be appreciated.

Matt

[phatkodi]

Also cc_exipres is blank also. Seems that info is not being passed, but when and where I am still trying to figure out.

[phatkodi]

Anyone have any ideas this keeps happening on random orders. It seems as though the cc info variables are not being passed from the order confirmation page. What I don't understand is why is Zencart allowing these to be processes without any AIM confirmation. I am unable to duplicate this for testing. Could this have something to do with Super Orders. Why are some going through and some are not. Any ideas for adding debug code to help figure out the problem.... Please HELLLLLLLLPPPPPP

[DrByte]

What I don't understand is why is Zencart allowing these to be processes without any AIM confirmation.

I agree. It was never designed to operate that way.
But without being able to duplicate the exact situation consistently, it's very difficult to come up with a fix.

I'm still inclined to think that you've got payment modules "installed" but have their settings set to "enabled=false" or have zone restrictions on them ... but somehow one or more of those are getting selected instead of the AIM module. Either that or you've got some customizations installed somewhere that are interfering with the normal checkout activity.