// stack · schnittstelle
Klarna ist keine weitere Kartenzahlung, sondern ein Zahlungsaufschub — der Käufer bekommt die Ware, bevor er zahlt. Für die Website hat das eine Folge, die alles andere bestimmt: Im Bezahlvorgang wird geprüft, ob dieser Kauf auf Rechnung läuft. Diese Seite beschreibt, wie siteway Klarna anbindet — und wie die Bezahlstrecke mit einer Ablehnung umgeht, statt in eine Sackgasse zu laufen.
// definition
Klarna ist ein Zahlungsanbieter, dessen Kern der Zahlungsaufschub ist. Der Käufer erhält die Ware, bevor er sie bezahlt. In Deutschland ist dafür vor allem der Rechnungskauf relevant — daneben stehen Ratenzahlung, Finanzierung und die sofortige Zahlung. Aus Sicht des Händlers ist das eine der wenigen Zahlarten, die eine Zielgruppe erreicht, die weder Karte noch Vorkasse nutzen möchte.
Technisch ist der Unterschied zur Karte größer, als es im Bezahlfenster aussieht. Bei einer Kartenzahlung geht es um Autorisierung und Einzug. Bei Klarna geht es um eine Frage, die vorher niemand beantworten kann: Übernimmt der Anbieter diese eine Bestellung auf Rechnung? Das entscheidet sich mitten im Bezahlvorgang, auf Basis der Daten, die die Website übergibt — und es kann auch Nein lauten.
Deshalb ist Klarna für eine Website weniger eine Frage der Schnittstelle als eine Frage der Strecke: Das Datenmodell der Bestellung muss stehen, bevor die Zahlung startet, und die Kasse braucht einen zweiten Weg für den Fall, dass der erste nicht angeboten wird. Beides ist beim Shop Teil des Bausteins — hier geht es um die Schnittstelle darunter.
// praxis
serverseitig · mit zweitem weg
Die erste Entscheidung fällt vor der Schnittstelle: Die Bestellung ist ein eigenes Datenobjekt auf deinem Server — mit Positionen, Mengen, Einzel- und Gesamtpreisen, Rabatten, Versandkosten und Steueranteilen. Erst wenn dieses Objekt vollständig ist und exakt die Zahlen ergibt, die im Warenkorb stehen, startet die Zahlung. Klarna prüft nämlich nicht nur einen Betrag, sondern einen Vorgang; unvollständige oder abweichende Daten sind die häufigste Ursache für Bestellungen, die im letzten Schritt nicht zustande kommen.
Danach läuft der dokumentierte Dreischritt. Der Server erzeugt die Bezahlsitzung und übergibt dabei den Warenkorb. Der Browser bekommt daraus nur ein kurzlebiges Token, mit dem Klarnas eigenes Frontend-SDK das Auswahlformular anzeigt. Wählt der Käufer und gibt frei, kommt ein Autorisierungs-Token zurück — und den nimmt wieder der Server, um die Bestellung abzuschließen. Zugangsdaten liegen dabei ausschließlich serverseitig, nie im Markup und nie im JavaScript-Bundle.
Der Teil, der in Angeboten regelmäßig fehlt, ist die Ablehnung. Sie ist hier kein Fehler, sondern ein vorgesehener Ausgang, und sie kann früh auftreten — dann wird die Zahlart erst gar nicht angezeigt — oder spät, beim Abschluss. Wir bauen die Kasse deshalb von vornherein mehrspurig: Der Warenkorb bleibt erhalten, eine andere Zahlart steht sofort bereit, die Meldung bleibt sachlich und kommentiert die Entscheidung nicht. Eine Bezahlstrecke mit nur einem Weg verliert genau an dieser Stelle die Bestellung.
Statusmeldungen sind die Quelle der Wahrheit, nicht die Rückkehr des Browsers. Ob eine Bestellung wirklich zustande gekommen ist, entscheidet der serverseitige Abschluss und die Rückmeldung von Klarna — nicht die Frage, ob der Käufer die Bestätigungsseite erreicht hat. Der eingehende Endpunkt prüft die Herkunft, verarbeitet jede Meldung idempotent und verträgt es, dieselbe Nachricht zweimal zu bekommen.
Und schließlich der Betrieb: Erfassung, Teillieferung, Erstattung, Stornierung. Das läuft nach dem Kauf über Klarnas Order-Management-API und hängt bei uns an den Status im Shop oder in der Warenwirtschaft, damit niemand zwei Systeme von Hand synchronisieren muss. Die buchbare Leistung dahinter beschreiben wir unter Schnittstellenentwicklung.
// technik · 6 details
belegt aus der doku
Was hier steht, stammt aus der öffentlichen Dokumentation von Klarna unter docs.klarna.com — Endpunkte, Feld- und Statusnamen im Original. Konditionen, Verfügbarkeiten je Markt und die genaue Zusammensetzung der Zahlartenauswahl hängen am Vertrag und an der Konfiguration des Kontos; die nennen wir hier bewusst nicht, sondern klären sie im Projekt.
// d-01sitzung
Der Server öffnet die Sitzung mit einem POST auf /payments/v1/sessions und übergibt den Warenkorb. Erwartet werden laut Doku unter anderem purchase_country, purchase_currency, locale, order_amount, order_tax_amount und die order_lines. Authentifiziert wird über HTTP-Basic mit den Kontozugangsdaten.
zweck: warenkorb übergeben
// d-02auswahl
Die Antwort auf die Sitzung enthält session_id, client_token und die payment_method_categories — also die Zahlarten, die für diesen Vorgang zur Verfügung stehen. Mit dem Token zeigt Klarnas JavaScript-SDK das Formular an; welche Kategorien erscheinen, ist keine feste Liste, sondern Ergebnis des Vorgangs.
zweck: käufer entscheidet
// d-03abschluss
Nach der Freigabe hält der Browser einen Autorisierungs-Token. Damit legt der Server die Bestellung an: POST auf /payments/v1/authorizations/{authorizationToken}/order. Zurück kommen unter anderem order_id, fraud_status und die tatsächlich gewählte Zahlart — die order_id trägt danach den ganzen weiteren Betrieb.
zweck: serverseitig verbindlich
// d-04daten
Die Dokumentation nennt die typischen Gründe, warum ein Abschluss scheitert: Der Warenkorb wurde nach der Autorisierung geändert, übergebene Daten weichen von der Sitzung ab, oder zwischen Autorisierung und Abschluss lag zu viel Zeit — genannt sind 60 Minuten. Anzeige und Übergabe müssen also dieselbe Bestellung meinen.
zweck: validierung besteht
// d-05ablehnung
Kann Klarna für diesen Vorgang keine Zahlart anbieten, meldet das SDK laut Doku show_form: false — dann gehört Klarna aus der Auswahl genommen, statt ein leeres Feld zu zeigen. Scheitert es erst beim Abschluss, liefert die Antwort einen Fehlercode. Beides braucht denselben Ausgang: eine andere Zahlart, sofort.
zweck: kein toter weg
// d-06betrieb
Erfassen, teilweise erfassen, erstatten, stornieren: Das läuft über die Order-Management-API unter /ordermanagement/v1/orders/{order_id}. Bleibt ein Teil der Autorisierung ungenutzt, wird er über release-remaining-authorization freigegeben, damit dem Käufer nichts offen stehen bleibt.
zweck: tagesgeschäft
Aus der Schnittstelle wird eine Strecke: Warenkorb, Adresse, Versandart, Zahlungsart, Bestätigung. Klarna hängt an der vierten Station — aber die drei davor entscheiden, ob sie funktioniert. Die Adresse muss vollständig und plausibel erfasst sein, die Versandkosten müssen feststehen, und der Steueranteil muss berechnet sein, bevor die Sitzung entsteht. Nachträgliche Änderungen am Warenkorb sind der klassische Fallstrick; wir sperren den Korb deshalb ab dem Moment, in dem die Zahlung startet, oder erzeugen die Sitzung neu.
Auf der Bestätigungsseite steht danach das, was der Server weiß — nicht das, was der Browser vermutet. Kommt der Käufer nicht zurück, weil das Netz abbricht, ist die Bestellung trotzdem angelegt und wird über die Statusmeldung nachgezogen. Dieselbe Sorgfalt gilt für den Versand der Bestätigungsmail und für die Übergabe an die Warenwirtschaft: einmal auslösen, auch wenn die Meldung zweimal kommt.
Beim Datenschutz ist Klarna ehrlicher gesagt der anspruchsvollere Fall. Für die Prüfung gehen personenbezogene Daten an einen Dritten — Name, Adresse, Positionen und Beträge. Das gehört in die Datenschutzerklärung mit Empfänger, Zweck und Grundlage und braucht eine saubere vertragliche Basis. Technisch heißt das bei uns: Übertragung serverseitig, Klarnas Skript erst im Bezahlvorgang statt auf jeder Seite, nur die Felder, die der Ablauf braucht. Grundlagen dazu im Stack unter Sicherheit & Datenschutz, die Prüfung als Leistung im Datenschutz-Audit. Die rechtliche Bewertung selbst gehört zu deiner Rechtsberatung.
// integration
drei systeme · ein muster
Der Weg ist in jedem System derselbe, weil ihn Klarna vorgibt und nicht das CMS. Die Bezahlstrecke liegt im CMS — Warenkorb, Adresse, Versandart, Zahlungsart, Bestätigung sind Seiten oder Schritte, die zur Website gehören und ihr Layout, ihre Sprache und ihre Zugänglichkeit teilen. Daneben steht ein serverseitiger Endpunkt, der zwei Aufgaben hat: die Bezahlsitzung erzeugen und die Bestellung abschließen. Er ist die einzige Stelle, die mit Klarna spricht. Die Zugangsdaten bleiben serverseitig, nie im Markup und nie im JavaScript-Bundle. Und weil der Browser bei einer Zahlung keine verlässliche Quelle ist, kommt der endgültige Status aus der eingehenden Statusmeldung — geprüft auf Herkunft und idempotent verarbeitet, damit dieselbe Nachricht zweimal nichts kaputt macht.
Die Besonderheit gegenüber einer Kartenzahlung ist das, was vor dem Endpunkt liegen muss: Klarna braucht vollständige Bestell- und Adressdaten — die einzelnen Positionen mit Menge und Preis, Rabatte, Versandkosten, den Steueranteil sowie Rechnungs- und Lieferadresse. Das Datenmodell der Bestellung muss also sauber stehen, bevor die Zahlung startet, und es muss exakt dieselben Zahlen ergeben wie die Anzeige im Warenkorb. In der Praxis ist das die eigentliche Integrationsarbeit: die Bestellung im CMS so zu modellieren, dass sie sich verlustfrei in die Übergabe an Klarna überführen lässt — und dass eine Ablehnung nur bedeutet, dass die Strecke eine andere Zahlart anbietet, nicht dass sie endet.
// cms-01typo3
In TYPO3 bauen wir die Anbindung als eigene Extension. Das Bestelldatenmodell beschreibt das TCA: Bestellung, Positionen, Beträge, Steueranteil und Adressen als Records mit klaren Feldern. Zwei Controller-Routen tragen den Ablauf — eine erzeugt die Bezahlsitzung und gibt das Token an das Frontend, die andere nimmt die Statusmeldung entgegen, prüft die Herkunft und schreibt den Bestellstatus fort. Die Zugangsdaten liegen in der Extension-Konfiguration oder, besser, in einer Umgebungsvariable, die von dort gelesen wird. Gerendert wird über Fluid: Warenkorb, Adressschritt, Zahlartenauswahl und Bestätigung als eigene Templates, die dasselbe Layout tragen wie der Rest der Website.
// cms-02wordpress
In WordPress entsteht die Anbindung als eigenes Plugin und nicht als Theme-Code — so überlebt sie jeden Theme-Wechsel und lässt sich getrennt aktualisieren. Zwei eigene REST-Routen bilden den Ablauf ab: eine für das Erzeugen der Bezahlsitzung, eine als Endpunkt für die Statusmeldung, beide mit Prüfung der Herkunft und idempotenter Verarbeitung. Die Zugangsdaten stehen in der wp-config.php oder in einer Umgebungsvariable, nie in einem Optionsfeld, das im Frontend landen kann. Im Frontend kommen Template-Dateien und Blocks für den Editor dazu, damit Zahlartenauswahl, Fehlerhinweise und Bestätigungsseite dort stehen, wo die Redaktion sie braucht.
// cms-03statamic
Statamic hat Laravel als Unterbau, und das passt zu einer Bezahlstrecke besonders gut: Route plus Controller für das Erzeugen der Sitzung und den Abschluss der Bestellung, eine zweite Route für die Statusmeldung, Validierung und Signaturprüfung als Middleware davor, Queues für alles, was nach der Bestellung passiert — Bestätigungsmail, Übergabe an die Warenwirtschaft. Die Zugangsdaten liegen in der .env und werden über die Konfiguration gelesen. Antlers oder Blade rendern Warenkorb, Adressschritt, Zahlartenauswahl und Bestätigung; im Control Panel pflegt die Redaktion die Texte, die an diesen Schritten stehen.
// entscheidung
zuordnung statt rangliste
Klarna lässt sich direkt anbinden oder als eine Zahlungsmethode innerhalb eines Zahlungsdienstleisters nutzen — Stripe etwa führt Klarna in seinem eigenen Bezahlfluss. Keiner der beiden Wege ist grundsätzlich besser; sie unterscheiden sich darin, wo die Verträge liegen, wie viele Schnittstellen die Website spricht und wie viel Kontrolle du über den Ablauf hast. An drei Mustern lässt sich das zuordnen.
// e-01direkt
Ist der Rechnungskauf die Zahlart, an der das Geschäft hängt, spricht viel für die direkte Anbindung: eigener Vertrag, eigene Abrechnung, voller Zugriff auf Sitzung, Bestellung, Erfassung und Erstattung. Der Preis dafür ist eine Schnittstelle mehr, die betrieben und beobachtet werden will.
volle kontrolle
// e-02dienstleister
Braucht die Kasse ohnehin Karte, Lastschrift und Wallet, ist Klarna als Methode innerhalb eines Dienstleisters der kürzere Weg: eine Schnittstelle, eine Abstimmung der Auszahlungen, ein Ort für Auswertung und Erstattungen. Die Mechanik dahinter bleibt dieselbe — nur die Sitzung erzeugt jemand anders.
eine schnittstelle
// e-03strecke
Die Arbeit an der Bezahlstrecke bleibt gleich: sauberes Bestelldatenmodell, exakte Beträge, ein zweiter Weg bei Ablehnung, Status aus der Statusmeldung statt aus dem Browser, benannte Datenweitergabe. Diese Punkte entscheiden über die Qualität — nicht die Frage, wessen Logo auf der Rechnung steht.
strecke vor anbieter
Vier Fragen entscheiden die Richtung, und sie lassen sich in einem Gespräch beantworten. Welche Zahlarten braucht deine Zielgruppe wirklich — und welche davon sind Pflicht, welche Kür? Läuft der Verkauf über einen Shop, über eine Buchungsstrecke oder über ein Formular mit Zahlung am Ende? Wie sehen Lieferung und Retoure aus, also wann wird erfasst und wie oft wird erstattet? Und wer betreibt die Anbindung später, wenn eine Bestellung einmal hängen bleibt?
Danach steht fest, welcher Weg trägt und was die Kasse an Alternativen bereithalten muss. Dieselbe Logik greift bei den anderen Zahlungsanbietern: Stripe bündelt viele Verfahren hinter einer Schnittstelle, PayPal bringt seinen eigenen Bezahlfluss mit. Was die Website daraus baut, klären wir im Konzept — vor dem Bauen, mit Begründung.
// faq
Klarna ist ein Zahlungsanbieter, dessen Kern der Zahlungsaufschub ist: Der Käufer bekommt die Ware, bevor er zahlt. In Deutschland ist dafür vor allem der Rechnungskauf verbreitet, daneben stehen Ratenzahlung, Finanzierung und die sofortige Zahlung. Für eine Website ist das ein anderer Vorgang als eine Kartenzahlung. Bei der Karte geht es um Autorisierung und Einzug eines vorhandenen Guthabens oder Rahmens. Bei Klarna geht es um die Frage, ob der Anbieter diese eine Bestellung auf Rechnung übernimmt — und das entscheidet sich erst im Bezahlvorgang.
In drei Schritten, wie Klarna sie dokumentiert. Erstens erzeugt der Server eine Bezahlsitzung mit einem POST auf /payments/v1/sessions und übergibt dabei den Warenkorb; die Antwort enthält unter anderem eine session_id, ein client_token und die verfügbaren payment_method_categories. Zweitens wählt der Käufer im Browser die Zahlart aus — Klarnas JavaScript-SDK zeigt dafür ein Formular an und liefert nach der Freigabe einen Autorisierungs-Token. Drittens legt der Server die Bestellung mit einem POST auf /payments/v1/authorizations/{authorizationToken}/order an und bekommt eine order_id zurück, mit der die Bestellung später über die Order-Management-API weiterbearbeitet wird. Entscheidend ist die Rollenverteilung: Der Browser zeigt nur an, gezahlt wird serverseitig.
Weil sie Teil der Prüfung sind und nicht nur Dekoration im Bezahlfenster. Die Sitzung erwartet laut Dokumentation unter anderem Einkaufsland, Währung, Sprache, den Gesamtbetrag, den Steueranteil, die einzelnen Positionen als order_lines sowie Rechnungs- und Lieferadresse. Genau daran hängt auch der häufigste Fehler beim Bestellabschluss: Ändert sich der Warenkorb nach der Autorisierung, schlägt die Prüfung fehl und die Bestellung wird nicht angelegt. Für eine Website heißt das, dass das Datenmodell der Bestellung stehen muss, bevor die Zahlung startet — Positionen, Rabatte, Versandkosten und Steuern müssen exakt dieselben Zahlen ergeben wie die Anzeige im Warenkorb.
Dann darf die Bezahlstrecke nicht stehen bleiben. Eine Ablehnung ist bei einem Zahlungsaufschub keine Störung, sondern ein vorgesehener Ausgang, und sie kann an zwei Stellen auftreten: Klarna kann die Zahlart schon gar nicht anbieten — das SDK meldet das laut Dokumentation über das Feld show_form — oder die Bestellung wird beim Abschluss nicht angelegt. Wir bauen die Kasse deshalb so, dass in beiden Fällen sofort eine andere Zahlart bereitsteht, der Warenkorb erhalten bleibt und die Meldung sachlich formuliert ist, ohne die Ablehnung zu kommentieren. Eine Bezahlstrecke, die nur einen einzigen Weg kennt, verliert genau hier die Bestellung.
Beides ist möglich, und die Entscheidung hängt am Rest der Bezahlstrecke. Direkt heißt: Deine Website spricht Klarnas API selbst, du hast die volle Kontrolle über Sitzung, Bestellung, Erfassung und Erstattung und arbeitest mit einem eigenen Vertrag und einer eigenen Abrechnung. Über einen Zahlungsdienstleister wie Stripe heißt: Klarna erscheint als eine Zahlungsmethode neben Karte und anderen Verfahren, die Website spricht nur eine Schnittstelle, und Abrechnung wie Auswertung laufen an einer Stelle zusammen. Der zweite Weg ist meist der kürzere, wenn ohnehin mehrere Zahlarten gebraucht werden; der erste lohnt, wenn Klarna eine tragende Rolle spielt und tief in eigene Prozesse eingebunden werden soll.
Über Klarnas Order-Management-API, und das ist der Teil, der nach dem Go-live jeden Tag läuft. Eine angelegte Bestellung ist zunächst autorisiert; erfasst wird sie, wenn geliefert wird. Bei einer Teillieferung wird nur der gelieferte Teil erfasst, und wenn kein weiterer Teil folgt, wird der Rest der Autorisierung wieder freigegeben — dokumentiert über den Endpunkt /ordermanagement/v1/orders/{order_id}/release-remaining-authorization. Retouren laufen als Erstattung auf die erfasste Bestellung, eine Stornierung vor der Erfassung gibt den Betrag frei. Damit das nicht zur Handarbeit wird, koppeln wir diese Schritte an die Status im Shop oder in der Warenwirtschaft.
Dass personenbezogene Daten an einen Dritten übermittelt werden, und zwar mehr als bei einer reinen Kartenzahlung: Name, Adresse, Bestellpositionen und Beträge fließen in die Prüfung ein. Das gehört benannt — in der Datenschutzerklärung mit Empfänger, Zweck und Grundlage, und in der Kasse an der Stelle, an der die Zahlart gewählt wird. Technisch halten wir die Übertragung serverseitig, laden Klarnas Skript erst im Bezahlvorgang und nicht auf jeder Seite, und übergeben nur die Felder, die der Ablauf braucht. Wie das konkret aussieht, ist eine Frage an die eigene Rechtsberatung; wir liefern die technische Grundlage dafür und prüfen sie im Datenschutz-Audit.
Ja, und der Aufbau ist in allen drei Systemen derselbe: Die Bezahlstrecke liegt im CMS, ein serverseitiger Endpunkt erzeugt die Sitzung und schließt die Bestellung ab, die Zugangsdaten bleiben serverseitig. In TYPO3 bauen wir dafür eine eigene Extension mit Controller-Routen für Sitzung und Statusmeldung, den Zugangsdaten in der Extension-Konfiguration oder in einer Umgebungsvariable und Fluid im Frontend. In WordPress entsteht ein eigenes Plugin statt Theme-Code, mit eigenen REST-Routen, den Zugangsdaten in der wp-config.php oder in einer Umgebungsvariable und Templates beziehungsweise Blocks im Frontend. In Statamic liegt Laravel darunter: Route plus Controller, Zugangsdaten in der .env, Antlers oder Blade im Frontend. Die Integration ist damit Teil unserer Leistung — vom Bestelldatenmodell bis zur Bestätigungsseite.
// womit das zusammenhängt
zahlung, strecke & leistung
// stack · schnittstelle
Der Zahlungsdienstleister, der viele Verfahren hinter einer Schnittstelle bündelt — Klarna lässt sich darüber als Methode nutzen.
zur technik →
// stack · schnittstelle
Der Bezahlfluss, den viele Käufer schon kennen — anderes Modell, dieselbe Frage: Wie sauber steht die Bestellung darunter?
zur technik →
// stack · grundlage
Wo Bestell- und Adressdaten zur Prüfung an einen Dritten gehen, wird es ernst: Zugangsdaten serverseitig, TLS, Datensparsamkeit.
zur technik →
// leistung · baustein
Der Baustein um die Zahlung herum: Produktkatalog, Warenkorb, Checkout und Warenwirtschaft — buchbar als Komponente.
zur leistung →
// leistung · strecke
Mehrstufige Strecken mit Validierung, Zwischenspeicher und klaren Fehlerwegen — die Mechanik, auf der eine Kasse aufsetzt.
zur leistung →
// leistung · buchen
Die Technik hier, das Angebot dort: Analyse, Datenmodell, Umsetzung, Monitoring und Betrieb der Anbindung. Hier wird gebucht.
zur leistung →
// Rechnungskauf in deiner Bezahlstrecke?
Projekt anfragen