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

Question

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.

I'd like to add a non-technical comment that you may wish to think about

Several of my clients run e-commerce sites, including a couple who have moderately large stores. Both of those, whilst they certainly could implement a payment gateway choose not too, they take the cc number, store it temporarily encrypted online and process it manually.

They do this because of the high incidence of fraud and manual processing allows them to take additional checks before filling an order. I'm told that they reject a little over 20% of all their transactions - processing manually certainly takes extra time and in one case they have an employee who does nothing but process transactions, but the cost of paying his salary is apparently less than their exposure if they just passed cc numbers though an online gateway.

Both of these clients are delivering physical goods with resale value, so are particularly exposed and for items like software where a fraudulent sale wouldn't result in any actual loss your mileage would vary, but it's worth considering above the technical aspects of an online gateway if implementing such is really what you want.

EDIT: And since creating this answer I'd like to add a cautionary tale and say that the time is past when this was a good idea.

Why? Because I know of another contact who was taking a similar approach. The card details were stored encrypted, the website was accessed by SSL, and the numbers were deleted immediately after processing. Secure you think?

No - one machine on their network got infected by a key logging Trojan. As a result they were identified as being the source for several score credit card forgeries - and were consequently hit by a large fine.

As a result of this I now never advise anyone to handle credit cards themselves. Payment gateways have since become much more competitive and cost effective, and fraud measures have improved. The risk is now no longer worth it.

I could delete this answer, but I think best to leave up edited as a cautionary tale.

Keep in mind that using SSL to send a card number from a browser to a server is like covering your credit card number with your thumb when you hand your card to a cashier in a restaurant: your thumb (SSL) prevents other customers in the restaurant (the Net) from seeing the card, but once the card is in the hands of the cashier (a web server) the card is no longer protected by the SSL exchange, and the cashier could be doing anything with that card. Access to a saved card number can only be stopped by the security on the web server. Ie, most card thefts on the net aren't done during transmission, they're done by breaking through poor server security and stealing databases.