Distribute Payment Program enablement to your Partners
Acquiring Partners can let their Partners self-serve optional Payment Programs through Klarna's Partner portal or through their own portal using the Klarna API. This overview lists the Payment Programs available today, compares both integration methods, and helps you choose the right path.
Why distribute Payment Program enablement
Optional Payment Programs are a conversion tool for your Partners. Programs like Financing 0% APR or longer instalment options give shoppers more ways to pay, lift checkout conversion, and increase average order value.
For you as the Acquiring Partner, distributing enablement is also a portfolio profitability lever: every optional Payment Program a Partner turns on grows transaction volume across your book and improves the unit economics of the Partners you've already acquired.
When a Partner is onboarded to Klarna, they automatically receive a baseline of preset Payment Programs. These are active from day one and require no action. On top of that baseline, a Partner can turn on optional Payment Programs.
As an Acquiring Partner, your job is to distribute this enablement capability to your Partners: to give them a way to discover, evaluate, and turn on optional Payment Programs.
| Enablement type | Behavior | Who can enable |
|---|---|---|
PRESET | Active automatically when the Partner is onboarded. Cannot be ended. | Klarna |
OPTIONAL | Off by default. Activated instantly when an enablement is created. | Acquiring Partner or Partner |
For details on the underlying resource, see createPaymentProgramEnablement
and the Payment Program Enablement resource.
and the Payment Program Enablement resource.Payment Programs reference: concrete examples
The list below gives a flavour of the Payment Programs that can show up under either enablement type. A Payment Program can either be ; the table below is illustrative only.
PRESET or OPTIONAL depending on the consumer country For example, Pay in 30 days is preset in most markets but is offered as optional in others. Always cross-check the actual enablement type per Partner via listPaymentProgramsForPaymentProgramPlan; the table below is illustrative only.| Payment Program | One-line description |
|---|---|
| Pay in Full | Immediate single-payment checkout via Klarna. |
| Pay Later | Buy now, pay later: shoppers receive the goods first and pay within 30 days. |
| Pay in 3 / Pay in 4 (Pay in N) | Shoppers split the cost into 3 or 4 equal, interest-free instalments. |
| Financing 0% APR | Longer-term instalments at 0% APR; classic conversion-uplift programs. |
| Financing | Longer-term instalments with interest, where supported. |
Always cross-check with listPaymentProgramsForPaymentProgramPlan for the canonical, per-Partner list (including which programs are
for the canonical, per-Partner list (including which programs are PRESET vs. OPTIONAL for each consumer country) and the payment_program_ids, before building your UI.Integration methods
Klarna supports two methods for distributing Payment Program enablement to your Partners. In both, the Partner is always the actor. The difference is which portal hosts the self-service experience. Method 2 then offers two integration paths, depending on how you source the enablement screen data.
| Classification | Description | Applicability |
|---|---|---|
| Method 1: Partner self-service in Klarna's Partner portal | Partners self-serve enablement directly in Klarna's Partner portal. You provide portal access and supply sell rates (optional) so Klarna can display them. | Acquiring Partners who want fastest time-to-market, lowest UI maintenance, and a Klarna-hosted experience. |
| Method 2: Partner self-service in your Partner portal | Partners self-serve enablement inside your own Partner-facing portal. You host the UI and integrate with the Klarna API to manage enablements on your Partners' behalf. Two paths, depending on how you source the screen data: • Method 2a: Compose the screen yourself: build the UI and compose the screen from data you already own (call the Klarna API to manage enablements, and render Payment Programs and pricing from your own systems). • Method 2b: Use Klarna's Payment Programs Presentation API: host the UI but render Klarna-curated presentation data (Payment Programs arrive already grouped into categories, with localized headers, lifecycle state, and migration hints ready to render). | Acquiring Partners who want full UX control and to keep Partners inside their own portal. |
Method 1 and Method 2 are mutually exclusive: pick one, not both. Within Method 2, paths 2a and 2b are two ways to build the same in-portal experience; pick whichever fits how you source the screen data. Klarna remains the system of record in all cases; when Method 2 is chosen, your portal is the Partner-facing surface for enablement and the Klarna Partner portal still shows a read-only view of the Partner's enablements with a notice telling them to go to you for any changes.
Drive Partner awareness and adoption
Whichever integration method you pick, awareness and discovery of optional Payment Programs stay your responsibility. They do not happen inside Klarna's Partner portal. Even under Method 1 (where enablement is Klarna-hosted), Partners learn that optional Payment Programs exist through your surfaces: your Partner portal, your lifecycle emails, your account-manager outreach. Without an awareness strategy, even the best enablement UX sits unused.
Channels typically include:
- Marketing campaigns to your existing Partner base, highlighting the conversion uplift of specific Payment Programs.
- In-portal placements: banners, empty-state copy, settings hints, and onboarding tours inside your own Partner-facing portal.
- Developer documentation and API references: mentioning Payment Programs alongside related capabilities so technical Partners encounter them in the natural course of integration.
- Lifecycle communications: onboarding emails, quarterly business reviews, account-manager outreach, in-app notifications.
This responsibility is summarised here at a high level. A dedicated page covering communication channels, in-portal placement patterns, and example campaigns is documented separately in Drive Partner adoption of optional Payment Programs (coming soon).
Visual examples
- AP-portal banner: a top-of-page banner inside your own Partner portal promoting a newly available Payment Program (e.g. "Financing 0% APR is now available. Turn it on in one click") with a direct link to the Payment Programs screen.
- Empty-state placement: when a Partner opens your Payment settings screen and has no optional Payment Programs enabled yet, surface a contextual prompt that explains what's available and links to the enablement flow.
- Onboarding tour step: include a step in your new-Partner onboarding tour that mentions Payment Programs alongside other commercial settings, so the capability is discovered early.
- Lifecycle email: a templated email sent on a milestone (first payment processed, first month complete, quarterly review) that highlights the optional Payment Programs the Partner has not yet enabled and the conversion uplift each one typically delivers.
Common concepts
The following concepts apply across both integration methods. Each per-method page builds on them.
Sell rates
Sell rates are the rates you charge your Partners for using each Payment Program. Klarna does not own this data. It lives in your contracts and your systems.
Sell rates matter at the moment a Partner is making an enablement decision for an optional Payment Program. They should be aware of the applicable rate before turning it on. In Method 1, sell rates should be visible inside Klarna's Partner portal. Since Klarna does not own this data, the portal will fetch the rates from you via the inbound pricing API. If that is not possible, Method 1 falls back to a generic message in the price column pointing the Partner back to you. In Method 2, you own the Partner-facing UI and are expected to display the sell rates from your own systems directly.
An inbound pricing API, exposed by you and called by Klarna to fetch sell rates for display in the Klarna Partner portal, is currently in design phase (specs not yet implemented). The API is expected to support returning the actual sell rate values, a URL pointing to where Partners can view them in your surfaces, or a combination of both. Until the API ships, Method 1 uses a generic price-column message as the interim default.
Enablement webhooks
Once a Payment Program is enabled or ended for a Partner, your systems likely need to know about it: for billing, reporting, and to keep your Partner-facing UI in sync. The scenarios that drive the need for webhooks are: contract updates, merchant price / fee recalculation, and Partner-portal UI refresh.
Enablement events do not currently emit Klarna webhooks. A webhook that notifies you when an enablement is created, deleted, or approved is on the roadmap. Until it's available, you can periodically reconcile state via listPaymentProgramEnablements for the Partner's current enablements and listPaymentProgramsForPaymentProgramPlan for the Payment Programs available to them.
for the Partner's current enablements and listPaymentProgramsForPaymentProgramPlan for the Payment Programs available to them.Global vs. advanced enablement
Klarna supports two enablement configurations, and they are mutually exclusive. The choice is decided at the Acquiring Partner level: you and Klarna agree which configuration fits your Partner base and your commercial setup, and the same configuration applies to every Partner you onboard. Klarna treats this as a recommendation we give you based on your portfolio and preferences; Partners themselves don't pick a configuration at enablement time. They see whichever one was agreed for you.
| Enablement style | What the Partner does | What happens to new Klarna-supported countries | When to choose it |
|---|---|---|---|
| Global enablement | One click: the Payment Program is activated for all existing and upcoming Klarna-supported consumer countries. | New countries Klarna adds in the future are enabled automatically. The Partner does not need to act again. | The right fit when the Partner wants a simple, low-friction experience and does not need country-level control over where the Payment Program is active |
| Advanced enablement | The Partner enables the Payment Program for one or multiple specific consumer countries. | New countries Klarna adds in the future are not enabled by default. The Partner has to explicitly extend their enablement to cover them. | The right fit when the Partner needs precise control over which markets the Payment Program is active in. |
Prerequisites
Before implementing either integration method, make sure you have:
- Klarna API credentials with permissions for the Payment Programs API
- Acquiring Partner Account ID (e.g.,
krn:partner:global:account:live:LYABCDEI) - An active Payment Program Plan assigned to your Acquiring Partner (see Payment Program Plans)
Next steps
Choose the integration method that best fits your portal strategy and resourcing:
- Method 1: Partner self-service in Klarna's Partner portal: fastest to launch, Klarna-hosted UX.
- Method 2: Partner self-service in your Partner portal: full UX control inside your own portal. Pick one of the two paths:
- Method 2a: Compose the screen yourself: you build the UI and source the screen data from your own systems.
- Method 2b: Use Klarna's Payment Programs Presentation API: you host the UI but render Klarna-curated presentation data.