• London

    Sweeps Building, 6-7 St Cross Street,
    London. EC1N 8UA

  • New York

    442 Broadway, 2nd Floor,
    New York, NY 10013

PCI compliance for taking payments on your e-commerce site - what you need to know

Growth Secrets|06.08.2013

The Payment Card Industry Data Security Standard (PCI DSS) was adopted by the Payment Card Industry Council in 2005 with the aim of protecting card holder data used during online payments.

It is backed by American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa.

Merchants are required to conform to a set of standards including:

  • Website and server vulnerability checks by Approved Scanning Vendors (ASVs)
  • Company security audits
  • Self assessment questionnaires (SAQs)

These are provided by a handful of internet security companies, appointed and recognised by the PCI standard backers.

Scope of this article and terminology

PCI DSS extends to any time a business takes payment via card. In this article, we will be discussing PCI DSS mainly within the scope of taking payment on an e-commerce website.

Onsite form - the form is provided by your servers and you process the card data, typically by sending it through to a payment gateway in the background.

Offsite form - the form is running on an external server provided by the payment gateway.

Onsite payment - the cardholder enters their details within your website and does not leave your checkout process. In the background, card details are transmitted to a payment gateway for approval and for making the actual payment, the gateway returns a result confirming whether or not the payment was taken. The customer never leaves your website.

Onsite payment with card storage - as above, but the customer's card details are stored for next time so they can complete their order quicker. The PCI requirements for this are extensive due to the security risks of storing card data.This is not trivial and involves passing the Payment Application Data Security Standard (PA-DSS).

Offsite payment - at some point during the checkout, the customer is redirected to a third party payment page provided by your payment gateway to complete payment, before returning to your website once payment has been completed.

Payment via offsite iframe - This one is quite confusing because the credit card form appears as if it is onsite but it is actually an offsite form shown through an iFrame. The iFrame is showing a third party payment gateway's payment form. This effectively mimics 'onsite payment', but has less stringent PCI requirements because you aren't actually hosting the credit card form, it is offsite.

What does becoming PCI compliant involve?

The standard requires the following as of v2, the current version:

GoalRequirements
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
  1. Protect stored cardholder data
  2. Encrypt transmission of cardholder data across open, public networks
Maintain a Vulnerability Management
  1. Use and regularly update anti-virus software or programs
  2. Develop and maintain secure systems and applications
Implement Strong Access Control Measures
  1. Restrict access to cardholder data by business need-to-know
  2. Assign a unique ID to each person with computer access
  3. Restrict physical access to cardholder data
Regularly Monitor and Test Networks
  1. Track and monitor all access to network resources and cardholder data
  2. Regularly test security systems and processes
Maintain an Information Security Policy
  1. Maintain a policy that addresses information security for employees and contractors

Just to make things more confusing: 

The PCI SSC sets the PCI DSS standard, but each card brand has its own program for compliance, validation levels and enforcement.

And the same is true for each major payment gateway. However, passing PCI DSS usually boils down to the following:

  • Choosing a Qualified Security Assessor (QSA) to audit your businesses operations to ensure they meet the standard.
  • Filling out a Self-Assessment Questionnaire (SAQ). 
  • Having your website scanned by a Qualified Security Assessor (QSA).

If you're lucky enough to be taking offsite payments only, you may only need to complete an SAQ.

Easy. Read on for more information on each of those.

A common misconception

A  common misconception is:

"Since I don't store credit card information, I don't have to be PCI compliant"

Unfortunately, the PCI DSS standard does not just apply to the storage of credit card data but also to the handling of data while it is processed or transmitted over open networks i.e. the internet.

However, not storing credit card data does eliminate some compliance requirements.

There is a good list of further misconceptions (and truths) about PCI here.

About covered parties

You may hear 'Covered Parties' mentioned by your payment gateway provider. If you a retailer, this includes your:

  • Employees
  • Agents
  • Representatives
  • Subcontractors
  • Processors
  • Service Providers, including Point-of-Sale equipment, systems or payment processing solutions, as well as any other party to whom a merchant may provide access to Card holder information in accordance with its Card Acceptance Agreement. 

So, basically, everyone.

Self assessment questionnaires

As mentioned above, we are sticking to covering PCI DSS for e-commerce sites only. If this is the only place you take payments from customers, you just need to complete either:

SAQDescription

SAQ A

Download SAQ A

Card not present, all card holder data (CHD) functions outsourced.

This is the self-assessment questionnaire required if you are using offsite payment.

SAQ C

Download SAQ C

Web-Based virtual terminal, no electronic cardholder data storage.

This is the self-assessment questionnaire required if you are using onsite payment

A list of all SAQs is here.

Headaches - finding out which standard level you require

If you've looked in to PCI, even casually, you'll see it's hard to even find what level you need to conform to. Here's a summary from some major payment gateway providers.

The basic theme is that in any situation where no payment card data is entered on, passed through, or stored on a merchant's website, a PCI scan of that website or web connected database is not needed for PCI compliance. This is what we mean by 'offsite' payments.

You may still be able to take 'in checkout' payments where a customer appears to be still on your website, if you use an iFrame. Not all payment gateways offer this option.

There also various levels of PCI, which complicates things further. The lower levels, with a higher number of transactions, may require additional checks and audits to be compliant.

  • Level 1- Businesses processing 6 million + transactions per year
  • Level 2 - Businesses processing 1 to 6 million transactions per year
  • Level 3 - Businesses processing 20,000 to 1 million transactions per year
  • Level 4 - Businesses processing less than 20,000 transactions per year

Now for specific payment gateways, here are the requirements...

SagePay

Offsite

'Server Integration' is SagePay's offsite redirect solution and costs from £72/year.

They also have an offsite iframe solution called InFrame

For more information on SagePay offsite payments click here. Note that they call offsite payments, 'hosted' payments. You may notice this terminology elsewhere.

On a related note, if you are the developer of the website, SagePay state that:

...[if you are] simply integrating a client's website with our payment gateway and handing over the completed project to your client, then you don't need to become PCI DSS compliant.

Onsite

If you want to take payments onsite you'll need to pass the following. Note that most people will be Level 4, which is for merchants processing less than 20,000 transactions per year, but if you're a bigger retailer refer to the levels above.

All levels require monthly or quarterly vulnerability scanning.

Level 4 - SAQ C (see above). Online self-assessment questionnaire. Price from £175/year.

Levels 2 and 3Remote assessment and compliance validation. Requires a validated SSL certificate.  Level 3 is £3400/year, level 2 is £6375/year.

Level 1 only - onsite assessment. POA.

For more information on SagePay onsite payments click here. Note that they call onsite payents, 'self-hosted payments'.

PayPal

Offsite

PayPal's offsite solution is called PayPal Web Payments Standard. They don't give much away on their website without you signing up, but at the most you would only need to complete SAQ A to become PCI compliant. 

Onsite

PayPal's onsite solution is called PayPal Web Payments Pro.  You would need to complete SAQ C and have have monthly or quarterly vulnerability scanning in place. I believe they force you to use TrustWave for this.

Authorize.net

Offsite

Authorize.net certainly win for the most confusing service names. Their SIM method (Server Integration Method) is their offsite payment solution.

If you already have a merchant account, their monthly gateway fee is £20/month + 10p per transaction. If you want to use their merchant account, the setup fee is £50 and then £20/month gateway fee then varying fees depending on the card type, see the details here.

You would only need to complete an SAQ A to become PCI compliant using the SIM payment method. 

Onsite

Authorize.net's AIM (Advanced Integration Method) is the Authorize.net onsite solution. Pricing is the same as onsite.

You would likely need to complete SAQ C and have have monthly or quarterly vulnerability scanning in place.

Server security

Most companies host their websites with a third party hosting provider. This can make passing physical access audits difficult unless the provider is PCI DSS compliant as a Service Provider.

We use Rackspace, who are PCI DSS certification Level 1 Service Provider Compliant. The scope of Rackspace's PCI service provider accreditation covers the following:

  • UK and US data centres 
  • US and UK offices
  • Network infrastructure (routers and switches) 
  • Employee access to network devices

This is obviously an important consideration when choosing your e-commerce website host. 

Criticisms of the PCI DSS standard

PCI-DSS has been called a “near scam” by a spokesman for the National Retail Federation. The way the standard is implemented suggests it’s designed less to secure card data than to profit credit card companies, who choose a select oligopoly of "approved vendors" for vulnerability scanning and consultancy.

Implementing the PCI standard burdens smaller retailers and web agencies, forcing them to audit their website and their businesses for a fee. A study by Ponemon Institute cited in Information Week found that:

50% of security professionals view PCI as a burden, and 59% don't think it helps them improve security

Mathew J. Schwartz interviewed the president of risk and information security consulting firm IP Architects, John P. Pironti, made the point that:

Security by compliance, doesn't do a company any favors, especially because attackers can reverse-engineer the minimum security requirements dictated by a standard to look for holes in a company's defense

Sometimes it seems like the standard is unnecessarily complicated, according to Information Week:

in a survey conducted earlier this year of UK businesses by market research firm Redshift Research on behalf of Tripwire, 89% of UK companies hadn't undergone the required auditing and certification process, and 35% said they still didn't fully understand PCI.

We're trying to change this and if you have advice or feedback, please leave a comment below.

For more information on criticisms of PCI DSS, have a read of our full article 'Criticisms of the PCI DSS standard'.

Conclusion

Despite the above, since PCI DSS is a requirement of most major card companies and therefore all major gateways, it is important to pass.

Contact us to find out how out how we can help you pass PCI and generate more revenue for your business.

All information accurate as of August 2013.

How can we help?

Get in touch to discuss your e-commerce ambitions and we’ll help you get there.

Get in touch