PCI compliant
How does the eCommerce module sit with PCI compliance?
Hello,
The ecommerce module is currently preparing for PCI certification which is very time consuming so I can`t give an exact date to get certified. We are working hard towards getting Sitefinity ecommerce PCI compliant. It is currently not PCI compliant, but when it is we will announce it in the release notes.
Greetings,
Stanislav Velikov
the Telerik team
Is there an update on this topic?
Sorry for the double post....
Hey John,
Any news on PCI certification?
Hey Philip,
Officially no news...
My tea leafs say it won't happen till after the new release (also given the fact that Ivan Osmak during the London conference promised a bug-free Ecommerce).
Is being PCI-compliant considered included in that bug-free e-commerce promise? That seems like a critical hurdle that needs to be overcome in order to be a relevant solution. Our clients, merchants, and their customers are at too much risk using a non-certified tool.
Hey John,
Honestly I don't know if PCI-Compliance is 'included' in the bug-free promise. I'm keeping a close watch on the ecommerce development and tried to jump on any issue since it was introduced in v4.2.1650 but still, I'm an outsider so I can't speak for Telerik.
Hello
Sitefinity is currently going through PA-DSS compliance. PA-DSS stands for “Payment Application Data Security Standard”. It is the merchant who has to be PCI-DSS certified, however a merchant cannot be PCI-DSS Certified if they are not using a PA-DSS compliant software.
The PA-DSS assessment is conducted by a third party service provider and usually takes between 6 to 12 months to complete. Sitefinity will pass any third party screen service which are services that scan for security vulnerabilities of a web site. These scanning services are usually required by banks or merchant service providers every quarter.
Greetings,
Stanislav Velikov
the Telerik team
Hi,
Hello Lee,
The ecommerce module is in the process of moving toward it, however as mentioned before the process is very long and the requirements in ters of security very strict and this process is not yet completed.
Greetings,
Stanislav Velikov
the Telerik team
This is frustrating as this module has been available for over a year. This process should not take this long.
G'day guys,
Request an update on PCI compliance. I'm keen to buy in and move off X-Cart - but don't wish to do so until you have PCI-DSS compliance and support for E-Way.
Hi,
The ecommerce module is not PCI compliant and we can`t give a time frame for making the module compliant.
In sitefinity 6.2 which will be the next release a new feature will be added for the ecommerce module to use offsite payments so nothing will be stored in sitefinity in terms of payments.
Regards,
Stanislav Velikov
Telerik
Wow, this HUGE! How is it that at least one large U.S. furniture sales firm uses a non-compliant ecomm package? They are not using Paypal Express or any other offsite credit card processing. Are they just large enough to pay the fines if Visa decides enforce compliance?
Hello,
Sitefinity is on the road to compliance and starting sitefintiy 6.2 release in October the new feature will be "PCI-DSS Compliance: Integration with PayPal Payments Standard & WorldPay" for more information please refer to the roadmap for 6.2.
Regards,
Stanislav Velikov
Telerik
Just came across this discussion. Starting on two sites using sf ecommerce with authorize.net as the processor. We are not storing credit card information in the database. I realize PCI compliance is a complicated issue, but I assume I can still use this product for these stores? Our hosting is dedicated and we've passed PCI checks on our environment. Is this a concern?
It is very complex, and it is confusing. As the PCI compliance rolled out the rules got stricter each year or so, probably to give companies more time to comply. As of 2010 the rules clearly state "ALL PCI Level 4 merchants (new and existing) using third-party software must use validated applications. July 1, 2010" A level 4 merchant is a small company with fewer than 20K transactions per year. The standards get tougher from there if you are a larger company. So the important words here are "validated applications" and this product is not currently validated. This is in ADDITION to your client being compliant. So they can have properly setup servers, and have their internal handling practices all together but they still would not be fully compliant. This is my understanding. Here is one source for a pretty good set of FAQ's : www.pcicomplianceguide.org/pcifaqs.php.
I'm not 100% sure if using Paypal Standard gets you off the hook for having a non-compliant software package, it appears to be the case. But you would not be able to use just Authorize.net and the SF checkout system.
It's not really that complex.
There's one metric that's the decisive factor - are you handling credit-card information?
That's why fully off-site payments have always been a big issue. Cause with 6.2 finally offering us full offsite payment we're finally able to comply.
Each payment provider might have a different subset of regulations and paperwork for certain cards they're accepting, but instead of having to be fully pci-compliant yourself like any brick-and-mortar store has to be with all their software and hardware, an e-commerce website can get away by outsourcing all the sensitive stuff to an offsite payment provider.
For sec e-commerce, in combination with an off-site payment provider who's PCI-DSS compliant you're only required to fill in SAQ A. It's a self assessment form, where you acknowledge all credit-card information is handled by a compliant 3rd party and you do not store this yourself.
The standards say:
PCI DSS applies to any entity that stores, processes or transmits cardholder data.If a merchant outsources all their payment operations, the applicable PCI DSS requirements for the protection of account data would apply to the environment(s) where the data is actually stored, processed and transmitted, such as third party service providers, payment gateways, etc. However, it is the responsibility of the merchant to ensure that the data they share with third parties is properly handled and protected – just because a merchant outsources all payment processing does not mean that the merchant won’t be held responsible by their acquirer or payment brand in the event of an account data compromise.Additionally, the merchant’s acquirer or payment brand may still require the merchant to validate their PCI DSS compliance status. For example, the merchant may be required to complete SAQ A in which the merchant attests that they have outsourced all payment processing services, do not store account data, and that they are compliant with PCI DSS Requirement 12.8. PCI DSS Requirement 12.8 states that merchants must have written agreements with their service providers that include the service provider’s acknowledgement of their responsibility for securing the data in their possession, and also requires that merchants monitor their service provider’s compliance at least annually.Merchants should check with their acquirer or payment brand to determine their compliance obligations when all payment processing is outsourced.I'll be curious to see how the interface looks, how much control we have of the look-and-feel of the pages. These types of solutions are frequently very amaturish looking to the customer if not well-integrated. It will certainly be fine for people who like to use Paypal (for us that is about 1/3 of our customers) given they are used to the "Paypal look".
At least there will be a solution for the short term because we're pretty much up a creek without it. I still wonder what those big installations using the cart we have now are doing for compliance.
Something else that is real unclear with the Paypal Standard solution, is that there appears to be no "Virtual Terminal" access. If you have customers that call in to place an order, you don't have anyway of putting an order through manually, no way to rebill if a customer wants to add on to their order after their original order is placed. It would really be helpful if there was a demo of 6.2 to take a look at, see what we are in for.
Sitefinity 6.2 is currently in beta still. The current internal build includes the working Paypal Standard and WorldPay, but they might change before release.
Since it's 'off-site' payments, as soon as you're hitting the payment stage a client is shown the familiar and trusted Paypal interface until payment is completed and they'll be back on your site. Paypal offers some 'visual tweaking' through it's interface.
There's an extensive pdf describing the entire paypal setup here, although not everything's applicable the first 40 pages should give you a firm grasp on its features and capabilities.
---
The 'virtual terminal' you're referring to is a Paypal Pro feature and is meant as a tool to process and accept credit-cards over the phone/email. This essentially negates the ability to offload all credit-card handling to a trusted 3rd party (because you're handling them as well) and thus falls under a different PCI-DSS Compliance level.
If you compare the Paypal editions you'll see that the difference between 'standard' and 'pro' is 3 features:
1. Customers pay without ever leaving your website.
We want them to 'leave' our site so all cc handling is done off-site and allow for easier PCI compliance.
2. Accept credit cards via phone, fax, and mail (Virtual Terminal)
Described above, we don't want to touch cc information.
3. Design and host your own checkout pages for full control.
Again we don't want to host anything that has to do with cc information.
Will sitefinity integrate an IPN with paypal standard? Otherwise I assume the order would remain in pending status and need to manually be processed? Any other insight into the process flow from paypal, cancel, success, showing order confirmation on return, etc.?
Hi,
IPN and PDT have been added with sitefinity 6.2 for paypal, here is the documentation on this.
Regards,
Stanislav Velikov
Telerik