Einleitung

Die Checkout-Konversion ist einer der wenigen Bereiche im E-Commerce, in denen die Qualität der technischen Umsetzung direkt im Umsatz sichtbar wird. Ein Formular, das 4 Sekunden zum Laden benötigt, ein Zahlungsfehler, der keine Erklärung liefert, oder ein 3DS2-Prüfbildschirm, der bei jeder Transaktion unabhängig vom Risikolevel erscheint: Jedes dieser Probleme reduziert die Konversion. Und jedes ist ein technisches Problem, kein reines UX-Problem.

Muster, die zu Konversionsverlusten führen, schleichen sich oft unbemerkt ein. Zahlungsanbieter werden bei der Einführung integriert und dann bei wachsendem Transaktionsvolumen und neuen Märkten nicht mehr angepasst. SCA-Anforderungen der PSD2 werden reaktiv erst nach dem Launch angegangen, wenn die Reibung im Funnel bereits spürbar ist. Checkout-Seiten, die zum Zeitpunkt der Entwicklung schnell genug waren, verlieren an Geschwindigkeit, wenn sich Drittanbieter-Skripte ansammeln. Die notwendige Instrumentierung zur Erkennung dieser Probleme fehlt oft, bis jemand die Umsatzzahlen bemerkt.

Gradion betrachtet den Checkout als ein Full-Stack-Engineering-Problem: von der Auswahl und Integration der Zahlungsanbieter über das PCI-DSS-Scoping und die SCA-Implementierung bis hin zur Checkout-Performance, OMS-Konnektivität und Funnel-Observability – von Anfang an integriert.

Zahlungsanbieter-Integration

Die Abdeckung der Zahlungsmethoden wird durch die bedienten Märkte und die erwarteten Transaktionsvolumen bestimmt. Stripe deckt die meisten kartenbasierten Zahlungsströme mit einem klaren API-Design ab. Adyen ist der Enterprise-Standard für hochvolumige, multinationale Operationen mit starken Acquiring-Beziehungen. Mollie bedient den europäischen Mittelstand gut, insbesondere für iDEAL- und SEPA-Zahlungsströme in den Niederlanden und der DACH-Region. Klarna steigert die Konversion in Produktkategorien, in denen „Buy Now Pay Later“ ein entscheidender Faktor ist. Für Südostasien erfordert die Abdeckung andere Anbieter: PayNow für Singapur, PromptPay für Thailand und marktspezifische Wallets, die ein einzelner europäischer PSP nicht abdecken kann.

Integrationsarbeit geht über das reine Verbinden einer API hinaus. Die Verarbeitung von Webhooks für asynchrone Zahlungsereignisse, Idempotenzschlüssel zur Vermeidung doppelter Abbuchungen bei wiederholten Anfragen, eine Logik für fehlgeschlagene Zahlungsversuche mit angemessenem Backoff und Reconciliation-Feeds, die Transaktionsdaten in Finanzsysteme einspeisen: Dies sind die technischen Aufgaben, die bestimmen, ob eine Zahlungsintegration tatsächlich zuverlässig ist. Die Buchungsplattform von roadsurfer, die 7 Währungen in europäischen Märkten unterstützt, ist ein Beispiel für diese Art von Multi-Währungs-Zahlungsarchitektur im Produktivbetrieb.

Architektur für PCI-DSS-Konformität

Der Umfang der PCI-DSS-Konformität hängt davon ab, wie Kartendaten durch das System fließen. Eine schlecht definierte Implementierung zieht die gesamte Commerce-Plattform in den Compliance-Bereich, was die Audit-Fläche und den laufenden Wartungsaufwand vervielfacht. Bei korrekter Definition stellt die Tokenisierung sicher, dass Kartendaten niemals die von Gradion entwickelte Infrastruktur berühren: Der PSP übernimmt die Kartenerfassung, gibt ein Token zurück, und das Händlersystem arbeitet von diesem Zeitpunkt an nur noch mit diesem Token. Dies begrenzt den potenziellen Schaden bei zukünftigen Vorfällen und reduziert die wiederkehrenden Kosten für die Aufrechterhaltung der Zertifizierung.

SCA- und 3DS2-Implementierung

Die Starke Kundenauthentifizierung (SCA), wie sie von PSD2 für europäische Zahlungsströme gefordert wird, fügt Kartentransaktionen einen Verifizierungsschritt hinzu. Wird sie ohne Berücksichtigung der Transaktionsrisikostufen implementiert, führt sie bei jedem Kauf zu Reibungsverlusten. Korrekt implementiert, nutzt sie das 3DS2-Ausnahmeregelwerk, um Authentifizierungsanfragen nur dort anzuwenden, wo Risikostufen oder Transaktionsbeträge dies erfordern. So können Transaktionen mit geringem Risiko ohne Unterbrechung fortgesetzt werden. Die Ausnahmelogik befindet sich auf der Konfigurationsebene des PSP und erfordert eine Koordination zwischen der Acquirer-Bank, dem PSP und der Checkout-Implementierung.

Engineering des Checkout-Prozesses

Die Performance des Checkouts auf Mobilgeräten ist entscheidend. Eine Ladezeit von unter 2 Sekunden auf einem durchschnittlichen Android-Gerät in einer 4G-Umgebung stellt eine anspruchsvolle technische Anforderung dar. Adressvalidierung, Auswahl der Versandart und Echtzeit-Steuerberechnung können bei unachtsamer Implementierung jeweils Latenzzeiten verursachen. Für A/B-testbare Checkout-Prozesse ist eine Feature-Flag-Ebene unerlässlich. Sie ermöglicht das Ausspielen von Varianten ohne Code-Deployment und damit statistisch fundierte Experimente zu Schrittanzahl, Feldreihenfolge, Fehlermeldungen und der Darstellung von Zahlungsmethoden.

Auftragsmanagement und BNPL-Integration

Der Checkout ist nicht mit der Zahlungsautorisierung abgeschlossen. Bestandsreservierung, Betrugsprüfung und die Übergabe an das OMS (Shopware, Spryker oder eine kundenspezifische Fulfillment-Ebene) müssen als eine zusammenhängende Sequenz konzipiert werden, nicht als lose gekoppelte Integrationen. „Buy Now Pay Later“-Anbieter (Klarna, Afterpay/Clearpay, Scalapay) erfordern eine korrekte Abwicklung von Retouren und Rückerstattungen, die nahtlos an den BNPL-Anbieter zurückfließt und im Finanzsystem abgestimmt wird. Der Konversionseffekt ist produktkategorieabhängig und sollte vor dem Integrationsaufwand gemessen werden.

Observability

Die Instrumentierung des Checkout-Funnels umfasst die Verfolgung von Abschlussraten pro Schritt, Zahlungsfehlerraten nach Anbieter und Fehlercode sowie den Zeitpunkt des Warenkorbabbruchs. Ein Anstieg der Zahlungsfehlerrate um mehr als wenige Prozentpunkte deutet typischerweise auf ein PSP-Konfigurationsproblem, eine SCA-Fehlkonfiguration oder ein nachgelagertes OMS-Problem hin. Ohne Echtzeit-Transparenz dieser Signale häufen sich Probleme an, bevor sie sich in den Umsatzberichten bemerkbar machen.

Praxisbeweis

Eines der größten europäischen Digitalzahlungsunternehmen hatte seine Shopware-Integration für On-Premise-Umgebungen entwickelt. Als Händler zur Shopware Cloud migrierten, war der Kunde von diesem wachsenden Segment ausgeschlossen: Die bestehende Plugin-Architektur basierte auf Backend-Zugriffen, die die Shopware Cloud einschränkt. Gradion konzipierte und entwickelte eine Cloud-native Shopware App von Grund auf neu. Dies geschah in einer backend-losen, API-First-Umgebung mit begrenzter Dokumentation und ohne bestehende Präzedenzfälle im Ökosystem. Die App wurde innerhalb von drei Monaten geliefert und im Shopware Store veröffentlicht. Dies ermöglicht es nicht-technischen Händlern, die Zahlungsintegration ohne Entwicklungsunterstützung zu installieren und zu konfigurieren. So sieht die PSP-Cloud-Migration in der Praxis aus – nicht als Konfigurationsänderung, sondern als architektonisches Umdenken unter Plattformbeschränkungen.

Schweizer Marktführer für mobiles Bezahlen ist die dominierende digitale Zahlungsmethode der Schweiz und deckt 64 % der Schweizer Digitalzahlungstransaktionen ab. Gradion entwickelte ein wiederverwendbares SDK-Framework für die Schweizer Marktführer für mobiles Bezahlen-Integration, das den Zeit- und Entwicklungsaufwand für die Anbindung neuer Händler an die Plattform reduziert. Für Commerce-Betreiber, die den Schweizer Markt ansprechen, ist die Schweizer Marktführer für mobiles Bezahlen-Integration keine optionale Abdeckung – sie ist die primäre Zahlungsmethode für einen großen Teil der Käuferschaft.

ein führender DACH-Anbieter von Zahlungsinfrastruktur, eine europäische Zahlungsplattform, die Transaktionsvolumen in Milliardenhöhe in der DACH-Region verarbeitet, arbeitete mit Gradion an Engineering-Leistungen, die zu einer Wertsteigerung von 1,4 Mrd. € beim PE-Exit beitrugen. Eine Zahlungs-Infrastruktur, die zuverlässig, gut instrumentiert und compliance-gerecht konzipiert ist, ist kein Kostenfaktor. Sie ist ein Unternehmenswert mit einem messbaren Multiplikator.

roadsurfer: Komplette Neuentwicklung des Buchungs- und Zahlungsflusses, in 20 Tagen live geschaltet. Buchungen und Umsatz verdoppelten sich im ersten Jahr. Die Plattform unterstützt 8 Sprachen und 7 Währungen in europäischen Märkten.

ein führender deutscher Designer-Möbelhändler: Lieferanten- und Auftragsmanagement-Plattform, in 8 Wochen geliefert. 70 % der manuellen Bearbeitung entfielen, und Einkauf, Lager und Finanzen wurden in einem einheitlichen System verbunden.

Nächster Schritt

Beschreiben Sie Ihren Checkout-Flow sowie die Konversions- oder Compliance-Anforderungen, mit denen Sie arbeiten. Wir definieren den technischen Umfang.