Archive for November, 2011


Of Redirects And Reposts – Updated

There are two major techniques in e-Commerce these days for processing payments: redirects and reposts.  Redirects are when the e-Commerce site sends their customer to the payment processor’s site for the processing of the payment.  Reposts are where the e-Commerce site posts the payment data to the payment processor by just changing the URL used to post the data to the processor’s site.

Since the original post which this post replaces, the Council has issued their e-Commerce Guidelines that address a variety of e-Commerce issues including redirects and reposts.  As a result, I wanted to update my post based on the new guidance as a reader pointed out to me that the original post needed updating.


Redirects cause a new window, an iFrame or a new page to be generated to the on-line customer.  This window/frame/page is where the e-Commerce site’s customer will enter their credit card information to pay for their e-Commerce order.  This window/frame/page is code written by the payment processor and can carry a URL that is not the same as the e-Commerce site.  Typically, while the e-Commerce merchant’s logo may appear on the window/frame/page, the processor’s logo may also appear.

The bottom line is that this window/frame/page does not belong to the e-Commerce site, the redirect method is driven by code developed, managed and maintained by the processor, not the e-Commerce organization.  In the case of a new window or page, it is the processor’s responsibility to ensure the windows/page is PCI compliance and protects cardholder information.

Where things can be obscured is with the embedded iFrame approach.  In this situation, the iFrame is typically not identifiable to the end user as being from the payment processor.  This is because the iFrame most likely appears as part of the e-Commerce site.  I have seen instances where processor logos and statements such as “Powered by …” appear, but those are not common and are typically missed by end users.  Merchants prefer the iFrame solution to minimize the abandoned cart problem that new windows and pages can cause.

The Council’s guidance on redirects is clear.  An e-Commerce solution using the redirect approach is in scope for PCI compliance.  The reason is that the redirect could be tampered with and an attacker could cause the redirect to end up at a rogue server that collects cardholder data and then sends it on to the processor.  But the Council does not say that a redirect scenario needs to meet all PCI requirements, only those that are relevant.  As a result, the server(s) doing the redirect need basic security such as firewall, security hardening, patching, critical file monitoring and anti-virus so that the redirect is protected and, if found to have been changed, the server is taken out of service.  The idea is that the merchant is still responsible for protecting the processing of the transactions even though the transaction is not directly processed by them.

Another area of confusion comes with the Braintree and (CyberSource) types of solutions that they advertise as keeping your e-Commerce site out of scope for PCI compliance.  The trouble with these solutions is that, while they do execute on the customer’s PC or mobile device, the actual code can reside on the e-Commerce site.  As a result, the merchant is responsible for ensuring that this code is not changed in any way other than when a new version is issued by the processor.  These solutions are therefore no different than the PCI compliance requirements of the other redirect approaches.

The take away from this discussion is that the redirect approach may reduce your PCI compliance requirements, but not by the amount that some processors seem to advertise and definitely will not remove all of your e-Commerce systems from PCI compliance.


In the repost scenario, the e-Commerce site is collecting the cardholder information and is then forwarding or posting that information to the processor.  Every transaction processor provides such repost methods through documented APIs.  This allows the e-Commerce developer to develop an integrated payment process for the e-Commerce site.

Under the repost scenario, the control of cardholder data is under the purview of the merchant and the processor has no input as to the how the cardholder data is controlled and secured until it receives it from the e-Commerce site.  Therefore, the merchant is responsible for the safety and security of the cardholder data and that puts the e-Commerce site in-scope for PCI compliance.  That is particularly true even when the cardholder data is only stored in memory during the processing of transactions.  As BlackPOS, JackPOS and other memory scraping attacks have shown, even memory is at risk when it comes to cardholder data processing.

The bottom line on the repost method is that it puts e-Commerce totally in scope for PCI compliance because the risk has not been minimized.

So for all of you trying to minimize your PCI compliance footprint, there is my take on redirects versus reposts.  If you really want to minimize your compliance footprint, use the redirect approach.

Welcome to the PCI Guru blog. The PCI Guru reserves the right to censor comments as they see fit. Sales people beware! This is not a place to push your goods and services.

November 2011