On 4/9/07, siavash1979@xxxxxxxxx <siavash1979@xxxxxxxxx> wrote:
Thanks a lot every one. These are great replies. I guess I should have explained a bit more about what I'm doing. first of all, this is not my site, it's for a client of mine. second, I did suggest using a paypal API or a paid site to take care of this, but my client said no. She has a credit card processing account and how she works with it right now, is that interested users email her, she calls them, gets their credit card info and charges their card manually without the card present. so, this is not really my problem, it's what she's been doing before and wants to continue doing. All she asked me to do is that as part of the form that people send their requests through, now she wants their credit card info as well. So that she doesn't have to call them. And the reason I'm keeping cc info in the session for a few steps, is to take them to confirmation page, and then the reciept page. and after wards, I want to keep it in there untill the client logs in to the admin page and sees new requests, charges them and then deletes them for ever. So now I've got two different responses, some people say do it, but use encryption/decryption methods, and some people say don't do it. But if I don't do it, that means I tell my client that I can't do it and I lose the job. Thanks again, Siavash Quoting Travis Doherty <travis@xxxxxxxxxxxxx>: > Jochem Maas wrote: > > >unless you are a payment gateway or a bank don't touch credit card numbers. > >there are plenty of threads in the archive of this list that give good > reasons > >not to e.g. being sued out of existence. > > > > > 100% agreed. Never touch credit card numbers. You can't just take > credit card numbers and manually process them in 'card not present' > transactions (or MOTO in more archaic terms.) You need a merchant > account that allows for this -- usually at a higher discount rate. > Check the merchant agreement. > > Your client should get an account like this, or better yet, provide you > with the instructions on how to integrate his site with the payment > providers so that you never have to worry about credit cards. > > As an additional note... Maybe your SSL cert secures the numbers from > the client to the server, and just maybe your PHP scripts have no > security flaws in them, but you must remember the server itself and > everything else outside of PHP. What if someone found a flaw in the FTP > server for example, or the mail server even, and used that to get the CC > info. I would hate to be explaining to a list of 1000 clients that I > was responsible for their card numbers being stolen. > > Travis Doherty > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Did you know sessions are just plain text files sitting on the webserver in most cases? So by putting a credit card in the session it is actually just cleartext for people to read. Also if for some reason you think the benefits of this job outweigh the chances that something could go wrong and the credit cards are compromised, make sure all pages that deal with this are SSL. So on the end-user side where they send data in and on the side where your client checks them. Also make sure to have something that purges the credit cards after X amount of days or after a transaction has been processed. The company I work for deals with lots of people like this who are stuck in their ways on "I already have a working system." The problem is that the liability is too high to do something on this level without serious thought into security. I think you should try to do a better job of convincing your client that a payment gateway that does a capture is the only way to go because it would change having the liability of credit cards laying around in temp files for sessions and databases. You could get it down to existing only once for $_POST and curl it away and be done. People generally do budge once they realize that the heavy hand can come down hard on them. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
