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.
Redirect
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 authorize.net (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.
Repost
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.
PCI Guru 
Not sure if this was answered or if I’m confused 🙂
for ecommerce, if my company uses a hosted payment page, then my ecommerce sites are out of scope as no CC information is stored, processed, transmitted or comes back in to my environment.
However, if for MOTO, our sales rep use the same hosted page developed for the sales team, via our Internet connection and from their laptops, then the laptops, the network and anything connected to those would be in scope for PCI, correct?
If that is correct, can you point me to where I can find some concrete information? My team is challenging me on this…
It depends on HOW your eCommerce site connects to the third party’s hosted payment page. If the connection is via an iFrame or redirect, then your eCommerce site does not need to be considered in-scope. That said, you better be protecting the mechanism on your eCommerce site that invokes the iFrame or redirect because if that is surreptitiously changed to go to a different site, it will be your organization on the hook, not the third party. That also includes updates and patching.
Assuming that your site uses an iFrame or redirect and the third party is PCI compliant, then only the salesperson’s notebook would be in-scope for PCI compliance. That is because the customer’s primary account number (PAN) is keyed into that device and could be intercepted by a keyboard logger or a memory scraper on that notebook. This is because the HTTPS connection isolates the network traffic to just the notebook and the payment page.
Just to be clear, with MOTO you also have some additional PCI compliance issues with order forms and the like.
Thanks! The ecommerce is via redirect. For the salesteam via mail order, they are presented with a hosted payment page from cybersource (https). They enter the card details on that hosted page on behalf of the customer. Great to know that the laptop is in scope but wouldn’t the network to which the laptop is connected (in our instance, this would be the corporate network) also be in scope?
As long as the computer that is used for data entry connects via HTTPS, then it is technically segregated from the other computers by that HTTPS connection. As long as the network gear between the computer and the payment page cannot decrypt the HTTPS data flow, that is also out of scope because the data is encrypted.
However, as I stated earlier, the risk is that the computers used to enter the data could have a keyboard logger or memory scraper installed that would capture the PANs entered on those systems. Therefore, you need to ensure that those computers are properly secured and configured to minimize that risk. Most organization’s basic security standards take care of this risk. However, I do have clients that add white listing, black listing, critical file monitoring and similar to further ensure that those computers do not become compromised.
That’s really helpful! I’ve worked with QSA’s in the past who have stated that regardless of the HTTPS connection, the laptop and the network the laptop sits on would be in scope. Your guidance makes sense…
It is up to your company to accept the risk that in-scope and not in scope systems are on the same network segment for the risks I’ve stated. If you feel your security standards are such that you can tolerate that risk, then you need to tell the QSAs that fact and they need to accept it. If you do not want to accept that risk, then you need to segregate those in-scope systems from the not in scope systems.
What about company A hosting a form that will allow the user to type in the information but the submit goes straight to the processor via a post. This way, the information I am still not processing, transmitting or storing. The card holder data does not even make it to company A’s servers memory. Does this still put company A in PCI scope?
Hosting a form (aka repost) means that the data still is processed and transmitted from your server to the processor and therefore puts you in scope.
Can you please clarify what you mean here? I understand that hosting your own form that posts directly to a payment processor is something that needs to be secured, however it is not technically accurate to say that the data is process and transmitted from your server. Only the HTML is on the server (and again, I understand it needs to be secured so cards can’t be skimmed), but it is common practice these days for client SDKs (eg. from Braintree) to post directly to the payment processor. In this case neither “repost” or “redirect” is technically accurate, and I’m wondering if you could update this article to reflect the state of the art.
Actually the techniques described here are still the only way that the PCI SSC allows for a Web site to be out of scope, so there is no update to be provided.
I’m not making an argument, or seeking advice that anything is out-of-scope, what I’m saying is that “hosting a form” is not a single thing, both require proper security, but they are materially very different.
In case #1 the merchant hosts a form, and it posts to the merchant’s server, and is then re-posted to the payment processor. This is the traditional flow you are describing, as implemented by Authorize.net and countless others in the 2000s.
In case #2 the merchant hosts a form, ie. an HTML page served by the merchant’s server, but it posts directly to the payment processor. In that case it is NOT a repost because it is NOT sending any cardholder data to the merchant’s server. However it is also NOT a redirect as described in the article, because the processor does not render the form.
The distinction here is critical because in case #1 cardholder data flows through the merchant’s server, and in case #2 it does NOT. Again, I am not trying to claim that takes scenario #2 out of scope, clearly the form itself is vulnerable and must be secured, but in a modern single-page app, or in mobile apps, the client code does not necessarily live on the same server with the API code.
I’ve been developing e-commerce sites for almost two decades now, so I understand why this guidance is written the way it is, but it’s very difficult to interpret for modern app development where everything is done in javascript or native code. Given that “repost” implies “merchant server receiving cardholder data”, and given that there are only two buckets which these methodologies can fall, that leaves me to conclude that modern development using, for example, Stripe or Braintree SDKs are classified as “redirect”. But that is confusing considering that both of these methods are entirely API driven with no actual redirect to be seen.
WHat it all comes down to is whether or not the merchant’s server is in control of the data. The Council wants that control limited to serving up a link to something on a processors server, not serving up a page. That is the only way to get out of scope.
Hello,
We are currently developing an online ordering platform for restaurants, most restaurant ordering websites allow consumers to go onsite and use a credit card to order from local restaurants, then they pay the restaurants later, minus a percentage.
Our proposed model is:
Instead of charging a consumers credit card through our merchant account direct (like most companies do),
were looking for a solution, vendor, or technology to help us simply capture the order and credit card data,
then securely transmit it to our partnering restaurants, for them to securely process individual transactions
(and) if elected by returning customers, have their CC data securely stored for ease of re-order…all while being a PCI DSS security complaint website.
In the above scenario we would have a merchant account to process our sites product sales, as well as to process commissions for each restaurant we generate business for.
Thanks in advance for any recommendations or input on something that seems closest to a repost.
Vic
I’ve encountered some similar solutions for other retail operations.
You would be a service provider for your restaurant clients. However, you would also be a merchant for processing payments for your services to your customers. Not a lot different from outsourcers that have similar services and then charge for those services.
Storage of cardholder data for future purchases is not a PCI DSS covered activity as such. You are storing pre-authorization data. That said, while not completely covered by the PCI DSS, you are required by the card brands to protect that data just as though it were covered by the PCI DSS. You would want to have some sort of agreement that people storing their CHD in your systems would acknowledge that you will keep their CHD secure and that you comply with all relevant state and federal privacy laws, etc.
Thank you very much for this post. I have a question regarding scoping for an e-commerce site using the redirect method. My assumptions are that the following are fully in scope:
The web application server running PHP/ASP.NET code handling the redirect
Any code written for that web app (PHP code, ASP.NET code, etc)
The database server that application server talks to (since they’re talking directly and are on the same subnet)
Any system providing security services to either of those systems
Any other system that can talk directly to those systems
Where I’m less sure is when it comes to the virtualization hypervisor, the hypervisor’s management (e.g. vCenter), underlying storage (NAS/SAN used by the hypervisor), out-of-band management of the physical hosts running the hypervisor, and backup solutions that use hypervisor tie-ins to simply copy the entire VM. I would assume each of them would have some limited scope, but I’m unsure how far down the rabbit hole to go with each of those since the primary attack vector is the redirect. If CHD were ever present (or worse, stored), I’d just assume all possible requirements apply. However, I’m trying to balance realistic risks with the costs and management overhead without opening up liability for PCI non-compliance and I’m doing so with applications that never see a PAN.
Can you provide some guidance on how to go about drawing the line in such cases so that a reasonable auditor would agree compliance objectives have been met based on the threat profile? I understand every CDE is somewhat unique, but a basic site with a hidden iframe is pretty common and I’m just not seeing any specifics on what actually needs to be done to fulfill the stated requirement to “protect the redirect”.
Thank you!
The hypervisor and related management tools are always in scope. Systems that can connect to that infrastructure are at least category 2x systems, possibly higher depending on how that access occurs and what they have access. The Open PCI Scoping Toolkit can answer your question.
if a non-PCI web server at Company A is having a link that redirects to ecommerce portal owned by Company B. The ecommerce portal redirects to payment gateway for credit card payment.
Does the non-pci server in company A is subject to PCI scope? Is there any other obligations imposed on company A?
From a PCI compliance perspective, Company A is not required to be PCI compliant because their Web site is not directly involved in a transaction. Just because a Web site sends a user to another Web site and that Web site is an eCommerce site, does not mean that the original Web site needs to be PCI compliant. That would mean that the entire Internet would need to be PCI compliant and we all know that will never happen.
While this is an old thread, at the community meeting it was stated that servers that are part of the server redirect are in scope for the PCI DSS scope of a customer. Pages 99-101 of the Community Meeting slides, this was specifically stated because of the confusion. At the Community Meeting, they also stated the presented this information at the 2013 RSA conference.
The Council will be publishing an information supplement on this very topic sometime this year.
Since I wrote this post, some other comments made by the Council changed and the redirect site is now in scope. Although the requirements such a site needs to comply are somewhat reduced because it is all about protecting the redirect code/URL.
I have a doubt about this, I suggest the redirection way in my company, but now the things changed, the company wants to associate the credit card number with a public transportation card, with this the customer charges credit in the transportation card paying with the credit card, the association is made once and then on the customer charges credit whenever they need it. By now the company has a third party processor, using the redirect scenary, but in the mean time, the company will be the processor. In what way does PCI impacts here? DO I have to comply with all PCI?
Will the version 3.0 change this?
I ask because of the new language in the scoping section
“Systems that provide security services (for example, authentication servers), facilitate segmentation (for example, internal firewalls), or may impact the security of (for example, name resolution or web redirection servers) the CDE.”
Possibly. The Council announced at the Community Meetings that a scoping document is coming next year as well as an SAQ focused on eCommerce. Until we have those, I really don’t have any idea as to the changes the Council will make on this topic.
I can tell you that internally, my firm has just met to finalize how we will be approaching this situation. When the guidelines get published I’ll pass along the link to them.
As near as I could tell with my discussions with various people and Council members at the 2013 Community Meeting, the “new” scoping language in the DSS only clarify scoping not redefine it. I took that to mean that QSAs and ISAs were supposed to be following this guidance in the first place. The Council also announced that there will be a Scoping Information Supplement coming out in 2014. One can only hope that the Council just adopts the Open PCI Scoping Toolkit as the basis for that supplement.
At the end of the day, if the server is doing a redirect, the risk is that the redirect is modified on the merchant’s server and the customer is now sent to a phony site where their card information is obtained. As a result, it is incumbent upon the merchant to ensure that they are not the cause of the merchant that the customer lost their card information. Therefore the merchant needs to protect that redirect server just as though it is actually processing the cardholder data.
Thanks for this post and your blog in general, lots of useful information. I did have a nagging question on this topic that I’m hoping you can help clarify.
The PCI SSC published the E-commerce Guidelines back in Jan 2013. On page 17 it states that merchants that “wholly outsource E-commerce implementations” may be allowed to fill out a SAQ A. On Page 13 it describes that utilization of redirects to a hosted payment page and direct post APIs as “shared management E-commerce Implementations”. Then on page 18 it further clarifies that a merchant that is SAQ eligible and “has outsourced all payment card data storage, processing, and transmission to compliant third parties (for example, merchants using a wholly outsourced e-commerce implementation as described in 3.4.4), the merchant may be eligible to complete SAQ A which reduces the number of applicable PCI DSS requirements for the merchant.”
Based on these statements am I off base in assuming that even a redirect to a hosted page would disqualify a merchant from being able to fill out an SAQ A? If not a SAQ A, would it be a C or D? It would seem to me overkill to apply all the controls found in SAQ D to a webserver supplying the redirect code to the payment processor. Any thoughts you have on this question are greatly appreciated.
Is there a accountability from the E-commerce merchant to protect the redirect URL with FIM or database?
And is this found in the DSS?
There is indirect accountability to protect the redirect URL.
The best documentation for this is actually in the Open PCI Scoping Toolkit (http://itrevolution.com/pci-scoping-toolkit/) and not the PCI DSS. While the PCI DSS somewhat describes scoping (supposedly scoping will be addressed this coming year in a supplement), the Toolkit does a fantastic job on discussing why the redirect needs to be protected. Whether you rely on a file integrity monitoring (FIM) or some other method(s) is up to you. But the risk is that the URL is tampered with and redirects to a rogue site that then captures your customer’s cardholder data.
Thank you so much for the explanation, I’m in the way to suggest redirection in my company and this post is giving me a lot of help!