Zusammenfassung

  • RFC 3538 ordnete 20, 40, 60, 80 und 100 der Erzeugung oder Verarbeitung aufeinanderfolgender SET-Nachrichten in der IOTP-Brücke zu. Die Skala beschrieb Schnittstellenfortschritt, keinen Anteil am Geschäftsergebnis.
  • Bei 100 konnte PRes eine genehmigte Autorisierung oder einen erfolgreichen Einzug melden. CompletedOK konnte nach Stornierung noch zu Failed werden; Abrechnung und Lieferung lagen außerhalb der Aussage.

Eine Betriebskonsole zeigt einen vollen Balken. Was weiß das Team nun? Wurde die Anfrage autorisiert, der Betrag eingezogen, zwischen Instituten abgerechnet, die Ware übergeben oder eine Stornierung ausgeschlossen? Benutzeroberflächen verdichten solche Fragen gern zu „abgeschlossen“. RFC 3538, im Juni 2003 als Informational veröffentlicht, antwortete enger: Die Brücke zwischen SET und IOTP hatte die letzte Nachricht ihrer Zuordnung verarbeitet.

IOTP sollte dem elektronischen Handel einen gemeinsamen Rahmen geben, ohne ein einziges Zahlungsverfahren vorzuschreiben. Das Supplement beschrieb, wie Secure-Electronic-Transaction-Nachrichten durch die Payment API von IOTP 1.0 laufen. Die eingefrorenen Quellen belegen weder Verbreitung noch eine konkrete Transaktion oder Störung. Historisch wichtig ist die Disziplin, einen lokalen Messpunkt nicht zum Urteil über das ganze Geschäft zu erheben.

Abschnitt 8.12 nennt fünf Marken. Nach Erzeugung oder Verarbeitung der ersten SET Initiation Response steht PercentComplete auf 20. PinitReq führt zu 40, PinitRes zu 60, PReq zu 80 und PRes zu 100. Consumer und Payment Handler sehen Erzeugung und Verarbeitung von entgegengesetzten Seiten. Die Zahl der Initiierungsnachrichten kann variieren; die erste Antwort erhält trotzdem 20. Die Skala misst weder gleich große Arbeitspakete noch Restzeit. Sie ist eine vereinbarte Landkarte der Schnittstelle.

Der letzte Punkt besitzt zwei Bedeutungen. Ein erfolgreiches PRes kann authorizationPerformed mit genehmigtem AuthCode oder capturePerformed mit erfolgreichem CapCode enthalten. Autorisierung erlaubt den nächsten Schritt; Einzug ist ein anderer wirtschaftlicher Vorgang. Gleicher Umschlag und gleicher Wert machen daraus kein identisches Ereignis. Erst der Code sagt, was geschah.

Auch die Zustandsmaschine begrenzt das Wort „fertig“. Auf der Payment-Handler-Seite kann ein Vorgang CompletedOK erreichen. Wird die Zahlung storniert, erlauben ChangeProcessState oder CancelPayment jedoch CompletedOK -> Failed. Ein Zustand ist die Sicht einer Komponente zu einem Zeitpunkt. Wer die Kante löscht, erfindet Unumkehrbarkeit.

Die Belegprüfung zeigt die Grenze besonders deutlich. CheckPayReceipt prüft die Payment Receipt Information nicht speziell, sondern liefert bei gültiger Anfrage eine allgemeine Antwort. Das kann als API-Aufgabenteilung richtig sein. Irreführend wäre es, strukturelle Gültigkeit als inhaltliche Prüfung anzuzeigen. Gültiger Umschlag, erkannter Beleg und bestätigte Behauptung sind verschiedene Nachweise.

Lieferung bleibt außerhalb der Zahlungsbrücke. Für physische Güter empfiehlt RFC 3538, IOTP Delivery Exchanges wegzulassen. Ein Abfrageort kann angegeben, die Autorisierungsabfrage zwischen Handlern außerhalb von IOTP abgewickelt werden. Für digitale Güter wird Echtzeitautorisierung empfohlen. Eine abgeschlossene Nachrichtenfolge bewegt kein Paket und beweist keinen Zugang zum Inhalt.

Abfrage und Fehler bleiben ebenfalls getrennt. SET Inquiry Initiation entfällt; Abfragenachrichten liegen in IOTP-Daten. Technische Brückenfehler erhalten HardError, geschäftliche Ablehnung nimmt einen anderen Weg. Ohne Herkunft wirkt eine korrekt transportierte Ablehnung wie ein Defekt oder eine gesunde Brücke wie ein Verkaufserfolg.

Der bestehende Artikel zu RFC 3354 besitzt die IOTP-v2-Anforderungen und die Grenze zwischen Komposition und Autorisierung. RFC 3504 besitzt Korrekturen, Identität, Abfrage sowie die allgemeine Trennung von Zahlung, Abrechnung und Lieferung. RFC 3538 liefert ein eigenes Instrument: fünf Werte, zwei PRes-Ergebnisse, begrenzte Belegprüfung und Stornierung nach „Abschluss“.

Die dauerhafte Regel lautet: Jeder Fortschritt braucht einen benannten Nenner. Exakte Nachricht, erzeugender oder verarbeitender Akteur, completion code und spätere Übergänge müssen erhalten bleiben. Dann ist 100 ein nützlicher Nachweis. Ohne Provenienz borgt sich die Zahl Gewissheit von Ereignissen, die sie nie maß.

Quellen