Can't set x_receipt_link_URL (should be returnUrl)

[delatbabel]

Further to #16 where the code change was made to set the x_relay_url from the notifyUrl instead of the returnUrl, a method needs to be in place to set the x_receipt_link_URL which is in effect the returnUrl for the SIM gateway.

This is a non-BC change for anyone who's currently using the returnUrl to set the x_relay_url.

References:

https://www.authorize.net/support/CNP/helpfiles/Account/Settings/Transaction_Format_Settings/Transaction_Response_Settings/Response_Receipt_URLs.htm

https://support.authorize.net/authkb/index?page=content&id=A587&actp=LIST

x_receipt_link_URL -- set to the URL where the customer should be sent after submitting payment. Parameterized URLs are not permitted.

https://support.authorize.net/authkb/index?page=content&id=A558

https://www.authorize.net/support/CNP/helpfiles/Account/Settings/Transaction_Format_Settings/Transaction_Response_Settings/Relay_Response.htm

[delatbabel]

Hrm, as per:

https://community.developer.authorize.net/t5/Integration-and-Testing/Return-url-after-payment/td-p/18552

It actually is not possible to use both a receipt link and a relay response URL, it is one or the other.

Relay Response is used if you would like to generate the receipt page that is displayed to the customer. When using Relay Response, Authorize.Net posts the transaction results to your page and then "relays" the resulting content of that page to the customer. It is expected that the customer will still see the Authorize.Net URL at the top of the page when they are viewing this receipt, although any links on the page should work as normal and take them away from Authorize.Net. The page is designed to work this way in case you do not have an SSL on your own website. If you tried to display the receipt directly to the customer from a site without SSL, it would result in security warnings popping up in the customer's browser between the time that they submit their card information and the timet hat they see the transaction results.

This is really limiting. You can have a returnUrl or a notifyUrl but not both.

[judgej]

The notify page can use a JavaScript redirect that gets around the SSL issue. There is an example of this in the SIM complete response message.

There are at least four different types of "redirect" I've come across that the gateways need, including GET and POST, and this one where a redirect page using window.location is "relayed" to the browser. Can't remember what the other one was, but it was surprising. Maybe just add the non-redirecting receipt page to the list.

[delatbabel]

Do the above 2 comments relate to this issue somehow or were they added in error? What do you mean by "thousands of deleted-and-replaced transactions in the system" and what has it to do with the use of notifyUrl / returnUrl?

[judgej]

Bugger. Too many git issues windows open.

One comment deleted - the other one for you :-) Basically you can return to any page you like (SSL or not) by returning this response from the Notify URL handler.

[judgej]

@delatbabel Quick question: does the receipt method also go along with the receipt URL? It seems that if we have the URL, then we should probably also need to be able to tell the gateway how to use that URL.

Thinking about it, if the receipt link URL and the notify URL are mutually exclusive (both amounting to some form of notify URL) then the receipt method could also be used to trigger using the URL for notify (if the receipt method is not set, i.e. there is no receipt method) or the receipt link (if the receipt method is set to "post", "link" or "get"). Does that sound like a way to implement this? It would mean setting the notify URL remains the same, but an additional flag can be supplied to tell the gateway driver (and ultimately the gateway) hoe to use that URL.