Offering Klarna payment methods to your customers
The Klarna Payments API allows you to offer any of Klarna's payment methods to your customers directly in your checkout. This article will describe how to implement the API in the best possible way for this purpose.
Klarna payment methods should be offered in your checkout process, at a step where the customer selects the payment method to use for their purchase. 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! This guide tells you how to leverage our Klarna Payments product top offer your consumers any collection of available Klarna Payment method in your checkout.
Below you can see a diagram of the relationship between user interaction on your checkout and what you should map this to in your integration towards Klarna Payments.
Availability of payment methods in countries
Getting it to work
The following description will tell you how to implement the feature into your checkout’s flow. Detailed descriptions of every single API-call used in this implementation will be on separate, call-specific pages.
Adding the payment method 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 still 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 and handling gift cards etc.
It is important that any data that is 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 page
When the user enters the page where Klarna’s payment methods are offered you must create a session towards Klarna. This session should be used throughout the whole purchase flow, until an order is placed.
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!
Placing the order
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 .
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 towards Klarna. 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.
Please note that some payment methods are only offered within certain amount thresholds. Updating the amount can therefore change the available payment methods in a session.
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 token 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. Be aware that releasing an authorization and then attempting to do a new one might impact out credit assessment of that consumer.
What logic do you need on your end
- You are responsible for everything outside payment method handling, such as order lines and customer data collection.
- Rejection flows and acting on different cases. 2.1. Including retry policies OR 2.2. Input errors.