On Dec 19, 2007 2:41 AM, Keith Spiller <[EMAIL PROTECTED]> wrote: > Ok I've done some research and some thinking. What about storing orders in > the database (product info and customer info) and then using GnuPG or PGP to > send the credit card info to the merchant? This way the credit card > information is not stored on the server or in the database but only in > printed format by the merchant. Since my client processes all of the credit > card orders by hand this seems like an ideal solution.
I had a client that did offline (manual) processing of credit card orders as well. With liability issues and the problems that others have already pointed out, storing the credit card information was not an option, yet my client still needed some way of having the data available offline. Consider the following: ISSUER LENGTH Diner's Club/Carte Blanche 14 American Express 15 VISA 13 or 16 MasterCard 16 Discover 16 Security checks aside (like making sure they selected the type of card and that it matched the algorithm - VISA beginning with 4 and being strlen($_POST['cardnum']) == 13 or 16, MasterCard being 16, beginning with 51xx to 55xx, et cetera), I then had a hybrid of storage and delivery. Mail the first <? rand(4,6); ?> digits to the sales email address(es) on file. Three addresses on two domains were used for redundancy in this case. Store the remaining digits in the database. You could write your own encryption algorithm or use one that is publicly-available and reversible (Blowfish is what I was using, at 128, key length of 56 lower ASCII characters, padded with 7 on the key and four on the output - MD5, SHA1, et al are NOT options here). The sales department then received the first digits of the credit card number via email, which stated it was an order key. Again, in my case, I wrote an algorithm that would encrypt these digits prior to sending, using the actual order number as a key. The accounting software I wrote (all in PHP) would then retrieve the latter half of the credit card number from the database, decrypt the first part of the credit card number from the email (entered by the sales team on an SSL-encrypted page), and the credit card number would be displayed in full on the screen, to print, process, or verify. The downside is that, if there are any problems with email and delivery, the first $n digits of the card might not be received by the sales department. While, to date, I'm not aware of this having been a problem for my client (knock on wood), it's still a possibility. For this reason, you need to be sure to either have the email address confirmed prior to processing the order, or require a valid telephone number, so that you can reach the customer in the event of a failure. To assure the customer that you are calling legitimately, you will still have the last digits of the credit card, as well as the expiration data and CVV number (also stored in the database), the billing address, and the date and time the order was placed. It may not work for you, but that's how I created the system for my client in 2004, and it's still being used today, with almost $8 Million in online sales. [pats self on back] ;-P Now if I could just go back and renegotiate my contract for that gig.... -- Daniel P. Brown [Phone Numbers Go Here!] [They're Hidden From View!] If at first you don't succeed, stick to what you know best so that you can make enough money to pay someone else to do it for you. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php