ISO 8583 : le langage des cartes de crédit

 (increase.com)
3 points par GN⁺ 2024-12-19 | 1 commentaires | Partager sur WhatsApp
  • ISO 8583 est la norme d’échange de messages en temps réel entre les réseaux de cartes de crédit
  • Cette norme définit les messages qui se produisent lorsqu’on approche une carte sur un terminal de paiement ou qu’on clique sur « acheter » en ligne
  • À l’origine, les POS ou les ATM généraient directement les messages, mais aujourd’hui on utilise surtout une conversion depuis un format de plus haut niveau comme JSON avant le passage en ISO 8583
  • La structure des messages est simple, mais les détails d’implémentation sont complexes, avec une flexibilité pensée pour l’interopérabilité entre réseaux

Format de message de base

Indicateur de type de message (Message Type Indicator)

  • Code à 4 chiffres indiquant le type de message (par ex. 0100 pour une demande d’autorisation)
  • Aide le destinataire à déterminer les champs attendus
  • La méthode de sérialisation peut varier selon le réseau (BCD, ASCII, etc.)

Bitmap

  • Indique la présence ou non des champs
  • 1 signifie qu’un champ est présent, 0 qu’il est absent
  • Taille de 8 octets permettant de représenter jusqu’à 64 champs

Éléments de données (Data Elements)

  • Les champs sont sérialisés après la bitmap
  • Les champs à longueur fixe ont toujours la même taille, tandis que les champs à longueur variable incluent une information de longueur
  • Les champs peuvent être encodés en ASCII, BCD, binaire, etc.

Structures de messages imbriquées

  • La norme ISO 8583 permet aux réseaux d’inclure des données personnalisées propres au réseau
  • Les messages imbriqués peuvent être implémentés sous forme de table, de bitmap ou de format TLV (Tag-Length-Value)

Table

  • Tous les champs y sont inclus avec une longueur fixe
  • Des sous-champs à longueur variable sont aussi pris en charge pour réduire le gaspillage d’espace

Message bitmap

  • La présence de chaque sous-champ est indiquée par une bitmap
  • Évite le gaspillage d’espace lorsqu’un champ est absent

Message TLV

  • Les champs sont sérialisés sous forme de triplets tag, longueur et valeur
  • Extensible et indépendant de l’ordre

Conception d’un parseur

  • Un parseur ISO 8583 commence par l’analyse de la bitmap et la définition de la sérialisation de chaque champ
  • Il faut prendre en compte le traitement des messages imbriqués ainsi que les différences d’implémentation selon les réseaux
  • Le système de types Sorbet de Ruby permet de définir des classes de messages sûres
  • Il est possible de configurer les champs à longueur fixe et variable, le padding, etc.

Gestion des erreurs

  • En cas d’échec lors du parsing d’un champ, le système est conçu pour permettre le parsing des champs suivants
  • Gère les erreurs partielles tout en conservant la sérialisation du message
  • En cas d’erreur critique, le traitement du message s’arrête

Conclusion

  • Depuis sa définition en 1987, la norme ISO 8583 n’a cessé d’évoluer pour répondre aux besoins de réseaux variés
  • Increase aide à traiter les messages ISO 8583 afin de permettre aux utilisateurs de se concentrer sur le développement de leurs produits
  • Vous pouvez consulter la documentation de l’API ou contacter l’équipe d’Increase

À lire aussi

1 commentaires

 
GN⁺ 2024-12-19
Commentaires Hacker News

  • Visa et Mastercard n’implémentent pas ISO 8583 de manière standardisée. Chaque entreprise publie des milliers de pages de documentation expliquant comment utiliser les champs standard et comment inclure des données propriétaires dans les messages. La plupart des plateformes de gestion/émission de cartes abstraient bien cette complexité. La transition vers ISO 20022 est une amélioration positive, mais elle a peu de chances de satisfaire les critères de ROI.

  • Le type de protocole (type de message, bitmap de définition des champs, ensemble de valeurs à longueur fixe et variable) était courant à l’époque de son développement. Le récepteur doit valider les longueurs de champ dynamiques et veiller à ne pas lire au-delà de la fin du message. Mais ces problèmes sont désormais bien compris.

  • Il est déconcertant que la norme ISO 8583 ne précise pas comment encoder les champs ou les types de message. Cela peut conduire le récepteur à recevoir un ensemble d’octets aléatoires qu’il est incapable de comprendre.

  • Il y a eu beaucoup de discussions récentes sur les paiements et patio11 propose un excellent contenu. Il y a 25 ans, il n’existait pas de site web avec ce genre d’explications visuelles. Comme l’a mentionné un autre commentaire à propos d’EBCDIC, les conversions entre endianness sont complexes. C’était amusant d’avoir collaboré avec Discover au début des années 2000 pour ajouter un champ GUID à la spécification ISO8583.

  • Les systèmes financiers sont l’un des champs de bataille du changement. Beaucoup de gens ne prennent pas conscience de ces transformations. Les grandes entreprises technologiques possèdent leurs propres écosystèmes de paiement, et il faut offrir des clés de compréhension à ceux qui ne s’en rendent pas compte. Certains pays suivent déjà cette tendance.

  • Charles Stross est devenu un peu fou à cause de la norme ISO 8583, et c’est peut-être ce qui l’a amené à écrire Accelerando. Cette norme est probablement la nouvelle norme qui a remplacé les protocoles flous des années 70.

  • Excellent article expliquant pourquoi ISO20022 remplacera 8583, en particulier dans les régions qui ne sont pas dominées par les réseaux propriétaires M/V. Les cartes de crédit peuvent être implémentées dans les nouveaux systèmes de paiement avec les comptes de crédit fournis par les banques. Les paiements instantanés de compte à compte, les transactions à prix fixe et faible coût, etc., deviennent possibles.

  • C’était amusant de voir les différentes façons de contourner les limitations d’ISO 8583. Récemment, on utilise beaucoup des appels API avant/après les messages ISO pour transmettre des informations supplémentaires en dehors de la transaction de paiement elle-même. Cela réduit le time-to-market, mais peut introduire de nouveaux modes de défaillance.

  • Ce format était amusant. Quand on analyse des messages ISO-8583, on voit l’histoire se dérouler. Les messages que j’ai analysés étaient en BCD et non en EBCDIC. Mais un champ contenait du XML, et le XML contenait du JSON. Chaque extension de message reflétait la mode de son époque.

  • Contrairement à Visa et Mastercard, les notifications de transaction AMEX arrivent presque immédiatement. Dès qu’on passe la carte, une notification apparaît sur le téléphone/la montre, comme par magie. On dirait qu’AMEX n’a pas les couches que V/MC traînent.

  • J’ai eu beaucoup de succès avec iso8583 en utilisant la bibliothèque Go.

  • C’était amusant d’examiner la logique de masquage de données de carte de crédit ISO 8583 encodées en base64 dans les logs système (ou encodées en base64 lui-même encodé en EBCDIC).