IFRAME integration not working, problem on booking process.

edited July 2015 in Developers
Hi.

Were changing a site to accommodate checkfront.
We have a wordpress installation wich already had all events in... So we added the possibility to add ITEM_ID in our wordpress post, so via API we get the item information, get all available dates and generate a link to our reservation page within an IFRAME.

A working example can be checked at http://horizon.ineditodev.info/tours/offroad/ocean-side-tour/
(links to follow, at the bottom - date ranges)

The problem is, the iframe works seamlessly until the last step of the booking process, where the Receipt page is shown (we disabled e-commerce, and added the PAY now link via email notification). The last page with the receipt is never shown. The loading at the bottom keeps spinning without moving forward.

Any ideas?

Thanks
Edaurdo

Comments

  • edited July 2015
    I have the same issue: iframed widget stuck on the last step. There is no error message.
    A (non)working example: http://www.beringer.com/CheckFront

    • Firefox – tour chosen and contact information entered -> loading icon spinning
    • Internet Explorer – same as FF
    • Neither system gave an error message, the loading icon just kept spinning (below is what Check showed for the whole 5 minutes)

    Neither browser went into ‘not responding’ mode while the loading icon spun
  • As neither of these sites implement the supported integration method by utilizing the iframe interface script, strictly speaking, the functionality hasn't changed here: it's impossible for a raw frame to redirect the parent window without the script, so you have always required them to click the "Continue" button, and the loading indicator has never had an effect on these frames. The problem is that the modal dialog isn't in the correct position due to the restricted height of the frame.

    A fix will go in to allow the bounce dialog to move appropriately in these frames, however the implementation of the iframe would be much better suited using the script to allow for automatic redirections -- or if you were to utilize HTTPS on your website, you'd be able to bypass the need for redirection entirely, as the entire process could occur within the frame itself.
  • Ok got it, instead of implementing the raw iframe, used the CheckFront Droplet (via PHP using the variables to configure the checkfront interface script) and it works like a charm.

    Also Kris, when you say "or if you were to utilize HTTPS on your website, you'd be able to bypass the need for redirection entirely, as the entire process could occur within the frame itself." is that straight simple, Checkfront detects if we're using HTTPS and if so, no redirects to payments gateways?

    Thanks Kris
    =)
  • At least for the interface-enabled iframe, yes, if the page is served over HTTPS, and a compatible inline gateway is used, it won't require breaking out of the frame to go through the final stages of the booking process. A gateway such as Stripe works well for this, but if it's not available in your region, there are typically a few other options available.
    Some gateways do require redirection (PayPal standard express checkout, for example), so this won't have the benefit of staying in the page for every gateway, but it is generally a very useful option.
Sign In or Register to comment.