If you’re adding Klarna to a physical checkout, there are really two paths: wire Klarna into each POS, terminal, or PSP yourself — where the route you pick depends on your size, your stack, and how much developer time you can spare — or connect it once through a payment connector and skip the integration work entirely.

This guide covers both honestly. We’ll break down the four direct routes most guides point you to — plug-and-play terminals, PSP/terminal integrations, the Klarna Merchant Portal, and the Klarna Payments API — including where each one fits and where it bites you later. But it’s worth saying up front: if you run more than one location, more than one POS, or expect to add other payment methods after Klarna, SensePass connects Klarna to your existing POS with no custom integration and no app for your shoppers to download — the same Klarna acceptance without the project. The rest of this article is the honest comparison so you can see why.

Before you get excited about the Merchant Portal route, know the gate: Klarna requires merchants to have used Klarna online for at least two months and captured at least 50 orders before they can self-onboard to certain point-of-sale features. If you’re brand new to Klarna, your fastest legitimate path is a Klarna plug-and-play terminal or PSP integration, not the self-service portal. E

Key Takeaways

The fastest, lowest-risk way to accept Klarna at a physical checkout is a plug-and-play terminal or PSP integration for most small and mid-size merchants, while enterprises and multi-processor operations gain more from a connector-based approach.

Point	Details
Match route to merchant size	Small kiosks check Clover/PSP auto-enablement first; enterprises scope a custom API integration.
Confirm onboarding eligibility	Merchant Portal self-onboarding requires two months of Klarna online history and 50+ captured orders.
Prepare for QR realities	Direct routes put a QR scan and a Klarna app step in front of the shopper; dynamic QR needs a customer-facing screen, static QR needs daily tampering checks.
Plan around limitations	Klarna doesn’t support split payments, and refunds must follow Klarna’s own return process.
Skip the integration entirely	SensePass connects Klarna to your existing POS with no custom integration and no shopper app download — one connector for Klarna and 100+ other methods.
Best for multi-store & omnichannel	Add Klarna once and every location gets it, with in-store and online transactions reconciling into one ERP.

Table of Contents

• How Do You Get Klarna to POS at Your Store?
• What Happens When a Customer Pays With Klarna In Store?
• What Do You Need to Build a Klarna Payments API Session?
• How Do You Onboard Klarna at Your Physical Checkout?
• What Are the Limitations of Klarna at Point of Sale?
• When Does a Payment Connector Make More Sense Than Direct Integration?
• The Real Tradeoff Nobody Talks About in Klarna Integration Guides
• Get Klarna Live Across Every Store Without Rebuilding Your Stack
• Where to Go Next for Klarna Integration Details
• Frequently Asked Questions
• Sources

How Do You Get Klarna to POS at Your Store?

The four routes above aren’t equally suited to every business, and picking the wrong one wastes either money or months. The table below breaks down what each route actually costs you in development time, what merchant profile it fits, and what you give up or gain at the checkout counter.

Dimension	Plug-and-play (Clover/PSP)	PSP/terminal (e.g., Verifone)	Merchant Portal web app	Klarna Payments API
Technical effort / dev required	None; activation only	Low; vendor-side enablement	None; browser-based setup	High; full API integration
Best for	Small kiosks, single-location retail	Mobile/remote sales, mid-market omnichannel	SMEs with existing Klarna online history	Enterprise, custom checkout flows
Onboarding time & prerequisites	Days; device must support Klarna	Weeks; vendor must confirm country availability	Fast, but requires 2+ months and 50+ Klarna orders online	Weeks to months; developer resources needed
Features supported at POS	QR, static QR/short_code (vendor-dependent)	QR, digital card, refunds	QR, short_code, partial refunds	Full control: one_qr, short_code, EMD, custom callbacks
Dependency on PSP/acquirer	High (fully vendor-managed)	High (vendor manages settlement)	Moderate (Klarna-hosted)	Low (you manage the session lifecycle)
Regional availability risk	Currently U.S.-focused (Clover)	Varies by terminal vendor and country	Varies by market	Depends on your own regional Klarna agreement
Cost / operational overhead	Lowest; no maintenance	Low; vendor handles updates	Low; occasional Klarna updates	Highest; ongoing dev and monitoring

A single-location coffee shop or boutique with a Clover terminal gets Klarna the same way it gets Apple Pay: someone flips a switch. A regional chain running Verifone terminals should contact Verifone directly to confirm Klarna is enabled for their country, since terminal integrations are phased by market. SMEs that already run a healthy Klarna online business can skip hardware vendors entirely and self-onboard through the Merchant Portal, provided they clear the volume threshold. Enterprises with branded checkout experiences or multi-processor setups tend to land on the API, because that’s the only route that gives you full control over session data, callbacks, and the customer-facing flow.

Klarna itself recommends checking your existing PSP or POS provider first before building anything custom. That’s not marketing spin. It’s the fastest, cheapest way for most SMEs to get Klarna live without touching a line of code.

What Happens When a Customer Pays With Klarna In Store?

Understanding the runtime flow matters even if you never write a line of integration code, because it explains what your staff will see on screen and why certain limitations exist (like the split-payment restriction covered later).

Here’s the sequence, step by step:

1. Your POS or merchant system creates a Klarna payment session with acquiring_channel set to in_store.
2. That session includes a distribution object specifying either one_qr (a dynamic, single-use QR code) or a short_code (a static code a customer can type in manually).
3. The customer scans the QR code on a customer-facing screen or receives the short code, then completes the Klarna flow on their own phone.
4. Klarna processes the payment and returns status through callback_urls, specifically the result_url, which your POS polls or listens to.
5. Once Klarna confirms authorization, your POS finalizes the order and settlement routes through your acquirer, not Klarna directly.

The distinction between dynamic and static QR matters operationally. Dynamic QR (one_qr) generates a fresh code per transaction and requires a screen the customer can see, which works well at a staffed checkout counter. Static QR or short_code flows use a printed code, which is cheaper to deploy but needs to be checked daily for tampering since anyone could swap a real code for a fraudulent one.

Here are the fields your integration needs to supply or expect on the wire:

Field	Purpose
acquiring_channel	Set to in_store to trigger the correct payment flow
distribution.method	one_qr for dynamic QR, or a short code equivalent
distribution.short_code	Static code value, when using the short-code method
callback_urls.status_update / result_url	Where Klarna sends payment status changes
attachment (EMD)	Extra Merchant Data required for risk and fraud checks
order_amount / order_lines	The transaction total and itemized cart
purchase_country / purchase_currency	Locale-specific settlement details
locale	Determines the language Klarna shows the customer

Picture it as a relay: your POS hands off to a Klarna session, the session hands a QR to the customer’s phone, the phone hands a confirmation back through the callback URL, and your POS closes the loop by finalizing the sale. Each handoff is where integrators most often introduce bugs, particularly around initiating the session correctly with the right distribution settings.

What Do You Need to Build a Klarna Payments API Session?

If you’re going the custom-integration route, the minimum viable request to Klarna’s sessions endpoint includes a handful of required fields, and missing even one of them is the single most common reason developers get stuck in sandbox testing.

At minimum, your POST needs: acquiring_channel set to in_store, purchase_country, purchase_currency, locale, order_amount, and a full order_lines array. You also need an attachment field carrying Extra Merchant Data (EMD), and a distribution object specifying your chosen method (one_qr or short_code) along with callback_urls.

Before you push anything to production, run through this testing checklist:

• Run sandbox sessions first, and confirm your result_url callback actually fires rather than relying on polling alone.
• Test both one_qr and short_code flows end to end, not just one.
• Trigger a refund and a partial refund in sandbox to confirm your reconciliation logic handles both.
• Test QR scanning across at least two device types and both major mobile browsers.

Pro Tip: Extra Merchant Data (EMD) formatting mistakes are the number one cause of failed or declined sessions during integration. Klarna’s own documentation flags EMD accuracy as a prerequisite, not an optional nicety, so validate your payload against the schema before you blame the API.

Printed static QR codes are a physical attack surface. Anyone standing at the counter can photograph or swap a static code, then hand the short code to a cashier as if it were their own.

That single fact should change how you operate, not just how you code. If you deploy short-code or static QR flows, build a daily visual inspection into your opening checklist the same way you would check a card reader for a skimmer.

How Do You Onboard Klarna at Your Physical Checkout?

Getting from “we want Klarna” to “customers are using Klarna” looks different depending on which route you picked in the comparison above. Here’s the practical sequence for each — and one route that skips most of these steps entirely.

1. Plug-and-play (Clover/PSP): Confirm your device model supports Klarna, then request activation through your Clover account or PSP dashboard. No developer involved.
2. Terminal integration (Verifone, etc.): Contact your terminal vendor directly to confirm Klarna is enabled for your country and request enablement on your existing hardware.
3. Merchant Portal web app: Verify you meet the prerequisite (two months of Klarna online activity and 50+ captured orders), then complete self-onboarding through the portal.
4. API integration: Request developer access and sandbox credentials from Klarna, scope your EMD requirements, and build against the sessions endpoint before going live.
5. SensePass connector: Connect Klarna to the POS you already run through SensePass’s ready-to-use integration — no device-by-device activation, no developer sprint, no volume gate. You get a chargeless SensePass tag: the customer taps to pay and completes Klarna in the same in-store flow they’d get online, with no app to download and no digital card to issue. It’s the fastest route to live, and the only one that also connects 100+ other payment methods through the same integration.

Prerequisites vary sharply by route. The Merchant Portal path has a hard volume gate. The API path has no volume gate but demands a developer, a QA cycle, and someone accountable for monitoring callback reliability long-term. Most direct routes also require standard merchant account setup: banking details, acquirer relationships, and the KYC documentation any payment method requires. The SensePass route removes the integration and hardware burden specifically — you connect once to your existing POS rather than enabling Klarna terminal by terminal or maintaining an API integration long-term.

Hardware and software needs also diverge sharply, and this is where the shopper experience is won or lost. Dynamic QR flows need a customer-facing screen, whether that’s a tablet, a secondary POS display, or a dedicated kiosk monitor. Static QR and short-code flows need only a printed card, but that convenience comes with the tampering risk mentioned earlier. Klarna also supports a digital single-use in-store card customers can load into Apple Pay or Google Pay for tap-to-pay, which sidesteps QR scanning but depends on your terminal supporting contactless and on the customer issuing the card first. SensePass sidesteps all of it: with the chargeless tap-and-pay tag, the customer taps their phone and pays with Klarna directly — no QR to scan, no app to download, no digital card to issue — the same experience they already know from checking out online.

Train your cashiers on two things specifically: how to guide a customer through a QR scan without touching their phone, and how to manually key in a short code if scanning fails. Both scenarios happen daily once volume picks up, and a confused cashier at a busy register is worse for conversion than not offering Klarna at all.

What Are the Limitations of Klarna at Point of Sale?

Klarna in-store isn’t a drop-in replacement for card payments, and a few behavioral quirks catch merchants off guard after launch.

• No split or multi-payment support. Lightspeed’s own documentation confirms customers can’t combine Klarna with another payment method on the same transaction, so a customer paying part cash, part Klarna simply isn’t possible at the register.
• Refunds follow a Klarna-specific process. You can’t process a Klarna refund the same way you’d refund a card swipe. It routes through Klarna’s own return flow, and skipping that step creates reconciliation mismatches in your ERP.
• Partial refunds work, but need care. Product exchanges or partial returns require you to track the Klarna order reference carefully, since Klarna settles adjustments separately from your acquirer’s standard batch.
• Regional availability isn’t universal. Verifone, for instance, lists country-specific availability for its terminal integration, so a feature live in one market may not exist in another yet.

The refund flow deserves a closer look because it’s where most reconciliation headaches start. A merchant initiates a refund request in their POS or Klarna dashboard, Klarna processes a settlement adjustment on its end, and that adjustment needs to match what lands in your ERP. If your finance team is reconciling by transaction total alone rather than by Klarna order reference, mismatches pile up fast.

Operationally, three habits keep this manageable: build a POS rule that blocks split payments before the cashier even attempts one, reconcile Klarna transactions against Klarna’s own reference IDs rather than generic batch totals, and inspect static QR displays daily as part of opening procedures.

When Does a Payment Connector Make More Sense Than Direct Integration?

Everything above assumes you’re adding Klarna and only Klarna. Most retailers aren’t in that position for long. Once you’re running Klarna alongside Apple Pay, PayPal, a couple of BNPL competitors, and maybe a crypto option for a niche customer segment, building and maintaining five separate direct integrations against five separate APIs becomes its own job.

That’s the gap SensePass is built to close — and it closes it two ways the direct routes can’t. First, no integration project: SensePass is a payment connector, the layer that links the POS, ERP, and eCommerce systems you already run to Klarna plus 100+ other methods and 50+ processors, so adding Klarna is activation, not development. It connects natively with NetSuite, Microsoft Dynamics 365 (Business Central, Finance & Operations, and Commerce), Oracle Xstore, Aptos, Shopify POS, BigCommerce, STORIS, and NCR. Second, no app friction for your shopper: instead of asking every customer to scan a QR and complete the flow inside the Klarna app, SensePass delivers Klarna through the same streamlined in-store experience it uses for tap-and-pay and every other method — so the customer just pays, and your cashiers aren’t troubleshooting scans at a busy register.

A multi-store retailer running Shopify POS or NetSuite or Dynamics 365 across a dozen locations benefits because adding Klarna once through Sensepass means every location gets it, not just the flagship store that happened to have a compatible terminal. An omnichannel brand selling online and in-store benefits because transactions from both channels reconcile back into the same ERP automatically, instead of finance manually matching Klarna’s in-store settlement against a separate online Klarna feed. An enterprise running Oracle Xstore or Dynamics 365 across regions benefits from processor-agnostic architecture and token ownership, meaning it can renegotiate acquirer rates or add a regional processor without re-integrating every store’s payment stack from scratch.

Klarna’s own positioning frames in-store flexible payments as a way to bring familiar online purchasing power into physical retail, aiming to lift both average order value and conversion at the register.

The Clover partnership is the clearest signal of how much demand exists for exactly this kind of frictionless rollout: Klarna’s plan to auto-enable more than 100,000 U.S. merchant locations tells you retailers aren’t waiting around for custom API projects. They want Klarna live now, without a developer sprint. A connector approach delivers that same speed, but extends it beyond one processor to every processor and payment method a merchant might need next year.

Klarna Direct vs. Klarna Through SensePass

The routes above all get Klarna to your register. What differs is what you and your customer have to do to get there — and live with afterward.

The direct routes answer “how do we launch Klarna fast.” SensePass answers “how do we accept Klarna — and whatever comes after it — without turning payments into a standing IT project.”

Get Klarna Live Across Every Store Without Rebuilding Your Stack

Sensepass gives you one integration for Klarna and everything that comes after it, so you’re not rebuilding your payment stack every time you add a new method or switch processors. Instead of activating Klarna terminal by terminal or maintaining a standalone API integration your developers have to babysit, you connect once to a payment connector that already links to platforms like NetSuite, Microsoft Dynamics 365, Shopify POS, Oracle Xstore, and BigCommerce, and already supports Klarna alongside 100+ other payment methods and 50+ processors.

Because Sensepass is processor-agnostic and gives you ownership of your payment tokens, adding Klarna to a new store or switching acquirers later doesn’t mean starting the integration over. That matters most for omnichannel and ERP-centric merchants who don’t want a different reconciliation process for every payment method they offer.

If you’re weighing your Klarna-to-POS options, here’s the concrete next step: see how the Sensepass connector works and request an integration plan mapped to your specific POS or ERP setup. You can also start from the Sensepass homepage to see the full range of platforms and payment methods supported before you commit to a single-processor Klarna project.

• Request a demo to see Klarna and your other payment methods running through one connector.
• Ask for a Klarna activation checklist specific to your POS or ERP.
• Get an integration plan scoped to your current systems before you build anything custom.

Where to Go Next for Klarna Integration Details

These are the primary references worth bookmarking before you start building or activating anything.

• Klarna Point of Sale standalone solution docs: onboarding eligibility and requirements (API reference and onboarding doc).
• Initiate an in-store payment — Klarna API docs: the sessions endpoint, required fields, and payload structure (API reference).
• Self service and no-code integrations — Klarna Docs: guidance for SMEs on checking existing PSP/POS integrations before building custom (onboarding doc).
• Klarna scales in-store offering with Clover — Klarna press: partnership announcement and rollout scope (partner enablement page).
• Verifone documentation: Klarna terminal: terminal-based flows and country availability (partner enablement page).
• Taking Payments with Klarna and Retail POS (X-Series) — Lightspeed support: practical sell-screen walkthrough and refund handling (partner enablement page).

Frequently Asked Questions

Can any merchant self-onboard Klarna to POS?

Not automatically. Self-onboarding through the Merchant Portal requires at least two months of Klarna online activity and 50 or more captured orders. Merchants without that history should start with a plug-and-play terminal or PSP integration instead.

Does Klarna support split payments at checkout?

No. Klarna in-store transactions can’t be combined with another payment method in the same sale, according to Lightspeed’s own integration documentation.

What’s the fastest way to add Klarna at POS?

Check whether your existing POS or PSP already supports Klarna. Clover, for example, is rolling out auto-enablement to over 100,000 U.S. merchant locations, which requires no development work at all.

Do refunds work the same way with Klarna as with card payments?

No. Klarna refunds follow a Klarna-specific process rather than your standard card refund flow, and skipping that process creates reconciliation problems in your accounting system.

Is Klarna in-store available everywhere?

Availability varies by country and by which terminal or PSP partner you use. Verifone, for instance, documents Klarna support market by market, so confirm availability for your specific region before committing to a route.

Sources

• Klarna Point of Sale – Klarna Docs
• Klarna scales in-store offering with Clover — Klarna press
• Verifone documentation: Klarna terminal
• Self service and no-code integrations – Klarna Docs
• Taking Payments with Klarna and Retail POS (X-Series) — Lightspeed support

Recommended

• How to Accept Klarna on Shopify POS Without Extra Hardware – Omnichannel payments at the Point Of Sale | Sensepass
• How to Accept Klarna in Business Central: Integration Guide – Omnichannel payments at the Point Of Sale | Sensepass
• How To Connect Alternative Payment Methods to Shopify POS