992 replies to this topic

[nfrobertson]

I just got this contrib to work on my windows test server. Running "Apache/1.3.34 (Win32) mod_ssl/2.8.25 OpenSSL/0.9.8a PHP/4.4.1" on Windows XP

FIRST let me say THANKS! to Vger for an excellent contrib!

Enable cURL for PHP on windows
First thing I had to do was to enable cURL for php on windows. I'm running the standard windows binaries for PHP 4.4.1 - I did not compile my own. After some googling on this topic, I found this resource page cURL with PHP and Apache on Windows Using my PHP version 4.4.1, I found that there is a php_curl.dll in my C:\php\extensions directory. In my php.ini file that resides in my apache webserver directory I made the following edits:

Establish the PHP Extensions location

; Directory in which the loadable extensions (modules) reside.
extension_dir = C:\php\extensions

Enable the cURL extension (remove the ; comment in front of this line)

extension=php_curl.dll

Once cURL was enabled for Apache on windows I was able to start testing this contrib.

Fix the error_message issue (STS bug?)
I first ran into the error_message in the URL but not on the page. This, for me, turned out to be a possible issue with STS. header.php was not capturing the GET params and adding them to the messageStack so STS didn't have it to display. I fixed that and the expected error_message then showed up at the top of the $content area. Click HERE to read more about how I fixed this.

Fix the blank response from Authorize.net issue
The next issue was the constant blank response. This results in an error message that is only the language file text since no error is received from the gateway. I think we should test for a blank response and take some sort of different action. Maybe log an error for the webmaster and/or add a message like "technical difficulties - contact the store owner" to the front of the error message so the customer doesn't think it's their fault when the gateway doesn't return a response.

To resolve the blank response issue, I first downloaded and extracted the ca-bundle.crt file from the latest curl distribution at cURL download page and put this file in my c:\php\extensions folder. I then added the CURLOPT_CAINFO line to includes\modules\payment\authorizenet_aim.php

$ch = curl_init();
	  
curl_setopt($ch, CURLOPT_URL,$url);
curl_setopt($ch, CURLOPT_VERBOSE, 0);
curl_setopt($ch, CURLOPT_CAINFO, 'C:\php\extensions\ca-bundle.crt'); // blank response fix
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $data);
curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);

$authorize = curl_exec($ch);

This resolved that issue and I was *finally* able to make connections to the Authorize.net server!

Test Mode
I tried both the https://certification.authorize.net and https://secure.authorize.net and they both worked with my Authorize.net account in TEST mode. One difference I found was that Authorize.net did not generate any emails for my test transaction to https://certification.authorize.net Once I switch back to https://secure.authorize.net then it started sending emails as expected.

Configuration
As far as configuration goes, I just followed Vger's excellent install.html and setup my Authorize.net settings as indicated (version 3.1 and Delimited Response=No Default Field Separator=,(comma) and Field Encapsulation Character=blank)

[Vger]

Thank you for your postive comments.

The issues with cURL only seem to apply when people use Windows servers. I haven't yet seen an instance on an Apache server when the standard module code for locating cURL does not work.

Vger

[nfrobertson]

Vger,

Now that I have this module running and am about ready to launch my store, I'm faced with the age old osc dilemma about credit card number security. Currently, the number is put into the DB in clear text. I do have mcrypt on my test server and on my isp's system. Is there are recommended way to mcrypt the cc_number and stuff it into the DB? I see mcrypt has several "flavors" so I'm wondering if there's a straight forward way to handle this?

Thanks!

Edited by nfrobertson, 27 March 2006, 22:02.

[Vger]

This is on the 'To Do' list, but realistically I don't have the time at the moment.

Vger

[nfrobertson]

Vger,

I found an issue between Authorize Net AIM (GPL) and the QBI contrib. Click Here to read about it.

Basically, QBI is scanning the payment modules language files for the partial string "TEXT_TITLE" which all the default osc payment modules have. Authorize Net AIM (GPL) has implemented different titles for the admin area vs catalog area using variable slightly different from the default payment modules.

To work around this, I just added another define to the languages/english/modules/payment/authorizenet_aim.php file which looks like:

// Admin Configuration Items
  define('MODULE_PAYMENT_AUTHORIZENET_AIM_TEXT_TITLE', 'Authorize.net AIM'); // FIX for QBI not "seeing" Authorize.net AIM
  define('MODULE_PAYMENT_AUTHORIZENET_AIM_TEXT_ADMIN_TITLE', 'Authorize.net AIM'); // Payment option title as displayed in the admin

Do you see any problems doing this? Since your contrib doesn't use that variable I'm hoping it's not an issue.

Maybe this could be added to a future version of Authorize Net AIM (GPL) to keep it compatible with QBI?

Thanks for your help.

[Vger]

There are over 3000 contributions - what is QBI?

Vger

[nfrobertson]

Vger, on Mar 28 2006, 02:21 PM, said:

There are over 3000 contributions - what is QBI?

Vger

Sorry. QBI is the QuickBooks Import contrib by Adam Liberman. You can find the contrib HERE and the support forum HERE (see the last page). HERE is my post regarding the issue between these two contribs.

Anyway, basically is comes down to the variable that the default payment modules define for their "*TEXT_TITLE" that QBI looks for. Your contrib modifes that slightly to *TEXT_ADMIN_TITLE and *TEXT_CATALOG_TITLE. I worked around the issue via my last post by adding the definition of the *TEXT_TITLE also...

// Admin Configuration Items
define('MODULE_PAYMENT_AUTHORIZENET_AIM_TEXT_TITLE', 'Authorize.net AIM'); // FIX for QBI not "seeing" Authorize.net AIM
define('MODULE_PAYMENT_AUTHORIZENET_AIM_TEXT_ADMIN_TITLE', 'Authorize.net AIM'); // Payment option title as displayed in the admin

It seems that this could be added to the next version of Authorize Net AIM (GPL) and that will keep it compliant with the other payment modules.

Thoughts?

[Rob Baker]

Does the CVV code get captured in the db anywhere?

[Vger]

Nathan - I'll bear that in mind for the next update.

Rob - there's no need to capture the cvv in the database, and it would be a bad move anyway (security wise). The website just needs to know that Authorize Net has validated the CVV for that card number.

Vger

[Rob Baker]

Vger, on Mar 29 2006, 07:08 AM, said:

Nathan - I'll bear that in mind for the next update.

Rob - there's no need to capture the cvv in the database, and it would be a bad move anyway (security wise). The website just needs to know that Authorize Net has validated the CVV for that card number.

Vger

While it may be a bad security move, it has merits too. For example: sometimes I need to modify an order (we do a lot of custom items to the poducts we sell), then I have to hit their credit card again (with their permission ofcourse). Currently I have to go into my ANET config and disable the "Code Card Verification" so that I can run the additional money, then turn the "Code Card Verification" back on.

I do not see any more harm in capturing the code, we are already retaining the card number and expiration date.

I do not want to sound negative here, I think this contrib is great! This has made my life much easier! Thanks!

[obakesan82]

Hello,

First let me say this is a great module and I appreciate the work that's been put into it. I have a curious problem that is proving difficult for me to figure out. I have the latest version of CCGV (Coupon Code/Gift Voucher Contribution) installed along with the Authorize.net AIM module for payment. Payment module works with authorize.net just fine. CCGV works fine in terms of correctly calculating the totals, etc. Here is the strange part: The amount passed to authorize.net is the total order without the coupon applied. So the order shows up correctly in the order confirmation page, in the email receipt, and in the order logged into the admin area. But the charge that shows up in the authorize.net interface shows the full amount not the discounted amount. Any ideas? Has anyone gotten the AIM module to work with the Coupon Module? Thanks for the help and a great module!

[Vger]

There are similar problems with CCGV and the osCommerce Pay Pal IPN module. If you go to Contributions and go to the osCommerce Pay Pal IPN module you will find a post which provides a workaround for using CCGV with Pay Pal IPN - maybe you can adapt this to use with Authorize Net AIM.

Vger

[obakesan82]

Vger, on Mar 30 2006, 08:11 AM, said:

There are similar problems with CCGV and the osCommerce Pay Pal IPN module. If you go to Contributions and go to the osCommerce Pay Pal IPN module you will find a post which provides a workaround for using CCGV with Pay Pal IPN - maybe you can adapt this to use with Authorize Net AIM.

Vger

Thanks! I will give that a try.

[crypie]

I'm seeing a similar problem with CCGV and this contribution. The order total is being calculated correctly everywhere - except in the value being submitted to Authorize.net.

I know you mentioned th paypal IPN fix but I'm not sure I see the exact one you're looking at. Could you point us in that direction or provide any other pointers in why this might be happening?

I look in my database and see the correct total so I'm stumped as to why the wrong one is being sent to Authroize.net!

Thanks.

[Vger]

You'll find it here, as Pay Pal IPN Tax Fix:

http://www.oscommerce.com/community/contri...rce+Pay+Pal+IPN

Vger

[crypie]

Vger -

I took a look at this contribution. I want to run my thought process by you & see if I'm on the right track.

It looks like I need to add some code in your before_process() function along these lines:

include(DIR_WS_CLASSES . 'order_total.php');
$order_total_modules = new order_total;
$order_totals = $order_total_modules->process();


If I understand this code, it will run the functions for determining the order total. I'm still unclear how to pull that final total back out. I'm still trying to work that out.

Am I on the right track?

Thanks.

[Vger]

I'm sorry, but other than suggesting a possible place to look I haven't got the time at the moment to resolve difficulties with CCGV and a whole variety of payment modules.

Vger

[crypie]

Vger -

Fair enough. I noticed you've now started a new CCGV contribution. Does yours work correctly with the Authorize.net contribution? If so, I could look at converting to the newer module.

Thanks for your patience

[Vger]

CCGV(trad) is an older version of CCGV which has been updated with a few added extras. I haven't tested it against Authorize Net AIM.

Vger

[crypie]

Vger -

Well, after many hours of tracking down my problem, I figured it out. Like most things it's pretty simple.

I needed to make sure that in checkout_process.php the call to $payment_modules->before_process() happened after the call to $order_total_modules->process()

My code now looks like this:

$order_totals = $order_total_modules->process();

// load the before_process function from the payment modules
$payment_modules->before_process();

before_process() was calculating the totals before the discounts were applied with $order_total_modules->process()

Seems embarassingly simple but I figured I'd post it back here in the hopes that it helps someone else out or that it can be included in future ccgv updates.

Thanks.