breck

Direct Post Method (DPM)

by ‎11-03-2010 05:23 PM - edited ‎11-03-2010 05:30 PM (15,521 Views)

Authorize.Net recently launched the Direct Post Method (DPM) which makes it faster than ever to take full control of the checkout process.

The Direct Post Method gives your merchants complete control over the pages related to the checkout experience. You can create your merchant's own checkout form and host it on their own server. If your merchant wants to add analytics to their page, they can. If they want to test different background colors, font sizes, live chat, or blinking text, go for it! You can design, tweak, and test your merchant's checkout forms as you would any other page on their site.

Sure, customizing checkout pages isn't a new phenomenon. But in the past, when a website hosted its own checkout form, it meant that the website would also be handling credit card numbers and other sensitive data. The Direct Post Method allows your merchants a fully customized checkout process without handling sensitive payment information. With DPM, all the user-facing content and forms are hosted on the merchant's site, and then you simply set the form to post to Authorize.Net's secure servers. Authorize.Net processes the sensitive cardholder data invisibly, and relieves some of the worries about security.

How it Works

Understanding how DPM works is very straightforward. Simply create a webpage with a credit card form, and post it to Authorize.Net's endpoint. Just add Authorize.Net's URL as the 'action' on the form, so

 

<form action="YOUR_URL" method="post">

 

becomes

 

<form action="https://secure.authorize.net/gateway/transact.dll" method="post">

 

Just make sure the name of the input fields corresponds to the Authorize.Net API fields, (credit card number should be "x_card_num" for example). The full list of fields can be found in the Authorize.Net SIM Guide.

When a merchant's customer submits this form, Authorize.Net sends the results of the transaction to the merchant's server without sending any of the sensitive cardholder information. The merchant's server can then store these results and send a response back to Authorize.Net. In the Direct Post Method, this response is simply a snippet of HTML which contains a bit of javascript and/or a meta refresh tag which directs the customer back to the merchant's site. When the customer comes back to the merchant's site, you can retrieve the transaction results saved a moment ago and execute any business logic, then show a receipt (or error) page to the customer.

All of this happens behind the scenes. To the customer, the experience is seamless. All they do is click the "Submit" button on the checkout form, and the next page they see will be the merchant's own receipt page.  As far as the customer is concerned, the domain name stays the same.

To summarize, the Direct Post Method offers a fully customizable checkout experience that's both easy to implement and secure. 

I'm imagining you might have a couple questions right off the bat.


Q: "This sounds a lot like SIM. What's the difference?"

A: Yes, SIM is a great solution to reduce PCI compliance risk, but the default is for those pages to be hosted on Authorize.Net. With DPM, the merchant hosts the order page and receipt page every time, allowing for full customization. This modified payment integration method simply allows maximum flexibility while still reducing the PCI compliance burden of handling the customers' personal payment information.  

Q: "Wait, what about security?  I thought a form with sensitive information should be hosted on a secure site?"

A: Yes, it is recommended that the order and receipt pages are hosted on a secure server. Having the checkout and receipt pages hosted on a secure server provides the customer with peace of mind. While an SSL is not technically required for DPM, if your merchant wants their customers to see HTTPS in the browser, this means that the merchant will need an SSL certificate. If acquiring an SSL certificate and hosting pages over HTTPS is a blocking issue, you should consider SIM instead.




For further reading, the Developer Center has more information about the Direct Post Method and also provides demos of the method in the Authorize.Net SDKs as well as in the quick start guides. If you have questions or run into problems implementing DPM, the forums are a great place to ask for help.

If you or your merchant need an even easier way to accept payments, there's the Simple Checkout Method. If you need a more advanced solution and are comfortable handling sensitive cardholder data, take a look at the Advanced Integration Method. If you want the best of both worlds, the Direct Post Method is for you.

 

 

 

---
Breck is a guest contributor for Authorize.Net

 

Comments
by kwestby on ‎11-04-2010 10:26 AM

I cannot see how this solution reduces any scope for PCI compliance for the merchants ecommerce server. Their server is still hosting the payment order forms, establishing the session the customer is submitting the payment card data through (from their browser) and the merchant server is establishing the connection to the Authorize.Net gateway using the DPM method and passing the CC data.

  

This does not provide any reduction in PCI compliance scope for the merchants server or hosting environment compared to any other gateway post method API. It seems very miss-leading to compare this to a hosted order form service where all capture and processing is done in a PCI compliant environment and on PCI compliant hosts communicating directly with a consumer through a secure session. This solution may achieve ease of implementation but has no benefit to security or compliance. As a QSA working in PCI compliance for over 7 years I can tell this would not reduce a merchants scope for any SAQ or ROC that I would sign off on.

by kwestby on ‎11-04-2010 11:34 AM

To clarify my earlier comment, the merchant server is still in scope because they are establishing the payment session with the customer, presenting the payment form and defining the posting logic from the customer to the DPM. If I have a compromised merchant ecommerce server there is no expectation of secure payment or PCI compliance. With a hosted order page method (SIM) you can have a compromised server and the consumer will have an opportunity to abort a fraudulent transaction if presented with another payment form or redirected to another site.

 

In the DPM solution the customer is presented that they are always communicating credit card data securely. However the context of the security is completely controlled by the merchant's server. A compromised merchant server with a couple of lines of code would mean that any consumer data entered through this method would be compromised. The customer would have no way of knowing. We all know that many small ecommerce merchants are hosting their sites on non-PCI compliant hosts and without proper environmental security.  Many times you will find wide open systems with unauthenticated FTP to shared servers.

 

The SIM method and any PCI compliant hosted order page method allows the merchant to remove their servers from scope because they are no longer controlling the payment transaction. The payment transaction is set-up from start to finish between the consumer and the PCI compliant service provider. The consumer has a way to validate this through their browser to confirm certificate and transmission security. The DPM method does not provide this protection to consumers and can present a false sense of security and compliance to both merchant and consumer.

 

 

 

 

by TNTitan89 on ‎11-10-2010 01:47 PM

Is there no response from Authorize.net regarding kwestby's comments?

 

I see that Breck provided this info on another post:

 

"A large number of tasks to meet the PCI DSS requirements only apply if you are storing or processing cardholder data. With theDPM method you are completely offloading the handling of cardholder data to Authorize.Net which leaves less for you to do."

 

That makes sense to me.  If that's so, what is left for the merchant to do?

by jeffshaikh on ‎11-16-2010 12:43 PM

Authorize.net,

 

Any response to kwestby's comments? Where and how is the best method to get this addressed?

 

The documentation says "...simplifying PCI compliance...",  "reduces risk to merchant...", but I understand and agree with kwestby's comments.

 

If the payment form is generated by the merchant server, then the mercahant server is inside PCI and SAQ scope.

 

Exactly how does DPM simplify the PCI compliance or reduce risk to merchant?

by Administrator Administrator on ‎11-16-2010 12:51 PM

It is generally accepted that reducing contact with cardholder data and limiting systems that transmit, process or store cardholder data can reduce the scope and complexity of a PCI assessment. That said, no one can take responsibility for a merchant’s PCI compliance efforts, but the merchant. Authorize.Net merchants are required to maintain compliance with all applicable industry and regulatory requirements including PCI. Our solutions (or any solution) must be properly implemented on compliant systems in compliant networks, but solutions such as SIM, CIM and DPM can and do help to simplify PCI compliance efforts.

With DPM, a merchant creates a payment form on the last page of their checkout process. When a consumer is ready to check out, they pull up the payment form with their browser, enter their credit card info, and when they hit submit, the browser transmits the data directly to Authorize.Net.  By posting directly to Authorize.Net, and not back to a script on the merchant server – as with AIM – a merchant can simplify their PCI compliance.

by zgpablo on ‎11-21-2010 11:29 AM

Hi Michelle,

It seems that the PCI language specifically states "receive, store, process, transmit". DPM clearly does none of these, it merely sends a form to the user that "transmits" PCI data from the clients computer and never touches the server.

 

But I spoke to support at Trustwave/Trustkeeper to verify this and the person I spoke to clearly stated that "because the server generates the form and sends it to the client, and because when completing the credit card form the URL is the server URL, then full server PCI compliance will be needed."

 

As far as I can tell, Trustwave is an Authorize.net partner and therefore should be in the loop if any PCI auditor is. So as it stands, I was specifically told by our representative at Trustkeeper that our server will need to be scanned if using the DPM method rendering it no more useful to us than the AIM (which we love) method.

 

I know you disagree with this but I would love to get an official agreement and maybe some support when dealing with PCI compliance companies.

 

Is there a future for my dream?

 

ps.

sorry for posting similar comments on 2 similar threads

 

by mikell on ‎12-01-2010 08:48 AM

"and because when completing the credit card form the URL is the server URL, then full server PCI compliance will be needed"

the whole idea of the direct post method is to post the credit card info *directly* to an authorize.net server.

if you need to save some form info (name/address/etc) to a database then do that first...then have another step to let them fill out

credit card info and make sure when they hit submit it posts to authorize.net. then you won't have to worry about PCI compliance.


by mikell on ‎12-01-2010 09:28 AM

nevermind just did a little more research and apparently generating a form with credit card info on your server

is enough to have to worry about PCI...perhaps to a lesser degree than if you were to post directly to your own server?

who knows.

by Administrator Administrator on ‎12-03-2010 03:32 PM

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, as already indicated, 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.

by rhaffner059 on ‎03-02-2011 07:31 AM

Is anyone using a Flash/Flex front-end to submit transactions through DPM to Authorize.net?

by spastic ‎07-13-2011 07:53 AM - edited ‎07-13-2011 08:06 AM

PCI is a Scam plain and simple!

 

There are companies and individuals trying to make PCI to be what it is not. Why? Because its putting a large number of $$$$'s in their pockets. These folks would have the browser be within the scope of PCI as well in their interpretation and it is NOT. The customers computer is "on a network" ---- Who is scanning their computer and their network to the server? Thats' right !! No-one !! Chances are high that the security problem is actually on the customers computer or their home network, and their computer network has at least one virus, one trojan or it has a rootkit on it already. If you don't believe it, check the stats on the number of personal computers that are already infected. In fact, saying the actual form has to be scanned is saying exactly this--- it is essentially saying, we really can't trust the browser or the customers network for that matter and we have to make a merchant responsible for that too via a PCI scan that won't really catch the real problem anyway because there is no sensitive card holder data there!  It can't be hacked on the merchants servers because it NEVER GETS THERE.

 

As I understand what AuthorizeNet is saying when they say it "takes you out of scope", they are referring to the shopping cart application. The scope of PCI-DSS falls on AuthorizeNet who alone collects and stores the "sensitive card holder data". The application does not.....  The customers scope of PCI is only with regard to vendors acting in their behalf. Look up the definition of who PCI pertains to and it pertains to those who "store and collect sensitive card holder data" (that's it).  Its scope on merchants is only to certify the vendors it chooses is pci compliant.  The merchant is only subject to PCI with regard to completing a Q&A because their vendor (Authorize.net) is subject to PCI, they do not have to do a PCI scan on their network because no card holder data rides on their network (transmitted), nor is it stored on their computers and processes.

 

The people who wrote PCI never realized that applications did not have to "operate" in the fashion they do...they can easily off load the "sensitive card holder" data to a few select vendors.  Thats because PCI was not written by anyone with any descent technical knowledge.  It was written by people who say a chance to make a lot of money.  Security-wise, that is the right thing to do. Its the right thing to do for the credit card companies, the merchants and customers as well. And sorry to say, all the people trying to make a buck off of PCI paranoia and blowing it up to be more than it really is will eventually be out of business...and that's a good thing too.

 

If someone has spent 7 years in PCI and doesn't see this takes the shopping cart application out of scope for PCI, then they should be out of business.  If you want to see who is in scope for PCI, you draw a flowchart of where the sensitive cardholder data "IS" and where it  "GOES".  If the data shows up at location "A" for even a second, then they are under the scope of PCI-DSS.  Plotting a simple flowchart in this case, the Form is served up by the merchants server- yes; however, there is no sensitive card holder data there so its just like any other form in the world, its just like the shipping information form that proceeded it.  Its not subject to PCI until and unless it has "card holder sensitive data in it" (Thats the definition of PCI scope).  In fact, the customer could just save the form from the browser to his desktop at that point, go to the bathroom, have lunch, then point his browser to the form already saved on his desktop.  At that point, he then puts the "sensitive card holder data" in the payment form on his computer browser screen.  The second he does that, the application and subsequent processes are NOW in PCI scope.  In fact, the customers computer and network is also in PCI scope...which as I indicated is the PROBLEM with PCI!!!  He presses the send button.  The data does NOT go to the merchants server or his company !!  The data from the browser crosses over the customers network and the customers ISP, which is under PCI, but we all seem to ignore that fact, and goes to AuthorizeNet.  AuthorizeNet now has accepted and subsequently stores this "sensitive card holder data".  Meanwhile, the customers computer, who was probably hacked long ago, and has had a packet sniffer installed as a part of a rootkit exploit from a chinese hacker that hacked his network 6 months ago.....so the card holder data has long been sent to the criminals, irrespective of what the merchant does, what the gateway does, or the merchants ISP does.

And, that brings me back full circle, PCI is a scam!

by spastic ‎07-13-2011 09:19 AM - edited ‎07-13-2011 09:25 AM

BTW,

This statement

"Their server is....establishing the session, the customer is submitting the payment card data through (from their browser) and the merchant server is establishing the connection to the Authorize.Net gateway using the DPM method and passing the CC data. "

 

Is just WRONG!  You do NOT know how the internet or how a browser works.  The browser will post the data directly to AuthorizeNet...it will not stop over the merchants server or travel over the merchants network at all.  The card sensitive data will NOT go THROUGH the merchants server period, end of story.  The merchants server sent the blank form to the customers browser, the customer inputs the sensitive data, for the first time(which is when PCI comes into being), on his personal computer which has never been PCI scanned, it travels on his network and via his ISP's network, that is also NOT PCI scanned and goes DIRECTLY to AuthorizeNet's server.  Since the form did NOT have card sensitive data on it when it was sent to the customer, it is out of the scope of PCI. 

by bobcatos on ‎12-13-2011 01:36 PM

My client has been using AIM for a long time and is wanting to switch to DPM to get out from under most of the PCI hassle.  However, we are using Perl and its Business::smileysurprised:nlinePayment module described here. I'm wondering if I can leverage B::smileysurprised:P for DPM or if I need to program down to the bare metal (build some XML thing), or if someone has already invented this wheel.  I've built a system for another client for use with PayPal's Instant Payment Notification, which looks similar to DPM but it's asynchronous while DPM is synchronous.  Any hints available?

(Those idiot smileys are not supposed to be there. I dunno how to turn the dang things off.)

by Administrator Administrator on ‎12-22-2011 01:09 PM

Hey there,

 

You know, since DPM is an extension of SIM, you may want to check out the documentation for SIM at http://developer.authorize.net/api/sim/. That may give you some ideas on how to proceed with DPM. 

 

Thanks,

 

Michelle

Developer Community Manager

by cedaly1968 on ‎10-30-2012 07:42 AM

I use X-Cart and have been using Authorize.net AIM for payment processing.  I installed the DPM module to directly post the data to Authorize.net (via my web-host of course).  In my SAQ I am being asked if the payment application, is PA/DSS validated.  I am assuming AIM/DPM is the payment application but I cannot find a vlaidation date for the app.  Does anyone know the validation date?

 

Thanks

About the Author
  • Authorize.Net Developer Community Manager
Announcements
Labels