Forum Moderators: buckworks

Message Too Old, No Replies

Credit Card Capture - Best Practices

         

neophyte

12:28 pm on Feb 10, 2008 (gmt 0)

10+ Year Member




Hello All -

I've got a client that wants to capture credit card details of those who are interested in his products. Currently, people just email him their credit card details and he hand-processes them one by one.

When I brought up the possibility of using a CC gateway service where card balances could be verified and amounts would be credited to his account, he doesn't want to get nicked on each transaction (apparently his margin is quite low - or so he says). Anyway, he came back to emailing the details as he is currently comfortable with which made me wonder about two things:

1. If a Versign (or other) certificate was installed on his site - I've never ventured into these waters before - I'm under the impression that private details are safe upstream (from the users computer to the email box on my clients server) but they could (I suppose) be compromised when my client retrieves his mail from his server. Is this correct?

2. Another option I was going to fling at him was to install a certificate AND then dump the CC details into a DB table. Then only he would have access to this information unless someone found out his back-end password.

I'd appreciate any commentary about options 1 and 2 above, as well as how it's REALLY done in the real world so that I'm generally better informed.

Great appreciation in advance!

Neophyte

Morgenhund

11:21 pm on Feb 10, 2008 (gmt 0)

10+ Year Member



Both options are bad, very bad.

E-mail communications are insecure, install Verisign or not. Period.

Store CC details into DB is a very bad idea -- unless you are able to invest into security heavily.

The only scheme I can imagine here (not very secure as well, but better than other options).

Clients use SSL-enabled web-form on his web-server (yes, you have to have Verisign there) for clients to post their CC info. This info must be encrypted by form-processing software on-the-fly (without to be stored on HDD) with a public key and sent to his e-mail in that form. Then he should use an encryption-enabled e-mail client to read these e-mails with his private key.

If strong encryption is not implementable, e-mails should be read using SSL/TLS enabled e-mail client.

Both web-server that posts data and a computer that is used to read encrypted mail must be dedicated to these purposes, and not for anything else (no web-browsing with that client computer, not even opening any e-mails other that encrypted from web-server, no hosting of other web-sites on that web-server). Appropriate security should be applied to that web-server (a book can be written about that, if you do not have much experience here, scan it with HackerSafe to reveal the dummiest security holes). Let a security-aware programmer to look at your script code that encrypts CC info.

Once CC data is on his client computer, print it on paper and erase the data.

This is still a weak scheme, since once web-server is hacked, someone can substitute your script to send CC data somewhere else -- but it's better than dump CC data into DB, where a lot of data is collected, prior to be stolen at once.

I am also sure there should be 3rd party e-billing products, that can do this trick for you as well.

Btw, faxing CC data is much more secure and less expensive than the way I described above -- why not to do it?

neophyte

11:59 pm on Feb 10, 2008 (gmt 0)

10+ Year Member



Morgenhund -

Thank you so much for your detailed reply. All of that encryption and private key stuff sounds like a mess (and improbable that my client would go for it from a technical as well as financial standpoint). I'm not sure I'd want to get into it from a technical standpoint as well - that sort of security option is well above my technical expertise at this point.

Faxing is an alternative that I hadn't thought of - is there a way to collect data using a webform and then FAX that data to a fax number simular to the way one sends an email? I'll post that question in the PHP forum to find out.

So, considering your reply, is a 3rd party payment gateway the safest and most reliable way to transmit CC data?

Neophyte

Quadrille

1:30 am on Feb 11, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



If the site is fairly small-scale - as I guess it must be to have survived the email risks so far! - the best bet is Paypal or Google checkout.

Neither have a monthly fee, but there is, of course, a transaction fee.

Both are easy to install, user friendly and known to most internet shoppers.

While email is theoretically unsafe, the chances of loss via email in the real world are pretty low. But should it happen, the thief will likely do it on a big scale!

Personally, I wouldn't touch a fax machine (or other last-century technology) with a bargepole ... but if the target readership are likely to have a fx standing by, it may be worth considering.

For most sites, fax would be the kiss of death, and should only be considered as one of several options. Txt messaging would be infinitely superior for consumer items.

[edited by: Quadrille at 1:34 am (utc) on Feb. 11, 2008]

Morgenhund

11:15 am on Feb 11, 2008 (gmt 0)

10+ Year Member



Neophyte: yes, 3rd party is the best option. Like Quadrille said, you can use PayPal or Google Checkout, since there is no cheaper option on the market.

Yes, you can send faxes from web form. But it will require your web-server be connected to landline using a special card adaptor -- and setting this configuration up is not a trivial task. There certailny are gateway services to forward your web data to fax or mobile phones, however.

Another option could be sending short messages (SMS) using mobile phone, as Quadrille suggested. It should be as secure as fax, but without its limitations.

Fax might be superior, if your customer's client base is business/small business, otherwise SMS should be great.

rocknbil

4:40 pm on Feb 11, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



I would become a little more versed on why this is such a liability for your client and convey this information to him. Put it in these terms: is your convenience worth the risk of fines that may easily exceed $30K USD and having a bill set in your lap for all transactions in arrears that you capture by methods other than card present?

If you client re-reads his contract for his merchant account, it will be very explicit in explaining that capturing CC info by any other method than card swipe or phone in will be subject to severe penalties, the least of which will be termination of the merchant account and the very real possibility he may not be able to get an account with any other company. It will also state that storing credit card info requires a PCI compliance audit. This is why online credit card processing is more expensive than offline transactions, it's a whole different account.

I know this stuff goes on all the time, but it is dangerous to both the customer and client. Even the methods you describe - storing CC info on a secure server - is only partly sufficient.

PCI Compliance Guide [pcicomplianceguide.org]

Wlauzon

5:38 pm on Feb 11, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



[quote]... he doesn't want to get nicked on each transaction ...[/quote}

Nicked how?

He is paying CC merchant fees already, so what would he get "nicked" for if he did the online capture and verification?

We have a B & M store and an online store. The difference between card swiped and card not present is about .6% for us.

And as others have said, both of the options in your original message are bad.

[edited by: Wlauzon at 5:39 pm (utc) on Feb. 11, 2008]