Klarna's products are built to run on desktop and mobile browsers. This allows us to add and improve features faster than anyone else. 

However, this also means that if our products want to run in an app, they need to run in something called a web view. This is a view that can render web content inside an app, just like a browser tab would.

Web views aren't fully featured browsers, and their functionality can be quite limited. Here are some of them:

Web views have a different lifecycle for storing information in Web Storage or as cookies compared to standalone browsers.

Klarna uses these, combined with the customer information you provide us to remember and verify returning customers' identities and payment choices. This way customers can place their purchase in as few clicks as possible.

Our SDKs "talk" with products like Klarna Payments and Checkout inside the web view to persist information on the native side.

Web views can't handle opening third-party applications without extra work on the developer's part.

Some payment methods depend on opening third-party apps (for example, the customer's bank's app) for bank and card-related payment methods. Some flows may need to identify or authenticate customers, and in some markets that means logging a user in through banking or government apps.

The SDK handles these cases and even configures requests to open apps with your app's own schema to make sure that when the customer is done, they are automatically returned to your app to complete their purchase.

Web views and Klarna's content are often integrated inline within your application, but may have content that needs to be presented modally. This is not a problem on desktop or mobile browsers, where there is plenty of space to display this content.

Two examples of this would be when users tap on links to see terms and conditions or read the privacy policy. We want to display this content in a full-screen presentation, but don't want to navigate away from the content that's already being presented.

An additional case would be when third-party content needs to be opened in its own window or tab (for example to open a banking page). We want to render this in its own browser, but not kick the user out of your app and risk them not knowing how to come back and finish their purchase.

The SDK can "move" its web views into a full-screen presentation, show a separate full-screen web view or present third-party content in its own internal browser, giving customers the best user experience for every case.

Some banks and third parties blocks WebView to access their web pages for increased security. The SDK handles these cases with communication with Klarna web components and presents a secure browser for flows requiring secure browsing sessions which would not possible with a plain WebView integraiton.

Just like with opening third-party applications, web views can't ask for the customer's permission to access hardware features like the camera without extra work from the developer.

In some markets like Spain and Italy, customers may need to identify themselves by taking a picture of their ID card. This requires asking for permission, and then accessing the device camera.

The SDK handles as much of this process as it can to minimize the work that you need to do.

Even if Klarna's products work properly inside a web view, it's very likely that your app will want to be able to interface with them from the native side. For example to trigger a flow, be notified of the result or handle errors. To do this, developers need to inject a bunch of JavaScript to interface with Klarna's components and handle the communication between the native side and the inside of the web view.

The SDK takes care of bridging communication between both sides and exposes simple, native APIs that you can use without dealing with the rest of the integration mess.

Our goal is to make your users' experience as smooth and pleasant as possible. To do that we enhance web views (or replace them entirely!) with sleeker native elements and patch missing functionality out.

Klarna's products are made to be as simple to use as possible, but there's lots of infrastructure behind it. This extends to the client-side components as well.

Even if you want to, say, just render a single payment method for a single market, you'll need to write code for almost all of the features we listed above, then test it through countless flows and support it as these flows change and improve.

Many of our components and products are subject to stringent compliance requirements, and not fulfilling them may make us (and if you built or own any part of it, you) liable.

There's been a case when a merchant decided to render a description of our payment methods in a web view but the Terms & Conditions links would not open. Under EU law, customers must be able to read T&C before agreeing to pay with financing.

Similarly within the payment process, merchants may not have access to customers' financial data. Integrating some of Klarna's products directly may expose you to data of this nature and lead to issues.

One of the fundamental reasons we insist on having you use the SDK is that we need to support a lot of merchants with very different integration needs and approaches. By this we mean supporting different operating systems, application and UI frameworks and programming languages.

If you use your own glue/integration code to the mix we can't tell if what you built works, make sure if it keeps working once you change something from your side, or we change something from ours, and definitely can't debug the problem if something went wrong.

On the other hand, having a single solution to integrate through (our SDK) makes it much easier for us to guide you through the integration process, monitor how its performing and support you if something goes wrong.