Klarna Docs - Signing Users Up for Automatic Payments with Klarna

Signing Users Up for Automatic Payments with Klarna

How to use Klarna Payments to register customers for automatic payments with Klarna using customer tokens.

When this integration guide has been completed you will be able to register your users for Klarna customer tokens to use for recurring and on-demand payments. These customer tokens can then be used to create orders without the customer needing to interact, supporting things like recurring subscription charges or on-demand e-wallet charges like with car sharing, e-mobility, parking apps, and so on.

Before going through the implementation guide, make sure to read up on Automatic Payments use cases.

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

Customer tokens are stored by the merchant to represent the Klarna payment method and a customer. These can be used to create orders without the customer needing to interact with any user interface. Use cases supported include things like recurring purchases, in case you offer subscriptions.

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 combine a purchase and 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 Klarna on 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 sign them for automatic payments with Klarna using the customer token, you must create a session towards Klarna with intent=tokenize or intent=buy_and_tokenize. This session must be the same throughout the whole signup process until a Klarna customer token has been created.

The intent specified in the session will determine which payment methods will be available for that 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 and on our in-depth article on intents.

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, it is recommended that you as a merchant  inform consumers in your terms and conditions that in some cases 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

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

When creating an order on a session, there are two actions that must be taken. A risk and fraud assessment must be performed on both the purchase and the user. This is initiated by triggering the authorize call on the client-side.

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 request to Klarna. This authorization_token should be used to create the customer token for the consumer. This is done via a server side call to the Klarna Payments API. This is explained in detail in the page on creating the customer token.

Should the cart have been updated, or the consumer has updated their details, you will need to inform Klarna of this change. This needs to be done so that we can properly assess the order from a risk and fraud perspective based on the correct information, and so that we present the consumer with the proper information in our touch points.

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

There is no difference between the two alternatives in how the updates are treated.

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.

If you have a multi-step checkout and your checkout offers customers the ability 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 reauthorization is possible to handle this situation and any necessary customer communication will be handled in Klarna owned assets.

In case the customer drops out of the checkout or you become aware that the consumer won’t complete a purchase, you can release the authorization. This will make sure that any credit or risk holds for the consumer in Klarna’s system are released in a timely manner. 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.