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.