Kartenzahlungen
Kartenzahlungen: vom Terminal zum Acquirer und zurück ins Hauptbuch
EMV-Terminals und Zahlungsgateways, über ISO 8583 oder APIs an Acquirer angebunden, mit Abwicklungsdateien, die im ERP abgestimmt werden.
Blueprint
Seitwärts scrollen, um die ganze Zeichnung zu sehen.
Kartenzahlungen: an der Kasse autorisiert, später abgewickelt, im ERP abgestimmt
Das Terminal oder der Checkout fragt das Gateway, das Gateway fragt den Acquirer, und der Acquirer leitet an Kartennetzwerk und Kartenausgeber weiter. Abwicklungsdateien kommen später und werden im ERP Umsätzen und Gebühren zugeordnet. Eine Zeitüberschreitung löst ein Storno aus, damit der Kunde nie doppelt belastet wird.
- Primärer Ablauf
- Asynchron
- Fehlerpfad
Der Ablauf in 8 Schritten
Der Ablauf Schritt für Schritt
- Von EMV-Terminal oder Online-Checkout nach Zahlungsgateway: Autorisierungsanfrage, über EMV · REST/JSON (primärer Ablauf).
- Von Zahlungsgateway nach Acquirer: Autorisierung, über ISO 8583 (primärer Ablauf).
- Von Acquirer nach Kartennetzwerk und Kartenausgeber: An den Kartenausgeber weitergeleitet, über ISO 8583 (primärer Ablauf).
- Von Acquirer nach Zahlungsgateway: Genehmigt oder abgelehnt, über ISO 8583 (asynchron).
- Von Acquirer nach Integrationsschicht: Abwicklungs- und Gebührendateien, über SFTP (asynchron).
- Von Integrationsschicht nach ERP: Abgewickelte Umsätze, Gebühren und Auszahlungen, über REST/JSON (primärer Ablauf).
- Von Zahlungsgateway nach EMV-Terminal oder Online-Checkout: Keine rechtzeitige Antwort: automatisches Storno, über ISO 8583 0400 (Fehlerpfad).
- Von Integrationsschicht nach Zahlungsbetriebsteam: Abweichung in der Abwicklung oder Chargeback (Fehlerpfad).
Überblick
Das ist der Weg einer Kartenzahlung, vom Terminal oder Online-Checkout zum Acquirer, zum Kartennetzwerk und zum Kartenausgeber und wieder zurück. Der Kunde wartet an der Kasse auf die Antwort. Das Geld kommt später, abzüglich Gebühren, in einer Abwicklungsdatei an und muss den Umsätzen in Ihrem ERP zugeordnet werden.
Das Referenzdesign schickt Autorisierungen über ein Zahlungsgateway, das die Karte tokenisiert und die Anfrage über ISO 8583 oder die API des Acquirers an ihn weiterleitet. Abwicklungs- und Gebührendateien werden von der Integrationsschicht eingesammelt, den ursprünglichen Umsätzen zugeordnet und als Umsätze, Gebühren und Auszahlungen ins ERP gebucht.
Das Design deckt auch die Fehlerfälle ab. Eine Anfrage, die nicht rechtzeitig beantwortet wird, wird storniert, damit der Kunde nicht doppelt belastet wird. Eine Abwicklung, die nicht passt, oder ein Chargeback geht mit dem ursprünglichen Umsatz an Ihr Team für den Zahlungsbetrieb.
So funktioniert der Ablauf
Am Terminal oder im Checkout beginnen
Das EMV-Terminal liest die Chip- oder kontaktlose Karte, oder der Online-Checkout erfasst die Karte über eine gehostete Seite, und sendet eine Autorisierungsanfrage an das Gateway.
Über das Gateway autorisieren
Das Gateway ersetzt die Kartennummer durch einen Token und sendet die Autorisierung über ISO 8583 oder die API des Acquirers an ihn.
Zum Kartenausgeber weiterleiten
Der Acquirer leitet die Anfrage über das Kartennetzwerk an den Kartenausgeber weiter, der sie genehmigt oder ablehnt.
Antwort zurückgeben
Die Genehmigung oder Ablehnung kehrt denselben Weg zum Terminal oder Checkout zurück, mit ihrem Antwortcode.
Abwicklung empfangen
Der Acquirer sendet später Abwicklungs- und Gebührendateien, die die Integrationsschicht einsammelt und prüft.
Zuordnen und buchen
Die Schicht ordnet abgewickelte Transaktionen den ursprünglichen Umsätzen zu und bucht Umsätze, Gebühren und Auszahlungen ins ERP.
Wenn etwas fehlschlägt
Keine Antwort in der Zeit
Erhält das Gateway innerhalb der Zeitgrenze des Acquirers keine Antwort, sendet es eine Stornierung, eine ISO-8583-0400-Nachricht oder das API-Äquivalent, damit der Kunde nie für einen nicht abgeschlossenen Umsatz belastet wird.
Eine Zahlung wird abgelehnt
Der Antwortcode erreicht die Kasse oder den Checkout mit einer klaren Meldung. Ablehnungsquoten werden überwacht, damit ein Sprung, der auf einen technischen Fehler deutet, eine Warnung auslöst.
Abwicklung passt nicht
Ein abgewickelter Betrag, der vom Umsatz abweicht, oder ein Umsatz ohne Abwicklung geht mit beiden Datensätzen nebeneinander an eine Prüfliste für Ihr Team für den Zahlungsbetrieb.
Ein Karteninhaber beanstandet eine Zahlung
Der Dispute-Bericht des Acquirers wird importiert und mit dem ursprünglichen Umsatz und der Abwicklung verknüpft, sodass Ihr Team mit den Belegen an einer Stelle antworten kann.
Standards und Systeme
- Banking-Standards und -Kanäle
- SFTP (H2H)
- Zahlungsverkehr
- ISO 8583
- EMV
- EMV 3-D Secure
- PCI DSS
- Integration
- REST
- Webhooks
Fragen und Antworten
Was ist der Unterschied zwischen einem Gateway und einem Acquirer?
Der Acquirer ist die Bank oder lizenzierte Institution, die Kartenzahlungen für Sie abwickelt und das Geld auszahlt. Das Gateway ist der technische Dienst davor, der Anfragen von Terminals und Checkouts annimmt, Karten tokenisiert und weiterleitet. Manche Anbieter sind beides. Das Design funktioniert in beiden Fällen und hält die beiden Rollen klar getrennt.
Hält das Kartendaten aus unseren Systemen heraus?
Das ist das Ziel des Designs. Kartennummern werden vom zertifizierten Terminal oder einer gehosteten Zahlungsseite erfasst und am Gateway durch Tokens ersetzt, sodass Ihr POS, Ihr ERP und Ihre Datenspeicher nur Tokens sehen. Das verkleinert den Teil Ihrer IT-Landschaft, für den PCI DSS gilt. Ihr Prüfer bestätigt den endgültigen Umfang.
Ist ISO 8583 bei jedem Acquirer gleich?
Nein. ISO 8583 definiert eine Struktur, und jeder Acquirer oder jedes Netzwerk veröffentlicht seine eigene Spezifikation von Feldern, Nachrichtentypen und Codes. Deshalb bauen wir nach der Spezifikation des Acquirers und führen seine Zertifizierungstests durch. Eine Gateway-API vor dem Acquirer verbirgt diese Unterschiede, was für Einzelhändler oft einfacher ist.
Warum kommt die Abwicklung später als der Umsatz?
Die Autorisierung reserviert nur die Mittel. Der Acquirer wickelt in Batches ab, nach Abzug seiner Gebühren und etwaiger Netzwerkentgelte, und zahlt nach seinem eigenen Zeitplan aus. Deshalb behandelt das Design Autorisierung und Abwicklung als getrennte Ereignisse und ordnet sie einander zu, sodass Finanzen sieht, was verkauft, was abgewickelt und was noch unterwegs ist.
Unterstützen Sie EMV 3-D Secure für Onlinezahlungen?
Ja. Für Online-Kartenzahlungen integrieren wir EMV 3-D Secure über das Gateway, sodass der Kartenausgeber den Karteninhaber authentifizieren kann, wo Regulierung oder Risiko es verlangen. Wir behandeln die Challenge- und Frictionless-Flows im Checkout und testen beide mit den Testkarten des Anbieters.
Können wir mehr als einen Zahlungsanbieter nutzen?
Ja. Die Integrationsschicht hält ein internes Modell einer Zahlung und bildet es auf jeden Anbieter ab, sodass Sie nach Kanal, Land oder Kartentyp routen oder Volumen zwischen Anbietern verschieben können. Jeder Anbieter braucht weiterhin seine eigene Integration und Zertifizierung, die wir Anbieter für Anbieter planen.
Beginnen Sie mit einem Gespräch, nicht mit einem Vertrag.
Sagen Sie uns, was Sie bauen, verbinden oder absichern möchten. Ein Architekt geht es mit Ihnen durch und empfiehlt dann, wo Sie beginnen sollten.
Wie es weitergeht
Terminabstimmung
Unser Team schreibt Ihnen, um einen Termin für das Gespräch zu vereinbaren.
Beratungsvorgespräch
Ein kostenlose 30-minütige Online-Vorberatung: Wir gehen Ihre Ziele, Systeme und Rahmenbedingungen durch.
Readiness-Review
In einer kostenlose 48-stündige Readiness-Review prüft ein Principal Architect Ihr Projekt gegen die 6-Punkte-Definition of Ready und empfiehlt den passenden Track.
Wahl des Tracks
Projekte mit klarem Leistungsumfang erhalten innerhalb von 3–5 Werktagen ein verbindliches Angebot. Projekte in der Konzeptphase starten im Blueprint Studio. Ein laufendes System, das ausfällt, nicht dokumentiert ist oder integriert werden muss, beginnt mit einer Diagnose von 1–2 Wochen. Blueprint Studio und Diagnose haben jeweils ein festes Honorar, das im Angebot genannt wird.