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. probably irrelevant from a legal pooint of view. > > 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. tell her 'PAYMENT PROVIDER OR BUST'. :-) > > 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. you think you want this, but you don't. > > 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. does your client have a million dollar budget (including cash surplus to handle lawsuits and fines from banks or CC companies) to design and administer the security of the complete software stack that the CC will be handled by and stored on? no I didn't think so, ergo don't go down this route .... anyone tell you its a good idea (regardless of encryption) needs their head examined. > But if I don't > do it, that means I tell my client that I can't do it and I lose the job. > good, dont take the job. some one else will take the blame when things go seriously wrong (assuming she can find anyone to take the job.) and leaves you to doa project that won't make you bankrupt. > > > 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
