Processing-Methoden

Als Processing-Methoden bezeichnen wir solche Methoden, die eine Transaktion gemäß Vorgabe des Clients an einen Kreditkartendienstleister senden und das Ergebnis dieser Anfrage an den Client zurückübermitteln.

Wir unterscheiden dabei zwischen reinen Autorisierungsanfragen mit und ohne Reservierung und monetären Transaktionen.

Unter den Autorisierungsanfragen unterscheiden einige Dienstleister zwischen einer Autorisierung mit und ohne Reservierung. Die erwartete XML-Struktur ist weitestgehend identisch, die Requests unterscheiden sich meist durch einen spezifischen Methoden- oder Funktionsnamen. Dasselbe gilt für die jeweils dazugehörige Zahlungsanforderung.

Monetäre Transaktionen sind solche, als deren Ergebnis Geld vom Kreditkartenkonto des Geschäftspartners abgebucht oder diesem zugebucht wird. Sie werden üblicherweise nur vom Backend-System – z.B. AVS/3 oder VHS/3 – durchgeführt, da sie einen Geldfluss auslösen und in der Buchhaltung abgebildet werden müssen. Dazu muss der betreffende Vorgang im System existieren, unter der angegebenen Referenz eindeutig identifizierbar und bebuchbar sein.

Dies kann nicht gewährleistet werden, solange z.B. der Auftrag, der bezahlt werden soll, noch nicht im System integriert ist.

Darum wird im Versandhandel in der eigentlichen Auftragsabwicklung ein zweistufiges Verfahren angewandt: Es trennt die Autorisierungsanfrage und den eigentlichen Zahlungseinzug und führt in der ersten Stufe, d.h. bei der Auftragserfassung, nur einen Autorisierungsversuch durch. Als Ergebnis einer erfolgreichen Autorisierung liegt ein Autorisierungscode in Verbindung mit einer externen Transaktions-UUID vor. In der zweiten Stufe, als Teil des Fakturprozesses oder nach der Faktur, wird die monetäre Transaktion – die Zahlungsanforderung - durchgeführt. Als Referenz dient die externe Transaktions-UUID der Autorisierungsanfrage, als Beleg für die erfolgreiche Autorisierung ist ggf. der Autorisierungscode zu übergeben.

Die Methoden für Folgetransaktionen – Rückbuchung, Guthabenauszahlung, nachgelagerte Zahlung - sind einstufige monetäre Transaktionen – sie veranlassen im Erfolgsfall unmittelbar die entsprechende Zahlung oder Rückzahlung.

Daneben bieten Kreditkarten-Zahlungsdienstleister in der Regel die Möglichkeit, eine schon getätigte Transaktion zu stornieren: Autorisierungsanfragen, solange die Zahlungsanforderung noch nicht erfolgt ist, und monetäre Transaktionen, solange die Transaktion noch nicht an die kartenausgebende Bank weiterübermittelt wurde. D. h. wo solche monetären Transaktionen vom Kreditkarten-Zahlungsdienstleister im Rahmen einer Batchverarbeitung am Ende eines Werktags ausgeführt werden, besteht am Tag der Transaktion auch noch die Möglichkeit, diese zu stornieren, sie erscheint dann nicht auf dem Kontoauszug des Karteninhabers.

Die aktuelle Version des Dokuments beschreibt zunächst die in einen externen Shop / Auftragserfassungssystem zu implementierenden Methoden.

Dies sind: Autorisierungsanfrage und Storno einer Autorisierung. Mit DSB ist vorab abzustimmen, welche Methoden eingesetzt werden sollen, damit auch in den BackendSystemen AVS/3 und VHS die entsprechenden Einstellungen durchgeführt werden können.

Die von den Zahlungsdienstleistern zur Verfügung gestellten Transaktionen werden von DSB in verschiedene Verarbeitungsarten unterteilt. Die folgende Abbildung gibt hierzu eine Übersicht:

: Bild einfügen

Alle Zahlungsvorgänge beginnen immer mit einer Starttransaktion. Je nachdem ob es sich um eine ein- oder zweistufige Transaktion handelt ist diese in sich abgeschlossen oder wird durch eine Folgetransaktion abgeschlossen.

Einstufige Start-Transaktionen sind: purchase, refund

Zweistufige Start-Transaktionen sind: authorise, preauthorise

Folge-Transaktionen sind: capture, cancel, bookback

Eine Start-Transaktionen kann mit oder ohne Kartendaten ausgeführt werden. Transaktionen ohne Kartendaten erhöhen hierbei die Sicherheit, da die Details einer Zahlkarte nicht mehr übertragen werden müssen, sondern lediglich eine Referenz-ID aus einer früheren Transaktionen, über die dann ein Rückschluss auf die tatsächlichen Zahlungs-Details gemacht werden kann.

Hierbei ist zu beachten, dass vor der ersten Start-Transaktion ohne Kartendaten (Repeating) mindestens eine Start-Transaktion vom Typ „Initial“ gemacht werden muss. In diesem Fall erhält man im Response die Referenz-ID für die späteren Transaktionen vom Typ „Repeating“.

Eine Start-Transaktion vom Typ „Single“ reicht hierzu nicht aus, da Single bedeutet, dass die Details der Zahlkarte nur für diesen einen Zahlungsvorgang verwendet werden dürfen und nicht in nachgelagerten Transaktionen vom Typ „Repeating“ erneut herangezogen werden dürfen.

Preauthorization gefolgt von einem Purchase kann in Situationen genutzt werden, in welchen zwei verschiedene Systeme in eine gemeinsame Transaktion involviert sind.

Der Shop verifiziert die Kreditkartendaten eines Kunden mit einem preauthorize(cc-process-type=INITIAL) und bekommt eine Repeating-ID zurück, welche der Shop zur weiteren Bearbeitung an das Backend System, übergibt. Der Shop muss sich nur um Fehler kümmern, die mit den übergebenen Daten in Verbindung stehen. Fehlerzustände, welche eine manuelle Bearbeitung fordern, können vom Shop ignoriert werden, da diese vom Backend-System behandelt werden sollten.

Das Backend-System fragt entweder die cc-repeating-transaction-id ab, hat diese Repeating-ID schon oder kann sie mittels der cc-dsb-transaction-id mit der Methode getCardTransactionByDsbID, abfragen. Der Purchase autorisiert und sichert den gegebenen Betrag.

Bei auftretenden Fehlern, entscheidet das Backend-System, wie der Fehler behandelt werden soll. Sollte zum Beispiel ein manuelles eingreifen/überprüfen erforderlich sein, hat das Backend-System die Pflicht die Transaktion an eine verantwortliche Person weiter zu leiten.

Wenn man diesen Arbeitsablauf benutzt, braucht das Backend-System keine Kreditkartendaten und braucht sich nicht um eine erfolgreiche Zertifizierung sorgen. Bei dem Shop muss man sichergehen, dass die Kreditkartendaten im Rahmen der PCI-Richtlinien behandelt werden.

Um dieses Vorgehen noch sicherer zu gestalten, kann der Shop eine indirekte „Pre-Authorization“ über die Bestellseite des Zahlungsdienstleisters tätigen. In dem Fall würde der Shop einen „Notify-Request ( siehe Abschnitt 2.4 ) mit den Details abschicken, die vom Backend-System für einen späteren Kauf benötigt werden. In diesem Fall würde kein Teilnehmer außer dem Zahlungsdienstleister einen Kontakt mit den Kreditkartendaten des Kunden haben ( hohe Erfüllung des PCI-Standards). In diesem Fall würde der gesamte Kaufvorgang mit einer cc-repeating-transaction-id laufen.

Zu bedenken ist, dass einige Backend-Systeme eine maskierte Kreditkartennummer benötigen um den Endkunden zu identifizieren und mit ihm zu kommunizieren.

In diesem Fall ist der Shop für die Autorisierung des benötigten Betrags zuständig. Das Backend-System ist für die Sicherung in Höhe des Betrags oder weniger verantwortlich ( das Backend-System kann nicht mehr als die Höhe des „Authorized“ sichern ). Einige Dienstleister erlauben Multiple-Capture über eine Autorisierung, solang der Gesamtbetrag gleich groß, oder kleiner als die Autorisierung ist. Es wird empfohlen nicht auf diese Funktionalität zu vertrauen, da sie die Unabhängigkeit des Codings gefährdet.

Das Backend-System muss eine Referenz auf die vorhergehende Autorisierung haben. In diesem Fall gibt es eine cc-external-transaction-id und ein cc-external-transaction-token. Einige Zahlungsdienste liefern nur eine ID, um die Unabhängigkeit von Zahlungsdiensten zu sichern, müssen aber beide abgespeichert werden. Die cc-dsb-transaction-id kann benutzt werden, um diese Informationen mit der Methode getCardTransactionByDsbID, abzurufen.

Der Shop sendet eine Autorisierung. Wenn ein Fehler während der Autorisierung auftaucht, muss der Shop über das weitere Vorgehen entscheiden. Zum Beispiel bei dem Fall, dass eine manuelles Nachbearbeitung/Prüfung notwendig ist. Das ShopSystem hat die Pflicht die Transaktion an eine verantwortliche Person weiter zu leiten. Nach einer manuellen Nachbearbeitung kann der Auftrag zur weiteren Bearbeitung an das Backend-System übergeben werden.

Das Backend-System sollte technische Exceptions von der API behandeln können wie zum Beispiel „CP30050000“, „Timeout(Timeoutsignal vom Zahlungszugang oder einem anderen System)“ Diese benötigen möglicherweise manuelle Nachbearbeitung.

Auch bei diesem Arbeitsablauf braucht das Backend-System keine Kreditkartendaten und braucht sich somit nicht um eine erfolgreiche Zertifizierung kümmern. Der Shop braucht ebenso keine besondere Handhabung mit den Kreditkartendaten um die PCI-Richtlinien zu erfüllen.