Showing results for 
Search instead for 
Did you mean: 

DPM and PCI compliance - I could use a definitive answer...

Confused new Authorize user here...


I'm trying to decide between SIM, AIM, and DPM for the payment gateway interface I am working on.  I don't like SIM because it strays too far from the look and feel of my site.  I don't really like AIM because of the whole PCI compliance thing.  That leaves DPM, an option about which I am extremely confused. 


The Authorize DPM summary states: "DPM is a hosted payment option that allows the user optimal site customization while still relying on Authorize.Net for help with PCI compliance."  What exactly does that mean???


In this thread, a user states that Trustwave told him that for PCI compliance purposes, it doesn't make any different whether you are using DPM or not - you still have a form on your website into which the customer puts a credit card number.


The way I understand DPM, the form lives on my site, but the action on the form points to an server rather than a payment script on my site.  Does this "count" as accepting a card number on my site, or should it be considered as secure as SIM?


To make things even more confusing, the Authorize summary also makes the following statement: "So developers customize a secure hosted payment form without needing an SSL certificate."  I can sort of see how this might be the case, since the form is submitted directly to Authorize, which presumably provides the needed SSL certificate from the other end.  However, the "How it works" diagram for DPM seems to directly contradict this statement, showing SSL on the arrow between the merchant's site and the merchant's self-hosted payment page.  How is this possible "without needing an SSL certificate"??


 I could really use some definitive answer on these questions.






Surely someone has some input to contribute??


DPM is essentially another way of implementing SIM — one which allows for more flexibility and customization by allowing the merchant to create a custom payment form. There are sections of PCI DSS assessments which deal with transmitting and storing sensitive data and, accordingly, reducing contact with, or storage of, cardholder data potentially reduces the scope and impact of those requirements.

However, every merchant’s implementation is different and ultimately each merchant is responsible for ensuring their own PCI DSS compliance. Also, our solutions (or any solution) must be properly implemented on compliant systems in compliant networks. We can never make a 100% assurance claim about DPM and PCI DSS compliance simply because we are not privy to the details of any merchant’s implementation.

All that being said though, PCI DSS itself is a continuously evolving standard and subject to interpretation by the QSA reviewing a merchant’s system, as well as the evolving interpretation of the PCI Security Standards Council. At the end of the day, it is up to each merchant to determine which integration method is best for them and to maintain compliance in consideration of their own system architecture and business needs.


Basically, I can't tell you if using DPM or any solution will keep you from needing to worry about PCI. There are too many variables. However, you can contact a qualified QSA who can give you the answers you need. Check out the PCI post here for a list of resources.





Developer Community Manager