Payment Processors - What do I need to know if I want to accept credit cards on my website?

I went through this process not to long ago with a company I worked for and I plan on going through it again soon with my own business. If you have some network technical knowledge, it really isn't that bad. Otherwise you will be better off using Paypal or another type of service.

The process starts by getting a merchant account setup and tied to your bank account. You may want to check with your bank, because a lot of major banks provide merchant services. You may be able to get deals, because you are already a customer of theirs, but if not, then you can shop around. If you plan on accepting Discover or American Express, those will be separate, because they provide the merchant services for their cards, no getting around this. There are other special cases also. This is an application process, be prepared.

Next you will want to purchase an SSL certificate that you can use for securing your communications for when the credit card info is transmitted over public networks. There are plenty of vendors, but my rule of thumb is to pick one that is a brand name in a way. The better they are known, the better your customer has probably heard of them.

Next you will want to find a payment gateway to use with your site. Although this can be optional depending on how big you are, but majority of the time it won't be. You will need one. The payment gateway vendors provide a way to talk to the Internet Gateway API that you will communicate with. Most vendors provide HTTP or TCP/IP communication with their API. They will process the credit card information on your behalf. Two vendors are Authorize.Net and PayFlow Pro. The link I provide below has some more information on other vendors.

Now what? For starters there are guidelines on what your application has to adhere to for transmitting the transactions. During the process of getting everything setup, someone will look at your site or application and make sure you are adhering to the guidelines, like using SSL and that you have terms of use and policy documentation on what the information the user is giving you is used for. Don't steal this from another site. Come up with your own, hire a lawyer if you need to. Most of these things fall under the PCI Data Security link Michael provided in his question.

If you plan on storing the credit card numbers, then you better be prepared to put some security measures in place internally to protect the info. Make sure the server the information is stored on is only accessible to members who need to have access. Like any good security, you do things in layers. The more layers you put in place the better. If you want you can use key fob type security, like SecureID or eToken to protect the room the server is in. If you can't afford the key fob route, then use the two key method. Allow a person who has access to the room to sign out a key, which goes along with a key they already carry. They will need both keys to access the room. Next you protect the communication to the server with policies. My policy is that the only thing communicating to it over the network is the application and that information is encrypted. The server should not be accessible in any other form. For backups, I use truecrypt to encrypt the volumes the backups will be saved to. Anytime the data is removed or stored somewhere else, then again you use truecrypt to encrypt the volume the data is on. Basically where ever the data is, it needs to be encrypted. Make sure all processes for getting at the data carries auditing trails. use logs for access to the server room, use cameras if you can, etc... Another measure is to encrypt the credit card information in the database. This makes sure that the data can only be viewed in your application where you can enforce who sees the information.

I use pfsense for my firewall. I run it off a compact flash card and have two servers setup. One is for fail over for redundancy.

I found this blog post by Rick Strahl which helped tremendously to understand doing e-commerce and what it takes to accept credit cards through a web application.

Well, this turned out to be a long answer. I hope these tips help.

Ask yourself the following question: why do you want to store credit card numbers in the first place? Chances are that you don't. In fact, if you do store them and manage to have one stolen, you could be looking at some serious liability.

I've written an app that does store credit card numbers (since the transactions were processed offline). Here's a good way to do it:

• Get an SSL certificate!
• Create a form to get CC# from the user.
• Encrypt part (not all!) of the CC# and store it in your database. (I'd suggest the middle 8 digits.) Use a strong encryption method and a secret key.
• Mail the remainder of the CC# to whoever processes your transactions (probably yourself) with the ID of the person to process.
• When you log in later, you will type in the ID and the mailed-out portion of the CC#. Your system can decrypt the other portion and recombine to get the full number so you can process the transaction.
• Finally, delete the online record. My paranoid solution was to overwrite the record with random data before deletion, to remove the possibility of an undelete.

This sounds like a lot of work, but by never recording a complete CC# anywhere, you make it extremely hard for a hacker to find anything of value on your webserver. Trust me, it's worth the peace of mind.

The PCI 1.2 document just came out. It gives a process for how to implement PCI compliance along with the requirements. You can find the full doc here:

https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml

Long story short, create a separate network segment for whichever servers will be dedicated to storing CC info (usually DB server(s)). Isolate the data as much as possible, and ensure only the minimum access necessary to access the data is present. Encrypt it when you store it. Never store PAN's. Purge old data and rotate your encryption keys.

Example Don'ts :

• Don't let the same account that can lookup general info in the database look up CC info.
• Don't keep your CC database on the same physical server as your web server.
• Don't allow external (Internet) traffic into your CC database network segment.

Example Dos:

• Use a separate Database account to query CC info.
• Disallow all but required traffic to CC database server via firewall/access-lists
• Restrict access to CC server to a limited set of authorized users.