Guest Analysis: Which Ecommerce Processing Methods Qualify for SAQ A-EP?
George Mateaki
October 24, 2014 - The technical differences between the five most commonly used ecommerce processing methods can be a bit confusing, especially when considering the new PCI DSS 3.0 A-EP Self-Assessment Questionnaire (SAQ). The key is to understand where the payment form actually resides, and to whom that information is transferred throughout the payment process.
The following is a breakdown of the five most common methods of ecommerce processing and their matching SAQ. If your ecommerce merchants have any questions regarding which SAQ they fall under, this should act as your resource.
Redirection
In this very common process, customers are passed from the merchant website to a separate, third party site to process the card transaction. Traditionally, small merchants use redirection to minimize scope and reduce liability.
How it works:
Merchant website sends redirect instructions to customer computer
Customer computer requests payment form
Payment Service Provider (PSP) creates payment form and sends back to customer computer
Customer computer displays payment form and sends card data to PSP
PSP receives and sends card data for authorization
Rarely do these attacks result in a large number of compromised payment cards. In other words, the impact related to a redirection breach is very low. This is part of the reason the PCI SSC classifies redirection processing as SAQ A.
IFRAME
The IFRAME (inline frame) begins when an HTML document (child page) is embedded into a separate HTML document (parent page). The biggest advantage of IFRAMEs is they allow the merchant site to maintain branding while outsourcing card data collection to a third party.
How it works:
Merchant website creates parent payment page
Customer computer requests child page, containing the payment form
PSP creates and sends form to customer computer
Customer computer displays both parent page and the child page payment form congruently and sends card data to PSP
PSP receives and sends card data for authorization
Like redirection, IFRAME is infrequently attacked by criminals. As such, the PCI SSC classifies merchants utilizing IFRAME as SAQ A.
Direct Post
The direct post (i.e. browser post or silent order post) payment form originates from the merchant website instead of the PSP. This allows the merchant more control over the payment process, but also relies on the merchant’s internal security controls to protect the transaction.
How it works:
Merchant website creates payment form
Customer computer displays payment form, sends card data to PSP
PSP receives and sends card data for authorization
Because direct post is typically used by larger merchants, VISA Europe classifies this method as moderate risk and merchants using it must validate to SAQ A-EP.
JavaScript
The JavaScript method is unique in that the customer computer executes code, which comes from the PSP, to create the payment form.
How it works:
Merchant website creates payment page
Payment page on customer computer requests JavaScript
PSP creates JavaScript and sends back
Customer computer uses JavaScript to create payment form within payment page, which customer completes and returns to PSP
PSP receives and sends card data for authorization
Similar to direct post, JavaScript is a moderate-risk ecommerce processing method, and merchants processing in this manner are required to validate to SAQ A-EP.
API
With API (i.e., merchant gateway), the merchant controls nearly the entire payment process. This method is attractive to merchants that want to create a custom purchase experience.
How it works:
Merchant website creates payment page and form
Customer computer displays payment form, which customer completes and returns to merchant website
Merchant website sends card data to PSP
PSP receives and sends card data for authorization
Hackers are always looking for the biggest bang for their buck. In ecommerce processing, API is the Holy Grail. Because API leads to greater breach impact and frequency, it is considered high-risk processing method and requires SAQ D validation.
Conclusion
Hopefully the reasoning behind certain SAQ ecommerce qualifications is a little clearer. Hopefully you’ve also realized that merchant website security heavily influences transaction risk. If the merchant website is breached, there is nothing the PSP can do to protect the data. PCI DSS 3.0 makes it very clear that merchants hold the responsibility to protect ecommerce transactions that originate from their website.
George Mateaki is a Security Analyst at SecurityMetrics. SecurityMetrics is a leader in data security and compliance company. Visit www.securitymetrics.com for additional PCI compliance and data security resources.
[More: http://www.electran.org/ecommerceprocessing/]