DPM - PHP SDK request and response conceptual overview

[nutmagpie]

I have the PHP SDK sample application (coffee shop) working.  I have begun configuring this for my client.  I am seeing a disconnect between what was explained in the conceptual overview of DPM and, now that I'm in the details, how this code can actually work for us.

I find myself deliberating between DPM extending SIM and DPM extending AIM.  I thought DPM was a separate methodology and therefore I distrust my undersanding of the documentation.  Can you please clarify?

Expected behavior based on DPM Developer Guide Conceptual Overview

1.) Payment form: Payment form is hosted on merchant server.  Client inputs credit card and other information.  We do live error validation (JavaScript) to verify valid inputs (length & format) before submission.  Form also includes hidden fields that are included in the POST to direct the processing of the transaction in the API.

2.) Request and Processing: Upon clicking 'Submit', data is sent via POST to Authorize.net's API URL.  Authorize.net attempts to process the transaction and generates a response code and, if applicable, error message.

3.) Response transmission and processing: Response is sent via POST to merchant's server to process.  Merchant can i.) use PHP API objects to interpret response as success or error, ii.) process POST data, including storing off data, and iii.) upon completion, provides a signal (not sure what) to Authorize.net to invoke the relay_response_url.

4.) Relay: Authorize.net's server sends relay_response_url to client's browser using JavaScript client-side redirect.  x_relay_response must be included as a hidden field in the form in step #1, so it must invoke a secondary client-side redirect to pass the client to the appropriate success or error page.

Snags

A.) Where to host the Payment Form. 

DPM extending AIM:  If the Payment Form is hosted on the merchant's server, then SSL is required for the secure transmission of the form data to Authorize.net.  This is an added cost.

DPM extending SIM: If the Payment Form is hosted on Authorize.net, then the user experience is compromised as we must use the hosted form template and it is no longer a "seamless" look and feel.

DPM opotion #3: I called the telephone helpline and he directed me to this forum for help with his understanding of how DPM should work which was not in the Developer Guide.  He believes that the payment form is dynamically generated by the merchant server but then passed to and presented by the Authorize.net server.  That way, Authorize.net has full responsibility for the data entry and submission.

B.) Error-handling of incomplete/ incorrect Payment Form.

DPM extending AIM:  Merchant's server must interpret various response errors (haven't figured out how complicated ths is yet). We re-present the form with all fields being "sticky" (remembering the client's input) except for the sensitive credit card information, which they would need to re-enter.

DPM extending SIM: I was quite disappointed with the user experience in testing the hosted payment form.  There is no live JavaScript validation to prod the client on required fields, incorrect formats, etc.  After submitting, the client is given a barely-formatted error message on a subsequent page, presses the back button, and must re-enter all information.  I see no way to customize the appearance of the hosted error page (for example, to provide the merchant's telephone number for help).

C.) Handling of response

i.) I do not see any documentation / example about how to process POST data before invoking the relay_response_url.  

 ii.) I do not see how to process POST data after invoking the relay_response_url.  I need the Authorize.net server to pass control back to the merchant's server and it seems the only way to do this is to make the client click a link.  "Relay Response does not redirect the end user back to your server, but relays your specified Relay URL to the end user through our receipt page instead of displaying our default receipt page. If you would like to redirect the end user back to your server, please provide a link on your Relay URL for this purpose."  

Can you please help by elaborating on the correct end-to-end order of events for DPM and, in doing so, how to address these three snags?

[RaynorC1emen7 · Accepted solution]

A.) Where to host the Payment Form.

The payment form is host on your site, but it post to authorize.net in https. So SSL is not required on your site but it will look better.

B)Since the page is host on your site, you can do all the javascript test you want before submitting to authorize.net. But for error like billing address not match or something you will have to redirect it back to your DPM page with an error message or something

C)The easier way is make a simple relay response page where you save all the response post data from authorize.net. then do a javascript redirect to you site to display the receipt or redirect back to the DPM with error.

[nutmagpie]

Thanks for the quick response!

A.) SSL helps with perception but there are also real security vulnerabilities in rendering and collecting the data prior to an SSL connection.  For example, an attacker could modify the page as it is sent to the user and change the form submission location or insert JavaScript which steals the username/password as it is typed.  My client has agreed to the expense of an SSL certificate, so we are all set in this regard.  It was just a surprise.

B.) Thanks!  I'll start testing this out.

C.)  Please confirm that the relay response expected from Authorize.net is simply this function from the PHP SDK:

echo AuthorizeNetDPM::getRelayResponseSnippet($return_url);

public static function getRelayResponseSnippet($redirect_url)
    {
        return "<html><head><script language=\"javascript\">
                <!--
                window.location=\"{$redirect_url}\";
                //-->
                </script>
                </head><body><noscript><meta http-equiv=\"refresh\" content=\"1;url={$redirect_url}\"></noscript></body></html>";

D.)  (New snag) My plan for tracking users on the merchant's site is to use https (SSL) along with a PHP Session ID cookie.  When I receive the transaction confirmation / error from Authorize.net, I can identify the user using the fingerprint and other fields in the transaction.  I could then re-issue a PHP session ID... but it will be lost again when passing the relay response to Authorize.net: "The HTTP header should not be relied on for including customer information such as cookies. When the response is relayed to the customer’s browser, HTTP headers are replaced."  So then my only option would be to pass a field to identify the user in an unsecured connection in the POST or GET arrays... or ask the user to login again... 

...Any ideas / examples how user tracking is maintained in the relay response?

Thanks again!

Megan

[RaynorC1emen7 · Accepted solution]

a)SSL is not going to help if your server got hack. It just look better for the everyday customer who doesn't understand that  as long as the form post to a https location, it is secure.

c)looks ok. but I'm don't have experience with php.

d)So then my only option would be to pass a field to identify the user in an unsecured connection in the POST or GET arrays

if you going to have SSL install on your web service, you can setup the relay response url to use https, then it will be secured. But the key thing is that anything can be change on the client browser, e.g. firebug for firefox, it's great for debug, too.

And if your php session id is non-sequence and unique, you can use that as the identify field.

[nutmagpie]

Thank you once again!

d.)  It clicked.  When the client's browser receives the relay "https" URL, they will send their existing PHP session cookie along with the URL to the merchant's server.  So the merchant's server will get the existing cookie sent securely and we can give them user-specific information on the next page.   I'll re-issue a new random php session id just in case.

Thanks for all your help Raynor!