PCI Compliance and Ajax

Question

I have this idea, but I am unsure if it is PCI compliant. I'm new to the arena of PCI compliance and am curious to know if this scenario violates PCI.

So, let's set up the scenario. Company A is PCI compliant and has a web service on https exposing bits of functionality around payment processing. Company B is not compliant, but their website is secure.

Here are the steps of the scenario.

1. B's website contacts A's webservice via server side code. This service sends back an encrypted authetication token.
2. B injects this token into a page containing a form for accepting credit card information.
3. The user enters their credit card information on B's website.
4. The form information, along with the token, are sent via an ajax call to A's webservice.
5. A's webservice processes the data and spits back a status (Approved/Denied/etc)

The question is, since the javascript goes directly from the user's machine to Company A's compliant servers, is it PCI compliant? I'm very interested to know what experts in this arena think.

Answer 1

Larry K's answer is good. It is mostly a political/layer thing.

It seems that using an iframe for posting from B to A is an accepted solution, while using Ajax - with CORS or JSONP - is somewhat more questionable but still, at least for some big players, acceptable.

The Information Supplement: PCI DSS E-commerce Guidelines v2 seams to say that this solution (direct-post API) is OK but that you should take care to code safely (though PCI DSS does not prescribe anything concrete you would need to do) - see the section 3.4.3.1 Third-Party Embedded APIs with Direct Post and the related 3.4.3.4 Security Considerations for Shared-Management E-commerce Implementations, which reads:

Direct-post API Approach: With the direct-post API approach, the merchant is still responsible for the web page that is presented to the consumer, and the merchant hosts the fields on the payment page that accept the data—only the cardholder data is posted directly from the consumer to the service provider. Since the payment pages are hosted by the merchant, the payment pages are only as secure as the merchant’s web site, and a compromise of the merchant’s system could lead to a compromise of payment card data. ... Specifically, for all of the above scenarios, the merchant should monitor for any evidence that systems have changed and respond quickly to restore systems to a trusted state when unauthorized changes are detected. Merchants who adopt these shared-management outsourced models to minimize applicable PCI DSS requirements should be aware of the potential risks that are inherent to these types of system architecture. To minimize the chance of attack in these scenarios, merchants should apply extra due diligence to ensure the web application is developed securely and undergoes thorough penetration testing.

For example the Stripe payment gateway uses direct-post over JSONP since 2012 instead of the iframe approach they have used before.

On the other hand, WePay also provides a direct-post API but recommends iframe to get completely rid of PCI requirements [WP] (claiming that with the direct-post API "[..] you’re still required to be compliant with the Payment Card Industry Data Security Standards (PCI-DSS) and the Payment Application Data Security Standards (PA-DSS) whenever applicable." (without specifying what exactly "whenever applicable" means).

[WP] WePay link: https://www.wepay.com/developer/tutorial/tokenization

Answer 2

Pamphlet on PCI DSS All of the PCI Standards

PCI DSS (Payment Card Industry Data Security Standard) has the concept of "Scoping" -- determining which systems come under the PCI umbrella.

Are you a Merchant or a Software Vendor? If the PAN (Primary Account Number), the long credit card number, is never sent to your website, then your website is usually not under the PCI Scope. -- Assuming that you're the merchant. If you're a software vendor, then your software would probably be in the scope of the PA-DSS (see below).

PAN transiting your server The old idea was that the PAN would be sent to your website (through a browser form submission), then your website would turn around and send it to a payment gateway (eg Authorize.Net). In this scenario, the PAN was never stored on your server, but did transit your server. This used to mean that your merchant systems would not be under PCI DSS scope since they never stored the PAN. But those days are ending quickly or are already gone. (Which depends on how aggressive your acquirer/Merchant Account supplier is about PCI.)

Controlling your web page Since your web page doesn't transmit any PAN to your server, you're not in the PCI scope. But how do you know that someone hasn't changed your webpage to transmit the PAN back to your server (or elsewhere, using JSONP techniques)? The answer is that you need to assure yourself that no one will tamper with your payment forms page.

How you assure yourself of this is up to you. You could use the PCI techniques or other techniques. This is a matter of your internal computer security and auditing.

Payment Application Data Security Standard (PA-DSS) If you sell your sw to merchants then it would probably be within the scope of the PA-DSS standard. See the standard.

PCI is political, not technical Remember that PCI scoping is up to you. If you're a big enough merchant, then you'll also need to work with a QSA (Qualified Security Assessor) who will review and ok your PCI compliance and scoping plan.

It is certainly possible that a QSA could say that since you control your web page it needs to be under PCI since it could be corrupted by someone. But that would be a pushy argument. After all, you could then say that every web page of any internet merchant needs to be under PCI since any web page could be corrupted to ask people for a PAN and then do something bad with it. On the other hand, this is exactly the sort of argument that Visa is using to increase PCI scope for corporate franchisors. Article.

PCI certification is not an excuse Also note that the card associations reserve the right to kick you out if you have a break-in--even if you were PCI compliant. So you want to be sure that you're a much tougher target than anyone else on your block.

Added: More on Scoping As you can tell from the above, a key issue is which systems are in or out of PCI Scope. The PCI Council now has a Special Interest Group (SIG) examining this whole issue of what is in and what is out of PCI scope. And my guess is that they'll want the envelope to grow, not shrink.

Added: It's between you and your lawyer Your scenario has the start of the PAN processing done on your customers' browsers. The PAN never reaches your systems, not even for an instant. So my interpretation is that you're out of Merchant PCI DSS scope. But you're the one signing the PCI compliance statement which is a contract between you and your acquirer. So it is up to you and your lawyer to interpret the PCI DSS standard, not me.

Bottom line You should never ever store PAN data on your systems. You shouldn't even have it transit your systems. New Payment Gateway protocols from Authorize.Net and Braintree enable the no-transit technique. Depending on your volume of credit card transactions, PCI compliance varies from a self-administered checklist to a huge project.

For more PCI war-stories, check the StorefrontBacktalk blog and their PCI coverage.