Hosted Payment Page and PCI Compliance

Synchronicity is, quite possibly, one of my favourite albums ever produced. It is also, according to wikipedia:

two or more events which are causally unrelated occurring together in a meaningful manner.

I experienced just such a series of events today. During an internal meeting, there was a discussion of the PCI compliance obligations surrounding the use of a hosted payments page. I have had similar discussions over the last several days with IP Commerce partners and their customers. So, imagine my delight when, upon opening my Google Reader, I noticed these two respective posts by gentlemen whose blogs regarding security I highly encourage you to follow:

• Trick Question: Can PCI DSS Apply if… – Anton Chuvakin
• Does PCI Apply to me? Store Process Transmit – Trey Ford

Let me begin by providing a bit of information regarding the “Hosted Payment Page”…

The traditional test of the application of PCI standards to a merchant is whether any/all of certain criteria are met. I tend to refer to them as the “big 3″…They are “Store, Process, Transmit”…in specific, and according the the PCI SSC:

PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted.

Before providing additional detail about merchant obligation in other scenarios, lets consider the implication of this single statement.

Compliance, as we’ve discussed in other posts, is gaining (and has gained) additional visibility in the market. As a result of this, merchants and the software companies who service them, are always looking for methodologies by which they can reduce the scope of their compliance obligation. I’ve heard arguments, in the past, that this sort of mindset is detrimental to the purpose of compliance at large…but, frankly, I simply view it as understandable. The reduction of the scope of compliance (when addressed properly) has the effect* of reducing overall risk for the merchant.

Enter the “Hosted Payment Page”

If storage, transmittal, and processing define the scope of requirements, how can a small merchant limit, or remove, these items from their environment whilst still accepting cards as a tender?

An answer, is that of leveraging a 3rd party to handle the big 3 on their behalf. In the world of eCommerce, this looks something like setting up a secure re-direct from your website to a validated compliant payment page that accepts payment on your behalf and then redirects the customer back to the merchant’s cart. The storage, transmittal, and processing are now happening outside the merchant’s environment.

HOWEVER…and this is what both Trey and Anton discuss…there is still a compliance obligation in this scenario. In particular, elements of PCI Requirement 9: Restrict physical access to cardholder data and PCI Requirement 12: Maintain a policy that addresses information security for employees and contractors are still applicable and the merchant must demonstrate compliance against these elements.

The beauty, however, lies in the fact that the demonstration of this compliance is through a Self-Assessment Questionnaire (SAQ). In particular, in the scenario of card-not-present, big 3 being “outsourced”, the outsource partner is compliant (and a few other items), the specific SAQ is SAQ Validation Type 1.

So, is the merchant still “in scope” for compliance. Absolutely. But it is quite a bit simpler.

You may have noticed that the concept of redirect to a partner for processing the payment transaction itself is quite similar, in notion, to that of the PayPal implementation. The complaint in this scenario, is often, the break in customer experience. Merchants are, understandably, wildly protective of their brand…and a perceived interruption in the checkout process is a trade-off decision that has to be made.

In the interest in a bit of self-promotion, one of the integration methods that IP Commerce offers through Commerce Lab and various partner portals is known as the Commerce Hosted Payment Page. Not only does this provide the functionality of the hosted payment page described above, it implements a cloning technology that supports the look/feel of the merchants website during the redirect process for a seamless experience for the end user. Even better, the integration process is impressively simple…and quick…we’ve seen start to code complete and certified in a matter of hours.

UPDATE:  To view a demonstration of this capability, and some additional commentary, please view the post Hosted Payments Page: a demonstration.

What’s your perspective? Agree? Disagree? Anything to add? Critiques? The comment form is below…

*intended or otherwise

July 9, 2009

Posted in Security.