Accept Hosted in iFrame: resizeWindow is not sent when form height changes because of window resize

[maxim_baranov]

I'm currently evaluating the possibility of using Accept Hosted form inside an iFrame in one of my projects. I've run into an issue while building a small test app, which, I believe, can also be reproduced in the Accept Sample App.

In step 3 of the "Accept Hosted Step-by-Step" guide there is a remark regarding "resizeWindow" message:

"An important message to receive is the resizeWindow message. Because our Accept Hosted form is responsive, we need to let your application know when the iframe should be resized. For example, when the form becomes single column on a phone, the height is increased and this height increase is sent in a ResizeWindow message."

However, in my tests this does not appear to be the case: when the iFrame that hosts the payment form is set to have a width as a percentage of the browser window width and the browser is resized so that the form changes from a two-column layout to a single-column one, the "resizeWindow" message is not sent. This results in both "Pay" and "Cancel" buttons being pushed below the visible area of the iFrame, making the form unusable. If a user manipulates the form in such a way that does trigger "resizeWindow" message (for example, if user checks the "bank account" or "credit card" radio button), the height is updated so that all form controls are visible again.

Here are the steps to reproduce the issue using Accept Sample App:

1. Install and run the sample app as described in the "How to Use the Sample App" section
2. Login with a customer profile ID and navigate to "pay" tab
3. Observe that the payment form is loaded, it has a two-column layout and both "pay" and "cancel" buttons are visible
4. Change the browser window width so that the form switches from two- to one-column layout
5. Observe that while window width is changing the form height does not change, while certain inputs and both "pay" and "cancel" buttons are pushed down and become invisible.
6. Select "Bank account"  payment option at the top of the form
7. Observe the form height now changed and all controls are now visible again.

Is there a way to have the form send the "resizeWindow" notification in step 5? 

While I certainly could listen to "resize" event on window in my host application, I don't believe that I can query the height of the payment form because of the browser restrictions on the cross-domain iFrame contents access. 

I would really appreciate any suggestions on the topic. 

Thanks,

Maxim. 

[RichardH]

Hello @maxim_baranov

It's been a while since you posted this question, are you still experiencing this issue or did you find a solution?

Richard

[maxim_baranov]

I was not able to find a solution, mainly because of the difficulties of determining an actual height of the content inside the iframe. I assume that one approach would be to have payment form itself detect the viewport width change and send the same resizeWindow message it does when the height of the content changes because of other reasons, such as switching between payment methods (CC or check). But that would require changes on the Accept Hosted side. 

We've also considered using a fixed width container to host the iframe for our project, thus circumventing the whole issue.

Ultimately (this issues was not a deciding factor), we decided to spend some extra time and build a custom payment form using the Accept.js instead. 

[Chris2017]

Same here.

The only time I see a resizeWindow message is when I click the radio button to change from credit card mode to bank account mode or vice-versa.

I have never seen a resizeWindow message when resizing the window.

[Aaron]

Hi @Chris2017,

I'll look into this. I honestly don't know whether it should be sending resize messages every time the layout changes or just when it's first loaded. I'm guessing the thinking might be that it needs to send its size when it's first loaded so you can set the iframe size appropriately.

It's going to load up at different sizes depending on whether it's loaded on mobile or desktop, for example, so setting the size at that time is important. However, it might be being assumed that the window size is not typically changed during the payment.

I'll have to double-check with some folks to see what the design was, whether it's working as designed, and clarify in documentation as appropriate.

[scottnes1]

Sorry to resurrect an old thread, but I don't see a resolution here, and I'm having the same problem as the OP. Accept.js and AcceptUI.js won't work for us because of PCI and payment flow issues.

@Aaron wrote, "...it might be being assumed that the window size is not typically changed during the payment."

This assumption doesn't always hold, particularly when you consider orientation changes on tablets and phones. Starting in landscape and rotating to portrait after the iframe is rendered can make the buttons overflow out of the bottom.

Is there any resolution or workaround? Iframes are known to be quirky in responsive designs. I'm continuing my research and experimentation, but I'm hoping someone here can save me.

Thanks,
Scott

[melissadavies]

Anyone have a solution for this? I'm running into the same issue.

[lawrence1379]

No sir couldn't find it sorry for that if any updates avalable put it here

[ebsjbulcher]

I guess I have to add my frustration to the list. I read Aaron's comment above, and had to do a facepalm:

---

...However, it might be being assumed that the window size is not typically changed during the payment.

I'll have to double-check with some folks to see what the design was, whether it's working as designed, and clarify in documentation as appropriate.

---

The issue - regardless of whether it is working as designed - is that its current design is flawed. It's either a bug in the code or a bug in the design - it doesn't matter. People resize their browsers all the time (at least I do when I'm multitasking) and if I suddenly couldn't pay I would be very confused for a few seconds. As a developer I would figure it out. As a customer? Who knows. I might have just lost a sale.

The sad thing is this isn't a difficult or time-consuming bug to fix, and it's frustrating that authorize.net hasn't cared to fix it in 5 or 6 years. This is making me second-guess our choice of payment gateways. I hope I don't see too much more of this attitude towards web design.