X-Cart forums

[Ene]

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]

Also, I don't see Auth.net advertises DPM as a cure for PA-DSS

[balinor]

Perhaps BCS should step in here and answer this question, as clearly there is some confusion - my own included

[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.

[BCSE]

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

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

and

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]

Yea, that's what I meant

[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).

---

[BCSE]

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]

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]

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:

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!