- ISO 8583 ist der Standard für den Echtzeit-Nachrichtenaustausch zwischen Kreditkartennetzwerken
- Dieser Standard definiert die Nachrichten, die entstehen, wenn an einem Point-of-Sale-Gerät eine Karte aufgelegt wird oder online auf „Kaufen“ geklickt wird
- Anfangs erzeugten POS-Geräte oder Geldautomaten die Nachrichten direkt, heute werden meist höherwertige Formate wie JSON verwendet und anschließend in ISO 8583 umgewandelt
- Die Nachrichtenstruktur ist einfach, die Implementierungsdetails sind jedoch komplex und bieten Flexibilität für die Interoperabilität zwischen Netzwerken
Grundlegendes Nachrichtenformat
Message Type Indicator
- Ein 4-stelliger Code kennzeichnet den Nachrichtentyp (z. B. ist
0100 eine Autorisierungsanfrage)
- Er hilft dem Empfänger zu erkennen, welche Felder zu erwarten sind
- Die Serialisierung kann je nach Netzwerk unterschiedlich sein (BCD, ASCII usw.)
Bitmap
- Zeigt an, ob Felder vorhanden sind
- 1 bedeutet, dass ein Feld vorhanden ist, 0 bedeutet, dass es fehlt
- Mit einer Größe von 8 Byte können bis zu 64 Felder dargestellt werden
Datenelemente
- Nach der Bitmap werden die Felder serialisiert
- Felder mit fester Länge haben immer dieselbe Größe, Felder mit variabler Länge enthalten zusätzlich Längeninformationen
- Für die Kodierung der Felder werden ASCII, BCD, Binärformate usw. verwendet
Verschachtelte Nachrichtenstrukturen
- Der ISO-8583-Standard erlaubt es Netzwerken, netzwerkspezifische benutzerdefinierte Daten einzubetten
- Verschachtelte Nachrichten können als Tabellen, Bitmaps oder im TLV-Format (Tag-Length-Value) implementiert werden
Tabellen
- Alle Felder sind mit fester Länge enthalten
- Um Platzverschwendung zu reduzieren, werden zusätzlich Subfelder mit variabler Länge unterstützt
Bitmap-Nachrichten
- Die Existenz jedes Unterfelds wird per Bitmap angezeigt
- Dadurch wird Platzverschwendung vermieden, wenn Felder fehlen
TLV-Nachrichten
- Felder werden als Tupel aus Tag, Länge und Wert serialisiert
- Unabhängig von der Reihenfolge und gut erweiterbar
Parser-Design
- Ein ISO-8583-Parser beginnt mit der Analyse der Bitmap und den Definitionen für die Serialisierung der einzelnen Felder
- Dabei müssen verschachtelte Nachrichten und netzwerkspezifische Implementierungsunterschiede berücksichtigt werden
- Mit dem Sorbet-Typsystem von Ruby lassen sich typsichere Nachrichtenklassen definieren
- Feste und variable Feldlängen, Padding-Verarbeitung usw. können konfiguriert werden
Fehlerbehandlung
- Bei einem Fehler beim Parsen eines Felds sollte der Parser so entworfen sein, dass das Parsen des nächsten Felds möglich bleibt
- Die Nachrichtenserialisierung bleibt erhalten, während partielle Fehler verarbeitet werden
- Bei kritischen Fehlern wird die Nachrichtenverarbeitung abgebrochen
Fazit
- Der ISO-8583-Standard hat sich seit seiner Definition im Jahr 1987 kontinuierlich weiterentwickelt und unterschiedliche Anforderungen verschiedener Netzwerke erfüllt
- Increase verarbeitet ISO-8583-Nachrichten und hilft so dabei, sich auf die Entwicklung von Produkten für Endnutzer zu konzentrieren
- Weitere Informationen finden sich in der API-Dokumentation oder über das Increase-Team
1 Kommentare
Hacker-News-Kommentare
Visa und Mastercard implementieren ISO 8583 nicht auf standardisierte Weise. Jedes Unternehmen veröffentlicht tausende Seiten Dokumentation, die erklärt, wie Standardfelder zu verwenden sind und wie proprietäre Daten in Nachrichten eingebettet werden. Die meisten Plattformen zur Kartenverwaltung/-ausgabe abstrahieren das gut. Die Umstellung auf ISO 20022 ist eine positive Verbesserung, wird die ROI-Kriterien aber wahrscheinlich nicht erfüllen.
Der Protokolltyp selbst (Nachrichtentypen, Bitmaps zur Felddefinition, Mengen fester und variabler Längenwerte) war zur Zeit seiner Entwicklung üblich. Auf der Empfängerseite muss man sorgfältig dynamische Feldlängen validieren und darauf achten, nicht über das Ende der Nachricht hinaus zu lesen. Diese Probleme sind inzwischen jedoch gut verstanden.
Es ist irritierend, dass der ISO-8583-Standard nicht festlegt, wie Felder oder Nachrichtentypen kodiert werden sollen. Dadurch kann der Empfänger einen zufälligen Byte-Satz erhalten, den er nicht verstehen kann.
In letzter Zeit gibt es viele Diskussionen rund um Zahlungen, und patio11 liefert großartige Inhalte. Vor 25 Jahren gab es keine Websites mit solchen visuellen Erklärungen. Wie ein anderer Kommentar mit Verweis auf EBCDIC sagte, ist die Umwandlung zwischen Endianness kompliziert. Es war interessant, Anfang der 2000er mit der Discover Card zusammenzuarbeiten, um dem ISO8583-Standard ein GUID-Feld hinzuzufügen.
Finanzsysteme sind eines der Schlachtfelder des Wandels. Viele Menschen nehmen diese Veränderungen nicht wahr. Große Tech-Unternehmen besitzen ihre eigenen Zahlungsökosysteme, daher sollte man denjenigen, die das nicht erkennen, Einblicke geben. Einige Länder folgen diesem Trend.
Charles Stross ist wegen des ISO-8583-Standards wohl ein wenig verrückt geworden, und das könnte der Grund gewesen sein, warum er Accelerando geschrieben hat. Wahrscheinlich war dieser Standard ein neuer Standard, der vage Protokolle aus den 70ern ersetzt hat.
Das ist ein großartiger Artikel, der erklärt, warum ISO20022 8583 ersetzen sollte. Besonders in Regionen, die nicht von den proprietären Netzwerken von M/V dominiert werden. Kreditkarten könnten in neuen Zahlungssystemen zusammen mit den von Banken bereitgestellten Kreditkonten umgesetzt werden. Sofortzahlungen zwischen Konten, kostengünstige Transaktionen zu Festpreisen usw. wären möglich.
Es war interessant, die verschiedenen Wege zu sehen, mit denen die Einschränkungen von ISO 8583 umgangen werden. In letzter Zeit wird häufig vor oder nach einer ISO-Nachricht per API-Aufruf zusätzliche Information außerhalb der Zahlungstransaktion übertragen. Das verkürzt die Time-to-Market, kann aber neue Fehlermodi verursachen.
Dieses Format war faszinierend. Bei der Analyse von ISO-8583-Nachrichten konnte man die Geschichte förmlich aufblättern sehen. Die von mir analysierten Nachrichten waren BCD statt EBCDIC. Ein Feld enthielt jedoch XML, und das XML enthielt JSON. Jede Erweiterung einer Nachricht spiegelte den jeweiligen Zeitgeist des Jahres wider.
Anders als bei Visa und Mastercard kommen AMEX-Transaktionsbenachrichtigungen fast sofort. Es fühlt sich magisch an, dass unmittelbar nach dem Durchziehen der Karte eine Benachrichtigung auf dem Handy oder der Uhr erscheint. Es scheint, als hätten V/MC zusätzliche Layer, die es bei AMEX nicht gibt.
Mit der Go-Bibliothek für iso8583 hatte ich viel Erfolg.
Es war interessant, die Maskierungslogik für ISO-8583-Kreditkartendaten zu überprüfen, die in Systemlogs base64-kodiert waren (oder base64-kodiert, das wiederum in EBCDIC kodiert war).