Authorize.net Direct Post Method (DPM)?

Are there any plans to add the Direct Post Method (DPM) to the Authorize.net plugin?

The other methods either take the customer off the page or require storing of credit card information, neither of which I want to do. DPM is the perfect solution, but it isn't implemented.

This, truly, is the only thing keeping me from switching to Hikashop.

My mistake. It had been a while since I went through the process of choosing an API to use with Authorize.net, so I refreshed my memory as to why I will only use DPM:

The advantage of DPM over AIM is this: With DPM, the customer's credit card info never touches my server. The customer fills out the fields on their browser screen, but when they submit the information, it is posted directly to authorize.net's servers. With AIM, the data is posted to my server which then turns around and submits the info to authorize.net.

So while the info is never actually stored in either method, when using AIM the data is at some point present on my server. Which, according to current PCI standards, puts my server is in the PCI envelope.

Also, DPM doesn't require SOAP.

DPM is fairly recent which is probably why there are few plugins and/or systems that have implemented it. So, I am the first to ask for it. Does that mean there is very little demand or does it mean that few people are aware that this far superior method exists? How many people have looked at Hikashop, passed on it because there is no support for DPM and just remained silent (as I did until yesterday)? Can you see how many people have searched your site and forum for "authorize.net dpm"?

Perhaps offering DPM would be a competitive advantage. With all the sample code Authorize.net provides, it doesn't seem like it would be too large of a development effort.

Ok, now that I have tried to make a logical case for it, the next step is just pure begging.

I mis-spoke earlier. The other showstopper for me is lack of support for serial numbers (or access codes).

I need to be able to upload a set of serial numbers which represent the quantity in stock. After purchase, a number is emailed and then deprecated in the database. I've searched the forum and there just aren't any good workarounds.

Which is a real bummer because everything else about Hikashop seems to be superior to the competition.

Actually I too would be interested in the DPM method over AIM as it keeps customer on your site.

From my understanding, AIM requires that the entire cart (and hosting) to be PCI compliant/validated.

However, DPM seems to be the area that most bank/merchant providers seem to allow since it is posting back to Authorize.net directly. A lot right now seems to be left up to the interpretations of the compliance officer with the bank/merchant provider (same goes with enforcement/fines).

DPM might be a grey area because there is some that question if it is PCI-DSS compliant because the form comes from the cart side itself however.

Some say agrue a bad guy could get access to the cart and hi-jack the form on the cart. Course I say you could do that no matter what method you used. You work hard enough you can spoof Google Checkout and PayPal so in my opinion that is a lame argument. So I think DPM is the best option to allow a shopping cart to be used and PCI-DSS compliant.

The only other option I see with Authorize.net is their SIM method.

There is a heated discussion about this very matter over on x-cart's forums as x-cart is completely pulling all back-end methods like AIM from their cart in the next version. They will only support the direct web methods like Authorize.net's SIM but that takes people off your cart site and to the gateway's site like paypal and Google Checkout.

I think x-cart approach is rather draconian and likely unnecessary (and an obvious push to their x-payments add-on for $1200 to be PCI compliant).

And we all know that the conversion rates drop through the floor when you leave your site during checkout.

Thus that is why I'm interested in the DPM method and I would suggest taking a serious look at this. Otherwise there is a looming deadline coming July 2012 where banks/merchant providers are suppost to start enforcing the PCI compliance and leving fines.

I've only hear stories of large fines being levied against the merchants for not being compliant. But I have a friend that is a reseller for First Data and he says it is coming in a major way.

Hello,

I'm in charge of the development of the Direct Post Method (DPM), and I managed to do something so if someone can test it and tell me how it works, it would be helpfull.

regards,
Mohamed Thelji.

I see that DPM is supported in the latest version of Hikashop, however the documentation has not been updated. If I simply change the API dropdown box from AIM to DPM, it doesn't work. The Payment screen shows my payment method, but no fields show to collect the credit card number, expiration date or validation code. Hitting "next" caused an error to appear.

Do I need to change anything else in order to use DPM?

I get the message:

Array()

Warning: Invalid argument supplied for foreach() in {...}/plug-ns/hikashoppayment/authorize_end.php on line 32


and then the screen moves on to show this:


The following errors have occurred.

(13) The merchant login ID or password is invalid or the account is inactive.

I have attached two screen prints. The first shows how the fields do not display for entering the credit card info and the second is the first of these two error messages.

Hello !

Can you please test it with this authorize.net plugin ?

I have tested the updated plug-in. The screen that shows the payment option still doesn't show a place to enter the CC info.

When I hit "Next" a page shows some info and I have attached the print screen for that. Then the page automatically advances to a screen that looks like the second screen print I have attached.

If the DPM screen is going to look like that second screen print, then don't bother working on this any more for me. My current store (running Prestashop) uses DPM and it operates and looks EXACTLY like the AIM version. That is what I am expecting to see here.

Hello,

regarding the CCV, you'll have to :

- log into your authorize.net merchant account
- Go to "Account->Payment Form->Form fields"
- set your Payment Form like it's set in the screenshot

And you should have a form like the second screeshot, regarding the error in your first screenshot, I'll try to fix it.

Sorry, I must not have been clear. The first payment screen that appears still looks like the screen shot provided 3 posts back (scroll up to see AuthNet_Screen.jpg). That is what I meant when I said "doesn't show a place to enter the CC info."

But the bigger problem is that I want my DPM screen to appear exactly like it does now when I am using AIM. What you are showing me looks like the Authorize.net screen in an iframe and that is definitely not what I am looking for.

Hi,
We developped the Authorize.net DPM method like it's said in the documentation, so we will maybe check what prestashop have done, but for now we will not change the DPM method before at least next release.

I suppose it's possible that my Prestashop setup is the one that isn't correct. The DPM setup in Hikashop looks like SIM in an iFrame. I want something that looks like AIM and perhaps AIM is the only way to do that.

Looking at Authorize.net's documentation for AIM and DPM, both show the merchant server as the one that displays the screen for payment entry. The difference is that with AIM, the page is posted back to the merchant server before being sent on to the Authorize.net server. With DPM, the post is made directly to the Authorize.net server. Based on that info, then, the page shown for payment entry could look the same. The only difference is what happens when the user submits the form.

I am referencing these two pages from Authorize.net: developer.authorize.net/api/howitworks/aim and developer.authorize.net/api/howitworks/dpm

Also, if you were to check out Prestashop, I am using an add-on component for DPM made by Presto-Changeo ( www.presto-changeo.com/en/payment-module...rizenet-payment.html ).

It sounds like Hikashop's implementation of DPM is NOT actually implemented. It sounds like it is SIM in an iframe. This is not how Authorize.net's DPM works. Has the Hika team made any progress on properly implementing the DPM? developer.authorize.net/api/dpm/

This would be a deciding feature for my situation. Thanks.