PCI DSS Compliance with Payment Gateway: A simple guide for e-commerce businesses

pci dss for ecommerceMagento 2 is an e-commerce platform for medium and large businesses. Merchants usually have to conduct a large number of transactions or each product might have really high value. This motivates hackers to attack stores running on Magento 2 and and put them at higher risk. This post will offer you a guide to the world of PCI DSS Compliance.

1. What is PCI DSS Compliance?

PCI DSS refers to Payment Card Industry Data Security Standard, a list of practices for merchants accepting payment to comply. By meeting PCI DSS Compliance, businesses will improve the security of card transactions and protect cardholder info from being stolen.

2. Why do I have to become PCI compliant?

Some useful case studies for you:

Heartland Payment faced approximately 12.5 million USD of fines.

Enron had to pay a whopping 225 million USD sum.

Target faced a data breach that cost them 248 million USD.

Sony suffered a loss of 24 billion USD when it customer payment info was leaked.

All of these companies failed to meet with the PCI DSS Compliance. They all ended up hurting the profit, a lot.

When stores do not employ PCI DSS compliant practices and their store get compromised, they will have to face heavy penalties.

And it doesn’t end there.

Companies have to face other consequences when they fail to protect their customer payment info.

– Credibility

In addition to financial damages, stores will also face a PR crisis. If you get your name on the news for losing your customer credit card info into the hands of hackers, no one will wants to shop at your website. E-commerce makes everything so easy, including stealing information. If it is a traditional store, thiefs can only steal a bag or a card from customers at the store. But this is online stores you are talking about. All customer info, including credit card details, can be stolen at the blink of an eye. This is thousands of customers, not just two or three customers.

– Operation

Next, banks and payment processors will likely take your merchant account away due to breach of security. Without a merchant account, you will not be able to accept any card payment. Worst of all, you will also get blacklisted on the “Terminated Merchant File”, preventing you from obtaining another merchant account for several years. And don’t even think about asking for help from friends, families or business partners. After all, your buisness info has already been registered in the blacklist.

So, to sum up, here’s what you might be faced with when failing to meet PCI Compliance:

  • Loss of customer trust and patron
  • Reduced sales
  • Penalty
  • Legal disputes
  • Termination of rights to accept payment cards
  • Job loss
  • Bankruptcy

OK. How do I become PCI Compliant?

First, you need to know what type of PCI certification that your business needs.

3. How many PCI Compliance levels are there?

There are 4 levels of PCI DSS compliance. Below is a complete list of 4 levels for PCI Compliance:

3.1. Level 1

  • More than 6,000,000 Visa or MasterCard transactions per year
  • More than 2,500,000 American Express transactions per year
  • Any MasterCard merchant who had account data compromised in the previous year
  • Any entity that handles credit card data and/or provides card processing services on behalf of other merchants

3.2. Level 2

  • 1,000,000 to 6,000,000 Visa or MasterCard transactions per year
  • 50,000 and 2,500,000 American Express transactions per year

3.3. Level 3

  • 20,000 to 1,000,000 Visa or MasterCard transactions per year
  • 50,000 American Express transactions per year

3.4. Level 4

  • Fewer than 20,000 Visa or MasterCard transactions per year (Note: American Express does not use level 4.)

If you’re a Level 1 merchant, you need to hire an auditor to verify your PCI DSS compliance.

Chances are most businesses are at level 2, 3 or 4. This means they don’t have to  hire an assessor to validate their compliance.

You are eligible to validate your PCI compliance using a Self-Assessment Questionnaire (SAQ)

But there are so many different forms of SAQ for e-commerce merchants. So which one is right for you?

It depends on the amount of risk that your payment processing & acceptance activities incur.

The PCI Council has built a total of 7 different SAQ forms to use for different types of businesses. However, for e-commerce businesses, which do not require payment card to be present, you only need to pay attention to three form types – SAQ A, SAQ A-EP, SAQ D.

4. What PCI DSS compliance level do I have to get?

For an ecommerce business, the scope of risk is related to the Card Data Environment, where you interact with payment card (receive, process and store card data). There are four factors that affect the your PCI Scope

– Storage: How you store your card data? Do you store the card data on your server or do you use a third party payment gateway?

– Transmission: how will the data be transmitted to the gateway? Does your website have SSL Certificate?

– Collection: How will payment info be collected? On customer’s browser, merchant’s server, or third-party payment gateway server?

– Processing: how will payment data be processed? Will it be processed by the merchant or by the third party payment gateway?

4.1. SAQ A

Target merchant: “Card not present merchants”, which includes any business and ecommerce businesses that do not hold, store or process cardholder data on their own. These merchants will outsource the task to a third party payment service provider that is PCI Compliance, usually payment gateway. They will not come in contact with customer’s payment info at any stage of the payment process.

4.2. SAQ A-EP

Target merchant: Ecommerce merchants that do serve a payment form on their website, and outsource the remaining tasks to a PCI Compliant third party payment gateway.

4.3. SAQ D

Target merchant: These are ecommerce firms that do not meet any of the criteria above. Service providers and merchants who do not meet the criteria for any of the above questionnaires.

5. PCI Compliance when using payment gateways

You may think that by using a payment gateway that is PCI Compliant will help you remove your PCI Compliance burden (many customers who look for payment gateway solutions at Magenest keep asking for PCI DSS certification of the payment gateway). This isn’t true. Out sourcing payment processing will not automatically remove your burden of compliance.

In fact, your PCI scope essentially depends on your card detail collection method.

Usually, payment gateways will provide you with the following ways to collect cardholder data:

5.1. Hosted payment page/ Redirection

With a hosted payment method, customers will be transferred to a page hosted by the payment gateway

  1. Merchant website sends redirect directives the browser of the customer
  2. The customer browser will request a payment form from the payment gateway
  3. The payment gateway will listen to the request and send the payment form back to the customer browser
  4. The customer will fill their card info in the payment form on their browser. The data will be sent to back to the payment gateway
  5. The payment gateway obtains the card details and send it to the payment system for processing

For merchants using payment gateways that collect card info using hosted payment gateway/redirection, they will have to meet the lowest level of PCI Compliance, and use a SAQ A form.

This method of collecting card info will be the most secure since all details will be held by and passed to the server of the third party for processing. Using a hosted payment page will relieve you from most compliance burdens.

5.2. Iframe

Under this method, a HTML form will be requested from the payment gateway side for the customer to fill in on their browser. Technically, this is similar to the hosted payment gateway method, except that customers will not be redirected to the website of the third-party payment gateway.

  1. Merchant website creates a payment page
  2. The customer browser requests the payment gateway provider to return a child page.
  3. The child page, which contains the payment form, is embedded into the parent page.
  4. Customers fill their  payment info in the payment form and send card data to payment gateway.
  5. The payment gateway sends the card data to the payment system for further processing.

An iframe helps to reduce waiting time when   the customer redirects from your website to the hosted payment website.

This will give customer a better user experience since their shopping experience is less interrupted. Within this collecting method, there are two sub methods that capture cardholder data differently:

+ Capture full data: All payment information that customers fill in will be stored on the gateway-hosted server

+ Partial data capture: The most important payment info – card number and CVV – will be collected by the server of the payment gateway. By capturing fewer payment details, this type of i-frame allows you to fully customize the payment form to meet your UI and UX needs, while still maintain security.

Similar to the hosted payment gateway method, merchants collecting card data with the iframe method will use a SAQ A form.

5.3. Direct post/ Transparent Redirect form

With this type of collection, card information collected from customer website will be transferred back to merchant website. Next, this info will be sent to the payment gateway’s website for processing.

  1. The website of the merchant creates the payment form.
  2. Customer browser will fill in the payment form on their browser, and data will be sent directly to the payment gateway.
  3. The payment gateway provider receives card details and send it to the payment system for further processing.

For merchants that collect card info using a Javascript form or Direct Post method, they will have to validate their compliance using the SAQ A-EP form.

5.4. Javascript Form

Under this collection method, the payment page on customer’s computer will request for a Javascript code from the payment gateway’s server. Payment details will be filled into the payment form hosted by the payment gateway.

  1. The merchant website creates a the payment page
  2. The page on customer’s browser will request a Javascript
  3. The Javascript is created from the payment gateway and sent back
  4. A payment form will be created on the customer’s browser
  5. The customer fills in the form and sends the data to the payment gateway.
  6. The payment gateway sends the payment data for further authorization

Similar to the Direct Post/Transparent redirect method above, the payment form is also served on the merchant’s server, which means they will face more PCI Compliance burdens when using the JavaScript API method.

This method of collecting payment info is more vulnerable since it will take an additional step to move data from customer’s browser to merchant’s site.

For merchants that collect card info using a Javascript form, they will have to validate their compliance using the SAQ A-EP form.

5.5. Payment gateway API (Application Programming Interface)

Using an API provided by the payment gateway will give merchant the highest level of control when dealing with payment info. With an API, merchants will be able to gain more access to customer info, thereby conducting market research and marketing campaign.

  1. The merchant site creates  the payment page and payment form
  2. Customers will fill their in their details
  3. The customer browser will send cardholder data back to the merchant website
  4. The merchant website will send the data to the payment gateway provider
  5. The payment gateway sends the card data into the system for further authorization

This data collection method is the most vulnerable to attacks, since data will be transferred back to merchant website before it is sent to the payment service provider. During the transmission stages, hackers can attack the merchant’ website and alter the code.

For merchants that collect payment info using the payment gateway API, they will have to face a high level of risk, and has to validate their compliance using SAQ-D.

So what choices do I have?

At Magenest, we have built a host of payment gateway integration solutions. We support payment gateways from different countries and regions with various data collection methods.

Below is a list of payment gateway integration solutions we have built, along with supported data collection methods and PCI requirement level. This list will be updated regularly as we release new payment integration extensions.

Card detail collection method Supported Payment Gateways PCI DSS Requirement SAQ type
Hosted Payment Gateway/Redirection Stripe, Barclaycard ePDQ Low SAQ A
Iframe Stripe, Skrill Low SAQ A
Javascript Form Moderate SAQ A-E
Direct Post/Transparent Redirect Stripe, Worldpay, Moneris,   Sagepay Moderate SAQ A-E
Payment Gateway API Barclaycard Direct Link High SAQ D
Summary

Share

Comments (4)

  1. Charles Longenecker
    Thank you for writing wonderful informations. Your website is so nice. I am impressed by the facts you have on this web site. It brings out how very well you perceive this subject. I Saved as a favorite this page and will return for further articles. I discovered simply the info I previously explored just about everywhere and merely could not come upon. What a wonderful site. http://www.echoindeep.com
  2. Anh Pham Tuan
    This article is very useful and attractive. I have learned a lot from this.

Speak Your Mind

60 − = 53