Klarna-koppeling laten maken voor achteraf betalen.

Waarom koppelen aan Klarna?

Klarna is een Zweedse betaaldienst die bekend werd met "achteraf betalen": de klant ontvangt eerst zijn bestelling en betaalt daarna, of spreidt het bedrag over een paar termijnen. Voor consumenten is dat aantrekkelijk, en voor webshops kan het de conversie verhogen — vooral in segmenten waar mensen het product eerst willen zien.

Wat Klarna fundamenteel anders maakt dan een gewone betaalprovider, is dat er krediet in het spel zit. Bij een betaling via iDEAL of creditcard stroomt het geld direct van de klant naar jou. Bij Klarna treedt Klarna ertussen: het beoordeelt of de klant de aankoop later kan betalen, betaalt jou (afhankelijk van het product) vooruit en int zelf bij de klant. Dat verschil bepaalt hoe je de koppeling bouwt en wat je administratief moet regelen.

Klarna, Mollie of Adyen — wat is het verschil?

Klarna staat naast providers als Mollie en Adyen, maar lost een ander stukje van de puzzel op:

• Mollie en Adyen — betaalproviders (PSP's) die transacties verwerken. Het geld komt direct van de klant, via iDEAL, creditcard, Bancontact en dergelijke. Zij regelen de gateway en, in het geval van Adyen, ook de acquiring.
• Klarna — in de kern een kredietaanbieder. De klant koopt op afbetaling of betaalt achteraf; Klarna doet de kredietbeoordeling en draagt (bij gegarandeerde producten) het betaalrisico. Voor jou voelt het als een betaalmethode, maar onder de motorkap is het consumentenkrediet.

In de praktijk bied je Klarna daarom meestal náást een reguliere PSP aan, niet in plaats daarvan. Veel webshops laten Klarna technisch zelfs via hun bestaande PSP lopen, omdat providers als Adyen en Mollie Klarna als betaalmethode aanbieden. Wil je meer controle, een eigen checkout of doorkoppeling naar je administratie, dan bouw je een directe koppeling met de Klarna API.

Wat kun je koppelen met de Klarna API?

De Klarna API dekt het volledige aankoopproces rond achteraf betalen. De koppelingen die we het vaakst bouwen:

• Sessie en betaalmethoden starten — Een betaalsessie aanmaken vanuit je eigen software en de juiste Klarna-opties tonen (achteraf betalen, in termijnen, of direct), afgestemd op land, valuta en bedrag.
• Order autoriseren — De aankoop laten goedkeuren nadat Klarna de klant heeft beoordeeld. Pas bij goedkeuring weet je dat de bestelling door kan.
• Capture bij verzending — Bij achteraf betalen factureer je de klant doorgaans pas als de goederen daadwerkelijk zijn verzonden. Die "capture" stuur je vanuit je eigen ordersysteem.
• Refunds en annuleringen — Een order geheel of gedeeltelijk terugbetalen of annuleren vanuit je software, zonder in te loggen op een dashboard.
• Statussen verwerken — De definitieve uitkomst ontvangen via webhooks en koppelen aan de juiste order of factuur.

Authenticatie en de Klarna API

Anders dan veel CRM- of boekhoudkoppelingen werkt Klarna voor server-naar-server-communicatie niet met OAuth2, maar met API-credentials die je meestuurt in de aanvraag. Die credentials horen veilig in je serveromgeving te staan — in een environment-variabele of secrets manager, nooit in je frontend of in je broncode.

Klarna heeft daarnaast een strikt gescheiden test- (playground) en productieomgeving met eigen credentials en endpoints. Die scheiding consequent doorvoeren voorkomt de klassieke fout dat een testbetaling per ongeluk in productie belandt of andersom. Bouw je koppeling daarom met omgevingsspecifieke configuratie vanaf dag één. Raadpleeg de actuele Klarna Payments API-documentatie voor de exacte endpoints, want Klarna onderhoudt meerdere productvarianten naast elkaar.

Betaalstatussen verwerken met webhooks

De uitkomst van een Klarna-betaling haal je niet betrouwbaar uit de browser van de klant — die kan het tabblad sluiten of de verbinding kan wegvallen. De betrouwbare bron is de webhook: Klarna stuurt jouw server een melding zodra de betaling is goedgekeurd of de status verandert.

Twee dingen zijn daarbij essentieel:

• Idempotente verwerking — Klarna hanteert een retry-strategie en kan hetzelfde event meerdere keren afleveren. Je endpoint moet dat aankunnen: een dubbel ontvangen melding mag nooit leiden tot een dubbele order, dubbele factuur of dubbele e-mail. Klarna stelt expliciet dat je endpoint duplicaten moet kunnen verwerken zonder de data-integriteit aan te tasten (Klarna Docs). Hoe je dat netjes oplost, lees je in ons artikel over idempotentie.
• De webhook is leidend, niet de redirect — De terugkeer naar je site na het afrekenen is een hint, geen zekerheid. Pas de webhook bevestigt de definitieve status.

Een betaalkoppeling staat of valt bij de webhook-afhandeling. De betaling starten is het makkelijke deel — de status betrouwbaar en precies één keer verwerken is waar het echte werk zit.

Gegarandeerd of niet: wie draagt het debiteurenrisico?

Dit is het stuk dat bij Klarna het vaakst over het hoofd wordt gezien. Klarna beoordeelt elke order: het doet een risico- en kredietwaardigheidscheck op de klant voordat achteraf betalen wordt goedgekeurd. Slaagt die check en betreft het een gegarandeerd product, dan betaalt Klarna jou vooruit en neemt het het fraude- en wanbetalingsrisico over.

Maar Klarna kent ook niet-gegarandeerde (non-guaranteed) producten. Daarbij ligt het beeld anders: behalve bij fraudegevallen handelt Klarna geschillen niet af, en blijft het incasso- en debiteurenbeheer grotendeels jouw verantwoordelijkheid. Welk product je afneemt bepaalt dus direct welke processen je zelf moet inrichten — denk aan aanmaningen, terugboekingen en correcties in je administratie.

Voordat je Klarna inbouwt, moet je weten welk product je afneemt — gegarandeerd of niet. Dat bepaalt of het debiteurenrisico bij Klarna ligt of bij jou.

Voor de administratie geldt hetzelfde principe als bij elke betaalprovider: Klarna houdt transactiekosten in en bundelt uitbetalingen. Voor een sluitende boekhouding wil je die uitbetalingen automatisch afletteren tegen je orders, net zoals bij het koppelen van je webshop aan je boekhoudpakket.

Klarna en de nieuwe Europese regels (CCD2)

Achteraf betalen was lange tijd licht gereguleerd, maar dat verandert. Vanaf 20 november 2026 valt "buy now, pay later" onder de herziene Europese richtlijn consumentenkrediet, de Consumer Credit Directive 2 (CCD2). BNPL wordt daarmee als krediet behandeld, met verplichte kredietwaardigheidstoetsen en bescherming tegen onverantwoorde kosten.

Nederland kiest voor een strenge invulling: het maakt geen gebruik van de versoepelde uitzonderingen die andere lidstaten wel toestaan (zoals een lichter regime voor kleine kredieten), en verbiedt achteraf betalen voor minderjarigen. Dat raakt in de eerste plaats Klarna als aanbieder, maar het heeft ook gevolgen voor jouw checkout: leeftijdsverificatie, duidelijke informatie en een klantflow die aansluit op de nieuwe eisen worden belangrijker. Bouw je nu een Klarna-koppeling, houd dan rekening met deze wetgeving in je ontwerp.

Veelgemaakte fouten bij Klarna-koppelingen

Op basis van de betaalkoppelingen die we bouwen, zijn dit de valkuilen die we het vaakst tegenkomen:

• Niet idempotent verwerken — Een opnieuw verstuurde webhook leidt dan tot dubbele orders of dubbele boekingen.
• Vertrouwen op de redirect — De terugkeer naar je site is geen bewijs van een geslaagde betaling; de webhook is de bron van waarheid.
• Capture verwarren met autorisatie — Bij achteraf betalen factureer je doorgaans pas bij verzending. Te vroeg captureren zorgt voor onterechte facturen en correcties.
• Het garantiemodel negeren — Bij een non-guaranteed product zelf geen debiteurenbeheer inrichten, en dan verrast worden door onbetaalde orders.
• Test- en productieomgeving door elkaar — Klarna heeft een aparte playground met eigen credentials. Strikt scheiden voorkomt vervelende verrassingen bij livegang.

Mijn kijk op Klarna in maatwerk

Klarna is geen betaalmethode die je "even" aanzet zoals een extra knop in de checkout. Omdat er krediet en regelgeving achter zitten, is het een betaalproduct met eigen processen: kredietbeoordeling, capture bij verzending, debiteurenbeheer en — sinds CCD2 — compliance. Een doordachte koppeling neemt die kanten serieus in plaats van alleen de geslaagde betaling.

Wat ik bedrijven meegeef: kies Klarna om de juiste reden. Voor sommige doelgroepen verhoogt achteraf betalen aantoonbaar de conversie, en dan is het de moeite waard. Maar onderschat het administratieve en juridische staartje niet. De fout die ik het vaakst zie, is dat de happy path werkt — een goedgekeurde order — terwijl de randgevallen niet zijn afgedekt: een dubbele webhook, een retour, een onbetaalde order bij een niet-gegarandeerd product.

Die randgevallen zíjn het echte werk van een betaalkoppeling. Daar zit het verschil tussen een koppeling die maandenlang ongemerkt goed loopt en een die elke maand handmatig recht moet worden getrokken.

— Jasper

Zo helpt Coding Agency hierbij

Wij bouwen betaalkoppelingen die meer doen dan een betaling starten: met correcte idempotente webhook-verwerking, een nette capture- en refundflow, oog voor het garantiemodel en — waar gewenst — doorkoppeling naar je boekhouding. Of je nu Klarna naast Mollie wilt aanbieden of een eigen checkout in je maatwerksoftware bouwt, we denken graag mee over de juiste aanpak.

Benieuwd of Klarna bij jouw situatie past, of hoe een koppeling er voor jou uitziet? Neem contact op voor een vrijblijvend gesprek.

Bronnen: Klarna Docs — Payments API (docs.klarna.com) · Betaalvereniging Nederland — Consumer Credit Directive 2 (betaalvereniging.nl).