Accept Hosted in iFrame - What does return URL do?

[coppercup]

Despite the fact that the Accept Hosted documentation says...

With any of the form integration methods, information specific to the customer can be passed back to the merchant’s server by embedding it in the continue/return URL or the cancel URL.

...so far I cannot figure out how, or even if, the continue/return URL provided in the token request is used in an iFrame integration. The request parameters documentation also says the continue/return URL is "optional" in iFrame integrations. Does it do anything at all?

I'm trying desperately to figure out how to get a few pieces merchant-defined information back out of the response, so that I can build out the correct receipt output, and I thought it would come from query string parameters added to the continue/return URL, but I'm starting to feel skeptical.

Thanks, Fritz

[coppercup]

Maybe I should put the question more simply:

In an Accept Hosted payment form iframe integration, does the continue/return URL value do anything? If so, what?

[Anurag]

When embedded in an IFrame, the url, urlText, cancelUrl, and cancelUrlTextparameters are optional.

https://developer.authorize.net/api/reference/features/accept_hosted.html#Requesting_a_Token

hostedPaymentReturnOptions

{"showReceipt": true, "url": "https://mysite.com/receipt", "urlText": "Continue", "cancelUrl": "https://mysite.com/cancel", "cancelUrlText": "Cancel"}

All options associated with the return URLs, text, and behavior. When embedded in an IFrame, the url, urlText, cancelUrl, and cancelUrlTextparameters are optional. When the showReceiptparameter is true, our system will display a receipt page after the transaction, with a "Continue" button that points back to the URL provided in the urlparameter. When showReceipt is false, a return URL must be provided in the urlparameter. Otherwise the receipt page will be shown. Important Note: If the payment form is not embedded in an IFrame, the receipt page will be displayed and cannot be disabled, regardless of the value of showReceipt.

[coppercup · Accepted solution]

Hi , I appreciate your response, however, your response seems to imply two points:

1. That I have not read the documentation (I have, numerous times).
2. That the word "optional" in the documentation addresses my question (it does not).

Unfortunately, the documentation either contradicts itself, is inaccurate, or both:

1. The word "optional" does not at all imply "purposeless" or "useless", in fact it implies the opposite. For example, the Cancel URL is also optional, but it does do something in iFrame integrations.
2. The same documentation you referenced also unequivically indicates that name-value pairs can be retrieved via the Return URL in "ALL METHODS" and "with any of the form integration methods":

"ALL METHODS With any of the form integration methods, information specific to the customer can be passed back to the merchant’s server by embedding it in the continue/return URL or the cancel URL. By embedding information into the URL that is provided in the token request, the merchant server can identify the specific customer and transaction that has been processed when the customer returns. Any name-value pairs embedded in the URL should be URL-encoded to ensure correct processing in the form request."

My question was an attempt to get clarification of the documentation.

Whether or not the Return URL is optional shines no light on what the Return URL does, if anything, when it is optionally included in the token request.

Taken collectively, the two relevant portions of the Accept Hosted documentation plainly suggest that the Return URL is optional in iFrame integrations but, when included, can be used to return name-value pairs to the merchant's server.

Drawing my own conclusions

All that said, at this point I am intelligent enough to conclude that the documentation does, indeed, contradict itself – that the Return URL is, most likely, not just optional but useless in an iFrame integration, despite the subsequent documentation clearly stating that it can serve a purpose in all possible integration methods.

Which brings me to my final point.

1. The Accept Hosted documentation is woefully inadequate and even misleading.

I am by far not the only experienced developer in these forums (and elsewhere) to reach this conclusion.

Given that the Accept Hosted Payment Form is the promoted replacement for the deprecated SIM form, it pains me to say that Authorize.Net has dropped the ball in terms of providing thorough, accurate documentation and/or a clear upgrade path.

And the SDK does not help.

As others have stated, the PHP-SDK sample app is overly complicated, mixing different aspects of the SDK so tightly as to make it extremely difficult and tedious to isolate the portions that are applicable to any one part, such as an Accept Hosted payment form token request. Plus, the SDK comes with virtually no documentation and the code is almost void of any helpful code commenting. The whole point of an SDK is to help developers develop, but it seems to be written as more of a puzzle than an aide.