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?
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.
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';
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';
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...
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...
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:
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
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.
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.
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.
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.
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.
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.
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.
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:
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:
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.
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.
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.mc49285 wrote:Plus, I did not know you could 'fix' this, I was thinking more along the lines of empathy and perhaps humorous pity.
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:
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.
Who is online
Users browsing this forum: Amazon [Bot] and 85 guests