Render the Checkout iframe
Place this script on the pages where you want the Checkout to appear.
<!-- Please note the src URL and use the correct one for test and production-->
To render the Walley Checkout, use a
<script> element as the example shows. The value provided in the data-token attribute corresponds to the public token received when initializing the Checkout session.
When the script is executed, the Checkout iframe is dynamically fetched and rendered on the page. Remember to use the correct endpoint in the src attribute, as specified in Checkout Environment Endpoints.
It is required that you also include the Checkout iframe in your purchase confirmation page as the Checkout iframe will show important purchase details to the customer. To display the "thank you" page on another page, for example when redirecting the user to a custom thank you page, put an identical
<script> element on this page as well. When the checkout is in the state of PurchaseCompleted it will show a thank you page instead of the normal checkout flow.
During the checkout, users can be prompted to redirect to URLs like
bankid://xxx. Opening these URLs inside the webview can cause issues with redirects and may not work as expected. To ensure a smooth user experience, your application needs to open these custom URLs natively on the device, either in a browser or through an alternative method. Also make sure to enable the data-webview along with the appRedirectPageUri properties.
Reuse public token per session
You should store and re-use the same public token (and the corresponding private id) during the whole session for each customer. The public token should stay the same even if:
- a customer refreshes the page in the browser
- a customer navigates away from the checkout page (i.e. to a product view) and then returns
- a customer opens the store in another tab
- the checkout is opened by a link from i.e. an email for a specific customer purchase
- a customer is toggling between B2C and B2B (their respective public token and private id should be stored and re-used when toggling between them)
Some of the advantages with using the same token for a single purchase session:
- The checkout state will be resumed, even in different devices. If instead a new session is created, the customer will have to re-enter all information every time the checkout is refreshed. This includes input forms for identification, custom address etc..
- We will be able to track conversion rate. If a new token is used each time, the previous unfinished ones will incorrectly be considered lost conversions.
- We will be able to analyze the complete, connected customer purchase flow. This will help troubleshooting and also help us make improvements for a higher conversion rate.
- The performance will be affected if new checkout sessions is created unnecessarily.
expiresAt property from the Initialize Checkout response will let you know when it is time to create a new Checkout session.
Script element attributes
|src||See frontend endpoints in Checkout Environment Endpoints|
|data-lang||(optional) The display language. Currently supported combinations are: |
|data-padding||(optional) Set this to |
|data-container-id||(optional) Set this to the id of an element on the page and the iframe will render inside this element instead of immediately above the script element of the loader script. Put the container element somewhere above the script element. This is to make sure the container element is loaded before trying to populate it with the iframe.|
|data-action-color||(optional) Set this to a hexadecimal color code to change the background color of call to action buttons, formatted as the following example |
|data-action-text-color||(optional) Set this to override the automatic text color of call to action buttons. Valid values are |
|data-webview||(optional) Set this to override automatic device detection for webviews. If set to "true" redirects will be used instead of pop-ups where applicable. Handy for in-app checkouts to avoid pop-up issues on mobile devices.|
Iframe element details
The loader script will create an
<iframe> element directly above itself. The iframe will use 100% of the available width (inside its container element) and will have its own padding. Therefore it is recommended that you don't add any extra margin or padding to the sides of the iframe yourself (this is extra important for narrow device widths). If you still feel the need to you may set the attribute