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.
46 min read
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.
Coming soon
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
Type
Definition
DEFAULT
Grants Portal Users, API Credentials, and Klarna webhooks access to all resources on the account. No individual rules can be defined.
SCOPED
Restricts 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 getAccountAccessPolicy. When you send access_policies in the onboard 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 getAccountAccessPolicyRule. 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
State
Definition
ENABLED
The policy is enabled and enforced for its connected Portal Users, API Credentials, and Klarna webhooks.
DISABLED
The 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 onboard request to scope Portal Users, API Credentials, and Klarna webhooks from the start. Each rule grants access to exactly one resource.
Use disableAccountAccessPolicy to temporarily suspend a policy — Portal Users, API Credentials, and Klarna webhooks regain unrestricted access while it is disabled. Use enableAccountAccessPolicy to reactivate it.
Use resolveAccessPolicyId to look up the Klarna identifier from your access_policy_reference. All other policy and rule actions require the resolved identifier in the path.