Documentation You are here: start » primer » security

Don't Be Insecure. Be Afraid.

One of the most important requirements to e-commerce is security. Unfortunately, there's no magic bullet that will make you secure, nor is there a way to fully outsource your security (though you can radically reduce your burden by using a hosted e-commerce platform like FoxyCart). This chapter exists to inform you about potential threats, common insecure practices, and best-practices.

Security is for EVERYBODY

One of the common complaints we hear from people getting started with e-commerce is:

I couldn't care less about this technical stuff. Security isn't my job! That's what I'm paying you for!

If only it were so easy. The simple fact is that anybody with access or even knowledge of an e-commerce website can potentially put the security of the entire system at risk. For example, many people use the same password for their email, website administration, and on random sites they visit. If any one of those sites is compromised, a malicious user could potentially reroute all your hard earned sales to their own bank account. So even though we at FoxyCart take our security very, very seriously, you could still create problems if you aren't familiar with basic security concerns.

Companies both giant and teensy get attacked every day. If you have a website available to the public, we'd bet dollars to donuts that it's getting attacked by bots on a daily basis. An ounce of prevention is worth a pound of cure, and a security breach averages between $150-$200+ per stolen customer record 1) 2) (though various state and federal fines can easily double or triple that figure, depending on the residencies of the impacted customers and the nexuses of the breached company).

So, yes, we're paranoid. But that doesn't mean they're not out to get us all.

PCI DSS: What It Is and What It Means To You

What Is the PCI DSS?

If you've been looking at e-commerce or gateway solutions for more than a few minutes, odds are that you've seen references to PCI DSS. While we can't give you specific advice relating to your own compliance requirements, we can help you understand some of the more important pieces of PCI DSS compliance.

First, it's important to know that the Payment Card Industry Security Standards Council (PCI SSC) is made up of the major card payment brands like Visa, MasterCard, AmericanExpress, and a few others.3) They put together the Data Security Standard (DSS), giving us PCI DSS. There are a few different levels of PCI compliance, and determining your level of compliance can sometimes be tricky. The multiple levels of PCI compliance is further complicated by the considerable amount of FUD and outright misinformation that is used to try to make a sale, sometimes for a product or service that you may not need as a merchant.

What Are the Requirements for PCI DSS?

The two “deliverable” requirements of PCI DSS are:

  1. The Self-Assessment Questionnaire (SAQ), ranging from SAQ A through SAQ D. The SAQ A is very short, while the SAQ D has over 200 questions and requirements.
  2. The Security Scan from an Approved Scanning Vendor (ASV).

You may be told by your merchant account provider or gateway that you are required to purchase a security scan through them in order to be PCI compliant, or that paying for a service will make you compliant. That is dangerously misleading information; simply paying for a service will not make you PCI compliant, as compliance can involve things like security training, paper shredding, and business policies and procedures that simply cannot be addressed by paying a 3rd party a monthly fee. So while the SAQ and the scan from an ASV are the pieces that are required to show compliance, they aren't simply things you pay for and magically become compliant.

What Are Your Compliance Requirements?

Though we cannot tell you with certainty what your compliance requirements may be, we can offer a set of guidelines that may help you discern when you do actually need to pay for a service to become compliant (and conversely, when you're being sold misinformation or FUD).

If you're being told by your merchant account provider or gateway that you need to pay a fee to become compliant, be sure to understand the actual requirements. In many cases you may not need a scan at all, and your SAQ requirements may be quickly and easily completed without paying any additional fees.

SAQ_Level Scan_Required How you collect payments
None No
  • Payments are only handled on a 3rd party system such as through PayPal Express Checkout or Pay with Amazon through FoxyCart. (These types of payment methods are fundamentally different than a “real” gateway in that the funds are transferred first to the 3rd party (ie. PayPal), then transferred to you. PCI DSS generally only applies to merchants with a Merchant ID, receiving payments directly.)
  • Payments are fully outsourced handled through your store's FoxyCart checkout using a “real” gateway (ie. a gateway that doesn't redirect the customer to their own hosted payment page).
  • Payment card details are never handled on the phone or using FoxyCart's Unified Order Entry or with any other virtual terminal.
  • No cardholder data transmission, ever. (ie. No computer or server under your control ever touches card numbers, anywhere, ever, at all. Not even getting the numbers POSTed and immediately sending them off to a 3rd party.)
  • No cardholder data storage, ever. (ie. You never store card numbers, anywhere, ever, at all.)
  • No fees should be charged by your merchant account provider if you fall under PCI SAQ A (unless breach insurance is required, which is discussed below).
  • Payments are partially outsourced. This gets a little technical, but this applies if you're doing a direct post or javascript-based (non-iframe) implementation. In general, using FoxyCart avoids this.
  • Fees may be required for a security scan for PCI DSS §6.6.
  • These SAQs aren't applicable to ecommerce merchants.
  • Payments are handled through standalone terminals, are swiped using a dedicated machine, processed manually on an internet-connected virtual terminal, etc.
SAQ D Yes, on applicable systems
  • If you don't fit under the above SAQs, SAQ D is what you fall under.
  • Cardholder data is transmitted or stored on systems you control, regardless of the payment methods. Systems that transmit or store cardholder data will need to be fully PCI compliant and scanned by an ASV.
  • If you have servers or hosting that touches credit cards at all (even if it's just a POST to your website that then sends it to the gateway), you fall under the SAQ D. Just because you don't store card numbers doesn't mean anything.
  • This is full PCI DSS compliance, 200+ requirements, though some of them may not apply. If you can avoid this, you should. There are many solutions (including FoxyCart) that give flexibility without exposing your systems to cardholder data.

Additionally, there are different merchant 'levels' that you should be aware of if you're doing more than 20,000 Visa transactions per year.

If you can limit your exposure to PCI DSS, we recommend it. Because there is no way to get a fully branded checkout experience without at least some level of PCI compliance, we generally recommend not using any virtual terminal functionality and completing the very manageable SAQ A. If you do need to use a virtual terminal, you'll likely be required to get a bit more advanced (possibly the SAQ D, though if you're using Foxy, many of the requirements won't actually apply). The one thing you really (really) don't want to do is store credit cards on your end, as the requirements become very complex and costly. And since FoxyCart handles this storage for you, there's little reason to spend the months or years and many thousands of dollars on becoming compliant at that level.

Becoming PCI Compliant

Your PCI DSS compliance will most likely be addressed when you set up a merchant account, though sometimes it will happen after the initial setup. As mentioned above, some processors have converted PCI DSS compliance into a profit point by tacking more onto the fees.

  • Some processors charge $149 annual PCI compliance fee plus another $99 annual fee. (This is generally pure profit for the provider.)
  • Others charge up to $19.95 per month on PCI compliance fees.

Again: Simply paying for a service will not make you PCI compliant, as compliance can involve things like security training, paper shredding, and business policies and procedures that simply cannot be addressed by paying a 3rd party a monthly fee. So if your merchant account provider or gateway tries to sell you on any services, make sure you actually need them (per the table above).

Breach Insurance

Breach insurance covers the merchant and processor in the event the merchant is PCI compliant but a breach occurs nonetheless. An example is a gas station with pay at the pump. Some people go into the convenience store to buy munchies and then leave the credit card at the counter to fill up the tank. That exposes the merchant to credit card number theft by any employees working behind the counter. This type of CC theft also happens very often in restaurants when waiter/waitresses carry the cards back to the cash register.

If you are concerned about this type of issue, your merchant account provider may be able to provide this for you. Our recommended gateway partner provides breach insurance included at no extra cost (so long as you keep your SAQ up to date, which they provide a tool to assist with as well).

So What About FoxyCart's Compliance?

Please read more about how FoxyCart is a PCI compliant service provider. If you yourself need to be PCI compliant at any level, you are required to ensure that your service providers are also PCI compliant.

Summary: What to do if you're being told you need to be compliant

If you're being told you need to be compliant and you don't have time to read all of the above, and assuming you don't process cards outside of your FoxyCart setup, here's the rundown:

  1. Copy/paste this to your provider:
    We've outsourced our card handling to FoxyCart, which is a Level 1 PCI Compliant Service Provider listed on both Visa and MasterCard's registries. You can see their AOC here:
    Do you still require that we provide proof of our own compliance? If so, do you have your own tool that we should use, or will providing the SAQ A be sufficient?
  2. If they respond that they have their own tool, you should be able to fill that out. Otherwise, complete and send to them the PCI SAQ A. (Get the latest version from directly.)
  3. If they respond that you must be compliant at a higher level, or that they need proof of a passing security scan, or something else, please let us know.

One of my customers reported their card was stolen!

We occasionally get emails like the following from FoxyCart users:

We got a call a day ago from a customer who stated that his AMEX had $4K of fraudulent charges. He said that after a purchase on our FoxyCart-powered site, his credit card details were taken and then used elsewhere.

FoxyCart goes through extensive security reviews and audits constantly. We have intrusion prevention and detection. We monitor the logs. We're proactive about security. We handle millions of transactions for thousands of merchants all over the world. We receive only one or two reports of a compromised card each year.

Though it's certainly possible we have a security breach on our end, it's far more likely that your customer's computer is compromised. The customer should wipe their computer, and/or toss it and get a new one.

Where FoxyCart has numerous safeguards in place, your customer's computer is a personal computer that may or may not be running antivirus and anti-malware. The customer uses it to browse the web and may not have the latest OS and browser security updates installed. The customer uses the computer to receive email, possibly on an older or unpatched email client. The customer's computer may be available to others (partners, spouses, children, friends) who visit questionable websites, download pirated software, clicked on an email attachment they shouldn't have, etc. There are myriad ways for the customer's computer to be compromised. Once that happens, as soon as they enter a credit card number anywhere (whether that's FoxyCart, Amazon, or their gas company's website), a keylogger can grab that, send it to the attacker, and their card is immediately compromised.

If this has happened to you or your customer and you'd like to loop us in to discussions, feel free. We take this extremely seriously. It's theoretically possible that FoxyCart had a security breach, and only one single customer was impacted, but the far more likely scenario is that the customer's computer has a virus or other malware. (We once had this happen where the customer said, “I never shop online because every time I buy something online, my card gets stolen.” The problem is obvious to those of us who've spent time scrubbing malware off friends' and family's computers, but the average computer user places far too much trust in their own computer's security.)

Bad Ideas: Email and Sensitive Information

The most important misconception to address right off the bat is about email privacy and security. Simply put, email is not a secure means of communication unless it is encrypted via S/MIME or PGP (GPG). Even amongst people who know what those abbreviations actually mean they're not commonly used, for all intents and purposes you can assume that emails are fundamentally insecure.

Wikipedia has an in depth discussion of privacy and security relating to email, but here is a short summary of issues 4):

  • E-mail messages are generally not encrypted.
  • E-mail messages have to go through intermediate computers before reaching their destination, meaning it is relatively easy for others to intercept and read messages.
  • Many Internet Service Providers (ISP) store copies of e-mail messages on their mail servers before they are delivered. The backups of these can remain for up to several months on their server, despite deletion from the mailbox.
  • The “Received:”-fields and other information in the e-mail can often identify the sender, preventing anonymous communication.

To drive that home, let's imagine a single email from Alice to Bob with Alice's credit card number in it. Once the email is sent and received, the credit card is either stored by or has passed through:

  1. Alice's computer itself, keeping a local copy in the sent mail folder.
  2. Alice's mail server (like Gmail, Hotmail, etc.), which keeps a copy in the sent folder.
  3. Likely at least two or more backup servers at the mail service provider.
  4. Probably about 6-12 mail servers in between Alice and Bob. (Connections aren't A to B on the internet, but rather hop along multiple servers.)
  5. Bob's mail server.
  6. Bob's helpdesk or CRM software's database, if applicable.
  7. Bob's local computer.
  8. Bob's iPhone, perhaps.

It should hopefully be clear that if any one of those points is compromised, Alice may now be dealing with an emptied bank account, overdrafts, considerable time wasted, and etc.

Even if your company manages its own mail servers, you trust your systems administrators with your life, and you maintain strong passwords and anti-virus protection on your computers, pay attention to the second bullet point there. In order to get from the sender to you, the recipient, an email bounces across many, many servers on its way. While it's doing this bouncing it is entirely unencrypted and can be intercepted. If one of those servers has been compromised it could be looking for emails coming through with 9- or 16-digit strings (social security numbers or credit card numbers, respectively).

Have you been emailing credit card numbers and passwords back and forth for years without consequence? Possibly. Should you continue? Not at all, especially not with any data belonging to your customers (as doing so violates agreements you've made with your merchant account provider at very least, and may violate state or federal laws depending on your location and the residency of the customer in question).

The Takeaway: Email Never, ever send sensitive information over email. This includes credit card numbers, passwords, social security numbers, or anything else you'd be embarrassed or liable for should it fall into malicious hands.

TLS / SSL Encryption and Email Security

It should be noted that mail servers are increasingly supporting a protocol known as TLS (or SSL), which does actually encrypt email in transit, but not “at rest.” So the above example would change a little, and the email would be secure between Bob's mail server and Alice's. Unfortunately, not all mail servers support this, so unless you're sure that both your own mail server and your recipient's mail server support TLS, you should assume that they do not.

While TLS does help in transit, once an email arrives it is still stored in the clear on your mail server and (likely) in your email client (on your phone, desktop, or etc.). In some cases this may not be a big deal, but you still likely do not want sensitive information stored unencrypted.

“Data breach costs top $200 per customer record”,
Data Loss Calculator by
Copied from Wikipedia's email entry

Site Tools