So integrieren Sie SAP Digital Payments erfolgreich in Ihr E-Commerce-System

Hinter jeder nahtlosen Online-Zahlung steckt eine komplexe Integration von Systemen, Daten und Prozessen – hier zeigen wir, wie wir diese Integration für einen globalen B2B-Marktführer mit SAP Digital Payments (SAP DP) umgesetzt haben.

Im ersten Teil unserer Serie haben wir erklärt, was SAP Digital Payments (SAP DP) ist und welchen geschäftlichen Mehrwert es für Unternehmen bringt, die Zahlungen über mehrere Märkte hinweg steuern.

Nun öffnen wir im zweiten Teil die „technische Küche“. Wir zeigen, wie man SAP DP tatsächlich mit einem E-Commerce-System integriert und Workflows entwirft, die Sicherheit, Flexibilität und Compliance sicherstellen – ohne dabei die Customer Journey zu stören.

Um dies greifbar zu machen, nehmen wir Sie mit hinter die Kulissen eines Projekts, das wir für einen unserer Kunden umgesetzt haben: ein globales B2B-Unternehmen mit E-Commerce-Aktivitäten in zahlreichen Ländermärkten. Das Unternehmen benötigte eine Lösung, die Zahlungsarten und Anbieter flexibel an die jeweiligen geschäftlichen und regulatorischen Anforderungen anpassen kann.

Warum ist dieses Thema so wichtig? Weil Zahlungen im E-Commerce zu den komplexesten Prozessen gehören: Sie betreffen User Experience, Order Management im Backend, ERP-Buchhaltung, Abstimmungen, regulatorische Vorgaben und den Kundenservice. Ein einziges schwaches Glied kann zu erheblichen operativen und finanziellen Risiken führen. Und im B2B – wo Bestellwerte oft deutlich höher sind als im B2C – sind die Risiken entsprechend größer.

Durch die Feinheiten von SAP Digital Payments führt uns unser Experte — Damian Woźniak, Technical Architect bei Striped Giraffe.

Zwei Integrationsmodelle

Wie bereits im ersten Teil erläutert, bietet SAP zwei Modelle an, um eine E-Commerce-Plattform mit SAP Digital Payments zu verbinden:

1. Payment Page
2. Direkte PSP-Anbindung

Beide Modelle haben unterschiedliche Auswirkungen auf Architektur, User Experience und Betriebsprozesse. Unser Kunde entschied sich, beide Ansätze zu implementieren und zu testen, um ihre jeweiligen Stärken und Schwächen zu bewerten.

Modell 1: Payment Page

Das Payment-Page-Modell ist PSP-agnostisch. Das bedeutet: Die E-Commerce-Anwendung muss nicht wissen, welcher Payment Service Provider (PSP) konkret genutzt wird. Der gesamte Zahlungsprozess wird über die Schnittstellen von SAP DP abgewickelt.

Nach Abschluss einer Transaktion werden alle relevanten Zahlungsdaten von SAP DP abgerufen und zusammen mit den Bestelldaten an SAP S/4HANA übergeben. Von dort können weitere Aktionen wie Rückerstattungen erfolgen.

Abbildung 1. SAP DP Payment Page Integrationsmodell

SAP stellt dafür die JavaScript-Bibliothek DPJSLIB bereit. Sie rendert die Payment Page in einem eigenen Fenster. Der Inhalt dieses Fensters wird direkt vom integrierten PSP bereitgestellt. Jede neue PSP-Integration erfordert also eine Abstimmung mit dem PSP-Team, um die Seite gemäß Business- und UX/UI-Anforderungen zu gestalten.

Über DPJSLIB können zudem alle im SAP DP-Admin-Panel konfigurierten Zahlungsmethoden geladen werden. Auf dieser Basis wählt der Nutzer seine bevorzugte Zahlungsart.

Zusätzlich stellt SAP REST-Endpunkte zur Verfügung, über die das angebundene System Zahlungen initiieren und deren Status prüfen kann.

Modell 2: Direkte PSP-Anbindung

In diesem Modell integriert sich die E-Commerce-Anwendung direkt mit einem spezifischen PSP, ohne SAP DP im eigentlichen Zahlungsfluss. SAP DP ist hier nur in der Backend-Schicht aktiv und unterstützt die finanziellen Folgeprozesse nach Bestellabschluss.

SAP DP erfährt von den Transaktionen über spezielle Endpunkte, die von einem Adapter aufgerufen werden.

Das bedeutet: Der PSP kontrolliert den gesamten Zahlungsprozess – inklusive UI und User Experience.

Abbildung 2. SAP DP Direct PSP Integrationsmodell

Integration der SAP DP Payment Page mit dem E-Commerce-System

Da unser Kunde bereits auf SAP Commerce setzte, basierte das Projekt auf dieser Plattform. Die gleiche Vorgehensweise lässt sich jedoch auch auf andere E-Commerce-Systeme wie Adobe Commerce/Magento, Shopify oder Salesforce Commerce Cloud übertragen.

Schritt 1: Laden der Zahlungsmethoden

Wir haben das DPJSLIB-Script ins Frontend injiziert, um digitale Zahlungsmethoden zu laden und die Payment Page des PSP anzuzeigen.

Schritt 2: Kommunikation mit SAP DP

Für die Kommunikation mit den SAP DP-Endpunkten entwickelten wir einen REST-Service (Microservice #1). Er zentralisiert alle Schnittstellenaufrufe und erleichtert die Integration mehrerer Anwendungen in die SAP-DP-Landschaft.

Dieser Service greift auf AWS Secret Manager zu, wo die SAP-Client-Credentials sicher gespeichert sind. Wichtig: Das Commerce-System selbst ist nicht direkt mit dem PSP verbunden. Dadurch lassen sich PSPs einfacher austauschen.

Abbildung 3. Payment Page Lösungsarchitektur

Schritt 3: Bestellanlage im ERP

SAP Commerce und Microservice #1 prüfen gemeinsam den Zahlungsstatus. Bei Erfolg lösen sie die Bestellanlage aus.

Dazu nutzten wir einen vorhandenen Middleware-REST-Service (Microservice #2), den wir projektspezifisch angepasst haben.

Schritt 4: Kommunikationsfluss

Das Frontend kommuniziert mit Microservice #1 und SAP Commerce über GraphQL, was Datenaggregation und API-Aufrufe vereinfacht.

Abbildung 4. Payment Page Sequenzdiagramm

(Bewegen Sie den Mauszeiger über das Diagramm, um bestimmte Bereiche zu vergrößern. Eine hochauflösende Version steht auch zum Download im PDF- und PNG-Format zur Verfügung.)

Ablauf des Payment-Page-Prozesses

1. Checkout-Seite öffnet sich
2. Zahlungstransaktion wird initiiert (über GraphQL & Microservice #1 → SAP DP)
3. DPJSLIB wird injiziert
4. Verfügbare Zahlungsmethoden werden geladen
5. Anzeige der Optionen im Browser
6. Kunde wählt Zahlungsmethode
7. Bestellbestätigung und Öffnen des PSP-Fensters
8. Draft-Order wird parallel an Microservice #2 übergeben
9. Kunde schließt PSP-Fenster → Promise an Frontend
   (⚠️ nur Interaktion, kein finales Payment)
10. Backend-Thread in Microservice #1 prüft den Status direkt bei SAP DP
11. Frontend pollt ebenfalls den Status und zeigt Success/Error-Seiten an

Mögliche Stolpersteine im Payment-Page-Modell

• Browser- oder Netzwerkausfälle → Promise bricht ab, daher Draft-Orders als Absicherung.
• Filterung von Zahlungsmethoden → derzeit nur im Frontend möglich, besser wäre ein REST-Endpunkt für Backend-Filterung.
• Finalisierung → Polling erzeugt Last, Callback-Mechanismen wären effizienter.

Weitere Überlegungen:

• SAP DP ist nicht plug-and-play, jede PSP benötigt eigene Integration.
• PSP-Software muss umfassend getestet werden.
• Lokale Regularien pro Land sind zwingend einzuhalten.
• Transaktionszeiten variieren je nach PSP und Infrastruktur.

Integration des Direct PSP-Modells

In diesem Szenario integriert das Frontend direkt mit dem PSP. Jeder PSP hat eigene Anforderungen, daher keine einheitliche Guideline. Zur Entkopplung der Logik setzten wir wieder auf ein Middleware-REST-Service (Microservice #1).

Abbildung 5. Architektur der direkten PSP-Lösung

Prozessschritte

1. Zahlung wird direkt beim PSP abgeschlossen (inkl. Webhooks für Status).
2. SAP DP wird nachträglich über dedizierte Endpunkte über die Transaktion informiert.
3. Microservice #3 verarbeitet die Webhook-Daten und registriert die Transaktion in SAP DP.
4. SAP DP legt eine interne Transaktion mit IDs, Tokens und Metadaten an.
5. Zahlung + Bestelldaten werden an SAP ERP übergeben.
6. SAP DP unterstützt die finanziellen Folgeprozesse (Reconciliation, Buchungen, Refunds).

Abbildung 6. Direct PSP Sequenzdiagramm

(Bewegen Sie den Mauszeiger über das Diagramm, um bestimmte Bereiche zu vergrößern. Eine hochauflösende Version steht auch zum Download im PDF- und PNG-Format zur Verfügung.)

Unsere Erkenntnisse zum Direct PSP-Modell

• Jede PSP erfordert individuelle Entwicklung.
• Im Vergleich zum Integrationsmodell der Zahlungsseite profitieren Sie jedoch von einer stärker personalisierten UX/UI und können alle PSP-Funktionen nutzen, da Sie nicht durch Zwischen-Schnittstellen eingeschränkt sind.
• Klare Verantwortung: PSP ist für den gesamten Payment-Prozess zuständig.

Fazit

Das Projekt unseres Kunden hat gezeigt: Beide Modelle haben ihre Berechtigung.

• Payment Page → schnellere Rollouts, einfacherer PSP-Wechsel, weniger Komplexität.
• Direct PSP → mehr Kontrolle, volle Nutzung PSP-spezifischer Features, aber höherer Entwicklungsaufwand.

In beiden Szenarien bleibt SAP Digital Payments das Rückgrat, das sicherstellt, dass alle Zahlungsdaten konsistent ins SAP ERP fließen – für saubere Buchhaltung, Refunds und Compliance, egal wie viele PSPs im Einsatz sind.

Das könnte Ihnen auch gefallen:

• SAP Digital Payments: Sichere, skalierbare und zukunftsfähige Zahlungsprozesse mit SAP S/4HANA » Mehr erfahren
• Was kommt nach dem Accelerator? Frontend-Strategien für SAP Commerce Storefront » Mehr erfahren
• 7 wesentliche Gründe für Data Sharing im E-Commerce » Mehr erfahren
• Technologie-Hacks für Kosteneinsparungen im E-Commerce » Mehr erfahren
• Die Suche im B2B-E-Commerce: Strategischer Wettbewerbsvorteil mit Potenzial » Mehr erfahren