Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ISO 8583: The language of credit cards

increase.com

Post reply on HN
Print view View original

11–20 of 81 posts

Re: ISO 8583: The language of credit cards

#11

Post by mananaysiempre »

t0mas88 wrote: post #4

The type of protocol (message type, bitmap to define fields, followed by a set of fixed and variable length values) is pretty normal for the time it was developed in. Many low level things are basically packed C-structs with this type of protocol. It comes with some pitfalls on the receiver side to be careful validating dynamic field length and refusing to read past end of message or allocate an infinite buffer. But…

A bitmap to define field presence doesn’t seem so offensive, as far as serialization formats go. FlatBuffers[1] use a list of offsets instead, but that’s in the context of expecting to see many identically-shaped records. One could argue that Cap’n Proto with zero-packing[2] amounts to the same thing if you squint, just with the bitmap smeared all over the message.

I mean, this specific thing sounds like it should have been a fatter but much more unexciting TLV affair instead. But given it’s from 1987, it’d probably have ended up as ASN.1 BER in that case (ETA: ah, and for extensions, it mostly did, what fun), instead of a simpler design like Protobufs or MessagePack/CBOR, so maybe the bitmaps are a blessing in disguise.

[1] https://google.github.io/flatbuffers/flatbuffers_internals.h...

[2] https://capnproto.org/encoding.html#packing

Re: ISO 8583: The language of credit cards

#13

Post by heywire »

It has been fun seeing all the different ways companies have come up with to work around the limitations of ISO 8583. One I’ve been seeing a lot lately is making an API call before/after the ISO message (with non-PCI data) to confer additional information outside of the payment transaction. Definitely speeds up time to market, but opens up a whole new array of failure modes to deal with.

Re: ISO 8583: The language of credit cards

#14

Post by lxgr »

t0mas88 wrote: post #4

The type of protocol (message type, bitmap to define fields, followed by a set of fixed and variable length values) is pretty normal for the time it was developed in. Many low level things are basically packed C-structs with this type of protocol. It comes with some pitfalls on the receiver side to be careful validating dynamic field length and refusing to read past end of message or allocate an infinite buffer. But…

> Many low level things are basically packed C-structs with this type of protocol.

Not really: C structs notably don't have variable-length fields, but ISO 8583 very much does.

To add insult to injury, it does not offer a standard way to determine field lengths. This means that in order to ignore a given field, you'll need to be able to parse it (at least at the highest level)!

Even ASN.1, not exactly the easiest format to deal with, is one step up from that (in a TLV structure, you can always skip unknown types by just skipping "length" bytes).

Re: ISO 8583: The language of credit cards

#15

Post by lxgr »

krab wrote: post #7

Oh, this format was fun. You could see history unfold when parsing it. The messages I parsed were ISO-8583 with ~EBCDIC~ no, BCD. But one field contained XML. And the XML had an embedded JSON. The inner format matched the fashion trend of the year when someone had to extend the message with extra data. :-)

> The messages I parsed were ISO-8583 with ~EBCDIC~ no, BCD.

The "great" thing about most ISO 8583 implementations I've worked with (all mutually incompatible at the basic syntactic level!) is that they usually freely mix EBCDIC, ASCII, BCD, UTF-8, and hexadecimal encoding across fields.

Re: ISO 8583: The language of credit cards

#16

Post by lxgr »

TacticalCoder wrote: post #5

> "ISO 8583: The language of credit cards" "ISO 8583: The language of both debit and credit cards"

And sometimes even bank transfers (I believe at least FPS in the UK used it, or possibly still does).

Also don't forget about prepaid cards, charge cards etc., depending on where they exist in your personal ontology of card funding methods ;)

Re: ISO 8583: The language of credit cards

#17

Post by quotemstr »

t0mas88 wrote: post #4

The type of protocol (message type, bitmap to define fields, followed by a set of fixed and variable length values) is pretty normal for the time it was developed in. Many low level things are basically packed C-structs with this type of protocol. It comes with some pitfalls on the receiver side to be careful validating dynamic field length and refusing to read past end of message or allocate an infinite buffer. But…

As far as I'm concerned, we solved binary formats with ASN.1 and its various encodings. Everything afterwards has been NIH, ignorance, and square wheel reinvention.

Re: ISO 8583: The language of credit cards

#18

Post by lxgr »

mananaysiempre wrote: post #11
t0mas88 wrote: post #4

The type of protocol (message type, bitmap to define fields, followed by a set of fixed and variable length values) is pretty normal for the time it was developed in. Many low level things are basically packed C-structs with this type of protocol. It comes with some pitfalls on the receiver side to be careful validating dynamic field length and refusing to read past end of message or allocate an infinite buffer. But…

A bitmap to define field presence doesn’t seem so offensive, as far as serialization formats go. FlatBuffers[1] use a list of offsets instead, but that’s in the context of expecting to see many identically-shaped records. One could argue that Cap’n Proto with zero-packing[2] amounts to the same thing if you squint, just with the bitmap smeared all over the message. I mean, this specific thing sounds like it should ha…

I'd trade the field layer of ISO 8583 for some ASN.1 any day!

Luckily, there's a bit of everything in the archeological site that is ISO 8583, and field 55 (where EMV chip data goes, and EMV itself is quite ASN.1-heavy, presumably for historical reasons) and some others in fact contain something very close to it :)

Re: ISO 8583: The language of credit cards

#19

Post by lxgr »

nonrandomstring wrote: post #9
bokohut wrote: post #6

A lot of payments chatter on here recently and patio11 throwing out some great content as well. May I ask where this pretty visual explanation website was 25 years ago? ;) Oh the woes of programming ISO8583 as I see another commented on EBCDIC which adds in a whole other level of mind numbing when passing between the endians. It was a fun experience however back in the early 2000s when I worked in isolation with Disc…

I learned a lot more about this discussing the PCI/DSS [0] regulation framework here [1]. It's about to change to a new 4.0 in 2025 which means that to use or run any payments system you'll have to meet ever more stringent regulation. This is going to start applying to other pseudo currencies (in game value tokens etc) if they exceed certain value and scale. At present Visa and Mastercard have a big stake in defining…

PCI-DSS is an industry standard, not a law. If you don't think it should apply to your domain, complain to your legislators/regulators, not the authors of PCI-DSS or the payment industry covered by it!

> Interestingly local real (non-digital) currencies like the Brixton Pound [2] and other local paper scrip seem to escape this

And so do countless other digital (non-real?) payment systems across the globe. That's not to say that there aren't any other security regulations, but they're also most certainly not in PCI scope.

Arguably, the original sin of the card payments industry in particular, and US American banking in general, is treating account numbers as bearer tokens, i.e. secret information; if you don't do that, it turns out that a lot of things become much easier when it comes to security. (The industry has successfully transitioned of that way of doing things for card-present payments, but for card-absent, i.e. online, card transactions, the efforts weren't nearly as successful yet.)

Re: ISO 8583: The language of credit cards

#20

Post by ocf »

Neither Visa nor Mastercard really implement ISO 8583 a standardized way. Which means they each issue many thousands of pages of documentation covering not only which of the standard fields they use and how, but also how they cram their proprietary data into the messages. Most card management/issuance platforms do a decent job of abstracting this away though.

Transition to ISO 20022 would be a positive improvement, but I don't think it will ever meet the required ROI threshold (globally) for that to happen.

Post reply on HN