[HN Gopher] ISO 8583: The language of credit cards
___________________________________________________________________
ISO 8583: The language of credit cards
Author : ekmartin
Score : 136 points
Date : 2024-12-17 15:53 UTC (1 days ago)
(HTM) web link (increase.com)
(TXT) w3m dump (increase.com)
| Rygian wrote:
| Fun times reviewing the masking logic of credit card data spewed
| out in system logs, in base64-encoded (or god forbid, EBCDIC-
| encoded base64-encoded) ISO 8583.
| aftbit wrote:
| I wonder if this is the standard that drove Charles Stross
| slightly insane and led to Accelerando.
|
| https://www.antipope.org/charlie/blog-static/fiction/acceler...
|
| Actually based on the timing, this is probably the new better
| standard that replaced the obscure protocols of the 70s.
| t0mas88 wrote:
| 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 all of those are well
| understood by now.
|
| What I find baffling is that this "standard" does not specify how
| to encode the fields or even the message type. Pick anything,
| binary, ASCII, BCD, EBCDIC. That doesn't work as a standard,
| every implementation could send you nearly any random set of
| bytes with no way for the receiver to make sense of them.
| mananaysiempre wrote:
| 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
| lxgr wrote:
| 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 :)
| lxgr wrote:
| > 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).
| quotemstr wrote:
| 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.
| TacticalCoder wrote:
| > "ISO 8583: The language of credit cards"
|
| "ISO 8583: The language of both debit and credit cards"
| lxgr wrote:
| 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 ;)
| bokohut wrote:
| 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 Discover card to get the
| GUID field added to the ISO8583 specification.
|
| We are living in changing times on many fronts and the worlds
| financial systems is one of those new battlefields. Many are
| ignorant as to what is occurring but with big tech owning their
| own payments ecosystems this should be insight for others not
| aware as we are absolutely certain to see more following their
| lead. Some of those others following are entire countries, they
| are just a bigger business after all, as it is already happening
| for those aware and a small select few are doing i.t.
|
| Stay Healthy!
| nonrandomstring wrote:
| 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 this
| (capturing the regulator).
|
| Interestingly local _real_ (non-digital) currencies like the
| Brixton Pound [2] and other local paper scrip seem to escape
| this, which seems a boost for paper technologies.
|
| [0]
| https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Sec...
|
| [1] https://cybershow.uk/episodes.php?id=36
|
| [2] https://brixtonpound.org/
| lxgr wrote:
| 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.)
| krab wrote:
| 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. :-)
| ekmartin wrote:
| Fascinating, I don't think I've ever seen an XML field! Do you
| remember which network that was for?
| krab wrote:
| We were the issuer. So these were probably the payment
| processor's extensions. But we were issuing MasterCards.
| lxgr wrote:
| > 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.
| indus wrote:
| (In the holiday spirit)
|
| The only language of credit cards is points, cashback, APYs, and
| hard to read TOS
| heywire wrote:
| 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.
| ocf wrote:
| 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.
| lxgr wrote:
| The large card networks have so many proprietary behaviors and
| extensions that I really doubt whether any common standard
| would even make sense at this point.
|
| And if you look at how "modern" ISO 8583 is evolving, almost
| all changes and extensions are already happening in TLV-like
| subfields (where a new field unexpectedly appearing doesn't
| make existing parsers explode spectacularly), and the top-level
| structure is essentially irrelevant.
|
| Of course, it's a significant hurdle to newcomers to get
| familiar with that outer layer, but I don't get the sense that
| catering to these is a particular focus by either network. ISO
| 8583 is also a great moat (one of many in the industry, really)
| for existing processors, which have no buy-in to switch to a
| new standard and the networks need to at least somewhat keep
| happy.
| TuringNYC wrote:
| Unlike Visa and Mastercard, I noticed that AMEX transaction
| notifications are near-instantaneous. There is something so
| magical about a notification popping up on my phone/watch
| literally the second i swipe a card. I always wondered about the
| layers on the stack which V/MC must have which AMEX doesnt.
| reaperducer wrote:
| _Unlike Visa and Mastercard, I noticed that AMEX transaction
| notifications are near-instantaneous. There is something so
| magical about a notification popping up on my phone /watch
| literally the second i swipe a card. I always wondered about
| the layers on the stack which V/MC must have which AMEX
| doesnt._
|
| Must be your bank, because both my Visa and MasterCard ping my
| phone instantaneously, too.
___________________________________________________________________
(page generated 2024-12-18 23:00 UTC)