Signing users up for Klarna customer tokens
The Klarna Customer Token let's you store customers on file, making it possible for you to use Klarna's payment methods for e.g. subscriptions. This article will present 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.
Availability of payment methods in your countries
What is a customer token
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.
Getting it to work
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.
Adding the customer token signup functionality on your site
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:
Loading the checkout/signup page
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.
Displaying the Klarna widget
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.
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 though!
Creating the customer token
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].
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 .
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.
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.
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 .
What logic do you need on your end
- It is recommended to present terms of how you will use the customer tokens when the consumer is signing up.
- Be able to securely store the tokens on your end.
- Be able to map your ID of the tokens to our customer token ID.
- Have logic on your side when to trigger purchases from a token. This is described in Use Case - Place orders from customer tokens.