Schnittstellen eines Shopsystems prüfen: ERP, Versand, Zahlung
Kurz gesagt
Welche Schnittstellen zwingend sind, ergibt sich aus Ihrem Prozess und nicht aus einer Liste im Angebot: Jeder Arbeitsschritt, der Daten in einem zweiten System verändert, braucht eine Verbindung. Prüfen Sie jede Verbindung einzeln auf einem Testsystem, mit eigenen Testdaten und Fehlerfällen, und achten Sie auf vollständige Übertragung, wiederholbare Zustellung und eine Meldung, wenn ein Lauf stillsteht.
Das Wichtigste
- Zwingend ist eine Verbindung, wenn Ihr Prozess ohne sie eine Angabe zweimal erfasst; welche Systeme das sind, gibt Ihr Ablauf vor.
- Jede Verbindung gehört vor dem Livegang auf ein Testsystem, mit eigenen Testdaten und Fehlerfällen.
- Nach RFC 9110 (Abschnitt 9.2.2) sind PUT, DELETE und die sicheren Methoden idempotent, also GET, HEAD, OPTIONS und TRACE; POST ist nicht generell idempotent. Dieselbe Regel richtet sich an den Absender: Er soll einen Aufruf mit einer nicht idempotenten Methode nur dann automatisch wiederholen, wenn er die Idempotenz des Vorgangs kennt oder feststellen kann, dass der ursprüngliche Aufruf nicht angewendet wurde.
- Die Klasse 4xx zeigt nach RFC 9110 an, dass der Aufrufer einen Fehler gemacht zu haben scheint, 5xx, dass der Empfänger nach eigener Kenntnis gescheitert ist (Abschnitte 15.5 und 15.6); welche Ursache vorliegt, sagt erst der einzelne Statuscode.
- Eine Datei nach der OpenAPI Specification beschreibt eine HTTP-Schnittstelle maschinenlesbar; aktuelle Ausgabe ist Version 3.2.1.
- Die BSI-Richtlinie TR-02102-2 (Version 2026-01) empfiehlt TLS 1.3 bevorzugt und TLS 1.2 nur noch bis Ende 2031.
Ein Shop tauscht an mehreren Stellen Daten mit anderen Systemen aus. Jede dieser Stellen lässt sich abnehmen oder dem Zufall überlassen: Der Unterschied liegt darin, ob Sie sie vor dem Livegang mit eigenen Testdaten durchgespielt haben.
Worum es bei der Auswahl geht
Eine Schnittstelle ist hier jede geregelte Übergabe von Daten zwischen dem Shop und einem anderen System: Bestellungen in eine Warenwirtschaft, Sendungsdaten zum Versand, Zahlungsstatus zurück in den Shop, Produktdaten aus einem PIM und Angebote zu einem Marktplatz. Welche Verbindungen nötig sind, gibt Ihr Ablauf vor: Wo ein Arbeitsschritt Daten in einem zweiten System verändert, braucht er eine Verbindung, sonst pflegen Sie dieselben Werte an zwei Stellen.
Der Artikel nennt keine Anbieter und keine Preise. Er liefert eine Prüfliste je System, ein Vorgehen zur Abnahme und die Posten, die in ein Angebot gehören. Die technischen Arten solcher Verbindungen behandelt Schnittstellenarten im Shop-Umfeld; die Systemwahl selbst steht unter Shopsystem auswählen.
Diese Kriterien zählen
Jede Zeile lässt sich ohne Mitwirkung des Anbieters prüfen. Die letzte Spalte gehört als Frage ins Angebot oder ins Lastenheft (Lastenheft).
| Kriterium | Warum es zählt | So prüfen Sie es | Frage an den Anbieter |
|---|---|---|---|
| Beschreibung | Ohne sie wird jedes neue Feld zur Handarbeit | Vergleichen Sie die Beschreibung mit einem echten Aufruf | Gibt es eine maschinenlesbare Beschreibung mit Versionsnummer? |
| Feldumfang | Was fehlt, tragen Sie doppelt ein | Legen Sie Ihre Feldliste neben die Beschreibung | Welche Felder sind Pflicht, welche optional? |
| Richtung und Takt | Ziehen im Intervall und Zustellen je Ereignis haben verschiedene Verzögerungen | Messen Sie die Dauer bis zum Zielsystem | Wer stößt an, in welchem Takt? |
| Stabile Kennungen | Ohne Kennung ist eine doppelte Lieferung nicht erkennbar | Verfolgen Sie eine Bestellnummer durch alle Systeme; bei Ereignismeldungen gilt die Kombination aus Quelle und Kennung als eindeutig (CloudEvents) | Welche Kennung bleibt über die Systeme gleich? |
| Wiederholte Zustellung | Nach einem Abbruch sendet der Absender erneut | Senden Sie denselben Vorgang zweimal | Was passiert bei einer zweiten Sendung? |
| Fehlermeldung | Freier Text trägt keine Automatik; RFC 9457 beschreibt maschinenlesbare Fehlerangaben für Programmschnittstellen | Lösen Sie einen ungültigen Datensatz aus und lesen Sie die Fehlerantwort | Wird der Fehler maschinenlesbar mit Kennung gemeldet? |
| Zeitstempel | Ohne Zonenangabe ist die Reihenfolge mehrdeutig; das Format aus RFC 3339 trägt eine Zonenangabe (Z oder Abweichung) | Vergleichen Sie Quell- und Zielzeit | In welchem Format und mit welcher Zone kommen Zeiten an? |
| Grenzen und Drosselung | Eine harte Sperre hält den Abgleich an | Fragen Sie nach dem Limit und fahren Sie es an | Was passiert bei Überschreitung, gibt es eine Wartezeit-Angabe? |
| Zugang | Ein Inhaber-Schlüssel gilt für jeden, der ihn kennt (RFC 6750); er gehört deshalb in eine sichere Ablage | Prüfen Sie Erneuerung und Entzug von Schlüsseln | Wer darf mit welcher Rolle welche Felder sehen? |
| Verschlüsselung | Die Verbindung trägt Bestell- und Kundendaten; die BSI-Richtlinie TR-02102-2 (Version 2026-01) empfiehlt TLS 1.3 bevorzugt | Prüfen Sie die ausgehandelte TLS-Version | Welche TLS-Versionen sind aktiv? |
| Vollständigkeit | Ein halber Abgleich fällt im Alltag nicht auf; seitenweise Abrufe können die nächste Seite im Link-Header mitteilen (RFC 8288) | Vergleichen Sie Zeilenzahl und Summe nach jedem Lauf | Woran erkenne ich einen vollständigen Abruf? |
| Änderungen | Ein umbenanntes Feld bricht den Abgleich ohne Vorwarnung | Fragen Sie nach der Änderungshistorie | Wie lange vorher werden Änderungen angekündigt? |
| Testsystem | Ohne Testsystem wird im laufenden Betrieb getestet | Fordern Sie den Zugang vor der Abnahme | Wie wird das Testsystem zurückgesetzt? |
| Überwachung | Ein Stillstand ohne Meldung bleibt bis zur Rechnung unentdeckt | Lösen Sie einen Ausfall aus | Wer meldet den Ausfall, und wo sehe ich ihn? |
Checkliste je System: Was übertragen wird und was Sie testen
Die folgenden Tabellen sind die Prüfliste nach System. „Shop → Ziel” heißt, der Shop sendet, „Ziel → Shop” heißt, das Fremdsystem sendet. Halten Sie je Zeile das sichtbare Ergebnis fest; getestet wird auf einem Testsystem.
ERP und Warenwirtschaft
| Datensatz | Richtung | Testschritt | Bestanden, wenn |
|---|---|---|---|
| Bestellung | Shop → ERP | Bestellung mit zwei Positionen auslösen, eine mit Menge 10 und einem Sonderzeichen im Namen | Ein Beleg im ERP, alle Positionen vorhanden, Summen gleich |
| Rechnungsdaten | ERP → Kundenkonto | Rechnung im ERP erzeugen und im Kundenkonto anzeigen | Belegnummer, Datum, Positionen und Steuerbetrag erscheinen; bei B2B-Rechnungen steht auf der Prüfliste, ob die Beschreibung die Felder des europäischen Datenmodells (EN 16931-1:2017) abdeckt |
| Storno und Gutschrift | Shop → ERP | Retoure auslösen und Wareneingang buchen | Genau eine Gutschrift, kein zweiter Beleg, Bestand korrigiert |
| Bestand und Preis | ERP → Shop | Bestand auf 0 setzen und einen Preis ändern | Artikel nicht mehr bestellbar, neuer Preis sichtbar; Verzögerung in Minuten notiert |
Versand und Zustellung
| Datensatz | Richtung | Testschritt | Bestanden, wenn |
|---|---|---|---|
| Sendung und Etikett | Shop → Versand | Bestellung mit drei Positionen übergeben | Eine Sendungskennung je Paket, sichtbar an der Bestellung im Shop |
| Statusmeldungen | Versand → Shop | Sendung durch die Stationen führen | Statuswechsel kommen in richtiger Reihenfolge; eine zweite gleiche Meldung ändert nichts |
| Teilversand | Shop → Versand | Bestellung in zwei Sendungen teilen | Zwei Kennungen, Restmenge stimmt, beide Sendungen sichtbar |
| Retoure | Versand → Shop | Rücklieferung auslösen | Retoure steht an der Bestellung; ob der Bestand sofort oder nach Eingang steigt, sagt die Beschreibung |
Zahlung
| Datensatz | Richtung | Testschritt | Bestanden, wenn |
|---|---|---|---|
| Autorisierung | Shop → Zahlungsdienstleister | Zahlung einmal erfolgreich, einmal abgelehnt auslösen | Bei Ablehnung bleibt die Bestellung unbezahlt, ein zweiter Versuch ist möglich |
| Statusmeldung | Zahlungsdienstleister → Shop | Dieselbe Statusmeldung zweimal senden | Die Bestellung gilt einmal als bezahlt; eine eigene Kennung je Vorgang macht die Dopplung erkennbar |
| Authentifizierung | Shop ↔ Zahlungsdienstleister | Zahlung im Authentifizierungsschritt abbrechen | Der Abbruch kommt als eigener Zustand, nicht als allgemeiner Fehler (SCA und 3-D Secure) |
| Erstattung | Shop → Zahlungsdienstleister | Einen Teilbetrag erstatten | Genau eine Erstattung, Betrag und Bestellbezug stimmen |
| Abrechnung | Zahlungsdienstleister → Buchhaltung | Tagesumsatz gegen die Abrechnung stellen | Gebühren und Umsatz getrennt, jede Auszahlung einem Zeitraum zuordenbar (Zahlungsgebühren berechnen) |
Eingehende Statusmeldungen sollten ihre Herkunft belegen: RFC 9421 beschreibt Signaturen und Nachrichten-Authentifizierungscodes über Teile einer HTTP-Nachricht.
PIM und Produktdaten
| Datensatz | Richtung | Testschritt | Bestanden, wenn |
|---|---|---|---|
| Artikelstamm | PIM → Shop | 200 Artikel übertragen, darunter Umlaute, Anführungszeichen, lange Namen | Alle Datensätze kommen an, keiner doppelt, Pflichtfelder gefüllt |
| Varianten und Bilder | PIM → Shop | Artikel mit drei Varianten und fünf Bildern anlegen | Varianten bestellbar, Bildadressen bleiben über Tage gleich |
| Änderung | PIM → Shop | Preis und Beschreibung ändern | Die Änderung kommt an, ohne den ganzen Katalog zu übertragen |
| Deaktivierung | PIM → Shop | Artikel deaktivieren, dann löschen | Der Artikel verschwindet aus dem Katalog, bleibt in bestehenden Bestellungen |
| Fehlerfall | PIM → Shop | Artikel ohne Pflichtfeld senden | Klare Fehlermeldung mit Kennung, kein halb übernommener Artikel |
Marktplatz
| Datensatz | Richtung | Testschritt | Bestanden, wenn |
|---|---|---|---|
| Angebot und Preis | Shop → Marktplatz | Preis eines Artikels ändern | Der Kanal zeigt den neuen Preis innerhalb der vereinbarten Verzögerung |
| Bestand | Shop → Marktplatz | Bestand ändern und die Übertragung protokollieren | Kanalstand folgt dem Shop; die Verzögerung steht im Protokoll |
| Bestellung | Marktplatz → Shop | Bestellung im Kanal auslösen | Bestellung einmal im Shop, mit Kanalkennung und Kanalnummer |
| Storno und Retoure | Marktplatz → Shop | Kunde storniert im Kanal, Retoure anlegen | Storno und Retoure stehen im Shop, Bestand und Zahlungsstatus folgen |
| Abrechnung | Marktplatz → Buchhaltung | Auszahlung gegen die Bestellungen prüfen | Gebühren, Erstattungen und Umsatz getrennt ausgewiesen |
Ob ein Kanal oder eine Warenwirtschaft überhaupt passt, klären Marktplatz-Anbindung und Warenwirtschaft auswählen.
Bei Dateiaustausch gehören Trennzeichen, Kodierung und Zeilenende in die Prüfliste. RFC 4180 beschreibt das CSV-Format und registriert den Medientyp text/csv; der Text ist informativ und dokumentiert nach eigener Angabe die Umsetzung, der die meisten Implementierungen zu folgen scheinen, statt eine formale Spezifikation zu setzen.
So prüfen Sie in acht Schritten
- Schreiben Sie die Anforderung als Feldliste: Feld, Datentyp, Pflicht oder optional, Richtung, Takt, Menge je Tag.
- Fordern Sie die Unterlagen an: Beschreibung mit Versionsnummer, Beispielnachrichten, Verzeichnis der Fehlerarten, Änderungshistorie und Zugang zum Testsystem.
- Wählen Sie die Testdaten selbst, mindestens 200 Datensätze, und nehmen Sie Sonderfälle auf: Umlaute, Anführungszeichen, Menge 0, Höchstmenge, Adresse ohne Zusatz, Bestellung mit 30 Positionen.
- Gleichen Sie nach jedem Lauf ab: Zeilenzahl und Summen in Quell- und Zielsystem, jeder Datensatz genau einmal.
- Fahren Sie die Fehlerfälle: falscher Zugang, Abbruch mitten im Lauf, Zeitüberschreitung, ungültiger Pflichtwert, doppelte Nachricht. Die Klasse 4xx deutet nach RFC 9110 darauf hin, dass der Aufrufer einen Fehler gemacht zu haben scheint, 5xx darauf, dass der Empfänger nach eigener Kenntnis gescheitert ist; die Ursache trägt der einzelne Statuscode, eine 429-Antwort steht für eine Mengenbegrenzung (RFC 6585, Abschnitt 4), eine 503-Antwort kann eine Wartezeit nennen (RFC 9110, Abschnitt 10.2.3).
- Wiederholen Sie eine Sendung: dieselbe Nachricht zweimal senden, im Zielsystem zählen. Nach RFC 9110 (Abschnitt 9.2.2) sind PUT, DELETE und die sicheren Methoden idempotent, also GET, HEAD, OPTIONS und TRACE; POST ist nicht generell idempotent. Die Regel für die Wiederholung richtet sich an den Absender und an automatische Wiederholungen: Er soll einen Aufruf mit einer nicht idempotenten Methode nicht automatisch wiederholen, es sei denn, er weiß, dass die Semantik des Vorgangs tatsächlich idempotent ist, oder er kann feststellen, dass der ursprüngliche Aufruf nie angewendet wurde. Dass der Empfänger den Vorgang kennt, genügt dafür nicht.
- Messen Sie die Dauer bis zum Zielsystem und das Verhalten nach zwei Stunden Ausfall des Ziels: Warteschlange oder Nachlieferung, oder ist die Nachricht verloren?
- Halten Sie die Abnahme schriftlich fest: Datum, Version der Beschreibung, Ergebnis je Zeile der Prüfliste, offene Punkte, Laufzeit der Testumgebung. Für den Weg in den Regelbetrieb passt Pilotbetrieb.
Was die Kosten bestimmt
Vier Posten entscheiden über die Kosten einer Verbindung: Einrichtung einmalig, Betrieb je Jahr, eine Gebühr je Vorgang und Stunden für Änderungen. Lassen Sie jeden Posten einzeln nennen; eine Gebühr je Vorgang wirkt erst mit dem Volumen, ein Pauschalpreis verdeckt genau den Posten, der mit Ihrem Wachstum steigt.
Beispielrechnung mit erfundenen Beträgen, netto, für einen Shop mit 2.000 Bestellungen im Monat und drei Verbindungen:
| Posten | Rechnung | Betrag im ersten Jahr |
|---|---|---|
| Einrichtung, drei Systeme | 3 × 2.500 Euro | 7.500,00 Euro |
| Gebühr je Bestellung | 24.000 × 0,03 Euro | 720,00 Euro |
| Änderungen, sechs Stunden | 6 × 120 Euro | 720,00 Euro |
| Überwachung, zwölf Monate | 12 × 50 Euro | 600,00 Euro |
| Summe erstes Jahr | 9.540,00 Euro |
Die Beträge sind erfunden und ersetzen kein Angebot. Die Annahme für das zweite Jahr: Die Einrichtung fällt einmalig weg; wie sich Betrieb, Vorgangsgebühr und Änderungsstunden dann entwickeln, ist für dieses Beispiel offen und keine allgemeine Regel. Lassen Sie beide Posten im Angebot getrennt je Jahr ausweisen, statt sie zu schätzen. Wie sich solche Posten neben Lizenzen und Transaktionsgebühren in die Gesamtrechnung einfügen, steht unter Gesamtkosten eines Shopsystems.
Warnsignale in Angebot und Vertrag
- Es gibt nur Fließtext, keine maschinenlesbare Beschreibung und keine Beispielnachrichten.
- Die Beschreibung hat keine Versionsnummer und keine Änderungshistorie.
- Ein Testsystem fehlt oder ist nur gegen Aufpreis zu haben.
- Fehler kommen als freier Text, ohne Kennung und ohne Verzeichnis der Fehlerarten.
- Eine zweite Zustellung derselben Nachricht erzeugt im Zielsystem einen zweiten Datensatz.
- Zur Drosselung fehlt jede Angabe, oder das Limit liegt unter Ihrer Spitzenlast am Aktionstag.
- Niemand meldet, wenn ein Abruf unvollständig war oder ganz ausblieb.
- Für den Wechsel des Anbieters ist weder ein Export Ihrer Daten noch eine Feldliste zugesagt.
- Die Frist, in der Änderungen angekündigt werden, ist kürzer als Ihr Testlauf; die Reaktionszeit im Störungsfall steht in keinem Dokument.
Welche Kriterien für welchen Betrieb
Die Zuordnung ist eine redaktionelle Einschätzung: Sie sagt, welche Zeilen bei einem Betrieb schwerer wiegen, und nichts über Anbieter aus.
| Betrieb oder Vorhaben | Was schwerer wiegt |
|---|---|
| Ein Kanal, wenige Bestellungen im Monat, Buchhaltung außer Haus | Ein Dateiexport je Woche kann genügen; prüfen Sie Kennungen, Vollständigkeit und Sonderzeichen |
| Eigenes Lager mit Warenwirtschaft | Bestand und Preis in beiden Richtungen; die Verzögerung ist das Vergleichsmaß |
| B2B mit Rechnungen aus dem ERP | Positionsgenauigkeit und Rechnungsfelder; testen Sie Teillieferung und Gutschrift |
| Mehrere Kanäle mit demselben Bestand | Takt der Bestandsführung je Kanal und die Frage, wer bei Überverkauf ausgleicht |
| Hohe Retourenquote | Retoure, Erstattung und Storno über alle Systeme, je Fall ein eigener Test |
| Kauf auf Rechnung oder Ratenzahlung | Statusmeldungen und Erstattungen, dazu der Abbruch der Authentifizierung |
Ob ein Abgleich vollständig gelaufen ist, lässt sich nur in jedem einzelnen Lauf prüfen. Welche Fehlerbilder dabei auftreten und welche Schwelle eine Meldung auslösen sollte, beschreibt Datensynchronisation: Fehler vermeiden.