error handling with DPM

[spinebibuw]

I have implemented the DPM using PHP, and everything seems to be working well in test mode.

However, I think I just realized a major shortcoming of this approach, so I wanted to see if someone could verify that I am right.

The problem I see is that when there is a problem with the user's submission (mistyped card number, for example), there is no way to repopulate the checkout form with the values the user entered the first time so that they can merely correct the problem rather than completely reentering the data.  With the card processing being done totally on the merchant server or totally on the authorize.net server, this is a simple task of populating the default form field values with the post data, but this data is lost in the process of making the round trip between the merchant server and the authorize.net server.  Is there a way around this while still avoiding the need for full PCI compliance?

[spinebibuw]

I have implemented the DPM using PHP, and everything seems to be working well in test mode.

However, I think I just realized a major shortcoming of this approach, so I wanted to see if someone could verify that I am right.

The problem I see is that when there is a problem with the user's submission (mistyped card number, for example), there is no way to repopulate the checkout form with the values the user entered the first time so that they can merely correct the problem rather than completely reentering the data.  With the card processing being done totally on the merchant server or totally on the authorize.net server, this is a simple task of populating the default form field values with the post data, but this data is lost in the process of making the round trip between the merchant server and the authorize.net server.  Is there a way around this while still avoiding the need for full PCI compliance?

[TJPride]

The whole point of DPM is to give you a form at your URL while avoiding having the credit card data passing through your system. So the form submits directly to Authorize.net, thus protecting you - but also making it technically impossible to repopulate the form, since you don't have access to anything they entered and Authorize.net doesn't have access to your form. So the short answer is no - if you want a custom form while still avoiding PCI issues, you're pretty much stuck. You can, however, eliminate most credit card typing errors at least by running the Luhn algorithm against it using Javascript onsubmit, which is entirely browser-side and therefore doesn't affect your PCI compliance.