Model your Partner Accounts

Model Partner Accounts so they reflect how a Partner’s business is structured, including legal entities, MCCs, brands, and stores. Correct modeling simplifies onboarding, supports accurate settlement, and keeps integrations easier to maintain over time.

Accurate Partner Account modeling ensures a smooth onboarding experience, simplifies account management, and supports flexible integration patterns — from small retailers to complex multi-entity organizations.

This article explains how to structure Partner Accounts within Klarna’s ecosystem and how to align them with a Partner’s business structure and internal systems.

Link copied!

flowchart LR subgraph Partner direction TB PA(Partner Account) PAY_PRO(Payment Product) PA_BRANDS_STORES(Brands & Stores) PA_PBE(Partner Business Entity) PA_PORTAL(Portal User / Access) PA -->|1| PAY_PRO PA -->|1..n| PA_PBE PA -->|1..n| PA_BRANDS_STORES PA -->|1..n| PA_PORTAL end subgraph Acquirer direction TB PA_AP(Partner Account) ACQ_PRO(Payment Acquiring Product) PA_AP_API_KEY(API Keys) PA_AP_WEBHOOK_CONFIG(Webhook Configuration) PA_AP -->|1| ACQ_PRO PA_AP -->|1..n|PA_AP_API_KEY PA_AP -->|1..n|PA_AP_WEBHOOK_CONFIG end Acquirer -->|onboards| Partner class PA primaryEntity class PA_AP primaryEntity

A Partner Account represents a Partner company in Klarna. Under a single Partner Account, you can configure:

Partners should use a single Partner Account per company and model complexity with Payment Accounts, Partner Business Entities, and Stores. This article shows modeling patterns for common business structures and provides sample onboardKlarna Icon requests for each.

For more details about Klarna's account structure, see here.

Link copied!

Before modeling your Partner Accounts, it's essential to understand How Partner Accounts Work and become familiarized with some key terminology:

TermDefinition
Partner AccountRepresents a Partner company that uses Klarna’s offering. In this context, it represents your own Partners.
Partner Account contactInformation about the main representative of the Partner for Klarna. Klarna uses these details if we need to reach out to the Partner directly.
Partner Business EntityRepresents a legal entity related to the Partner, including information Klarna needs for compliance, fraud prevention, and settlement.
Payment ProductRepresents the Partner Account’s ability to use Klarna’s payment offering, including pricing and configuration.
Payment AccountConnects attributes such as the Partner Business Entity, the Payment Acquiring Account(s) configured for the Acquiring Partner, and the default Merchant Category Code for that Partner Business Entity.
  • For each legal entity used by the Acquiring Partner to distribute Klarna as a payment method to their Partners, Klarna configures a unique Payment Acquiring Account. Each Payment Acquiring Account contains the settlement configuration Klarna uses to pay out the Acquiring Partner.
Stores & BrandingRepresents websites, mobile apps, or physical stores where Klarna products are available, as well as the related branding data.
MCC (Merchant Category Code)Defines the type of goods or services sold by the Partner.

The following examples show how to combine Partner Accounts, Payment Products, Payment Accounts, Partner Business Entities, and stores to match different business structures.

  • One legal entity
  • One MCC
  • One website or store
  • Unified settlement configuration
flowchart TB subgraph ACC[Partner Account: CoolBrand] CON[Contact: Julia] end subgraph PBE[Partner Business Entity] LE[Legal Entity: CoolBrand s.r.l] ST[Stakeholder: Julia] BA[Bank Account: Julia's BA] end subgraph SG[Store Group] S1[Store: coolbrand.com] end PROD[Payment Product] PA[Payment Account<br>CB003-1] ACC --> PROD PROD --> PA PA --> PBE PA --> SG

Example 1: Retail SME company

A small clothing brand, CoolBrand, operates one online store in Italy. The setup includes one Partner Account, one Payment Product, and one store. Their online shop URL is Coolbrand.com, and the company is owned by a single owner, Julia Doe. 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.

{{GuideBlock|end=true}}

Sample request

JSON

Copied

{
  "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": [
    {
      "payment_profile_id": "krn:partner:global:account:distribution-profile:206bbb83-9b6e-46fa-940d-337153c04a58",

Larger enterprises often manage several legal entities under a single Partner Account. Use this when you have multiple legal entities for the same partner.

Example 2: Multi-brand enterprise

flowchart TD ACCT --> PRO PA1 --> PBE1 PA1 -->|default| SG1 PA2 --> PBE2 PA2 -->|default| SG2 %% Account subgraph ACCT[<strong>Partner Account</strong>] CON[<strong>Contact:</strong> Jan] end PRO[Payment Product] PRO --> PA1 PRO --> PA2 PA1[<strong>Payment Account:</strong> M33341] PA2[<strong>Payment Account:</strong> M33342] %% Partner Business Entities subgraph PBE1[<strong>Partner Business Entity #1</strong>] LE1[<strong>Legal Entity:</strong> Super Auto] ST1[<strong>Stakeholder:</strong> Hans] BA1[<strong>Bank account:</strong> Super Auto's BA] end subgraph PBE2[<strong>Partner Business Entity #2</strong>] LE2[<strong>Legal Entity:</strong> Auto Start] ST2[<strong>Stakeholder:</strong> Giulia] BA2[<strong>Bank account:</strong> Auto Start BA] end %% Store Groups subgraph SG1[<strong>Store Group #1</strong>] S1[<strong>Store:</strong> SuperAuto.de] end subgraph SG2[<strong>Store Group #2</strong>] S2[<strong>Store:</strong> AutoStart.it] end

AutoMakers operates multiple brands, each with its own legal entity and website. Klarna configures one Payment Account per legal entity, allowing transactions to be attributed correctly at payment time.

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

JSON

Copied

{
  "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": [
    {
      "payment_profile_id": "krn:partner:global:account:distribution-profile:206bbb83-9b6e-46fa-940d-337153c04a58",

Payment Accounts can also be used to support multiple Merchant Category Codes (MCCs) under the same Partner Account. The configuration attached to the payment accounts can be the same, but they may have different default_merchant_category_code s and must have different references.

Example 3: Multi MCC company

flowchart TD ACCT --> PRO PA1 --> PBE1 PA1 -->|default| SG1 PA2 --> PBE1 PA2 -->|default| SG1 %% Account subgraph ACCT[<strong>Partner Account</strong>] CON[<strong>Contact:</strong> Mathias] end PRO[Payment Product] PRO --> PA1 PRO --> PA2 PA1[<strong>Payment Account:</strong> A4421-1<br/><br>MCC: 5691] PA2[<strong>Payment Account:</strong> A4421-2<br/><br>MCC: 5641] %% Partner Business Entity subgraph PBE1[<strong>Partner Business Entity</strong>] LE1[<strong>Legal Entity:</strong> AstroxSox GmbH.] ST1[<strong>Stakeholders:</strong> Mathias &amp; Debora] BA1[<strong>Bank account:</strong> AstroxSox BA] end %% Store Group subgraph SG1[<strong>Store Group</strong>] S1[<strong>Store:</strong> astroxsox.de] end

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.

Sample request

JSON

Copied

{
  "partner_account_reference": "M12378999999",
  "partner_account_name": "AstroSox",
  "partner_account_contact": {
    "given_name": "Mathias",
    "family_name": "Doe",
    "email": "Mathias@AstroSox.de",
    "phone": "+49555555555"
  },
  "products": [
    {
      "payment_profile_id": "krn:partner:global:account:distribution-profile:206bbb83-9b6e-46fa-940d-337153c04a58",

Partners operating across several physical or digital locations can group them under a single Partner Account.

Example 4: Multi physical store company

A French bakery, called “Ivette Croissanterie”, operates two physical stores and one website under the same MCC.

The pastry shop is owned by Ivette, and the physical stores are located in Marseille, France. Ivette also sells pastries through an on-line store.

The Partner Account is therefore 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.

flowchart TD ACCT --> PRO PA1 --> PBE1 PA1 -->|default| SG1 %% Account subgraph ACCT[<strong>Partner Account</strong>] CON[<strong>Contact:</strong> Ivette] end PRO[Payment Product] PRO --> PA1 PA1[<strong>Payment Account:</strong> I59923<br /><br>MCC: 5462] %% Partner Business Entity subgraph PBE1[<strong>Partner Business Entity</strong>] LE1[<strong>Legal Entity:</strong> Ivette Croissants SARL] ST1[<strong>Stakeholder:</strong> Ivette] BA1[<strong>Bank account:</strong> Ivette Croissants BA] end %% Store Group subgraph SG1[<strong>Store Group</strong>] S1[<strong>Store:</strong> IvetteCroissanterie.fr] S2[<strong>Store:</strong> Joliette] S3[<strong>Store:</strong> Port] end
JSON

Copied

{
  "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": [
    {
      "payment_profile_id": "krn:partner:global:account:distribution-profile:206bbb83-9b6e-46fa-940d-337153c04a58",

Link copied!

Franchise networks can be modeled according to how they are structured and managed in your systems

  • Multiple Payment Accounts: When all franchisees have their own identifier towards you and your system but you have an overarching entity to group them, you can manage them separately by having individual Payment Accounts. They still share the same Partner Accounts
  • Multiple Stores: When all franchisees share the same identifier but are represented as different physical addresses on your systems, you can use one Partner Account with one Payment Account and multiple stores. The stores can be passed on the Payments API integrations
  • Multiple Partner Accounts: When all franchisees have their own account with you and don't share any data, then multiple Partner Accounts can be created to manage all companies as individual entities.

The shape the Klarna account structure takes should be reflective of the structure of the business.

Example 5: Franchise

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 Payment Account and Store identifiers 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 Partner 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 identifiers in the request, Klarna can present to the customer different store details and an experience personalized to the originating store.

flowchart TD %% Relationships ACCT1 --> PRO1 ACCT2 --> PRO2 ACCT3 --> PRO3 PA1 --> PBE1 PA1 -->|default| SG1 PA2 --> PBE2 PA2 -->|default| SG2 PA3 --> PBE3 PA3 -->|default| SG3 %% Partner Account – Maja subgraph ACCT1[<strong>Partner Account</strong>] CON1[<strong>Contact:</strong> Maja] end PRO1[Payment Product] PRO1 --> PA1 PA1[<strong>Payment Account:</strong> MW2351<br/><br>MCC: 5812] %% Partner Business Entity – Maja subgraph PBE1[<strong>Partner Business Entity</strong>] LE1[<strong>Legal Entity:</strong> Maja WTB] ST1[<strong>Stakeholder:</strong> Maja] BA1[<strong>Bank account:</strong> Maja WTB BA] end %% Store Group – Maja subgraph SG1[<strong>Store Group</strong>] S1[<strong>Store:</strong> wtb_maja] end %% Partner Account – Liam subgraph ACCT2[<strong>Partner Account</strong>] CON2[<strong>Contact:</strong> Liam] end PRO2[Payment Product] PRO2 --> PA2 PA2[<strong>Payment Account:</strong> MW2352<br/><br>MCC: 5812] %% Partner Business Entity – Liam subgraph PBE2[<strong>Partner Business Entity</strong>] LE2[<strong>Legal Entity:</strong> Liam WTB] ST2[<strong>Stakeholder:</strong> Liam] BA2[<strong>Bank account:</strong> Liam WTB BA] end %% Store Group – Liam subgraph SG2[<strong>Store Group</strong>] S2[<strong>Store:</strong> wtb_liam] end %% Partner Account – Vera subgraph ACCT3[<strong>Partner Account</strong>] CON3[<strong>Contact:</strong> Vera] end PRO3[Payment Product] PRO3 --> PA3 PA3[<strong>Payment Account:</strong> MW2353<br/><br>MCC: 5812] %% Partner Business Entity – Vera subgraph PBE3[<strong>Partner Business Entity</strong>] LE3[<strong>Legal Entity:</strong> Vera WTB] ST3[<strong>Stakeholder:</strong> Vera] BA3[<strong>Bank account:</strong> Vera WTB BA] end %% Store Group – Vera (4 stores) subgraph SG3[<strong>Store Group</strong>] S3[<strong>Store:</strong> wtb_vera_3] S4[<strong>Store:</strong> wtb_vera_4] S5[<strong>Store:</strong> wtb_vera_5] S6[<strong>Store:</strong> wtb_vera_6] end

To onboard, we would need three onboardKlarna Icon calls.

First sample request: One Store

JSON

Copied

{
  "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": [
    {
      "payment_profile_id": "krn:partner:global:account:distribution-profile:206bbb83-9b6e-46fa-940d-337153c04a58",

Second sample request: One Store

JSON

Copied

{
  "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": [
    {
      "payment_profile_id": "krn:partner:global:account:distribution-profile:206bbb83-9b6e-46fa-940d-337153c04a58",

Third sample request: Four stores

JSON

Copied

{
  "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": [
    {
      "payment_profile_id": "krn:partner:global:account:distribution-profile:206bbb83-9b6e-46fa-940d-337153c04a58",