X-Cart: shopping cart software

X-Cart forums (https://forum.x-cart.com/index.php)
-   Third Party Add-Ons for X-Cart 4 (https://forum.x-cart.com/forumdisplay.php?f=45)
-   -   Authorize.net DPM (PA/DSS Compliant) (https://forum.x-cart.com/showthread.php?t=57792)

Ene 03-16-2011 05:24 AM

Re: Authorize.net DPM (PA/DSS Compliant)
 
Quote:

Originally Posted by balinor
Because the credit card form isn't actually on your site and the data isn't processed by your site.


Hm, if you use Authorize.Net DPM, then the credit card form is generated by your shopping cart/scripts.

Anna_S 03-16-2011 05:26 AM

Re: Authorize.net DPM (PA/DSS Compliant)
 
Also, I don't see Auth.net advertises DPM as a cure for PA-DSS

balinor 03-16-2011 05:48 AM

Re: Authorize.net DPM (PA/DSS Compliant)
 
Perhaps BCS should step in here and answer this question, as clearly there is some confusion - my own included :)

gravel 03-16-2011 07:55 AM

Re: Authorize.net DPM (PA/DSS Compliant)
 
I think the concept behind this is the same as the Braintree Transparent Redirect:

The key thing isn't where the cc information is typed in; it's where and how information is sent. A customer's computer is completely outside of PCI scope, and they can type their cc numbers anywhere on their computer til the cows come home, with no problem. It's how and where the numbers are sent that makes the difference.

So they type it in their browser but instead of it being sent to your server, that information is sent directly to the gateway (Braintree / Authorize.net). Your hosting server never sees it.

BCSE 03-16-2011 08:09 AM

Re: Authorize.net DPM (PA/DSS Compliant)
 
Quote:

Originally Posted by gravel
I think the concept behind this is the same as the Braintree Transparent Redirect:

The key thing isn't where the cc information is typed in; it's where and how information is sent. A customer's computer is completely outside of PCI scope, and they can type their cc numbers anywhere on their computer til the cows come home, with no problem. It's how and where the numbers are sent that makes the difference.

So they type it in their browser but instead of it being sent to your server, that information is sent directly to the gateway (Braintree / Authorize.net). Your hosting server never sees it.


I think Gravel explains it very well.

Authorize.net can't say it takes you out of PA/DSS scope because they cannot comment on your other business processes which may touch/transmit CC information. This is also why we state on our site states that it
Quote:

supports you to be PCI compliant including the new PA/DSS standard

and

Quote:

Allows the store owner to complete PCI compliance with a Self Assessment Questionnaire (SAQ) A, instead of the more complex SAQ D*.
.....

* A full assessment of a vendors specific business process is required to determine which SAQ needs to be completed to achieve PCI compliance.


So it is one step towards PCI compliance, but PCI compliance goes beyond just your payment gateway.

This is also the same as X-payments if you choose to use that route. It's just one step towards PCI compliance.

I hope this helps.

Carrie

balinor 03-16-2011 08:39 AM

Re: Authorize.net DPM (PA/DSS Compliant)
 
Yea, that's what I meant ;)

gb2world 03-16-2011 10:27 AM

Re: Authorize.net DPM (PA/DSS Compliant)
 
For what it is worth - I sent the links for DPM and also the product descriptions on BCSE's site to the director of PCI compliance for the bank who holds the merchant account for one of my clients. They reviewed it and let this particular client know that they would qualify to use SAQA for compliance. I always advise people to try and get the plans for compliance to be reviewed by the bank (with mixed results).

---

BCSE 03-16-2011 05:28 PM

Re: Authorize.net DPM (PA/DSS Compliant)
 
Quote:

Originally Posted by gb2world
For what it is worth - I sent the links for DPM and also the product descriptions on BCSE's site to the director of PCI compliance for the bank who holds the merchant account for one of my clients. They reviewed it and let this particular client know that they would qualify to use SAQA for compliance. I always advise people to try and get the plans for compliance to be reviewed by the bank (with mixed results).

---



Glad to hear they were able to do the SAQA! That's good news! Thanks for letting us know.

Carrie

gb2world 03-16-2011 08:12 PM

Re: Authorize.net DPM (PA/DSS Compliant)
 
No Carrie - thank you. Your mod + DPM is a real game changer for my newer Authorize.net clients as well as the clients I have that were lucky enough to get delayed by the confusion over PCI/DSS compliance. (I guess sometimes the late bird lucks out and gets a worm as well.) I hope Authorize.net, Braintree and others with these methods start getting a competitive advantage so the other gateways are encouraged to do it as well. (I'm plagued with several Innovative and Cybersource accounts to support.) But even within Authorize.net - they ignore my pleading with them to offer a DPM for their CIM method! Not that I want to give X-Payments an early retirement - but with the gateways knowing this kind of thing is possible and not doing it - we'll still need X-Payments.

Also - for at least 2 of my clients, it swings us back in favor of upgrading to 4.4.x or waiting for 5, instead of leaving X-Cart all together. If more gateways start implementing similar methods, and you are still able to release reasonably priced connectors - this should be good news for QT too.

---

ambal 03-18-2011 03:41 AM

Re: Authorize.net DPM (PA/DSS Compliant)
 
Just to make sure we are on the same track - we are talking about one of the PCI-DSS requirements - having to use a PA-DSS certified solution in case you want customers to enter credit card details on your site.

Technically DPM implementation makes entering credit card details "out of scope" of your shopping cart, but at the same time the credit card details page belongs to shopping cart application and this is the fuzzy moment here - must that shopping cart application be PA-DSS certified or not?

Our QSA suggested that yes since the credit card form is generated by the application and this is the main reason we had to implement a separate "enter credit card details" page in X-Payment.

Looks like DPM makes meeting PCI-DSS requirements easier for a merchant (SAQ A instead of SAQ C according to gb2world's post), but it can't be advertised as a PA-DSS compliant solution (Auth.net doesn't advertise it so either). Neither DPM is a replacement for X-Payments in terms of "using a PA-DSS certified solution".

I am still not sure whether or not it can be a way to avoid having to use a PA-DSS certified solution.

I "+1" to gb2world's suggestion:
Quote:

Originally Posted by gb2world
I always advise people to try and get the plans for compliance to be reviewed by the bank


Ask *your bank* before implementing DPM or anything else. PCI-DSS requirements are vague and different specialists may understand it differently.

PS:
and post your results here to help other merchants, too!


All times are GMT -8. The time now is 11:49 PM.

Powered by vBulletin Version 3.5.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.