ajmcdonald Posted November 29, 2006 Share Posted November 29, 2006 Hi, I have been using this contribution for a while now and it has been working great (mostly). I have been having ossacional trouble though with some customers being incorrectly rejcted with an error (Red banner accross the top of the checkout page) saying their credit card was rejected because the card validation code was invalid. I have even tried to help the customer by trying to do the checkout for them myself and doublecheck that everything is correct and still the same error. If I run their card manually throug the Authoize.net virtual terminal it goes through OK. (CCV not required there) I even have tried unchecking all four CCV options to reject on my Authorize.net account.. Does NOT Match (N) Is NOT Processed (P) Should be on card, but is not indicated (S) Issuer is not certified or has not provided encryption key (U) and still the client gets the error. Then (and this part is really frustrating..) I went into the Authorize.net AIM Module configuration and disabled even asking for the CCV number and the error occured again! So my question is 2 parts.. 1 - Why are valid CCV numbers being rejected about 5% of the time? Even when I don't have any rejection options set in the Authorize.net settings. 2 - Why can't I turn off the CCV option to get around the issue? Hope someone can help. Thanks, Andy Quote Link to comment Share on other sites More sharing options...
ValleyRoaster Posted November 29, 2006 Share Posted November 29, 2006 On my store it now takes 2 tries to get the card info to go through. Here is the error code I get back There has been an error processing your credit card. Please try again.Credit card number is required.: 33 When I enter it the second time it works fine. I had to turn register_globals back off when my host changed to php5. I am thinking this is where it may have started. Any ideas on a fix? My store has been live for almost 4 years and I would like to get this fixed before the Christmas rush is over! Quote Life Is Too Short, Enjoy Your Coffee! Pete Link to comment Share on other sites More sharing options...
♥Vger Posted November 29, 2006 Author Share Posted November 29, 2006 (edited) You'll either have to turn Register Globals back 'on' via a root level .htaccess file (only on Apache servers with mod rewrite enabled): php_flag register_globals on Or else create a file called php.ini and put it in the root of your web with this in it: register_globals = On Vger Edited November 29, 2006 by Vger Quote Link to comment Share on other sites More sharing options...
ValleyRoaster Posted November 29, 2006 Share Posted November 29, 2006 You'll either have to turn Register Globals back 'on' via a root level .htaccess file (only on Apache servers with mod rewrite enabled): php_flag register_globals on Or else create a file called php.ini and put it in the root of your web with this in it: register_globals = On Vger I had to turn register_globals off to get my store to work at all. I am guessing I need to do the register_globals contrib to get the entire site fixed. I really do not have much time to do this. I also hold a fulltime job as a carpenter as well as run my web site and roast coffee and ship the equipment I keep in stock. Do you have any recomendations for a php software editor to hire? Just to do some updating like this. Quote Life Is Too Short, Enjoy Your Coffee! Pete Link to comment Share on other sites More sharing options...
♥Vger Posted November 29, 2006 Author Share Posted November 29, 2006 Even if you install the Register Globals Patch you'll find that most contributions are not written to work with Register Globals 'off'. Best to use a host that allows them 'on'. Vger Quote Link to comment Share on other sites More sharing options...
ValleyRoaster Posted November 29, 2006 Share Posted November 29, 2006 Even if you install the Register Globals Patch you'll find that most contributions are not written to work with Register Globals 'off'. Best to use a host that allows them 'on'. Vger Thanks Vger, My host updated to php5 and turned on register_globals that's when my site quit working completly, so I had to turn it off to get anything to work. I am going to try this contib, phpini-copy.php and see if that works. It just looks like the easy and fast fix for my heavily modified store. 4 years of tinkering and no updating may have gotten me into a little trouble! Quote Life Is Too Short, Enjoy Your Coffee! Pete Link to comment Share on other sites More sharing options...
♥Vger Posted November 29, 2006 Author Share Posted November 29, 2006 I don't know why hosts are upgrading to PHP 5 when the PHP project is going to drop it. The next big thing is going to be PHP 6 and support for 5 will be discontinued - they've already said that. Vger Quote Link to comment Share on other sites More sharing options...
ValleyRoaster Posted November 30, 2006 Share Posted November 30, 2006 I just turned register_globals on and I get the same result. On the first try after entering ALL the card info after clicking the confirm button I get the error code 33 and it takes me back to the payment page with no card info entered. It works fine the second time. I have to believe I am losing a LOT of sales over this! Any new ideas? Quote Life Is Too Short, Enjoy Your Coffee! Pete Link to comment Share on other sites More sharing options...
Guest Posted November 30, 2006 Share Posted November 30, 2006 I just turned register_globals on and I get the same result. On the first try after entering ALL the card info after clicking the confirm button I get the error code 33 and it takes me back to the payment page with no card info entered. It works fine the second time. I have to believe I am losing a LOT of sales over this! Any new ideas? a good idea to avoid losing sales at this time of the year might be to tun on the module credit card manual processing as an emergency, and use your authnet vitrual terminal. Deal with your host and php5 after the holidays! Quote Link to comment Share on other sites More sharing options...
♥Vger Posted November 30, 2006 Author Share Posted November 30, 2006 Unfortunately the default osCommerce credit card validation is so many years out of date that a large number of cards will get rejected - because it doesn't have the updated card number issues. I agree that it's a very bad time of year for this to happen, but another drawback with the CC module is that it stores card data in the osCommerce database which will put the owner of the site in violation of the new rules on credit card security insisted on by the card companies - and by law in many countries (UK and USA for certain). Vger Quote Link to comment Share on other sites More sharing options...
Guest Posted November 30, 2006 Share Posted November 30, 2006 (edited) Unfortunately the default osCommerce credit card validation is so many years out of date that a large number of cards will get rejected - because it doesn't have the updated card number issues. I agree that it's a very bad time of year for this to happen, but another drawback with the CC module is that it stores card data in the osCommerce database which will put the owner of the site in violation of the new rules on credit card security insisted on by the card companies - and by law in many countries (UK and USA for certain). Vger ahem :-) Take a look at THIS: it comes from the database populated with your AIM module;-) Edited November 30, 2006 by pixclinic Quote Link to comment Share on other sites More sharing options...
ValleyRoaster Posted November 30, 2006 Share Posted November 30, 2006 I just did the fastest update I have ever done with the Authorize.net AIM and it works just fine! I will do a couple more trials just to make sure. Quote Life Is Too Short, Enjoy Your Coffee! Pete Link to comment Share on other sites More sharing options...
♥Vger Posted November 30, 2006 Author Share Posted November 30, 2006 It's been a while since I worked on this - but I think that is actually caused by the default osCommerce 'orders' functionality - but I will have to go back and check it out when I have the time. There's no reason for Authorize Net to store card data. Vger ahem :-) Take a look at THIS: it comes from the database populated with your AIM module;-) Quote Link to comment Share on other sites More sharing options...
Guest Posted November 30, 2006 Share Posted November 30, 2006 Just curious but does any body run XAMPP ? It's a all in one apache, mysql, php + perl package for Linux, Mac, and Windows. I was just wondering if anybody uses that and oscommerce with this module and could get it to work. Quote Link to comment Share on other sites More sharing options...
♥Vger Posted November 30, 2006 Author Share Posted November 30, 2006 I use it for an offline web server (Intranet) for test purposes. I wouldn't use it to run an online server. Vger Quote Link to comment Share on other sites More sharing options...
Guest Posted November 30, 2006 Share Posted November 30, 2006 I use it for an offline web server (Intranet) for test purposes. I wouldn't use it to run an online server. Vger Ok cool thanks for your input ! Quote Link to comment Share on other sites More sharing options...
whodah Posted December 1, 2006 Share Posted December 1, 2006 (edited) It's been a while since I worked on this - but I think that is actually caused by the default osCommerce 'orders' functionality - but I will have to go back and check it out when I have the time. There's no reason for Authorize Net to store card data. Vger maybe a modification of: catalog/checkout_process.php in the $sql_data_array around line 60 or so, change: 'cc_number' => $order->info['cc_number'], to 'cc_number' => "XXXX-XXXX-XXXX-".substr($order->info['cc_number'],strlen($order->info['cc_number'])-4), or something? the cc_number field in the orders table is already set to varchar(32), so the X's shouldn't freak it out i wouldn't think. thoughts? Edited December 1, 2006 by whodah Quote Link to comment Share on other sites More sharing options...
Guest Posted December 1, 2006 Share Posted December 1, 2006 maybe a modification of: catalog/checkout_process.php in the $sql_data_array around line 60 or so, change: 'cc_number' => $order->info['cc_number'], to 'cc_number' => "XXXX-XXXX-XXXX-".substr($order->info['cc_number'],strlen($order->info['cc_number'])-4), or something? the cc_number field in the orders table is already set to varchar(32), so the X's shouldn't freak it out i wouldn't think. thoughts? if you do this, you will pass Xes to Authnet It is actually more complex as it may appear: the checkout process MUST contain all the data - including the CC number, because this is where we pass it to authnet. The CC wipe must occur when authnet passes back the OK to Oscommerce, there must be an update on the order table that deletes the number afterwards, as opposed as "during" the checkout process. So the CC number will be written in the table temporarily, then deleted when authnet has processed the transaction. Vger, what do you think? Quote Link to comment Share on other sites More sharing options...
♥Vger Posted December 1, 2006 Author Share Posted December 1, 2006 As I said before it does come down to the 'update orders table' that takes place when the transaction comes back. I am reticent to alter the whole basic functionality of osCommerce, but with the rules that the credit card companies have in place now (and laws in some major countries) the situation where a site on a shared server (as most are) stores credit card data not only leaves the site owner liable to be blacklisted by the card companies - but the hosting companies can even get the server the site is on seized by police forces. This has already happened. The unfortunate side-effect is that all other websites on the same server go down as the police are in physical possession of the server. The basic rules (laws) are: 1. You must not store card data on your server or, if you do 2. It must be stored on a separate server to the one the site is hosted on, used only for that purpose, it must be heavily firewalled and undergo an annual security audit by qualified professionals (very expensive). What this means is that the osCommerce default Credit Card module should never be used. Vger Quote Link to comment Share on other sites More sharing options...
Guest Posted December 1, 2006 Share Posted December 1, 2006 As I said before it does come down to the 'update orders table' that takes place when the transaction comes back. I am reticent to alter the whole basic functionality of osCommerce, but with the rules that the credit card companies have in place now (and laws in some major countries) the situation where a site on a shared server (as most are) stores credit card data not only leaves the site owner liable to be blacklisted by the card companies - but the hosting companies can even get the server the site is on seized by police forces. This has already happened. The unfortunate side-effect is that all other websites on the same server go down as the police are in physical possession of the server. The basic rules (laws) are: 1. You must not store card data on your server or, if you do 2. It must be stored on a separate server to the one the site is hosted on, used only for that purpose, it must be heavily firewalled and undergo an annual security audit by qualified professionals (very expensive). What this means is that the osCommerce default Credit Card module should never be used. Vger At this point, the default CC module and this AIM are in the same basket: CC numbers are stored... so we need to find a solution. What about storing encrypted (I should say encoded) credit card numbers? (I know the salt can be found anyway if somebody really diggs the server, but..) Quote Link to comment Share on other sites More sharing options...
♥Vger Posted December 1, 2006 Author Share Posted December 1, 2006 As far as the card companies are concerned it doesn't matter if the card numbers are encrypted or not. Card numbers which are encrypted in the db can be found unencrypted if someone accesses them from the admin panel. Vger Quote Link to comment Share on other sites More sharing options...
Guest Posted December 5, 2006 Share Posted December 5, 2006 So I've narrowed down a problem I was having with my previous hosting company. Which name I will exclude from this post. It goes like this, I could not get this contribution to work for the life of me, I would keep getting this generic error every time I made a CC transaction no matter what I did. On a whim I decided to try OSC with this contribution on a different account of mine with the same hosting company but it's on a different server completely and it worked, right out of the box, I was shocked and the only difference that I and the hosting company could find was this. (works) /usr/bin/php (which is 4.4.3 CGI) (doesn't work) /usr/local/bin/php (which is 4.4.4 CLI) They used CLI library's for the Ubersmith software. I am not saying that this is the problem for everybody out there, but it seems to have been my problem, at least that is all we could find as a difference between the two servers , 1 worked the other didn't so we went down the list to see what wasn't the same. Now I am curious for those who have both of these libraries installed is there a way to determine which one to use in the contribute script? or .htaccess file without having to go through all the trouble with your hosting provider, are there any variables or lines we could add to set it to the CGI. Because my other server has both of them and I still can't get this contribution to work on it because I don't know how to tell the script to use the "/usr/bin/php" CGI path not "/usr/bin/php" CLI path. I hope this information help's somebody out, and I also hope somebody can help me out on this. Thanks! Happy Holidays! :lol: Quote Link to comment Share on other sites More sharing options...
ValleyRoaster Posted December 6, 2006 Share Posted December 6, 2006 As far as the card companies are concerned it doesn't matter if the card numbers are encrypted or not. Card numbers which are encrypted in the db can be found unencrypted if someone accesses them from the admin panel. Vger I was using an older Advanced Integration Method Contrib that did NOT store the card info. Why does this newest one? I need to get this corrected fast! I don't like having anyones financial info stored on my server. Quote Life Is Too Short, Enjoy Your Coffee! Pete Link to comment Share on other sites More sharing options...
Iggy Posted December 6, 2006 Share Posted December 6, 2006 I was using an older Advanced Integration Method Contrib that did NOT store the card info. Why does this newest one? I need to get this corrected fast! I don't like having anyones financial info stored on my server. Hmmm, Looking at Austin Renfroe's old AuthorizenetConsolidated_1.7.12.zip (which doesn't store CC numbers) it seems he had made a change in checkout_payment to monkey the fields around in process. I just had a quick look. Not sure exactly. Here's the old AuthorizenetConsolidated_1.7.12.zip contrib for perusal if it's useful. Iggy Quote Everything's funny but nothing's a joke... Link to comment Share on other sites More sharing options...
jonw118 Posted December 7, 2006 Share Posted December 7, 2006 I'm having a big problem here in the middle of busy holiday sales. I've had numerous people calling to tell me they are getting an error "Card Code Invalid" when the 3 digit code is 100% correct. I tried one of these myself- and it came back with the error "Card Code Invalid...". But here's the kicker, I called Authorize.net and nothing was declined- in fact this order never made it their way to even decline it. I did run that same card thru the virtual termincal with the CVV and worked fine. But, lots of cards are going through... it's very, very odd. I really hope someone can help cause this is costing big holiday sales right now. Quote Link to comment Share on other sites More sharing options...
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.