ISO 8583: The language of credit cards

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&#x2F;issuance platforms do a decent job of abstracting this away though.<p>Transition to ISO 20022 would be a positive improvement, but I don&#x27;t think it will ever meet the required ROI threshold (globally) for that to happen.

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.<p>What I find baffling is that this &quot;standard&quot; does not specify how to encode the fields or even the message type. Pick anything, binary, ASCII, BCD, EBCDIC. That doesn&#x27;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.

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.<p>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.<p>Stay Healthy!

I wonder if this is the standard that drove Charles Stross slightly insane and led to Accelerando.<p><a href="https:&#x2F;&#x2F;www.antipope.org&#x2F;charlie&#x2F;blog-static&#x2F;fiction&#x2F;accelerando&#x2F;accelerando-intro.html" rel="nofollow">https:&#x2F;&#x2F;www.antipope.org&#x2F;charlie&#x2F;blog-static&#x2F;fiction&#x2F;acceler...</a><p>Actually based on the timing, this is probably the new better standard that replaced the obscure protocols of the 70s.

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. :-)

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&#x2F;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.

I got my last company certified with Visa and Mastercard for authorization and clearing. It&#x27;s funny how they call it a standard but it&#x27;s anything but that. There were some similarities but a lot of subtle differences which made the process 10X harder. Mastercard was the worst to deal with.

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&#x2F;watch literally the second i swipe a card. I always wondered about the layers on the stack which V&#x2F;MC must have which AMEX doesnt.

&gt; &quot;ISO 8583: The language of credit cards&quot;<p>&quot;ISO 8583: The language of both debit and credit cards&quot;

We’ve had a lot of success with our Go library for iso8583<p><a href="https:&#x2F;&#x2F;github.com&#x2F;moov-io&#x2F;iso8583">https:&#x2F;&#x2F;github.com&#x2F;moov-io&#x2F;iso8583</a>

Great article that exposes why ISO20022 will replace 8583 over time, especially in areas not dominated by the M&#x2F;V monopoly networks.<p>Credit cards, with all their nonsense about cash backs and rewards can be imnplemented in the new payment systems with banks offering line of credit accounts that are part of the appropriate &quot;national payment system&quot;, like UPI, PromptPay, Osko&#x2F;PayID, FedNow etc.<p>Instant settlement between accounts, low cost fixed price txns etc.

An interesting side effect of this low-level bit mapping is that various banks authorization logics can be manipulated to increase auth rates by subtle bit flipping across various fields.<p>All the big fintech companies have ML running over changes to identify what results in the highest auth rates on a per bin basis.

Not only payment cards but value added services as well like prepaid airtime and bill payments and ISO8583 1993 or the 1987 version ???.

So is ISO20022 the future then? There should* be a standard system that all the networks stick to... instead of the hodgepodge of bullshit there is now.

I really wonder what a future would look like without companies like Visa&#x2F;Mastercard&#x2F;Discover&#x2F;AMEX.

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.

(In the holiday spirit)<p>The only language of credit cards is points, cashback, APYs, and hard to read TOS