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-->
<script
  src="https://api.uat.walleydev.com/walley-checkout-loader.js"
  data-token="public-SE-7f1b3d2a2a73d348dfbd17d3965ff1458c249f84c695eac1"
></script>

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.

About the use of webviews in apps

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.

The expiresAt property from the Initialize Checkout response will let you know when it is time to create a new Checkout session.

Script element attributes

Attribute	Explanation
src	See frontend endpoints in Checkout Environment Endpoints
data-token	The publicToken acquired when Initializing a Checkout Session.
data-lang	(optional) The display language. Currently supported combinations are: sv-SE, en-SE, nb-NO, fi-FI, sv-FI, da-DK and en-DE. Both sv-SE and en-SE are available for use with swedish partners. In the other cases, the country part must match the country code used when initializing the checkout session or it will be ignored. Setting this attribute is optional and will only be of interest when there is more than one language for any single country. If not set the checkout will fallback to using the lang attribute of the html tag (if set) and the market's default language if not.
data-padding	(optional) Set this to none in order to cancel out the left and right padding inside the iframe (by adjusting its margins and width).
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 #582f87. Button text color will automatically be set to dark gray instead of white if not enough contrast according to WCAG 2.0 level AA for large text.
data-action-text-color	(optional) Set this to override the automatic text color of call to action buttons. Valid values are black, white, #000000 and #ffffff. Other hexadecimal color values are also valid, but will be interpreted as either black or white (and instead of black, the actual text color will be dark gray).
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 data-padding to none.