Re: [PHP] Getting Credit card details

2005-04-27 Thread John Nichel
Ross wrote:
Here's what I want to do..
Uh-Oh, here we go again.
--
John C. Nichel
ÜberGeek
KegWorks.com
716.856.9675
[EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[PHP] Getting Credit card details

2005-04-26 Thread Ross
Here's what I want to do..

I want to take Credit card details from customers number, expiry, 
security number and send them to my client who will put these through his 
card terminal in his place of business.

Any suggestions how to do this?

Secure Email, SSL any ideas will be gratefully accepted.


Ross 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Getting Credit card details

2005-04-26 Thread Richard Lynch
On Tue, April 26, 2005 5:10 pm, Ross said:
 Here's what I want to do..

No, you just *THINK* you want to do that :-)

 I want to take Credit card details from customers number, expiry,
 security number and send them to my client who will put these through his
 card terminal in his place of business.

 Any suggestions how to do this?

Don't

 Secure Email, SSL any ideas will be gratefully accepted.

Making the email secure is simple enough.

You could use encrypt to encrypt it with the public half of a key-pair.

Then, at the other end, your client has to have the private half of the
key-pair, and use it to decrypt the data, and run it through.

And therein lies the problem.

Who has access to that private key?
Where will it be stored?
How will it be input to the computer, and then erased?
Who will be able to see the decrypted data?
Is his POS right next to his computer, or will he print it out, and then
carry it to the POS and run it through?
What happens to the print-out?

Sending the email securely is not the issue:  Keeping the CC#s safe at the
other end, is a HUGE issue, completely outside your control.

To do this PROPERLY, you'll need to come up with a 10-page manual, with
Process and Workflow and Policies and Procedures, and run through a
training program every employee who has to run the CC#s and...  And this
all has to be done with a very careful eye on SECURITY.  *MOST*
credit-card fraud is not on-line.  It's from minimum-wage short-term
employees on the paper-based system.  Just like you think you want to use.
:-)

Yet, if something goes wrong, guess who can be held responsible?

Yup.  You.

Last I heard, if YOUR programming causes CC#s to leak, *YOU* can be held
responsible for the losses.  Think about that long and hard, my friend.

Your client already has a Merchant Account with some bank somewhere. 
That's how he has the terminals already.

Dollars to doughnuts says that Merchant Account has an upgrade path that
lets him start taking orders on-line.  And you can do that safely with an
SSL server and any stock shopping cart you can download.

If his existing account won't let him upgrade to add on-line, there are
innumerable banks out there only too happy to take a cut for your on-line
Sales.

It may cost him a few more pennies, but the SECURITY of having the CC# not
be exposed is well worth it.

-- 
Like Music?
http://l-i-e.com/artists.htm

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php