Building an ecommerce site has become remarkably trivial over the last five years. The proliference of open source shopping carts and turn-key merchant processing means that retailer can now run a powerful retail Website. This combination is intoxicating as smaller merchants have rushed to compete with Internet Goliths like Amazon. The idea of a 24 hour sales machine can make the average small business owner salivate.
Unknown Territory, Unexpected Risk
What many small businesses ( Level 4 merchants, less than 20,000 transactions ) fail to recognize is the risk PCI poses. If you are unfamiliar, PCI ( Payment Card Industry ) has set forth a set of guidelines, PCI DSS ( Data Security Standard ) for providing a safer retail environment. PCI DSS compliance covers online and offline credit card handling. If you accept plastic at your business, you should read up on PCI ( https://www.pcisecuritystandards.org/ ). If you are currently running an online shopping cart or are considering opening one, please consider what PCI means to you and your business.
PCI DSS sets guidelines for compliance including:
| Build and Maintain a Secure Network | 1. Install and maintain a firewall configuration to protect cardholder data |
| 2. Do not use vendor-supplied defaults for system passwords and other security parameters | |
| Protect Cardholder Data | 3. Protect stored cardholder data |
| 4. Encrypt transmission of cardholder data across open, public networks | |
| Maintain a Vulnerability Management Program | 5. Use and regularly update anti-virus software on all systems commonly affected by malware |
| 6. Develop and maintain secure systems and applications | |
| Implement Strong Access Control Measures | 7. Restrict access to cardholder data by business need-to-know |
| 8. Assign a unique ID to each person with computer access | |
| 9. Restrict physical access to cardholder data | |
| Regularly Monitor and Test Networks | 10. Track and monitor all access to network resources and cardholder data |
| 11. Regularly test security systems and processes | |
| Maintain an Information Security Policy |
12. Maintain a policy that addresses information security |
SOURCE: Wikipedia: http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard
Failing to meet PCI guidelines can result in:
- Fines of $500,000 per data security incident
- Fines of $50,000 per day for non-compliance with published standards
- Liability for all fraud losses incurred from compromised account numbers
- Liability for the cost of re-issuing cards associated with the compromise
- Suspension of merchant accounts
The Real World Problem
I've worked with many merchants over the last several years and it is common for them to NOT understand PCI DSS. When it comes to their offline transactions, most use a modern credit card machine and follow the guidelines explained to them by the people who service them. However, many maintain customer records including their full payment card number, have no internal controls, and no written policy.
When it comes to their online store, things get really ugly. Most small businesses use consultants and freelancers to build their Websites and they rely on these "professionals" to ensure the safety of their store. Unfortunately, many small Web design and development companies don't understand PCI DSS any more than the merchants. Even if they have any experience with PCI DSS, the newest version has many changes that invalidate much of what was once acceptable.
Becoming PCI compliant can be quite costly, totalling in the hundreds of thousands of dollars. For most merchants, this is completely out of the question.
What Used to Work
In the past, a common way to set up a shopping cart for a small online merchant would include installing one of a dozen ( or more ) payment "modules" and activate with the Payment Gateway ( the company that actually accepts the card ). The payment flow would work like this:
- Customer adds products to the cart.
- When they checkout, they go to a payment form and enter their card information.
- The form POSTS back to the site, which would ( hopefully ) encrypt the data and transmit to the gateway.
- The gateway sends back a confirmation code.
This was a simple, low cost solution. The merchant does not store the card information, and if they purchased an SSL ( secure sockets layer ) certificate, the entire transaction is encrypted. This used to be the standard, and used to keep the merchant out of the PCI crosshairs.
Unfortunately, this is no longer good enough.
The New Requirements
The problem with this method, in the eyes of the payment card industry is that credit card information is transmitted through your server and your software. If your server has been compromised, the card information would be at risk. Therefore, if you want to use this method, you must ensure your server and software and business practices meet PCI guidelines.
Basically, if it touches your stuff, you are responsible.
Common Work-Arounds
The best way to protect yourself as a merchant is avoid falling into the scope of PCI DSS. If you never touch the card, how can you be accused of not handling it properly?
For online merchants, the most common solution is to send your customer to a payment page managed by your gateway. Alternately, Paypal checkout is commonly used.
Typically, this is how it works:
- The customer adds the product to their cart and clicks "Checkout".
- The cart information is sent to a checkout page on the GATEWAY's server ( or Paypal ).
- The customer enters their payment information.
- The gateway sends the customer back to your site where they enter their shipping info or are thanked for the purchase.
Obviousely, the biggest benefit here is the merchant ( and server, software, etc ) never touches the payment information, so the PCI risk is little or none.
However, there are two huge draw backs to this method:
- It creates a disjointed user experience ( the user is suddenly sent to a potentially unfamiliar site, which is scarey ) and there is a potentially high risk of them abandoning the sale.
- There is not a good way to have re-occurring transactions, such as subscriptions.
For businesses that don't have a lot of repeat sales, or their customers have a high level of trust, these may be the best solution.
Actually, I use Paypal for accepting payments on my site. For me, it is just a convenient way for customers to pay invoices. I know every person whom I invoice, and they only make payments when they receive an invoice, so I don't need to store any information, and I am not performing a lot of cross selling or other marketing.
But if you are selling goods to customers you don't know, these are major drawbacks.
Customers sent to another Website for payment are very likely to abandon the transaction. Even if the gateway allows you to customize the payment page with a logo, it is still very obviously not your site. You can manage this with some clear messaging prior to redirecting them, but in this day of online scams, customers are very wary.
And removing any possibility of re-occurring transactions makes so many businesses impossible to operate online. If you sell advertising, subscriptions, memberships or anything else where your customers pay on a regular schedule, you must have a method of billing without forcing the customer to go back to your Website and complete another transaction.
What to do?
So you've decided you want to take cards, you can't pay for PCI ( either the upfront and maintenance costs, or the fines for non-compliance ), you don't want to send customers to a third-party site or need re-occurring payments, now what are your options?
Well, we were just faced with this situation, we needed to run monthly transactions for many subscribers on a site. Luckily, the gateway the customer provided had just released a new API method that totally removes our customer from the PCI scope.
The exact details are not public, but this is how it works:
- When the customer is ready to check out, we request a URL from the gateway which we use to build our payment form.
- The customer enters their details and submits.
- The payment information is sent DIRECTLY to the gateway, it never touches our server.
- The gateway processes the transaction and sends the customer back to our site. The customer doesn't even know they left our site!
Fantastic solution, we get the benefit of having the payment form on our site, but we never touch their data.
But wait! What about re-occurring transactions?
Well, this is where things get really cool, the gateway creates a record for the customer and stores their payment information. The gateway returns a token to represent that customer which we store on our site. Now, whenever we need to process the customer's card, we send a request to the gateway with the customer's token, and the transaction is processed. And it works!
I want this!
Right now we have one production environment for one gateway. The code is built specifically for Drupal 6, and for this specific project. We plan to release it as an open source module for Drupal and Wordpress in the future, but it will need some work to become a general purpose solution. Not all of the methods available in the API have been implemented and it isn't integrated with a shopping cart ( sort of a custom payment system ).
What we are looking for are small merchants that want to implement this solution for a new shopping cart with Drupal or Wordpress. It doesn't need to be a re-occurring transaction type of store, but that is definitely a possibility. Wouldn't it be nice to offer your customer a quick checkout feature?