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

51–60 of 81 posts

Re: ISO 8583: The language of credit cards

#51

Post by mschuster91 »

akira2501 wrote: post #30
TuringNYC wrote: post #26

Earlier quoted context omitted.

>> Must be your bank, because both my Visa and MasterCard ping my phone instantaneously, too. Well thats sort of the thing...with Visa and MC, there is an extra layer or two of the bank or Fidelity Information Services. With Amex, they own the full stack end to end.

Your card limit gets checked on every transaction. There doesn't seem to be a technical reason why information flow back to me should be limited in any way. If the extra layer fails to work the transaction fails to pass.

> Your card limit gets checked on every transaction.

Nope. The merchant can choose the level of verification - in some cases, like copying the card with an imprinter [1] or running phone transactions (yes, that is possible - it's called MOTO [2]), it's obviously impossible to check card limits.

Downside of CNP transactions is, the merchant is fully liable for anything from fraud over chargebacks to exceeding limits.

And then you got card-present transactions but the network connectivity is down for whatever reasons... been a while since I messed with that, but at least for German cards you could configure the terminal to store the account details for later submission when connectivity was restored.

[1] https://en.wikipedia.org/wiki/Credit_card_imprinter

[2] https://docs.adyen.com/point-of-sale/mail-and-telephone-orde...

Re: ISO 8583: The language of credit cards

#52

Post by feldrim »

feldrim wrote: post #27
nonrandomstring wrote: post #9

Earlier quoted context omitted.

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…

There is some confusion in that comment. - PCI DSS 4.0 is already in place and to be retired on December 31, 2024. PCI DSS 4.0.1 is the replacement and I place already. - PCI DSS 4.0.1 and game tokens have nothing in common. The applicability of PCI DSS requirements are decided by card brands, aka Visa, Mastercard, etc. And it is the acquirers to enforce on the third party service providers to enforce the standard. S…

* in place

Re: ISO 8583: The language of credit cards

#53

Post by phrotoma »

__turbobrew__ wrote: post #42
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.

I have a visa card with a Canadian bank and get transaction messages within 5 seconds of payment usually. Maybe it is a per bank thing?

It's a per country thing. Card txns in the US are bananas arcane byzantine nightmares. (Source: worked at Canadas largest bank on txn processing software).

Re: ISO 8583: The language of credit cards

#54

Post by simoncion »

wbl wrote: post #38
quotemstr wrote: post #36

Earlier quoted context omitted.

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

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

I must be misunderstanding what you're saying, because this exists: https://www.erlang.org/doc/apps/asn1/asn1ct.html#>

From the linked page:

> asn1ct

> ASN.1 compiler and compile-time support functions

> The ASN.1 compiler takes an ASN.1 module as input and generates a corresponding Erlang module, which can encode and decode the specified data types. Alternatively, the compiler takes a specification module specifying all input modules, and generates a module with encode/decode functions.

Re: ISO 8583: The language of credit cards

#55

Post by ErneX »

akira2501 wrote: post #30
TuringNYC wrote: post #26

Earlier quoted context omitted.

>> Must be your bank, because both my Visa and MasterCard ping my phone instantaneously, too. Well thats sort of the thing...with Visa and MC, there is an extra layer or two of the bank or Fidelity Information Services. With Amex, they own the full stack end to end.

Your card limit gets checked on every transaction. There doesn't seem to be a technical reason why information flow back to me should be limited in any way. If the extra layer fails to work the transaction fails to pass.

I remember being charged after a while when paying for bus/metro tickets in some places, I think those machines process transactions by batches or something.

Re: ISO 8583: The language of credit cards

#56

Post by williamdclt »

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.

As others say, it's not a matter of Visa VS Amex. I use both a Mastercard and a Visa with a neobank in Europe, and I get instant notifications. Must be more something to do with the bank (US banking is famously so behind, but I also see days-long delays with traditional european banks).

Even more magical: when sending money to someone I'm physically present with, I hear their notification before the "money sent" animation finished on my own phone

Re: ISO 8583: The language of credit cards

#57

Post by cess11 »

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.

Re: ISO 8583: The language of credit cards

#58

Post by david-gpu »

lxgr wrote: post #14
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 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 sort of say the same about variable length struts in C, but at least the strict tupe definition usually has a field that tell you the length of the variable length array at the end.

[0] https://rgambord.github.io/c99-doc/sections/6/7/2/1/index.ht...

Re: ISO 8583: The language of credit cards

#59

Post by miki123211 »

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 straight up won't send your transaction to the network at purchasing time. Apple[1] is one notable example. They seem to have a cron job that runs at midnight and does billing for that day. This is really annoying if you're buying an expensive Apple product and increase your card limits for one day only.

I've even seen places that do extremely-low-value transactions "on faith" - the transaction is entirely offline, it gets send to the network the next day, and if it is rejected, your card number goes on a blacklist until you visit the company's office in person and settle the debt.

Re: ISO 8583: The language of credit cards

#60

Post by Copyrighted »

I got my last company certified with Visa and Mastercard for authorization and clearing. It's funny how they call it a standard but it'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.
Post reply on HN