Post by mc49285 » Fri May 11, 2012 7:49 am

OC 1.5.2.1 Carbon Theme

CC payments resolve to what Authorize.net people claim is an error 13, which is a communication issue between my site and theirs. I checked the local files and everything seemed to be in order, so the recommendation was to follow the instructions at http://developer.authorize.net/tools/datavalidation. So I changed the local files to point to their validation server, which is supposed to give a response of data pairs; however, the connection to the validation server just hangs.

Anyone run into this error 13 situation and get it resolved?
Last edited by mc49285 on Thu May 17, 2012 6:28 am, edited 1 time in total.

New member

Posts

Joined
Wed Mar 14, 2012 7:28 am

Post by mc49285 » Fri May 11, 2012 8:34 am

error log shows:

2012-05-11 0:24:17 - PHP Notice: Undefined offset: 4 in /home/metrodar/public_html/store/catalog/controller/payment/authorizenet_aim.php on line 157

Line 157 is blank, here is what surrounds it:

$json['error'] = $response_data[4];
}
} else {
$json['error'] = 'Empty Gateway Response';

New member

Posts

Joined
Wed Mar 14, 2012 7:28 am

Post by mc49285 » Fri May 11, 2012 10:38 am

So one post I found said you needed to set your delimited response at authorize.net, check did that.

I refreshed the /controller/payment/authorizenet_aim.php file and tried:

elseif ($this->config->get('authorizenet_aim_server') == 'test') {
$url = 'https://test.authorize.net/gateway/transact.dll';
returns the error invalid username or password (error 13)

elseif ($this->config->get('authorizenet_aim_server) == 'test'){ $url = 'https://developer.authorize.net/tools/p ... /index.php'

This option still hangs...

New member

Posts

Joined
Wed Mar 14, 2012 7:28 am

Post by Avvici » Fri May 11, 2012 10:56 am

This may interest you. It was take from a previous A.net PLEASE WAIT (hang problem)

http://forum.opencart.com/viewtopic.php ... 36#p222736


Taken from this:
Re: Authorize.net "Please Wait" Hangs

Unread postby Qphoria » Tue Mar 27, 2012 1:26 pm
Try this
viewtopic.php?f=133&t=46708&p=222736#p222736

User avatar
Expert Member

Posts

Joined
Tue Apr 05, 2011 12:09 pm
Location - Asheville, NC

Post by mc49285 » Fri May 11, 2012 11:36 am

Thank you for the link, but it does not help me. Those changes

return:

store/catalog/controller/payment/authorizenet_aim.php on line 51

public function send() {
if ($this->config->get('authorizenet_aim_server') == 'live') {
$url = 'https://secure.authorize.net/gateway/transact.dll';
} elseif ($this->config->get('authorizenet_aim_server') == 'test') {
//$url = 'https://test.authorize.net/gateway/transact.dll';
$url = 'https://developer.authorize.net/tools/p ... /index.php'
Line 51 }

Now I will switch off the dev server link and go back to the test server.

And that returns me to: (TESTMODE) The merchant login ID or password is invalid or the account is inactive.

New member

Posts

Joined
Wed Mar 14, 2012 7:28 am

Post by mc49285 » Fri May 11, 2012 11:00 pm

Well, I am more than a bit lost here. The error message seems to come from authorize.net, based on I cannot find that particular message in the language files. However, the username and transaction key have been verified, reset, and reverified with authorize.net. The only answer I get from them is that their servers are functioning without issue, please talk to your developer...

Well, the developer is the one who cannot perform the transaction. Site has been restored to default theme, hotpatch has been applied, and since I cannot use the authorize.net development server, I am at a dead end. Well, I suppose I could undertake to assume that rewriting a payment gateway is easier than what I have already achieved, but that is nonsensical because I cannot even figure out what PHP entity calls product_send. Others have this working, where do I look for errors? There is nothing in the error file.

New member

Posts

Joined
Wed Mar 14, 2012 7:28 am

Post by Avvici » Fri May 11, 2012 11:20 pm

Na don't fret dude. I can help you if you like just get on Skype at Involution Media.

User avatar
Expert Member

Posts

Joined
Tue Apr 05, 2011 12:09 pm
Location - Asheville, NC

Post by mc49285 » Sat May 12, 2012 2:18 am

I cannot skype, thank you though and I really appreciate it.

wondering now if some php module or Curl something or other is missing from the VPS I have.

New member

Posts

Joined
Wed Mar 14, 2012 7:28 am

Post by Avvici » Sat May 12, 2012 2:29 am

I am pretty sure you need to call your web host on this. This error is not common with A.net and open cart unless the issue is deeper. I am pretty sure it means your server is trying to clean its own php session tmp folder out but it can't. Contact your webhost about that. Don't let them bully you around either.

User avatar
Expert Member

Posts

Joined
Tue Apr 05, 2011 12:09 pm
Location - Asheville, NC

Post by mc49285 » Sat May 12, 2012 4:49 am

Is that what I tell the host, that my PHP session temp file is being emptied when that should not happen? I was surprised today that I could not install pro_mysql.so on my server because the file did not exist on my server and that sort of file should be there for me to control. That got me wondering what else I am missing. Thanks for your help.

New member

Posts

Joined
Wed Mar 14, 2012 7:28 am

Post by mc49285 » Sat May 12, 2012 12:26 pm

Would it be useful to post my server copy of php.ini? I have a WHM front end to the server, so what I see in the option to configure the options for PHP, may, or may not, represent the entire file. Further, I have no idea what the base php.ini file open cart is tested against.

New member

Posts

Joined
Wed Mar 14, 2012 7:28 am

Post by mc49285 » Mon May 14, 2012 12:00 am

Email from server management, still get timeout message after this change:


The PHP handler enabled in your server is DSO. So it not possible to set PHP values for your site using a custom php.ini file..

---------
Available handlers: suphp dso cgi none
DEFAULT PHP: 5
PHP4 SAPI: none
PHP5 SAPI: dso
SUEXEC: enabled
RUID2: not installed
---------

When using PHP as an Apache module, you can change the PHP parameter values for single domains using directives in .htaccess files.


Some PHP scripts suggest using "php_value" or "php_flag" commands in .htaccess files, as in this example:

-------------
php_value include_path ".:/usr/local/lib/php"
php_flag display_errors Off
php_value upload_max_filesize 2M
-------------


We have now set your required PHP values by adding the following values in .htaccess file under "/home/metrodar/public_html":

========
php_flag magic_quotes_gpc Off
php_flag register_globals Off
php_value default_charset UTF-8
php_value memory_limit 64M
php_value max_execution_time 18000
php_value upload_max_filesize 999M
php_flag safe_mode Off
php_value mysql.connect_timeout 20
php_flag session.use_cookies On
php_flag session.use_trans_sid Off
php_value session.gc_maxlifetime 12000000
php_flag allow_url_fopen on
========

Please verify it using the PHP info page through the following URL:

New member

Posts

Joined
Wed Mar 14, 2012 7:28 am

Post by mc49285 » Mon May 14, 2012 11:16 am

More research only adds to my confusion... Using the DSO PHP handler means that php.ini files are useless. Using the PHP handler SuPHP means you cannot have file permissions set to 777. Open Cart uses a php.ini file and there exist firm recommendations that the image folder permissions be set to 777. That eliminates SuPHP and DSO as default PHP handler options for the server. That leaves CGI and FCGI as the only possible default server setups compatible with Open Cart.

Disclaimer: My operating assumption at this point is that the Payment process requires a particular site user, not the 'nobody' that is user for mod_PHP (DSO) on Apache, since DSO is the only handler that runs under the Apache user and not the site owner. Further proof of this is granted that DSO requires the PHP directives be put into the .htaccess file and the site will still not process authorize.net payments, still get the invalid user/password/inactive account message with that configuration.

Given a choice, I would prefer SuPHP because CGI is not safe and FCGI uses memory. FCGI stays memory resident, and SuPHP works on-demand. I have the ability to configure any of the handlers, but don't know the complete level of fallout from changing the handler, nor am I certain of how the 775 permissions of SuPHP would work with Open Cart and the required 777 permissions.

And finally, I am 24 hours from committing to another e-commerce solution. It is a simple matter of a lack of requirements information on the part of Open Cart (if a particular server feature is required...), and the fact that I must commit a response to the client on Monday.

New member

Posts

Joined
Wed Mar 14, 2012 7:28 am

Post by mc49285 » Tue May 15, 2012 1:17 am

It is the position of the web hosting company that given the 'requirements' of Open Cart, that either DSO or SuPHP should work. That tells me that I am on the wrong track in looking for a solution.

New member

Posts

Joined
Wed Mar 14, 2012 7:28 am

Post by Avvici » Tue May 15, 2012 4:59 am

Dude, I told you. If you install Skype which is "free" I would fix it for you. :joker:

User avatar
Expert Member

Posts

Joined
Tue Apr 05, 2011 12:09 pm
Location - Asheville, NC

Post by mc49285 » Tue May 15, 2012 6:24 am

It seems pointless to install Skype on a computer without a camera or microphone, but I have done it. Find me at my username. Thanks if you do, the techs at my host have been hacking at this for a while.

New member

Posts

Joined
Wed Mar 14, 2012 7:28 am

Post by mc49285 » Tue May 15, 2012 6:25 am

Plus, I did not know you could 'fix' this, I was thinking more along the lines of empathy and perhaps humorous pity. :)

New member

Posts

Joined
Wed Mar 14, 2012 7:28 am

Post by Avvici » Tue May 15, 2012 6:57 am

mc49285 wrote:Plus, I did not know you could 'fix' this, I was thinking more along the lines of empathy and perhaps humorous pity. :)
It's no skin off my back. If you have your doubts then move on. I thought I could help you because I have been using A.net for nearly 10 years. Good luck to you.

User avatar
Expert Member

Posts

Joined
Tue Apr 05, 2011 12:09 pm
Location - Asheville, NC

Post by mc49285 » Tue May 15, 2012 7:01 am

Never intended to offend with those remarks. Thanks either way.

New member

Posts

Joined
Wed Mar 14, 2012 7:28 am

Post by mc49285 » Wed May 16, 2012 11:08 am

Well, the response back from the host was disappointing to say the least. The transaction are being sent to authorize.net, but they say the transactions are being rejected - which means that authorize.net does not have the test environment setup properly. Seems hard to imagine since the help desk folks at authorize.net were arrogantly confident that everything was fine.

The specific response is below, posting in case something else jumps out at any of you reading this:

Code: Select all

However these configuration files has no effect in the FastCGI environment you currently have. So I went ahead and adjusted system wide PHP config to create environment that appears to be required by your shopping cart and, it looks like, what it really needs is to have magic_quotes_gpc option turned Off. Once this was done session files started to contain more content which appears to be correct at this point of time.

I have also traced PHP engine that serves your script and confirmed that connection to auth.net is being established and is not rejected or anything to that extend. After that I started to play with the code and found that "(TESTMODE) The merchant login ID or password is invalid or the account is inactive" message is returned by this line in the store/catalog/controller/payment/authorizenet_aim.php file:

*************
if ($response_data[1] == '1') {
...
} else {
$json['error'] = $response_data['4'];
}
....
*************

and here is the complete printout of the array returned by auth.net in the "item number: value" format:
************
1: 3
2: 2
3: 13
4: (TESTMODE) The merchant login ID or password is invalid or the account is inactive.
5: 000000
6: P
7: 0
8: 
9: 
10: 506.65
11: 
12: auth_capture
13: 
14: 
15: 
16: 
17: 
18: 
19: 
20: 
21: 
22: 
23: 
24: 
25: 
26: 
27: 
28: 
29: 
30: 
31: 
32: 
33: 
34: 
35: 
36: 
37: 
38: 3C377FE676969738B0D9105310BF71BA
39: 
40: 
41: 
42: 
43: 
44: 
45: 
46: 
47: 
48:
49: 
50: 
51: 
52: 
53: 
54: 
55: 
56: 
57: 
58: 
59: 
60: 
61: 
62: 
63: 
64: 
65: 
66: 
67: 
68: 
************

out of everything listed above these two lines would be the most important ones:


3: 13
4: (TESTMODE) The merchant login ID or password is invalid or the account is inactive.


This error code (13) along with the error message matches with this auth.net's KB article: https://support.authorize.net/authkb/index?page=content&id=A415&pmv=print&impressions=false - according to the article you have to specifically request test account to play with their test servers and looks like either test account was not requested or wasn't provisioned to their test servers so they're rejecting your test authorization attempts.

New member

Posts

Joined
Wed Mar 14, 2012 7:28 am
Who is online

Users browsing this forum: Bing [Bot] and 66 guests