Klarna Docs - Signing users up for Klarna customer tokens

Signing users up for Klarna customer tokens

How to use Klarna Payments to signup customers for a Klarna customer token.

When this integration guide has been completed you will be able to sign your users up for Klarna customer tokens on your website. These customer tokens can then be used to place orders without the customer needing to repeatedly enter their details or select payment method.

See table for customer token payment methods here.

A customer token is the collected information about a customer, a payment method and the merchant that has created the customer token.

Customer tokens are stored by the merchant to represent a payment method and a customer. These can be used to place orders without the customer needing to repeatedly enter their details or select payment method. Use cases are for example recurring purchases, in case you offer subscriptions, or express checkouts if you want to enable no-signup purchase flows.

For more detailed information about the lifecycle of a token, please go to the in-depth article.

The following description will tell you how to implement the feature into your checkout. Detailed descriptions of every single API-call used in this implementation will be on separate, call-specific pages.

NOTE: Only tokenizing or connecting it to the purchase flow? It is possible to create a free-standing signup flow for consumers to sign them up for tokens. It is also possible to use the purchase session to create a customer token in the same session.

The Klarna Payments API will be used to connect to Klarna’s services to display and offer the payment method in your checkout. Offering these payment methods should be done at the payment method selection stage in your checkout.

You are responsible for the other steps of the purchase journey for your customers, including handling of basket and order lines, shipping method selection, customer data collection (e.g. gift cards)

It is important that any data sent to Klarna is aligned with the data format of Klarna’s systems. Please validate that you are handling the following correctly:

  1. Tax handling, as seen in the in-depth article.
  2. Customer data, as seen in the in-depth article.

Note: If you are sending in Extra Merchant Data, this should be added as an attachment already at session creation.

When the user enters the page where you signup them for the Klarna Customer token, you must create a session towards Klarna. This session must be the same throughout the whole signup process until a Klarna customer token has been created.

The session defines what payment methods that will be available for a certain session, depending on the country of the purchase and the amount of the basket.

You can find all the details of how to correctly create a session towards Klarna in the create session-page.

After creating the session, the Klarna widget should be initialized and loaded on your checkout. It is advised to do this right after creating the session, so that the customer won’t notice any delay in loading. The widget can be hidden as long as the address details are not yet collected and the consumer has not yet triggered the display of it.

NOTE: In relation to the Klarna widget, you as a merchant must also display that there will be a token stored as well as terms for how it is used.

Since all checkouts are designed differently, there are many ways to do this and you should think about how you can make the purchase experience as smooth as possible for your customers. We have some recommendations in our Klarna Payments integration best practices guide

Best Practice: We will do a pre-assessment of the purchase already at load, you should listen to the response of the load-call and act accordingly to offer your customers a great purchase experience!

In-depth descriptions of how to use the JS library do display the Klarna widget is presented in Initalize and Load call pages seen here.

For placing an order for session, there are two actions that must be taken. Initially, a risk and fraud assessment must be done on the purchase and user. This is achieved by using the authorize-call in the client, which is described [in-depth here]load-call.

Please be aware that any customer info that has not been shared before this point in time, must be done here to enable risk and fraud assessment.

If the authorization is successful, you will receive an authorization_token in the response from the authorization towards Klarna. This authorization_token should be used to request Klarna to create a customer token for the consumer as a result of the signup. This is done via a server side call to Klarna Payments API. This is explained in detail in the page on creating the customer token.

In case the cart has been updated, or the consumer has updated their details, you will need to propagate this information to Klarna. This needs to be done so that we can update our risk or fraud decisions based on the correct information, or simply display the widget in a correct way to the consumer.

In case the cart or consumer updates are done before an authorization call has been made, there are two ways of propagating changes to Klarna. The first alternative is to update session server-side and the second is to do a client-side load with new details.

There is no difference between the two alternatives in how the updates are treated. However the effects of the update is only shown to the consumer in the Klarna widget if a load is done, so if you do a server side update you should also do a client-side load.

Note: If you try to place an order with changed details or the order without doing a new authorization or session update the order will fail Klarna’s validation as described here.

In case the cart or consumer updates are done after an authorization call has been made, there are also two ways of propagating changes to Klarna. If the Klarna widget is still displayed to the consumer on the page, you can do a new authorization call with updated details, which will trigger a new risk and fraud assessment.

Making a new authorization will result in a new authorization_token being shared with you as a merchant. Make sure that the new is being used when placing an order.

If you have a multi-step checkout and your checkout offers the customer to change any details of the order after the payment step (e.g. an order review page) you will need to reauthorize if the customer changes anything.

On such an order review page there is typically no Klarna widget and hence the standard way of authorizing (init + load+ authorize) is not possible. A reauthorize is possible to handle this situation and any necessary customer communication will be handled in fullscreen modals.

Best Practice: It is recommended that you will display triggered modals as these might include items that require user input to complete the purchase.

In case the customer drops out of the checkout or you become aware of that the consumer won’t complete a purchase, you can release the authorization. This will make sure that any reservations for the consumer is released, e.g. in the case of a card purchase. You can find detailed descriptions of this call in the release authorization page.

  1. It is recommended to present terms of how you will use the customer tokens when the consumer is signing up.
  2. Be able to securely store the tokens on your end.
  3. Be able to map your ID of the tokens to our customer token ID.
  4. Have logic on your side when to trigger purchases from a token. This is described in Use Case - Place orders from customer tokens.