zxedxz Posted March 25, 2006 Posted March 25, 2006 sorry for so many questions, but i came into another problem with sessions. When i click continue to process the payment, it returns me to the loginpage with a different session id. It runs fine when it is using cookie mode thought. Anyway to fix this? Quote
mendocino95445 Posted March 25, 2006 Posted March 25, 2006 (edited) It's standard practice for ecommerce website owners to insist that the first order by a new customer is shipped to their Cardholder Statement address, and only second and subsequent orders can be shipped to a separate (shipping) address. Vger Does this script have something in place to take care of this or is it just something that the store owner should state on their sign up page? Edited March 25, 2006 by mendocino95445 Quote GB Web Hosting
♥Vger Posted March 25, 2006 Author Posted March 25, 2006 Last question first - yes, it's something you should put on your sign-up page, homepage, or somewhere in the checkout procedure. This module does require cURL - it says so in the install instructions. If you are having a problem with sessions then it's a problem with your installation and nothing directly to do with this module. Vger Quote
zxedxz Posted March 26, 2006 Posted March 26, 2006 but it works fine if i choose pay with check. Why is that? Quote
♥Vger Posted March 26, 2006 Author Posted March 26, 2006 If you are having a problem with sessions then it's a problem with your installation and nothing directly to do with this module. Vger Quote
nfrobertson Posted March 26, 2006 Posted March 26, 2006 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! :D 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); :thumbsup: 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) Quote
♥Vger Posted March 26, 2006 Author Posted March 26, 2006 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 Quote
nfrobertson Posted March 27, 2006 Posted March 27, 2006 (edited) 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 March 27, 2006 by nfrobertson Quote
♥Vger Posted March 27, 2006 Author Posted March 27, 2006 This is on the 'To Do' list, but realistically I don't have the time at the moment. Vger Quote
nfrobertson Posted March 28, 2006 Posted March 28, 2006 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. Quote
♥Vger Posted March 28, 2006 Author Posted March 28, 2006 There are over 3000 contributions - what is QBI? Vger Quote
nfrobertson Posted March 28, 2006 Posted March 28, 2006 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? Quote
Rob Baker Posted March 29, 2006 Posted March 29, 2006 Does the CVV code get captured in the db anywhere? Quote
♥Vger Posted March 29, 2006 Author Posted March 29, 2006 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 Quote
Rob Baker Posted March 30, 2006 Posted March 30, 2006 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! Quote
obakesan82 Posted March 30, 2006 Posted March 30, 2006 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! Quote
♥Vger Posted March 30, 2006 Author Posted March 30, 2006 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 Quote
obakesan82 Posted March 30, 2006 Posted March 30, 2006 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. Quote
crypie Posted March 31, 2006 Posted March 31, 2006 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. Quote
♥Vger Posted March 31, 2006 Author Posted March 31, 2006 You'll find it here, as Pay Pal IPN Tax Fix: http://www.oscommerce.com/community/contri...rce+Pay+Pal+IPN Vger Quote
crypie Posted March 31, 2006 Posted March 31, 2006 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. Quote
♥Vger Posted March 31, 2006 Author Posted March 31, 2006 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 Quote
crypie Posted March 31, 2006 Posted March 31, 2006 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 Quote
♥Vger Posted March 31, 2006 Author Posted March 31, 2006 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 Quote
crypie Posted April 1, 2006 Posted April 1, 2006 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. Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.