Adding Klarna Payments to Your App
The main idea behind Klarna Payments is to give merchants the ability offer Klarna’s payment methods to customers. Because Klarna doesn’t own the entire checkout flow, a check needs to be performed before an order is created.
Four Simple Steps
Our goal with this integration is to offer you the same simple development experience as you have on the web. As such, integrating Klarna Payments consists of four simple steps:
- Creating a session.
- Rendering the payment view.
- Authorizing the session.
- Creating an order.
We offer a few extra features, if your application’s flow requires it:
- Reauthorizing the session.
- Finalizing the session.
- Showing a payment review.
When the user is ready to check out, your app will want to render Klarna’s payment views. These views provide customers with information about the payment methods and terms.
Backend Session Creation
Before rendering these views, your backend will need to create what we call a “Payment Session”
with Klarna. This payment session contains details about your prospective order and customer.
A session also contains a
Client Token that identifies the session to the SDK.
You can add payment views to your checkout view at any point, but to render content in them, you’ll need to initialize and load them.
Initializing the View
Once you have a client token, you can initialize the payment view in your app. Initializing the view loads resources and configures it before performing any rendering.
In your checkout view, you’ll need to initialize the view with:
- The session token you have from your previous step.
- The payment method category you’d like to render.
- A “return URL” the SDK can use, when opening 3rd-party applications to complete payment, to return the user on completion. You can read more about this below.
You can do this by calling the
initialize() method on the payment view.
The SDK will call your event listener once initialization is complete. This stage may fail if, for example, the token your app intializes the view with is invalid.
Loading the View
Once the view is successfully initialized, you can load the view. This is the stage at which content will be rendered into the payment view.
This is done by calling
load() on the payment view.
Your listener will be notified if the view loaded. At this stage, we can assume that you have a fully displayed checkout view in your app, presenting a selection of payment methods and a buy button.
Once a user has tapped your buy button, you’ll need to authorize the session with Klarna. Authorizing the session:
- Evaluates whether the order and customer details Klarna has are valid.
- Performs a credit risk assesment.
- Evaluates whether an order can be created.
You can authorize the session by calling the
authorize() function on the appropriate
It’s possible that you have created a session with all the information Klarna needs, but if any information is missing, the SDK may present the customer with a dialog where they can input additional information.
The SDK will call your event listener with the result of the authorization. If it’s successful, you will receive an authorization token that you can create an order with. This token will be valid for 60 minutes.
If you have an authorization token, you can go ahead and create an order.
The user may, in some cases, need to introduce data a second time (e.g. providing a legal authorization, or selecting a bank account). We call this the finalize step.
By default, the SDK performs authorization and finalization automatically after each other,
but you can request to perform these separately if the flow in your app requires it. If
that’s the case, your listener will be notified with a
finalizeRequired parameter set to
With the authorization token from the SDK, your backend is ready to create an order.
Backend Order Creation
Rendering the Confirmation
A created order response from the backend contains a URL to a confirmation page. You should render this URL in your app in a web view, as it contains information about the order details that the customer must see.
There are cases when you might want to allow your customer to change their order after it has been authorized (e.g. in some form of order/summary view). In these cases, if the order or customer details have changed, you’ll need to perform a reauthorization.
You can reauthroize the session by calling the view’s
We recommend that this method is called as few times as possible. This is because it might prompt the customer for more information as well as because it might trigger additional network requests which might take time.
This should ideally only be called when the “complete order” step of checkout is performed, and then only if the state of the order has changed since authorization.
As with other methods, the SDK will notify your listener with the outcome of the reauthorization.
If the session needs to be finalized, you’ll need to perform this last step to get an authorization token. The finalization should be done just before the purchase is completed, meaning the last step in a multi-step checkout.
You can finalize the session by calling the view’s
You guessed it, your listener will be notified with the outcome of the finalization step.
If your checkout offers the customer an opportunity to review the order after the payment step (e.g. an order review page) it can make sense to present the payment method the customer selected on a previous page.
This gives the customer a chance to review the payment method and its terms.
Loading the Payment Review
Once you have authorized the session, you can create a new payment view, initialize it
with the same session token, then call
loadPaymentReview() to show an overview of the
payment method category that has been authorized.