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

31–40 of 81 posts

Re: ISO 8583: The language of credit cards

#31

Post by lxgr »

throwway120385 wrote: post #29
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…

I thought that chip-in EMV was bad until I saw some of the stuff coming out of Discover cards for contactless EMV. Buying a test card set from somewhere like B2 Systems was very beneficial even just integrating an EMV reader from a hardware device to a payment processor.

The problem is that the contactless stuff is all custom per network.

Some of the implementations are reasonably close to contact EMV; others might as well be a completely different stack and technology.

Re: ISO 8583: The language of credit cards

#32

Post by kdmtctl »

reaperducer wrote: post #23
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. 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.

Some smaller banks upload available balances to processors and perform clearing later in a back office only. They just don't have a hook to link a notification and send it only after the actual settlement.

Re: ISO 8583: The language of credit cards

#33

Post by lxgr »

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.

It's probably less about layers and more about the different number of stakeholders.

Visa/MC transactions go through at least four systems (merchant, merchant payment service provider/acquirer, Visa/MC, issuer processor); Amex is merchant acquirer and card issuer in one, so there is no network and accordingly at most three parties involved (merchant, merchant PSP, Amex).

That said, some of my Visa/MC cards have very snappy notifications too. In principle, the issuer or issuer processor will know about the transaction outcome even before the merchant (they're the one responding, after all), and I definitely have some cards where I get the notification at the same time and sometimes before the POS displays "approved".

Re: ISO 8583: The language of credit cards

#34

Post by wbl »

quotemstr wrote: post #17
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.

ASN.1 DER, BER, or OER? Implicit and optional can really break compat in surprising ways. Then there are the machine unfriendly roster of available types. XDR was more tuned for that.

Finally free tooling doesn't really exist. The connection to the OSI model also didn't help.

Re: ISO 8583: The language of credit cards

#36

Post by quotemstr »

wbl wrote: post #34
quotemstr wrote: post #17

Earlier quoted context omitted.

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.

ASN.1 DER, BER, or OER? Implicit and optional can really break compat in surprising ways. Then there are the machine unfriendly roster of available types. XDR was more tuned for that. Finally free tooling doesn't really exist. The connection to the OSI model also didn't help.

> ASN.1 DER, BER, or OER?

Or XER or JER! One of the brilliant things about ASN.1 is that it decouples the data model from the serialization format. Of the major successor systems, only protobuf does something similar, and the text proto format barely counts.

> Implicit and optional can really break compat in surprising ways

Any implementation of any spec can be broken. You could argue that the spec should be simpler and require, e.g., explicit tagging everywhere, like protobuf. Sure. But the complexity enables efficiencies, and it's sometimes worth making a foundational library a bit more complex to enable simplifications and optimizations throughout the ecosystem.

> Then there are the machine unfriendly roster of available type

Protobuf's variable-length integers are machine-friendly now? :-) We can always come up with better encoding rules without changing the fundamental data structures.

> Finally free tooling doesn't really exist.

What do you mean? You use ASN.1 to talk to every server talking SNMP, LDAP, or the X.509 PKI. Every programming environment has a way to talk about ASN.1.

> The connection to the OSI model also didn't help.

Agreed. The legacy string types aren't great either. You can, of course, do ASN.1 better. No technology is perfect. But what we don't need, IMHO, is more investment in "simple" technologies like varlink that end up being too simple and shunting complexity and schema-ness that belongs in a universal foundation layer into every single application using the new "simple" thing.

Re: ISO 8583: The language of credit cards

#37

Post by devman0 »

quotemstr wrote: post #36
wbl wrote: post #34

Earlier quoted context omitted.

ASN.1 DER, BER, or OER? Implicit and optional can really break compat in surprising ways. Then there are the machine unfriendly roster of available types. XDR was more tuned for that. Finally free tooling doesn't really exist. The connection to the OSI model also didn't help.

> ASN.1 DER, BER, or OER? Or XER or JER! One of the brilliant things about ASN.1 is that it decouples the data model from the serialization format . Of the major successor systems, only protobuf does something similar, and the text proto format barely counts. > Implicit and optional can really break compat in surprising ways Any implementation of any spec can be broken. You could argue that the spec should be simpler…

XML also decouples the data model and serialization with the XML Infoset specification.

Re: ISO 8583: The language of credit cards

#38

Post by wbl »

quotemstr wrote: post #36
wbl wrote: post #34

Earlier quoted context omitted.

ASN.1 DER, BER, or OER? Implicit and optional can really break compat in surprising ways. Then there are the machine unfriendly roster of available types. XDR was more tuned for that. Finally free tooling doesn't really exist. The connection to the OSI model also didn't help.

> ASN.1 DER, BER, or OER? Or XER or JER! One of the brilliant things about ASN.1 is that it decouples the data model from the serialization format . Of the major successor systems, only protobuf does something similar, and the text proto format barely counts. > Implicit and optional can really break compat in surprising ways Any implementation of any spec can be broken. You could argue that the spec should be simpler…

There are zero free ASN.1 compilers or module checkers.

Re: ISO 8583: The language of credit cards

#39

Post by dekelpilli »

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…

Having been involved in several ISO8583 implementations/integrations, it's really quite wild how different each one was in both structure and required content from one another.

Re: ISO 8583: The language of credit cards

#40

Post by csomar »

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.

AMEX is the bank. For Visa/Mastercard, the latency is probably due to the bank they have to route the transaction through.
Post reply on HN