Für wen diese Seite gedacht ist
Wenn Sie ein fertiges Modul in einen Standardshop einspielen, brauchen Sie diese Seite nicht. Sie ist für die Fälle gedacht, in denen selbst gebaut wird: ein Shop mit angepasstem Bezahlvorgang, eine Fachanwendung mit eigener Rechnungsstellung, ein Buchungssystem, eine App. Agenturen finden hier die Punkte, die erfahrungsgemäß in der Abnahme auffallen.
Vorweg eine Einordnung, die Zeit spart: Je weiter Sie sich von der gehosteten Bezahlseite entfernen, desto mehr Verantwortung übernehmen Sie — nicht nur technisch, sondern auch für den Nachweis der Kartendatensicherheit. Ein selbst gebautes Formular, das Kartendaten über den eigenen Server schickt, ist eine andere Hausnummer als eine eingebettete Komponente. Diese Entscheidung sollte am Anfang des Projekts stehen, nicht am Ende.
Konkrete Endpunkte, Feldnamen und Zugangsdaten bekommen Sie mit dem Zugang zur Testumgebung. Was hier steht, ist das, was unabhängig vom konkreten Abwickler gilt.
Was Sie je Integrationsweg selbst bauen
Dieselbe Zahlung, vier Bauformen — mit sehr unterschiedlichem Umfang an Eigenleistung.
| Integrationsweg | Liefert der Abwickler | Bauen Sie selbst | Selbstauskunft |
|---|---|---|---|
| Fertiges Shopmodul | Modul samt Statuslogik und Erstattungen | Einstellungen und Abnahmetests | einfachste Stufe |
| Gehostete Bezahlseite | Bezahlseite, Authentifizierung, Zahlartenauswahl | Anlage der Zahlung, Rücksprungadressen, Statusverarbeitung | einfachste Stufe |
| Eingebettete Komponenten | abgeschirmte Eingabefelder und Bezahllogik | Einbettung, Layout, Fehleranzeige, Statusverarbeitung | einfach bis mittel |
| Direktanbindung | Schnittstelle und Dokumentation | Formular, Authentifizierungsablauf, Fehlerbehandlung, Datenschutz und Absicherung | vollständiger Fragebogen |
Die Einstufung zur Selbstauskunft ist eine Orientierung, keine verbindliche Klassifizierung. Verbindlich ist die Einschätzung durch einen qualifizierten Prüfer auf Basis Ihrer tatsächlichen Umsetzung.
Testumgebung und Testdaten
Vor dem Echtbetrieb wird gegen eine getrennte Testumgebung entwickelt. Sie hat eigene Zugangsdaten, eigene Adressen und eigene Kennungen. Der häufigste Fehler beim Livegang ist, dass irgendwo noch ein Testzugang oder eine Testadresse steht — deshalb gehören diese Werte in die Umgebungskonfiguration und nicht in den Quelltext.
In der Testumgebung stehen Testkarten bereit, mit denen sich Ergebnisse gezielt auslösen lassen: erfolgreiche Zahlung, Ablehnung durch die Bank, Ablehnung wegen fehlender Deckung, Rückfrage bei der Authentifizierung, Zeitüberschreitung. Bauen Sie für jeden dieser Fälle einen Testdurchlauf, nicht nur für den Erfolgsfall. Der Erfolgsfall ist der einzige, der sich später von selbst meldet.
Eine Regel ohne Ausnahme: Echte Kartendaten haben in einem Testsystem nichts zu suchen. Auch nicht die eigene Karte, auch nicht kurz zum Ausprobieren. Testsysteme sind schlechter abgesichert, werden häufiger kopiert und landen regelmäßig in Sicherungen, an die niemand mehr denkt. Wer echte Daten hineinträgt, zieht sein Testsystem in den Geltungsbereich des Kartensicherheitsstandards.
Das Statusmodell einer Zahlung
Fast alle Abwickler bilden dieselben Zustände ab, nur mit unterschiedlichen Bezeichnungen. Wer sein eigenes Bestellmodell an diesen Zuständen ausrichtet, spart sich später Sonderfälle.
| Zustand | Was passiert ist | Was Ihr System tun sollte |
|---|---|---|
| Angelegt | Die Zahlung ist erzeugt, der Kunde hat noch nichts getan. | Bestellung als unbezahlt führen, keine Ware reservieren, die Sie nicht halten können. |
| Autorisiert | Die Bank hat den Betrag freigegeben und auf der Karte geblockt. | Bestellung annehmen, Kommissionierung starten; Geld ist noch nicht geflossen. |
| Gebucht | Der Betrag wurde endgültig belastet. | Als bezahlt verbuchen, Rechnung erzeugen, Versand freigeben. |
| Storniert | Die Autorisierung wurde vor der Buchung aufgehoben. | Bestellung schließen, Reservierung freigeben, Kunden informieren. |
| Erstattet | Ein gebuchter Betrag wurde ganz oder teilweise zurückgezahlt. | Teilbeträge sauber zuordnen; mehrere Teilerstattungen zu einer Zahlung müssen möglich sein. |
| Fehlgeschlagen | Die Bank hat abgelehnt oder der Vorgang lief in eine Zeitüberschreitung. | Warenkorb erhalten, erneuten Versuch ermöglichen, den Grund nicht im Detail anzeigen. |
| Zurückbelastet | Der Karteninhaber hat die Zahlung reklamiert. | Vorgang kennzeichnen, Nachweise bereitstellen, Fristen überwachen. |
Die Fehlerfälle, die man beim ersten Mal übersieht
Diese sieben Punkte tauchen in fast jedem Abnahmegespräch auf. Wer sie vorher abarbeitet, spart die zweite Runde.
- 01Doppelte Absendung
- Kunden drücken zweimal auf den Knopf, Browser wiederholen Anfragen, Netzwerke liefern verspätet. Jede Anfrage, die Geld bewegt, braucht einen eindeutigen Schlüssel, damit dieselbe Anfrage nicht zweimal ausgeführt wird. Das ist kein Feinschliff, sondern die Voraussetzung dafür, dass niemand doppelt belastet wird.
- 02Zeitüberschreitung ohne Antwort
- Der schlimmste Fall ist nicht die Ablehnung, sondern die ausbleibende Antwort. Sie wissen dann nicht, ob die Zahlung durchging. Lösen Sie das über eine gezielte Nachfrage zum Status anhand Ihrer eigenen Referenz, nicht durch einen zweiten Zahlungsversuch.
- 03Der Kunde kommt nicht zurück
- Fenster geschlossen, App abgestürzt, Verbindung weg. Die Rückkehr des Kunden ist ein Komfortmerkmal, kein Ereignis, auf das Sie sich verlassen dürfen. Maßgeblich ist immer die Serverbenachrichtigung.
- 04Benachrichtigungen kommen mehrfach oder in falscher Reihenfolge
- Statusmeldungen können wiederholt zugestellt werden, und sie können in anderer Reihenfolge eintreffen, als sie entstanden sind. Verarbeiten Sie sie deshalb idempotent und prüfen Sie den Zeitstempel, bevor Sie einen späteren Zustand durch einen früheren überschreiben.
- 05Beträge und Währungen
- Beträge werden in der Regel in der kleinsten Einheit übertragen. Rundungsfehler entstehen fast immer beim Umrechnen von Fließkommazahlen. Rechnen Sie in ganzen Zahlen und prüfen Sie den übergebenen Betrag gegen den Warenkorb, bevor Sie die Zahlung anlegen.
- 06Teilerstattung und Teillieferung
- Ein Kunde bestellt drei Artikel, einer geht zurück, einer kommt später. Ihr Modell muss mehrere Buchungen und mehrere Erstattungen zu einer Zahlung abbilden. Wer nur den Alles-oder-nichts-Fall baut, baut spätestens beim ersten Retourenlauf nach.
- 07Fehlermeldungen für den Kunden
- Der Kunde braucht eine verständliche Aussage und einen Weg weiter. Der genaue Ablehnungsgrund der Bank gehört nicht auf den Bildschirm — er hilft dem ehrlichen Kunden nicht und dem unehrlichen sehr. In Ihre Protokolle gehört er sehr wohl.
Serverbenachrichtigungen richtig absichern
Die verlässliche Quelle für den Zahlungsstatus ist nicht der zurückkehrende Browser, sondern die Benachrichtigung, die der Abwickler an einen Endpunkt Ihres Servers schickt. Dieser Endpunkt ist öffentlich erreichbar und muss entsprechend behandelt werden: Signatur oder Kennung prüfen, bevor irgendetwas verarbeitet wird, und niemals allein aufgrund des Inhalts einer eingehenden Nachricht Geld oder Ware freigeben.
Antworten Sie schnell und verarbeiten Sie langsam. Nehmen Sie die Nachricht entgegen, bestätigen Sie den Empfang und legen Sie die eigentliche Verarbeitung in eine Warteschlange. Andernfalls laufen Sie bei Lastspitzen in Zeitüberschreitungen, und der Abwickler wiederholt die Zustellung — was die Last weiter erhöht.
Planen Sie außerdem den Ausfall ein. Ist Ihr Endpunkt eine Stunde nicht erreichbar, werden Benachrichtigungen in der Regel wiederholt, aber nicht unbegrenzt. Ein regelmäßiger Abgleich, der offene Zahlungen aktiv nachfragt, fängt die Fälle auf, die sonst als bezahlt-aber-nicht-verbucht liegen bleiben.
Checkliste vor dem Livegang
Abzuarbeiten, bevor der erste echte Kunde bezahlt — nicht danach.
- 01Alle Zustände getestet
- Erfolg, Ablehnung, Abbruch, Zeitüberschreitung, Rückfrage bei der Authentifizierung, Storno, vollständige und teilweise Erstattung. Jeweils mit Blick darauf, welchen Bestellstatus Ihr System daraus macht.
- 02Zugangsdaten getrennt
- Test und Echtbetrieb sauber getrennt, keine Zugangsdaten im Quelltext, kein Testschlüssel in der Konfiguration des Echtsystems.
- 03Protokolle ohne Kartendaten
- Prüfen Sie Ihre Protokolle und Fehlerberichte darauf, dass keine Kartennummern und keine Prüfziffern gespeichert werden. Fehlerberichtssysteme protokollieren gern ganze Formularinhalte mit.
- 04Bezeichnung auf dem Kontoauszug
- Der Text, den der Kunde auf seinem Kontoauszug sieht, muss zu Ihrem Firmennamen passen. Eine unverständliche Bezeichnung ist eine der häufigsten Ursachen für vermeidbare Rückbelastungen.
- 05Abgleich eingerichtet
- Ein täglicher Vergleich zwischen Bestellungen im System und Zahlungen beim Abwickler. Ohne diesen Abgleich merken Sie Differenzen erst am Monatsende.
- 06Zuständigkeit geklärt
- Wer bekommt die Meldung, wenn eine Zahlung hängt, und wer bearbeitet eine Rückbelastung innerhalb der Antwortfrist? Diese Frage gehört vor den Livegang, nicht in den ersten Streitfall.
Häufige Fragen aus der Umsetzung
Wie bekomme ich Zugang zur Testumgebung?
Über uns, in der Regel vor Vertragsabschluss, damit Sie den Aufwand einschätzen können. Sie erhalten Zugangsdaten, Dokumentation und Testkarten. Sagen Sie uns vorher, welches System und welche Zahlarten geplant sind, damit die richtige Konfiguration bereitsteht.
Kann ich Kartendaten selbst speichern, um Folgezahlungen auszulösen?
Möglich ja, sinnvoll fast nie. Der übliche Weg ist, die Karte beim Abwickler zu hinterlegen und mit einem Platzhalter zu arbeiten. Damit bleiben Sie im einfachen Nachweisverfahren und haben im Fall eines Einbruchs nichts Verwertbares gespeichert.
Was ist mit Zahlungen aus einer mobilen App?
Der Ablauf entspricht dem im Browser, nur wird der Bezahlvorgang in einer abgesicherten Ansicht innerhalb der App dargestellt. Die Authentifizierung kann dabei die Banking-App des Kunden öffnen; die Rückkehr in Ihre App muss zuverlässig funktionieren und sollte auf beiden Betriebssystemen getestet werden.
Wie gehe ich mit Vorautorisierungen um, die lange offen bleiben?
Autorisierungen haben eine begrenzte Haltbarkeit, die von Kartensystem und Kartenart abhängt. Läuft sie ab, ist der Betrag nicht mehr gesichert. Für lange Vorläufe — Fertigung, Vorbestellung, Buchung mit weitem Vorlauf — braucht es deshalb ein bewusst gewähltes Modell. Das besprechen wir am konkreten Fall.
Brauche ich für die Anbindung eine eigene Verschlüsselung?
Die Übertragung ist ohnehin verschlüsselt. Was Sie brauchen, ist eine saubere Verwaltung Ihrer Zugangsdaten, geprüfte Signaturen bei eingehenden Benachrichtigungen und ein Rechteverfahren, das nicht jedem Mitarbeiter Erstattungen erlaubt.
Wie teste ich die Authentifizierung, ohne eine echte Bank-App zu haben?
In der Testumgebung gibt es Karten, die gezielt eine Rückfrage auslösen und eine simulierte Bestätigungsseite anzeigen. Damit lassen sich beide Abläufe durchspielen — mit Rückfrage und ohne. Testen Sie insbesondere den Abbruch mitten in der Rückfrage.