A Partner Account is a construct that consolidates all relevant information, capabilities, and features based on agreements made between the Acquiring Partner and their Partners.

A Partner account can reference multiple Partner Products, each representing a service offered by Klarna through the Acquiring Partner. Every product is configured with specific capabilities and settings.

For example, a Payment Product includes:

• A Payment Profile, defining the pricing plan and payment program plan used by the Acquiring Partner to onboard a Partner.
• Payment Accounts defining the default Merchant Category Code, the contractual relationship between the Partner's and Acquiring Partner's business entity(ies), as well as the settlement configuration(s) Klarna will use to pay out the Acquiring Partner.

Partner Accounts are used for managing the relationship between your Partners and Klarna Payment Services. These accounts, created and managed via Klarna’s Management API, contain critical information to facilitate a successful partnership. These blocks consist of:

• Partner Account contact: Information about the main representative of the Partner for Klarna. This data point is used in case we need to reach out to the Partner directly.
• Products: List the Klarna products and configuration the Partner account is onboarded with. At the moment the only available product type is PAYMENT .
• Payment Accounts: Payment accounts connect various attributes, such as the Partner Business Entity, the Payment Acquiring Account(s) Klarna has configured for the Acquiring Partner, and the default Merchant Category Code for the Partner Business Entity.
  
  • For each legal entity used by the Acquiring Partner to distribute Klarna as a payment method to their Partners, Klarna will configure a unique Payment Acquiring Account. Each Payment Acquiring Account contains the settlement configuration Klarna will use to pay out the Acquiring Partner.
  
• Stores & Branding: Lists containing the details of the website, mobile app or physical store where Klarna products are going to be made available as well as the related branding data.
• Partner Business Entities: Any information relevant for Klarna to efficiently run its fraud prevention functionality.

If a Partner operates through multiple entities, Klarna prefers that the account structure be simplified towards Klarna by creating a single Partner Account containing multiple Partner business entities and associated Payment Accounts.

However, as the Acquiring Partner, you should align the creation of Klarna's Partner Accounts with the structure reflected in your own systems.

Overall, it is required that a Partner be able to enable Klarna without additional effort as compared to cards or any other low-friction payment method.

Product and Account lifecycles are independent, more information available in the Manage your Partner section.

Let’s take a look into a few different examples of how Partner accounts can be used to represent Partners:

In a typical retail setup, the structure includes a Partner Account, a Payment Product, and their Stores.

Example 1

Consider a small clothing shop in Italy called "CoolBrand". CoolBrand consists of an online shop with the URL Coolbrand.com, it is owned by a single owner, Julia. The store operates under MCC 5691.

This store receives all their payouts from their Acquiring partner in a single bank account. They operate under the same address to which they are registered in Milan.

This is an example of a basic Partner Account set up. It’s a single account, with a single Payment Product, and a single store.

Given it’s 1:1:1, there is no need to identify anything when initiating a payment request for this Partner.

Sample request

{
  "partner_account_reference": "M123786123412",
  "partner_account_name": "CoolBrand",
  "partner_account_contact": {
    "given_name": "Julia",
    "family_name": "Doe",
    "email": "julia.doe@CoolBrand.com",
    "phone": "+15555555555"
  },
  "products": [

For enterprise companies, there might be more than one legal entity involved. Klarna needs to know all legal entities that are counterpart to consumers.

Example 2

Consider a big auto maker enterprise multinational that groups several different auto makers. The group is called AutoMakers, and is made of a couple of different legal entities, each with their own websites and branding. Both entities operate under the same MCC, but they have different legal entities towards consumers.

In this case, both legal entities have to be created at Klarna, and two different Payment Accounts have to be onboarded connected to the different Partner Business Entities. These Payment Accounts are later utilized on the Payments API, and allow us to differentiate which legal entity is taking the purchase.

Given pricing is the same across the different legal entities, one Payment Product contains both Payment Accounts.

Sample request

{
  "partner_account_reference": "E494442",
  "partner_account_name": "AutoMakers",
  "partner_account_contact": {
    "given_name": "Jan",
    "family_name": "Doe",
    "email": "jan.doe@automakers.de",
    "phone": "+15555555555"
  },
  "products": [

In case a Partner has multiple MCCs and operates under a single account, there are two different ways that the model can be applied. These approaches can be applied to Partners that sell different types of products or marketplaces.

Single MCC provided at onboarding

The first way would be the same as previously indicated, where only the primary MCC is set during onboarding. Different MCCs can later be passed at transaction time, and override the primary MCC.

This approach should be used when you don’t have the list of MCCs the partner operates at during onboarding. Utilizing a too-different or restrictive MCC at the time of transaction might lead to the transaction being rejected.

Multiple MCCs provided at onboarding

If you have the list of MCCs the partner is using at the point of onboarding, those MCCs can be passed on the enforced MCCs list as part of the payment product . When the enforced MCC list is present, providing an MCC that is not the list when initiating a transaction may result in the transaction being rejected.

Example 3

Consider a Partner called “AstroxSox”. This business sells new socks to its customers, but also provides a subscription service so their customers never run out of socks. This means that AstroxSox operates both under MCC 5691, but also 5641.

AstroxSox is owned by Mathias and his sister, Debora, and operates under a single website, astroxsox.de.

In this case, the Partner must indicate the appropriate MCC at time of transaction, allowing correct pricing and payment options to be shown. The specific MCC is passed when initiating a payment request.

Sample request

{
  "partner_account_reference": "M12378999999",
  "partner_account_name": "AstroSox",
  "partner_account_contact": {
    "given_name": "Mathias",
    "family_name": "Doe",
    "email": "Mathias@AstroSox.de",
    "phone": "+49555555555"
  },
  "products": [

For companies with multiple websites, we allow you to model the store configuration in the same way as it’s modeled on your side. In case you require different accounts per store on your end, you can apply the same model as the simple retail example to create all the different accounts.

In case you support multiple stores on the same account, the same can be created on our side.

Example 4:

Consider a pastry shop called “Ivette Croissanterie”.

The pastry shop, owned by Ivette, has two physical stores located in Marseille, France. Ivette also sells pastries through an on-line store.

The account is configured with a payment product with the MCC 5462, with three stores. Two physical stores, and one website.

When initiating a payment request, the specific store where the purchase is being made needs to be passed to the Partner Payments API.

Sample request

{
  "partner_account_reference": "994323",
  "partner_account_name": "Ivette Croissanterie",
  "partner_account_contact": {
    "given_name": "Ivette",
    "family_name": "Doe",
    "email": "Ivette@IvetteCroissanterie.fr",
    "phone": "+49555555555"
  },
  "products": [

Franchise accounts should be modeled as close as possible to the business structure. Their Klarna account could be modeled either by:

• Managing all franchises via a single account
• Creating individual accounts for each franchise owner

The form the Klarna account structure takes should be reflective of the structure of the business, for some franchises a single account will suffice. This is dependent on how they wish to receive settlements and how these accounts are managed by the business owners on your side.

Example 5

Consider a burger chain called William’s Top Burger. William’s operates under a franchise model, where currently they have three franchisees, owned by Maja (store 1), Liam (store 2) and Vera. Out of the three, Vera was able to run a really successful business and now owns four different burger locations, stores 3, 4, 5 and 6.

In this case, if the franchises are managed as separate accounts on your side and settlements are received separately from the Acquiring Partner, they can be modeled using a combination of the Retail and the Multi Store examples, as below:

In the Partner product API, the specific account ID and store ID must be sent as part of the payload so Klarna can properly identify from which specific store the payment request originates. Applied to our example, Maja, Liam, and Vera would each have a separate account. Maja and Liam would have a single store each, and Vera would have four stores, one for each of her physical stores. By passing the correct account ID and store ID in the request, Klarna can present to the customer different store details and an experience personalized to the originating store.

To onboard, we would need three /onboard calls.

First sample request

{
  "partner_account_reference": "M123789922222",
  "partner_account_name": "Maja WTB",
  "partner_account_contact": {
    "given_name": "Maja",
    "family_name": "Doe",
    "email": "maja.franchisee@wtb.se",
    "phone": "+49555555555"
  },
  "products": [

​Second sample request

{
  "partner_account_reference": "M123789922223",
  "partner_account_name": "Liam WTB",
  "partner_account_contact": {
    "given_name": "Liam",
    "family_name": "Doe",
    "email": "liam.franchisee@wtb.se",
    "phone": "+49555555555"
  },
  "products": [

​Third sample request

{
  "partner_account_reference": "M123789922224",
  "partner_account_name": "Vera WTB",
  "partner_account_contact": {
    "given_name": "Vera",
    "family_name": "Doe",
    "email": "vera.franchisee@wtb.se",
    "phone": "+49555555555"
  },
  "products": [