Access Policies

Access Policies define which resources Portal Users, API Credentials, and Klarna webhooks can access on a Partner Account, allowing Acquiring Partners to scope and control permissions for their Partners.

Overview

Use Access Policies to control which resources a Portal User, an API Credential, or a Klarna webhook can access within a Partner Account. An Access Policy groups a set of rules, where each rule grants access to a specific resource such as a Payment Account, Store Group, or Brand.
Acquiring Partners use Access Policies to restrict or define the scope of a Partner's operations — for people signing in to the Klarna Partner Portal, automated traffic using API Credentials, and Klarna webhooks. For example, a Partner that processes payments across multiple Payment Accounts can have Portal Users, credentials, and webhooks that only reach a subset of those Payment Accounts through an Access Policy.
Access Policies can currently be defined during onboarding but are not yet enforced. Assigning policies to Portal Users, API Credentials, and Klarna webhooks will be available in a future release.
Access Policies can be defined during onboarding or managed separately throughout the Partner lifecycle.

Relationships & Dependencies

graph TD PA(Partner Account) AP(Access Policy) APR(Access Policy Rule) PA_ACC(Payment Account) SG(Store Group) BR(Brand) PU(Portal User) API(API Credential) WH(Klarna Webhook) PA -->|1..n| AP AP -->|1..n| APR APR -->|1..1| PA_ACC APR -->|1..1| SG APR -->|1..1| BR AP -.->|0..n| PU AP -.->|0..n| API AP -.->|0..n| WH class AP primaryEntity
  • Access Policy: A named set of rules tied to a Partner Account. Each policy has an access_policy_reference provided by the Acquiring Partner (unique within the Partner Account), a type, and a state. Policies determine what Portal Users, API Credentials, and Klarna webhooks can reach on that account.
  • Access Policy Rule: An individual permission within a policy. Each rule references a specific resource and is identified by an access_policy_rule_reference (unique within the Access Policy).
  • Resource: The target entity a rule grants access to. Supported resource types are PAYMENT_ACCOUNT, STORE_GROUP, and BRAND.
A Partner Account can have multiple Access Policies. Each Access Policy contains one or more rules, and each rule grants access to exactly one resource. Together, the rules define the effective scope for Portal Users, API Credentials, and Klarna webhooks on that account.

Policy types

TypeDefinition
DEFAULTGrants Portal Users, API Credentials, and Klarna webhooks access to all resources on the account. No individual rules can be defined.
SCOPEDRestricts Portal Users, API Credentials, and Klarna webhooks to only the resources explicitly listed in the policy's rules.
When no Access Policy is explicitly configured, Portal Users, API Credentials, and Klarna webhooks are assigned the DEFAULT policy, which grants full access to all resources on the account. Use a SCOPED policy to limit access to specific resources.

Resource properties

Access Policy

The following fields come from the 200 response of getAccountAccessPolicyAPI. When you send access_policies in the onboardAPI request, use the same references and rules but omit read-only response fields (type, state, and access_policy_rule_id on each rule).

Access Policy Rule

The following fields come from the 200 response of getAccountAccessPolicyRuleAPI. The nested resource object identifies the target (for example a Payment Account, Store Group, or Brand); property names appear flattened in the table (for example resource.type).

Lifecycle

flowchart LR enabled[ENABLED] -->|Disable| disabled[DISABLED] disabled -->|Enable| enabled
StateDefinition
ENABLEDThe policy is enabled and enforced for its connected Portal Users, API Credentials, and Klarna webhooks.
DISABLEDThe policy is no longer active and is not considered when defining access for its connected Portal Users, API Credentials, and Klarna webhooks.
Access Policies are created in the ENABLED state. Use the disable and enable actions to manage the policy lifecycle.

Frequent Use Cases

Restrict Portal Users to specific Payment Accounts

When a Partner operates multiple Payment Accounts — for example, one per legal entity or MCC — an Acquiring Partner can create a SCOPED Access Policy that limits a group of Portal Users to only the relevant Payment Accounts. Each policy contains rules that reference the target Payment Accounts, and the Portal Users assigned to that policy can only see and manage those Payment Accounts in the portal. See Model your Partner Accounts for a concrete example with a multi-brand enterprise.

Restrict Portal Users to specific Brands or Store Groups

When a Partner has multiple Store Groups or Brands, an Access Policy can control which Portal Users can manage each one. Create a SCOPED policy with rules referencing the target Store Groups or Brands to scope a group of Portal Users to only their relevant resources — preventing cross-region or cross-brand changes while keeping everything under a single Partner Account.

Create Access Policies during onboarding

Include the access_policies array in the onboardAPI request to scope Portal Users, API Credentials, and Klarna webhooks from the start. Each rule grants access to exactly one resource.

Read an Access Policy

Use getAccountAccessPolicyAPI to retrieve a policy and its rules.

Disable or re-enable a policy

Use disableAccountAccessPolicyAPI to temporarily suspend a policy — Portal Users, API Credentials, and Klarna webhooks regain unrestricted access while it is disabled. Use enableAccountAccessPolicyAPI to reactivate it.

Read or remove a rule

Use getAccountAccessPolicyRuleAPI to retrieve a single rule, or deleteAccountAccessPolicyRuleAPI to remove it.

Resolve an Access Policy ID

Use resolveAccessPolicyIdAPI to look up the Klarna identifier from your access_policy_reference. All other policy and rule actions require the resolved identifier in the path.
Related articles
Setup your webhooks
Partner Accounts
Payment Accounts
Partner Stores and Brands
Submit the onboarding request
API & SDK references
API