Zahlungen, agentischer Handel (AP2) und POS
Kartenzahlungen, agentischer Checkout und Filialen, vom Terminal bis zum Hauptbuch verbunden
Wenn Filialen, Checkouts und Hauptbuch nicht übereinstimmen
Eine Kartenzahlung berührt in wenigen Sekunden mehrere Systeme: das Terminal oder den Checkout, ein Gateway, den Acquirer, das Kartensystem und den Issuer. Geld und Gebühren kommen später in Abrechnungsdateien an, die jemand den Verkäufen in Ihrem ERP zuordnen muss.
Wenn Filialen, Online-Checkouts und ERP in nächtlichen Batches synchronisieren, wird der Bestand bei Aktionen überverkauft, und Abrechnungsdifferenzen häufen sich über mehrere Acquirer an. Der Checkout wird zu den geschäftigsten Zeiten langsam. Jetzt beginnen auch KI-Agenten, im Auftrag von Kunden zu kaufen.
Was sich für Sie ändert
Eine Sicht auf Bestand und Verkäufe
Verkäufe, Retouren, Preise und Bestand im Gleichschritt über jede Filiale, jeden Webshop und das ERP, in Echtzeit statt über Nacht.
Abrechnungen, die passen
Abrechnungs- und Gebührendateien jedes Acquirers automatisch den Verkäufen zugeordnet, mit Differenzen, die Ihrem Team aufgelistet werden.
Bereit für agentischen Handel
Ein Checkout, der Zahlungen von KI-Agenten annehmen kann, mit einem überprüfbaren Nachweis darüber, was der Kunde autorisiert hat.
Was wir liefern
Anbindung an Gateway, Acquirer und Kartennetze
Abläufe für Autorisierung, Capture, Rückerstattung und Storno über ISO 8583, ISO 20022 oder die API des Anbieters, mit Orchestrierung über mehrere Acquirer und Behandlung jedes Antwortcodes.
AP2 und Checkout mit kryptografischem Mandat
AP2 ist ein offenes Protokoll, das einen KI-Agenten im Auftrag eines Kunden bezahlen lässt. Kryptografisch signierte Mandate halten fest, was der Kunde freigegeben hat, und wir integrieren sie in Ihren Checkout.
EMV- und SoftPOS-Terminals
EMV-Chip- und Kontaktlos-Terminals sowie SoftPOS, das kontaktlose Karten auf einem gewöhnlichen Telefon oder Tablet annimmt, angebunden an Ihre POS- oder Kiosk-Software.
Automatisierte Verarbeitung von Abrechnungsdateien
Abrechnungs- und Gebührendateien der Acquirer werden gesammelt, validiert, geprüft und in Buchungen verwandelt, die Ihr ERP zuordnen kann.
Echtzeit-Synchronisierung vom POS ins ERP
Verkäufe, Retouren, Preise, Aktionen und Bestände zwischen jeder Filiale und dem ERP über eine Event-Streaming-Schicht synchronisiert.
Tokenisierung und PCI-DSS-Umfang
Kartennummern durch Token ersetzt und aus Ihrem POS und ERP herausgehalten, mit einer schriftlichen Übersicht, welche Systeme im PCI-DSS-Umfang bleiben.
Zertifizierung und Einführung
Testskripte und Nachweise für die Zertifizierung jedes Anbieters, ein Pilot in wenigen Filialen und dann eine Einführung Filiale für Filiale mit täglich verglichenen Summen.
So arbeiten wir
Einem Verkauf folgen
Wir folgen mit Ihren Finanz-, Filial- und IT-Teams einem Verkauf von der Kasse oder dem Checkout bis ins Hauptbuch und vereinbaren den Umfang.
Integration entwerfen
Wir wählen Protokolle, Tokenisierungsansatz und Nachrichtenflüsse und schreiben die Schnittstellenspezifikation.
Bauen und testen
Wir bauen die Zahlungs-, Abrechnungs- und POS-Abläufe mit automatisierten Tests, einschließlich Ablehnungen, Timeouts und Rückerstattungen.
Beim Anbieter zertifizieren
Wir führen die Testfälle des Anbieters in seiner Testumgebung aus und beheben, was seine Zertifizierung findet.
Pilot, dann Einführung
Wir gehen zuerst in wenigen Filialen oder Kanälen live, vergleichen täglich die Summen und führen dann Filiale für Filiale ein.
Überwachen und betreuen
Wir beobachten Genehmigungsraten, Abrechnungsdateien und Filialbuchungen und behandeln Anbieteränderungen, sobald sie angekündigt werden.
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).
Seitwärts scrollen, um die ganze Zeichnung zu sehen.
POS zum ERP: jeder Verkauf genau einmal verbucht
Umsätze fließen als Ereignisse von den Kassen ins ERP, Preise und Bestand fließen zurück. Eine Filiale, die offline geht, verkauft weiter und holt auf. Eine fehlgeschlagene Buchung wird wiederholt und dann an einen Menschen übergeben.
- Primärer Ablauf
- Asynchron
- Fehlerpfad
Der Ablauf in 8 Schritten
Der Ablauf Schritt für Schritt
- Von POS-Terminals nach Filial- oder POS-Cloud-Server: Umsätze, Retouren und Stornos (primärer Ablauf).
- Von Filial- oder POS-Cloud-Server nach Integrationsschicht: Umsatzereignisse und Tagesabschlüsse über eine Ereigniswarteschlange, über REST/JSON (asynchron).
- Von Integrationsschicht nach ERP: Umsätze und Bestandsbewegungen verbucht, über OData · REST/JSON (primärer Ablauf).
- Von ERP nach Integrationsschicht: Preise, Aktionen und Artikeldaten per API oder Dateiexport, über REST/JSON (primärer Ablauf).
- Von Integrationsschicht nach Filial- oder POS-Cloud-Server: Preis- und Bestandsaktualisierungen, über REST/JSON (primärer Ablauf).
- Von Integrationsschicht nach Wiederholungswarteschlange: Buchung fehlgeschlagen (Fehlerpfad).
- Von Wiederholungswarteschlange nach Integrationsschicht: Erneut versucht (Fehlerpfad).
- Von Wiederholungswarteschlange nach Filialbetriebsteam: Weiterhin fehlgeschlagen: Warnung mit den Details (Fehlerpfad).
Standards und Protokolle
Die Nennung eines Produkts oder Anbieters bedeutet keine Partnerschaft mit ihm.
- Programmiersprachen
- Go
- Frameworks
- Node.js
- Daten und Analytik
- Apache Kafka
- Datenbanken
- Redis
- DevOps und Observability
- Kubernetes
- Banking-Standards und -Kanäle
- ISO 20022
- Zahlungsverkehr
- ISO 8583
- EMV
- EMV 3-D Secure
- PCI DSS
Nachweis im Produktivbetrieb
Für eine Einzelhandels- und Mall-Gruppe mit mehreren Marken in der Golfregion haben wir nächtliche Batch-Skripte durch Echtzeit-Synchronisierung vom POS ins ERP ersetzt. Wir haben außerdem Zahlungen über mehrere Acquirer mit automatischer Abrechnung vereinheitlicht und einen Bestandsreservierungsdienst für Spitzen bei Flash-Sales gebaut.
So beginnen
Klare Anforderungen an Anbieter und Filialen gehen direkt in ein Angebot. Eine neue Zahlungsplattform oder ein agentischer Checkout beginnt meist im Blueprint Studio.
Wie es weitergeht
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.
Umsetzung in fünf Phasen
Mobilisierung, Sprints mit Live-Demonstrationen, Integration und Härtung, Abnahme und Inbetriebnahme, dann Managed Services. Nach dem Start folgt eine Gewährleistungsfrist, danach optional Support und Wartung.
KI-native Produktteams
Geführte, funktionsübergreifende Pods aus Senior-Ingenieuren, ausgestattet mit agentischen Coding- und QA-Harnesses.
Projekte mit festem Ergebnis und Managed Services rund um die Uhr
Lieferung mit festem Umfang und Meilensteinen unter benannten Delivery-Leads sowie Application Managed Services rund um die Uhr unter SLA-Governance.
Fragen und Antworten
Arbeiten Sie direkt mit ISO 8583?
Ja, wo der Acquirer oder Prozessor es anbietet. ISO 8583 ist ein Rahmenwerk, kein einheitliches Format: Jeder Acquirer veröffentlicht seine eigene Spezifikation von Feldern und Nachrichtentypen. Wir bauen nach dieser Spezifikation, behandeln Autorisierungen, Stornos und Advice-Nachrichten und testen jeden Antwortcode.
Was ist AP2, und brauchen wir es jetzt?
Das Agent Payments Protocol (AP2) ist ein offenes Protokoll für Zahlungen, die KI-Agenten ausführen. Jeder Kauf trägt signierte Mandate, die zeigen, was der Kunde autorisiert hat, sodass Händler, Issuer und Acquirer ihm trauen und es prüfen können. Wenn KI-Agenten wahrscheinlich bei Ihnen einkaufen werden, können wir Ihren Checkout neben den heutigen Abläufen AP2-fähig machen.
Wie verringern Sie unseren PCI-DSS-Umfang?
PCI DSS können wir nicht abschaffen, aber wir können verringern, auf wie viel Ihrer IT-Landschaft es zutrifft. Gehostete Zahlungsseiten, Punkt-zu-Punkt-Verschlüsselung am Terminal und Gateway-Token halten Kartennummern aus Ihrem POS, ERP und Data Warehouse heraus. Wir dokumentieren die Datenflüsse für Ihren Prüfer.
Können wir Karten auf Telefonen statt an Terminals annehmen?
Ja, mit SoftPOS. Kontaktlose Karten und Wallets werden auf einem unterstützten Telefon oder Tablet über eine zertifizierte Zahlungs-App Ihres Acquirers oder Anbieters angenommen. Wir integrieren diese App wie jedes andere Terminal in Ihre POS-, Verkaufs- und Abrechnungsabläufe.
Was geschieht, wenn eine Filiale die Verbindung verliert?
Die Filiale verkauft weiter. Verkäufe werden lokal gespeichert und bei Rückkehr der Verbindung an das ERP gesendet, jeweils mit einer eindeutigen Kennung, damit nichts doppelt gebucht wird. Ob Kartenzahlungen offline weiterlaufen können, hängt von den Regeln Ihres Acquirers und Ihrer Risikobereitschaft ab, und wir gestalten das mit Ihnen.
Behandeln Sie Rückerstattungen und Chargebacks?
Ja. Rückerstattungen und Stornos sind Teil der Zahlungsabläufe, die wir bauen. Für Chargebacks importieren wir die Dispute-Berichte des Acquirers und verknüpfen jeden mit dem ursprünglichen Verkauf und der Abrechnung. Ihr Team erhält eine Liste zum Abarbeiten, mit den Nachweisen im Anhang.
Bereit zu bauen? Fragen Sie nach einem Angebot.
Senden Sie Ihre Anforderungen oder Ausschreibung. Unsere Architekten prüfen sie und liefern ein verbindliches Angebot mit festem Umfang.
Wie es weitergeht
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.
Verbindliches Angebot
Nach Architekturvalidierung kostenfrei erhalten Sie innerhalb von 3–5 Werktagen ein verbindliches Angebot mit festem Leistungsumfang: Meilensteine, Architektur, Teamstruktur und SLAs. Wir unterzeichnen auf Wunsch eine Geheimhaltungsvereinbarung (NDA) mit Ihnen, bevor Sie Ihre Anforderungen teilen.
Mobilisierung
Sobald Sie unterzeichnen, beginnen unsere Engineering-Pods innerhalb von 5–10 Werktagen nach Vertragsunterzeichnung mit Sprint 0.
Umsetzung in fünf Phasen
Mobilisierung, Sprints mit Live-Demonstrationen, Integration und Härtung, Abnahme und Inbetriebnahme, dann Managed Services. Nach dem Start folgt eine Gewährleistungsfrist, danach optional Support und Wartung.