What are the steps to take in order to securely transmit credit card information via a standard web form?

Question

I have a client who wants to be able to have new customers who sign up with them online for a delivery service to be able to submit their credit card information as well. Once the information is obtained the client will manually enter this information into their POS system at their retail store. The client does NOT want to offer clients the ability to pay online, or store credit card data, or anything else. They only want to allow the customer to submit their card information via a standard web form. What encryption will need to be done in order for this to be done securely? (BTW...I am outsourcing this task to another, but I need to get an answer to this question ASAP so I can give my client an idea as to how involved it is.) I'm trying to convince my client to use a service and not set this up locally, but I need to know what would have to happen in order to do this locally so I can show him the benefits of using a service.

Thanks

PS: Are there services that you would recommend? Are there services that you would suggest I avoid? (Thanks BTW for all of the answers I greatly appreciate everyone's time.)

Answer 1

I cannot emphasise enough that this is highly "involved".

1. You would need to be compliant with PCI DSS, since you'll be handling card data. PCI DSS is the definition of involved. I'm also unsure as to where you stand with someone actually copying this data into a PoS, but I can imagine it would be extremely difficult to generate a complaint process that includes this step.

2. Data will need to be secured in-transit, so that means configuring an SSL/TLS server to only support strong, non-vulnerable ciphers, protocols and other configuration settings. You will need to purchase an SSL/TLS certificate and keep this in-date. Furthermore, you'll need to consider any transport encryption beyond the web server... for example, you definitely cannot email this data to your copy-typer.

3. Data will need to be secured at rest (and it will need to be at rest at some point if its not being immediately passed to a separate payment processor). This means that all card details will need to be encrypted using a strong scheme, most likely involving both symmetric and asymmetric forms. Keys will need to be securely managed to prevent the data from being accessed.

4. A secure Card Data Environment (CDE) needs to be established - a highly secure network that is segregated from other business areas. Access to this would need to be tightly controlled.

5. Both the web application (form) and the network infrastructure need to be regularly tested/reviewed for security vulnerabilities, which then have to be managed and resolved.

This really only scrapes the surface. Try the PCI DSS requirements for a full understanding of the steps involved in securely handling card data.

It would be significantly easier and cheaper, especially for a small operation, to utilise a 3rd party service that have already undergone these processes. For extreme ease-of-use, an out-of-the-box service like PayPal could be used. If you're interested in using your own form, consider a service like Stripe that can handle the back-end and security. These services are already PCI compliant.

Answer 2

OK.... let's assume for a second that one were to go ahead with the plan where:

• Client's customer enters CC info (CC#, ExpDate, Address, Name, CVV#) into your site
• Your Client later retrieves this data and manually enters it into a POS terminal

Besides being horribly inefficient, here are the BSDs (Big Scary Details):

• Your server is now handling AND storing Credit Card data. This means that it is now "in-scope" as far as PCI standards go. By the way, CVV data may NEVER be stored at any time... anywhere
• This data must be encrypted both in transit AND at rest on the server
• Your server must undergo periodic vulnerability scans by a PCI-approved service
• Your company must have in place specific controls for how CC data is handled
• There are a TON of additional requirements... see documentation below

Also, your Client NOW gets to see if the cards are declined and gets to figure out how to handle those situations... Much better when the approve/decline decision is made at the time of purchase.

The stuff above is pretty generic and I'm assuming this is a small business, so I'd go here to get more specifics. They will most-likely fall into category D here which means you'll need to work with SAQ D v2.0 here.

If your client doesn't soil himself after you hand him the PCI SAQ-D document... RUN.

Answer 3

You would have to be fully PCI-DSS compliant which is going to cost orders of magnitude more than the entire project would otherwise cost. They would be in breach of their merchant services agreement to take the data electronically without full PCI-DSS compliance which requires a very long list of requirements to be met. It is quite simply too complex for the project you are talking about.

Just for starters you would have to have a completley segmented network that isolates the payment details server from anything else and it would have to dump, one way in to an isolated network for storage and use of the credit card information. That information would then have to be pulled up and entered manually for processing. We're talking months of full time developer work for a skilled developer that knows what they are doing, so you are most likely talking a budget in the tens of thousands of dollars if it's a consulting gig, just for the payment form, not to mention the hardware and network costs of the needed hardware.

It will be far, far cheaper for them to use a merchant gateway to provide the credit card processing, not to mention faster and more efficient. In that case, they can forward the transaction details to a payment service provider and just get back a receipt confirmation for the payment. The rates aren't going to be substantially worse than the rates they would be paying for the card not present transaction anyway.

Answer 4

I know a small vendor who started taking credit card orders by phone in 1991. Numbers were manually entered into a PC with POS software which dials a card network 800 number via modem, and is still used to this day. In 1996 they put up a web site and began capturing card numbers on order forms with plain HTTP, which the server merely saves in a text file. Those orders are manually copied and entered into the POS. In 2011 an employee downloaded and installed a tiny SSL server on a $275 notepad, just so they'd have something to serve the order form page from (because customers kept asking for HTTPS to "secure" their orders), otherwise their operations remain the same. They only do a handful of credit card orders per day, and don't use the net for card processing. PCI doesn't bother them, and they don't bother with PCI, and their development costs have been zilch, but they're conscientious about their data, and I'd trust them with my card much more than the typical restaurant or gas station.

Answer 5

All the answers so far are looking at the bigger picture of what might be done with the data after the secure transmission of a credit card number to your client, so those answers focus on all the scary details about subsequent security and compliance. However, to answer the actual question you posed, which only asks about secure transmission from a web form: you would need an SSL server (or service), which are widely available, and in minimal form can be just a handful of lines of code running on a phone or notepad. That protects the card number on its way from the web form to your machine (just like putting your thumb over your card number protects it from being seen by everyone else in the restaurant when you hand your card to a waiter), but once the card number reaches your server the transmission (and SSL protection) are over and the server (or operator) can do anything with that number (just like the waiter can do anything with your card once you've handed it over).