Authorize.net DPM (PA/DSS Compliant)
 

Just released! Authorize.net DPM (PA/DSS Compliant).

https://www.bcsengineering.com/store/authorize.net-dpm-module-for-x-cart-pa-dss-compliant.html?MMCF_xfAN_DPM

This uses your existing Authorize.net AIM account and changes it to post directly to Authorize.net, rather than going through your X-cart code to post to Authorize.net This can take your site out of PA/DSS Scope and still allow you to process credit cards on your site!

This allows you not to need X-payments!

Thanks,

Carrie

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

Looks fantastic Carrie thank you for releasing this.

When a visitor places an order using this mod are they taken to the exact same receipt page (from X-cart) as in the past? (the &orderids page)

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

No problem! I hope it helps many!

Yes you will be taken to the same page. The customer won't see any changes. It uses javascript to alter how the post is handled.

Let me know if you have more questions!

Carrie

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

If anyone has requests for versions other than 4.1.x through 4.4.x do let us know.

Carrie

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

Just wanted to say that I installed the first one of these yesterday, and it works SEAMLESSLY. The client didn't even notice the difference, and the install was flawless as well. HIGHLY recommended - I'm even advising a number of my clients to switch to auth.net just so they can use this. X-Payments? Who needs it?! Great work BCSE!

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

Thanks Padraic! I'm glad it went so smoothly and that you and your clients are happy! :)

Carrie

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

Carrie: If we do captures only and then charge them through the xcart admin pannel will this modification keep the same going? So we can bill them in the admin pannel? or must we go to authorize.net to bill people if we use this? I know the customer side is the same, but i'm curious what changes on the backend/admin side I guess?

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

I don't think that's something we can test, with a test account. I'm assuming that the admin functions are still the same. Really the only thing that has changed is how the CC info gets to Authorize.net. I don't think any admin features are different. You still get a transactionID which I'm assuming there would be no reason that you couldn't charge using it like always.

Do let me know if you find out. I don't know of anyone trying this.

thanks,

Carrie

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

so the checkout page looks 100% the same as before this mod? What about the admin pannel? can you still have pre-authorized status and bill it from within Xcart?

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

It doesn't change the admin panel at all, or the functionality - same as before. And the only change to the customer side is that the user stays on the same page while the order is processing - they see a spinning graphic after they hit submit, and the CC entry areas grey out.

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

Carrie,

Concerning the mod, when I look at your website, I see "Minimal installation. Simply apply an SQL patch and upload files!" and "This should work seamlessly if your cart is not modified or minimally modified." So how do you define "minimally modified"? What specifically should we be concerned with pre-install?

Thanks much,

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

I just changed the description some. It should more specifically say:
"This should work seamlessly if your checkout area is not modified or minimally modified. All source code is provided though if you need to make any modifications to suit your checkout area if it is customized."


So it's not really X-cart in general, just the checkout area. If your submit order button has not been changed, it should work seamlessly. Also the paymentID must be in the URL or in a post variable (which it would be by default unless your checkout area is modified.) We've only run into a few carts that we had to debug, but only because their submit button was changed for the checkout area or the paymentid was where it normally is in X-cart.

Let us know though if you have more questions!

Thanks,

Carrie

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

Carrie,


1. As we use AlteredCart OPC, should we be concerned with a paymentID issue?

2. On the authorize.net side, would there need to be any changes in our account as we are already an AIM user?

Thanks again,

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

1. Yes it's compatible with Altered Cart AND X-cart's OPC module.

2. No changes needed to Authorize.net account. They just see it being posted a different way but it all goes into your existing AIM account.

Do let me know though if you still have more questions!

Thanks,

Carrie

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

We have a lot of people using this module now. If you have any feedback we'd love to hear it! We're also improving our testing/trouble shooting area of the install file here in a few days. We've had relatively little support issues with it but there are a few key settings that we'll be documenting to make sure the transition is even smoother. :)

Carrie

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

Carrie you are freaking awesome!!! Love you guys :mrgreen::mrgreen::mrgreen:

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

Thanks! :D

Carrie

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

Hi Everyone,

This is a stupid question I guess, but why you think Auth.net DPM makes your store out of PA-DSS scope taking in account a payer still enters credit card info on your site? Did I miss something?

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

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

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

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

http://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Direct-Post-Method-DPM/bc-p/10804

That page says the opposite about the credit card form.


Then in the comments it is stated that DPM "reduces scope of PA-DSS", but it doesn't take "out of scope".

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

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

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

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

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 :)

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.

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

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

and


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

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

Yea, that's what I meant ;)

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

---

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

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

Carrie

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.

---

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:

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!

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

The issue though is that one piece of software can't make you PA-DSS compliant. The DPM module is just one tool to help you move toward that. Authorize.net also doesn't state that I can see that their SIM integration is also PA-DSS compliant either, yet the whole transaction is taken on their site. The main reason being they can't guarantee anything else about your business process.

This would be the same as X-payments, even if it's does get approved as an application that's PA-DSS complaint, it doesn't make you PCI compliant without reviewing all of your other business processes around credit card transactions and security of your server.

Customers should always rely on their PCI compliance Auditors as to whether they are PCI compliant and whether the applications they are using are PCI compliant. This is one of the reasons we state it helps 'support you to be PCI Compliant including the new PA/DSS standard' It only supports you, it won't certify you.

I hope that clears it up.

Thanks,

Carrie

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

Price aside, what is the major difference between using x-payments and authorize.net DPM?

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

- The installation of DPM is vastly easier.
- The process for managing is no different for the shop owner than AIM. X-Payments management process is much more complex (Pin Codes, setting up crons, etc.)
- SAQ-A vs. more difficult paper work required by the bank
- One Page checkout is possible with DPM, not with possible with X-Payments
- X-Payments is even more complex installation for pre 4.3 X-Cart

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

I thought X-payments cannot be installed on 4.3 and earlier now?

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

X-Payments can work with 4.3 out of the box
and it requires code tweaking for older versions.

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

Excellent...thank you.

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

Hello Carrie, can such a module be developed also for Sagepay?

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

I looked through their site and I don't know if I'm missing it or what but I couldn't tell for sure. What I'd do is give them the Authorize.net link we provide on our site and see if they have some sort of direct posting method like that, that keeps you on your site still. If so, drop us an email to 'support' and we can evaluate doing it for you.

Thanks,

Carrie

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

Honestly, I'm a bit lost. Would you, gentlmen, clarify for the poor one what else do we need to qualify for the bank requirements in addition to installing, say, DPM and completing SAQA?

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

Rdr. Michael ,


I'm not sure anyone on this forum is in a position to address the qualifications for any particular bank or card provider. If you have installed DPM and successfully completed SAQA, perhaps consulting with your bank would be a good idea if you are still concerned about compliance with them.

As for our business, after installing the BCSE Authorize.net DPM mod on all our sites, we created and distributed protocol to all staff members for destroying all cc information via phone, fax, land-and-e-mail. It's our policy not to store cc information in our building and we tell our repeat customers that it's for their protection. Only one customer complained but 99% have appreciated that we do not store their cc data.

We successfully competed SAQA and will keep the audit on file both on site and remotely (cloud server). With recent news like this http://reut.rs/dF6cSt the public will appreciate all you do to make their sensitive information as private as possible.