Issues with iFrameCommunicator

[tfreeman]

I am having an issue with the hosted payment form sending some events to the iframecommunicator.

Resize events get sent correctly:

E.G.
https://local.bizlock.net/payment/authnet/iframe-communicator/payment#action=resizeWindow&width=442&...

But the url for transactResponse is being truncated after the first '{'

E.G.

https://local.bizlock.net/payment/authnet/iframe-communicator/payment#action=transactResponse&respon...{

This is an only an issue for the first event since only the first event is sent by loading a url with the event data in the url fragment identifier.

You also do not check to make sure the iFrameCommunicator iframe is loaded before you try to send messages to it. This leads to a "Failed to execute ‘postMessage’ on ‘DOMWindow’: The target origin provided (‘https://local.bizlock.net’) does not match the recipient window’s origin (‘https://test.authorize.net’)." error. You also don't catch and retry sending messages so they will be lost when they are sent before the iFrameCommunicator has loaded.

[tfreeman]

Part of the issue is the the hosted payment form (as opposed to the hosted profile forms) does not load the iFrameCommuncator prior to dispatching its first event. This means that if the first and second events fire in rapid enough succession vs. any network delay, the second event is lost.

This also means that the first event fired by the hosted payment form is often the 'transactResponse' event which is sent via the document fragment identifier in the url rather than via a JS postMessage event. This means that the necessary information needed from the 'transactResponse' payload is missing and we are unable to send the customer on to the next part of the checkout process.

[daves0]

Any response from Authorize.Net here?  These are significant issues, and a resolution has been suggested...

[satheesh22]

Refer this :

https://community.developer.authorize.net/t5/Integration-and-Testing/AUthorize-net-hosted-payment-pa...

[Wei]

Guys,

after severals days headache, confusing and depressing, we figured it out!

this intermittent issue is due to how we(the integrator) use the hosted form, that is render hosted form too earlier cause listener not registered.

inside the hosted form

<div _ngcontent-c0="" class="iFrameClass" id="divIframeCommunicator"></div> is not fully rendered.

<div _ngcontent-c0="" class="iFrameClass" id="divIframeCommunicator"><iframe src="your_site_url" name="ifrmCommunicator" id="ifrmCommunicator"></iframe></div> the correctly one.

the symptom is unable to receiveMessage but location.hash give truncated JSON like "#action=transactResponse&response={"

also noticed their demo page in doc is a button to trigger post form token, where is an implied delay.

when realized this the solution is simple, instead of do $("#send_token").submit(); in .ready() but do it in setTimeout with 1-2 seconds delay.

now the hosted iframe working perfectly under Firefox, Chrome, Edge, IE11 and Opera


From avetticommerce