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

61–70 of 81 posts

Re: ISO 8583: The language of credit cards

#61

Post by Copyrighted »

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…

Painful memories of when you tell brands your data is coming in as ASCII and they have it as EBCDIC.

Re: ISO 8583: The language of credit cards

#62

Post by nulbyte »

miki123211 wrote: post #59
TuringNYC wrote: post #22

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.

> Unlike Visa and Mastercard, I noticed that AMEX transaction notifications are near-instantaneous. No idea where you bank, but my Visa notifications are instantaneous, so the network is clearly capable of that. I'm with a modern European bank though, I wouldn't be surprised if the mainframe-lowing US banks that do everything via overnight batch jobs are incapable of this. With that said, there are places which strai…

> I'm with a modern European bank though, I wouldn't be surprised if the mainframe-lowing US banks that do everything via overnight batch jobs are incapable of this.

I wouldn't be surprised if your European bank still relies quite heavily on its mainframes. The mainframe offers high availability, reliability, and, contrary to popular belief, high throughput. Batch processing is just one thing they're good at; real-time processing at high speed is another.

Re: ISO 8583: The language of credit cards

#63

Post by j16sdiz »

ocf wrote: post #20

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, b…

I don't know the current state of affairs. Last time I worked on ISO20022 (almost 10 years ago), our system were doing a 1-to-1 mapping from ISO8583, keeping every bit of unmaintable shit one could imagine

Re: ISO 8583: The language of credit cards

#64

Post by j16sdiz »

david-gpu wrote: post #58
lxgr wrote: post #14

Earlier quoted context omitted.

> 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 for…

> Not really: C structs notably don't have variable-length fields Feast your eyes: C99 introduced an ~~abomination~~ feature called flexible array members (FAM), which allows the last member of a struct to be a variable length array. If you want to ~~gouge you eyes~~ learn more, see section 6.7.2.1.16 [0]. > To add insult to injury, it does not offer a standard way to determine field lengths That's awful. You can sor…

FAM was a (not so successful) attempt to standardise some existing usage

Re: ISO 8583: The language of credit cards

#65

Post by CamouflagedKiwi »

cess11 wrote: post #57
ocf wrote: post #20

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, b…

ISO 20022 roll-out is well underway. Unless the US decides to extend it's war on the world to the rest of G20 the plan is to be done a year from now, and if I'm not mistaken the US is a member of the PEPPOL society already. It's the lingua franca of european banks and has been for some time. Back in 2018 when I built a piece of financial software I talked ISO 20022 with a swedish bank in Luxembourg.

This is not the case for card networks. I know of no plan for Visa or Mastercard to move to ISO20022 and even if so I am certain it will not be complete within a year from now. In fact, if they announced they were starting a migration like that, I would be dubious if it could be completed within 10 years, there are so many systems out there that would have to change.

On many other payment systems, yes, ISO20022 is or is becoming the lingua franca - e.g. FedWire is going to move next year.

Re: ISO 8583: The language of credit cards

#66

Post by j16sdiz »

miki123211 wrote: post #59
TuringNYC wrote: post #22

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.

> Unlike Visa and Mastercard, I noticed that AMEX transaction notifications are near-instantaneous. No idea where you bank, but my Visa notifications are instantaneous, so the network is clearly capable of that. I'm with a modern European bank though, I wouldn't be surprised if the mainframe-lowing US banks that do everything via overnight batch jobs are incapable of this. With that said, there are places which strai…

You missed the footnote for [1].

Did you meant Apple Card, Apple Pay or the Apple Store?

Re: ISO 8583: The language of credit cards

#67

Post by cess11 »

CamouflagedKiwi wrote: post #65
cess11 wrote: post #57

Earlier quoted context omitted.

ISO 20022 roll-out is well underway. Unless the US decides to extend it's war on the world to the rest of G20 the plan is to be done a year from now, and if I'm not mistaken the US is a member of the PEPPOL society already. It's the lingua franca of european banks and has been for some time. Back in 2018 when I built a piece of financial software I talked ISO 20022 with a swedish bank in Luxembourg.

This is not the case for card networks. I know of no plan for Visa or Mastercard to move to ISO20022 and even if so I am certain it will not be complete within a year from now. In fact, if they announced they were starting a migration like that, I would be dubious if it could be completed within 10 years, there are so many systems out there that would have to change. On many other payment systems, yes, ISO20022 is or…

The planning stage is history.

https://usa.visa.com/content/dam/VCOM/global/ms/documents/ve...

https://usa.visa.com/content/dam/VCOM/regional/na/us/sites/d...

Mastercard uses data sucking nag screens, but I don't think you actually need to read the papers to get the point:

https://b2b.mastercard.com/news-and-insights/payments-modern...

https://b2b.mastercard.com/news-and-insights/report/iso-2002...

In 2018 SWIFT decided to migrate. Do you seriously believe that VISA and Mastercard did not notice this when it happened? Do you think they've been watching India adopt ISO 20022 for years and not acted upon it?

Edit: The reason adoption is fast when the devs finally can get to work is that it's XML, you get schema files and punch your programming button and generate a lot of the necessary code and then do the plumbing and call it a day.

Re: ISO 8583: The language of credit cards

#70

Post by happosai »

BiteCode_dev wrote: post #48
lxgr wrote: post #21

Earlier quoted context omitted.

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 es…

In this world and age of AI, having this kind of inside knowledge that is scattered, usually behind paywall and nda, and always to be updated, is a real advantage. Because no LLM will be able to replace you for quite a while.

Job security via obscurity.
Post reply on HN