Hello,
I need to make a form to get credit card numbers.
To confirm booking of rooms in a small hostel, we ask customers to give us there credit card number.
Generally people send it by mail but it seems to be dangerous.

I would like to make a https page with some form fields to get the CC and expiration number.

Is this as easy as buying a ssl certificat and make a https://mydomain.com/form.html page?

where can I buy this certificate for a good price?
is there some tutorial to make this kind of page?

Thanks in advance for youe advices :)

I would like to make a https page with some form fields to get the CC and expiration number.

Not sure how your are configured now with your web site, hosting, etc but first you will need to ensure you meet PCI guidelines before collecting credit card numbers from your customers.

More information here: https://www.pcisecuritystandards.org/

If you are already PCI compliant, ensure your form comes from and submits to your PCI enabled environment, that the card number is encrypted and only authorized personnel have the ability to decrypt the card number. There are lots of other things to deal with. You may want to consider not using a web form and collecting the number by phone to avoid dealing with the expense of PCI.

Hey Asco,

I'd really recommend Machform by Appnitro for forms. It's very easy to make them with that one. I tried a lot of them and quickly got frustrated with mail handlers, formmail and the rest. The SSL is easy to get with your web host, prices have really come down compared to many years ago.
The most important thing is to make sure the form results are sent to an email box at the domain you have the certificate at. Also that you receive your email with SSL enabled. Otherwise the data gets exposed to packet sniffers which scan for 15 and 16 digit credit card numbers and can be intercepted.

Nick

The last post is helpful in that it brings to light the security needs for encrypting during transport but overlooks encryption while stored. Section 4.2 of the Payment Card Industry Data Security Standard (DSS) states "Never send unencrypted PANs by end-user messaging technologies (for example, e-mail, instant messaging, and chat)".

The problems you are going to experience if you receive credit cards via form and send via email are:


The form needs to be on a PCI compliant host, i.e. it will need to have pen-test, vulnerability scans, host ids, network ids, lots and lots of standards, logging, log monitoring, etc, etc. Just by putting a form on a web page and receiving card data directly you move yourself into needing the FULL PCI requirements.
When receiving the form and converting it into an email, if you store the form data on disk while you process it, you are required by PCI to encrypt it while it is stored; if you are just converting to an email and "sending live" keep in mind that email systems cache every message; so you will need to encrypt every message uniquely. Just sending via an email system that supports SSL is not enough (that and if the email system is "internal" to the network where the form is being received it is not required to be encrypted via SSL or other transport technologies on internal networks. I would strongly recommend it but it is not required. What is required is that the email itself be encrypted.

One of the biggest problems with emailing card data is that every mail server that receives / processes the email will have the card data stored while it is processing. And then there is never a guarantee that the email, once processed, will be removed from the system. It could be forwarded, copied for compliance archives, or just put in who knows where by your exchange server or other mail server.

This is why section 4.2 of the DSS exists; if you are going to email card data it needs to be encrypted. The most common method is to incorporate pgp or gpg into your form processing. However unless you pipe it directly, then you will most likely create a file that stores the card number / email while it is creating an encrypted version. Once you store it, it needs to be stored encrypted; so you are going to have to use an encrypted file system or have your mail for incorporate gpg/pgp directly and pipe it to the application and be sure to not hit the disk while encrypting the data.

If you use an encrypted disk, be sure to check DSS section 3.4 for requirements on the types and ways you are required to handle & use encrypted disks.

If you do store the form data on disk while processing it, you will also need to securely wipe the data as required by DSS section 9.10.2 "Verify that cardholder data on electronic media is rendered unrecoverable via a secure wipe program in accordance with industry-accepted standards for secure deletion, or otherwise physically destroying the media (for example, degaussing)."

And I forgot to notice if you were collecting the CVV data on the form. If so, you could also be not complying with DSS section 3.2.2 which states "Do not store the card verification code or value (three or four digit number printed on the front or back of the payment card) used for verifying card not present transactions". Now you can probably find some way of handling the CVV but the issue comes anywhere it is stored.

If you are just receiving the card to hold a room in a hotel then you will have the card present on checkout then I would just recommend not using CVV but just the PAN for holding the reservation and then checkout the customer with their card in hand.

All of this leads me to ask, what you are doing with the form once the card number is received. I would strongly recommend reading through the PCI-DSS as what I have quoted are only a few items that you are required to do if you are storing/transmitting/processing or connecting to systems that store/transmit/process cardholder data.

I recommend contacting a QSA or someone who is knowledgeable on PCI and cardholder requirements and security before attempting to collect credit card numbers on your form.

As the hotel probably already process credit cards in person (via a terminal or PC), it would be best to integrate a payment processing script into the website. One that collects the data on a secure form and transmits it to a processing gateway (say, Authorize.net). The gateway would process the data and send it to the hotel's existing merchant account.

This all assumes the host and gateway are PCI compliant.

Thank you very much to all!

yes I understand that getting the number on the server with a secure form is only a little part of the problem. after that, sending it to the hotel by mail is another big question, more of that, a web site with this kind of form become a good target for hackers...

So I think I'll keep using phone to get my CC.

Thank you very much!
Asco

First, find a solution that allows you to store tokens, not real card information. Once the card information has been tokenized, you can use it just like the real credit card information but you don't have the risks associated with storing the sensitive data.

Second, find a solution that both your property management software and your web site can both use (as well as any other POS system the property might have). This way you can negotiate with merchant service providers your best rate for the entire property.

Point #1 is really the biggest one to worry about -- use tokenization and don't store card information. And make sure the tokenization solution can handle the transactions in a similar fashion to how the property currently handles the transactions. If they charge a single night up front, most solutions handle this without issue. If the propery simply holds onto the card information and only bills the card upon a no-show, many solutions cannot handle this and you have to do a little research on the solution.

Good luck. Hope this helps.

There are some existing scripts/services for running reservations. Some like Checkfront are a hosted solution. I remember seeing a wordpress plugin as well.