Integration and Testing

[marks75]

I would have thought the relay response need only return a URL for a 303 response by authorize.net to the user's browser (i.e. typical Post/Redirect/Get). I'm using Ruby. I know that AuthorizeNet::SIM::Response#direct_post_reply handles the dirty work, generating the HTML document with the javascript/http-equiv redirect. Using "refresh" redirects can break the back button and is not recomended practice. I was curious if it is a know design glitch or if there is a specific reason. Is there any reason authorize can't accept a JSON document or a custom header with the redirect URL as an alternative? 

http://www.w3.org/QA/Tips/reback

http://en.wikipedia.org/wiki/Post/Redirect/Get

-lenny

[TJPride Expert]

I think the idea is to give you control over the response, but not give you the ability to set headers, which could result in a lot of exploitation. You could just replace the function that generates the relay response (in the PHP API, getRelayResponseSnippet() in AuthorizeNetDPM.php) with code that gives a response more to your liking. Not that anyone I know has had problems with only going one way - people aren't supposed to be hitting back through the ordering sequence anyway.

[marks75]

Thanks for responding. Unfortunately, now that I've integrated DPM with my site, I'm more confident that the current implementation requiring an HTML refresh/redirect is less than ideal. In addition to not being "correct", it requires integrating sites to implement more code. Worst of all, it unnecessarily interrupts what would otherwise be seamless integration. I had previously been using an advanced integration method (payment form submitted to my server) via ActiveMerchant. Before DPM integration, as a user, if I submitted a valid payment form, I would immediately see a confirmation page. With DPM, I see an intermediate page splash followed by an automatic redirect to the confirmation page. Now of course, as you mention, the intermediate page can be customized, but I don't need or want to see/wait for it at all. Integrating DPM has had a negative impact on the user experience.

    "I think the idea is to give you control over the response, but not give you the ability to set headers, which could result in a lot of exploitation. "

There are no additional exploits that I'm aware of that would be introduced by allowing the "relay response" response to include a custom response header providing a redirect location for authorize.nets 303 response to the user's browser. Alternatively, the same could be accomplished via a text/plain response with the redirect location in the body, JSON, etc..

Anyway, it seems it would be a trivial change to support HTTP redirects as an alternative to the current implementation and I believe it would support a better user experience and truly seamless integration. Is there a recommended channel beyond posting to this list that I can pursue?

-lenny

[TJPride Expert]

Not really. If you wait long enough, one of the admins will read this, but the chances of any mechanics change being implemented within at least the next few months are minimal. Theoretically, you can prevent the user from hitting "back" from the receipt, though:

http://viralpatel.net/blogs/disable-back-button-browser-javascript/

[RichardH Administrator]

As @TJPride mentioned, I have been lurking here during your discussion and have forwarded this suggestion to our product management team for consideration in a future release.  Unfortuantely, I can't provide any guidance on when this might be included.

I'd recommend subscribing to this topic so that you'll be alerted via email if there are updates or suggestions from other community members. To subscribe, click Topic Options at the top of this thread and then select Subscribe. You'll then receive an email once anyone replies to your post.

Thanks,

Richard

[kingIZZZY]

+1

It's as if the Authorize.net DPM developers never heard of the HTTP 'Location' response header :robotsurprised:

http://en.wikipedia.org/wiki/List_of_HTTP_header_fields

http://en.wikipedia.org/wiki/HTTP_location

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30

http://tools.ietf.org/html/rfc7231#section-7.1.2

Additionally, Use of meta refresh is discouraged by the World Wide Web Consortium