These are some integrations issues that we’ve seen, sorted roughly by how common they are. This is by no means an exhaustive list, but rather a top of mind inventory.
Do not re-initialize KCO without reloading the page. If you need to make changes to the order and see them reflected in KCO, use suspend/resume instead.
When KCO is created, it sets up a number of listeners and creates multiple iframes. If you re-initialize KCO, these iframes and listeners are not cleaned up, causing errors and unknown behavior.
To guarantee KCO works as expected, make sure to inject in your main page/frame the snippet you get from the backend, if not this would cause many UI/UX and functionalities issues.
This is similar to Re-initializing KCO, but for a different reason.
We pass messages between our different iframes through the merchant page, so if one or both of the iframes are re-created (event with the same URL) or detached from the DOM, our message passing will break (because the target windows no longer exist).
We have run into issues where merchants modify global functions, causing our code to fail. For example, one merchant was using an 8 year old version of the library Prototype.js, which implemented its own version of Array.toJSON, and replaced the browser’s own implementation. However, their implementation was incorrect, and did not convert arrays to proper JSON. This caused our encryption library to fail, which caused the checkout to not load.
In general, we don’t recommend using very old libraries. However, most of all we don’t recommend modifying the behavior of built in functions, as there’s no way for us to know how the code will behave if built-in functions suddenly give a different result. Thankfully, most libraries don’t do this. The only common one we’ve seen problems with is old versions of Prototype.js.
If you need to re-implement some functionality that the browser normally provides, create local functions without modifying the browser’s built in functions instead.
We add a number of iframes to the merchant’s DOM. One inside the element where the snippet is rendered, and one at the end of the body. These iframes are styled with inline styles, which means that they will have high specificity.
However, we’ve seen some merchants applying styles to our iframes by mistake, breaking interaction primarily with our fullscreen iframe. This means that you cannot see any of our modals.
Don’t use !important in your CSS declarations, and don’t apply styles to all iframes on the page.
If you use !important, there’s no way we can override that styling and ensure that KCO is displayed properly.
We pass along important information from the merchant page to KCO via the iframe URL. In some instances, we’ve seen merchants modifying the URL of the iframe, which causes KCO to fail to parse that information and thus break.
The fullscreen iframe is created as a direct child of the body, and is positioned using position: fixedin order to cover the viewport. Adding thetransform` property to the body will make the fullscreen iframe be positioned according to the dimensions of the body, rather than the viewport, causing it to have the wrong dimensions. We’ve seen this cause the fullscreen iframe to be much taller than the screen and therefore make the contents of the iframe disappear below the fold of the page, which ultimately defeats the purpose of it.