Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Credit Card Information


cdi-buy.com

Recommended Posts

I'm using Authorize.net Gateway but I do not want the credit card information to be put into my database. I don't want to see it (I have no need) and I do not want anyone else to potentially see it. Where is the call/form/function that tells OSC to push that information into the database? I couldn't find it anywhere in the payment module itself so I'm thinking it's a generic call somewhere else, since the orders page can display money order, paypal, etc information instead if applicable.

 

Any help is much appreciated!

Link to comment
Share on other sites

Unfortunately that one doesn't seem to work. I've given it a shot and for the life of me cannot get it working. I'm not alone in that though, and there is seems to be no support for it from Ponce. :(

 

I may try to write an SQL command that deletes the information from the db automatically...but I'm a little slow on figuring things like that out.

Link to comment
Share on other sites

There are contributions to remove the CC and CVV numbers, once you view the order it's just a button click. You might be able to setup a cron job to run the script like every 30 minutes, haven't tried it though.

Installed Contributions: CCGV, Close Popup, Dynamic Meta Tags, Easy Populate, Froogle Data Feeder, Google Position, Infobox Header Entire Row, Live Support for OSC, PayPal Seal with CC images, Report_m Sales, Shop by Price Revised, SQL Updater, Who's Online Enhancement, Footer, GNA EP Assistant and still going.

Link to comment
Share on other sites

There seems to be something not working right with the one you are using, since it should not store any cc info..unless in debug/test mode....

Link to comment
Share on other sites

There are contributions to remove the CC and CVV numbers, once you view the order it's just a button click. You might be able to setup a cron job to run the script like every 30 minutes, haven't tried it though.

I just installed the Order Editor contribution since typing up my last post, so I can remove it that way if I have to. I was thinking of trying to run an include file or something containing an SQL query to empty all CC tables when the "contratulations!" order confirmation page is loaded but I'm not sure if that would work...I don't know at what point the CC info is placed in the db. If I can find that, maybe I can even eliminate it happening in the first place.

Link to comment
Share on other sites

There seems to be something not working right with the one you are using, since it should not store any cc info..unless in debug/test mode....

Actually it's an OSC thing. OSC by default plugs the CC info into the DB. Bad....very bad.

 

Anyway, somewhere along the line I found a post with info on how to make OSC X out all but the last four digits of the CC number right off the bad so I think that'll be fine. Only had to change one line of code too, so I'm pretty happy about that. lol.

Link to comment
Share on other sites

Actually it's an OSC thing. OSC by default plugs the CC info into the DB. Bad....very bad.

 

Anyway, somewhere along the line I found a post with info on how to make OSC X out all but the last four digits of the CC number right off the bad so I think that'll be fine. Only had to change one line of code too, so I'm pretty happy about that. lol.

 

 

No, its not a osc thing....Its something wrong with the module you are using....

 

 

No payment modules for any gateway should save the cc info in the db.

 

 

The old authorize modules did save the cc info in the db...but the newer versions should not do so....

 

And actually if you read your authorize.net TOS agreement i think its actually mentioned that you should not store the cc info.

Link to comment
Share on other sites

No, its not a osc thing....Its something wrong with the module you are using....

 

 

No payment modules for any gateway should save the cc info in the db.

 

 

The old authorize modules did save the cc info in the db...but the newer versions should not do so....

 

And actually if you read your authorize.net TOS agreement i think its actually mentioned that you should not store the cc info.

With the modification, I'm not storing the cc number. The db never gets the actual information because it places the X's in the database from the word go. I'll likely take it a step further though and have it do the same thing for the CVS and expiration date as well, assuming this modification can be applied to those fields as well. I will of course delete everything when I see an order and process it if this mod doesn't work for the other fields, but this is for that time in between getting the order and actually seeing it since I don't sit at my computer 24/7 waiting for the next order to be placed.

 

If you had read my original post completely you would have seen that it's not my idea to store the information in the first place...I'm trying to NOT do that. Unfortunately I'm not a PHP guru so I can't just yank it out right away myself. I have to find workarounds here and there, hence the point of starting this thread. I also cannot get Ponce's contribution to work (I'm not alone in that) so I had to use Vger's, which did not modify OSC to not store the information.

Link to comment
Share on other sites

By the way,

 

The modification that I had to make to conceal the CC number is in a native OSC file... checkout_process.php. Yeah, the module wasn't written to encrypt that information, but OSC was written to accept, store, and display it in plain text. That makes it an OSC thing...as well as a module thing.

Link to comment
Share on other sites

By the way,

 

The modification that I had to make to conceal the CC number is in a native OSC file... checkout_process.php. Yeah, the module wasn't written to encrypt that information, but OSC was written to accept, store, and display it in plain text. That makes it an OSC thing...as well as a module thing.

 

That function is for the default cc module and for test and debugging...

 

A payment module for a payment gateway should not use those save functions at all...or simply post just an empty value for it.

 

You can have a look at this version from the authorize aim contrib too:

 

XXXX for credit card number jasonabc 3 Feb 2007

 

The AIM module sends full credit card numbers in unencrypted, plain-text format straight into the ORDERS database table.

 

This very quick edit replaces the middle digits with XXXX's before it is inserted into the database.

 

This is a patch, NOT the full package

 

 

From what you say, it appears that the authorize.net aim module is in need of some modifications to make if compliant with both PCI regulations and Authorize.net's TOS.

Link to comment
Share on other sites

Ahh sweet relief. I figured out that I could eliminate the entry of ANY CC information right off the bat in checkout_process. I had no idea it'd be such a simple workaround (since I don't use any other means of CC processing).

Link to comment
Share on other sites

That function is for the default cc module and for test and debugging...

 

A payment module for a payment gateway should not use those save functions at all...or simply post just an empty value for it.

 

You can have a look at this version from the authorize aim contrib too:

 

XXXX for credit card number jasonabc 3 Feb 2007

 

The AIM module sends full credit card numbers in unencrypted, plain-text format straight into the ORDERS database table.

 

This very quick edit replaces the middle digits with XXXX's before it is inserted into the database.

 

This is a patch, NOT the full package

 

 

From what you say, it appears that the authorize.net aim module is in need of some modifications to make if compliant with both PCI regulations and Authorize.net's TOS.

Yeah I think Vger's needs work to be 100% right out of the gate, but Ponce's doesn't seem to work at all. By making the mod I made (basically telling OSC to leave the DB blank), I'm pretty sure that takes care of PCI compliance and the a.net TOS.

Link to comment
Share on other sites

Yeah I think Vger's needs work to be 100% right out of the gate, but Ponce's doesn't seem to work at all. By making the mod I made (basically telling OSC to leave the DB blank), I'm pretty sure that takes care of PCI compliance and the a.net TOS.

 

 

If you have not already done so, i suggest you write up a modified module with instructions and upload it...it would help others who wish to use the aim version... :-)

 

 

It might be that the ponce module only work on RC1 and RC2...

Link to comment
Share on other sites

Well I didn't change the AIM module itself. I changed checkout_process.php...and that would possibly kill other modules. I'll upload some instructions for those not using any other CC options or not needing to debug, etc though.

 

Thanks for your help...I didn't mean to get snappy if it came across that way. It didn't occur to me that the CC info in the DB may be necessary for test/debugging.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...