Payments reference tables: MCC, currency, 3DS

The values that catch people out

Currency minor units are the classic. Most currencies have two, so code written against them works everywhere until it meets JPY with none or KWD with three, and then an amount is out by a factor of a hundred or a thousand. Amounts in DE 4 and tag 9F02 are always in minor units, so the exponent is not a display concern, it is the meaning of the number.

Country codes in payments are numeric, not the two-letter codes everyone recognises. EMV tag 9F1A and DE 19 both carry ISO 3166-1 numeric, so 826 and 840 are values you end up learning by heart and the rest need looking up.

ECI values differ between Visa and Mastercard, and they differ in a way that inverts: the value meaning fully authenticated on one is not the same digit on the other. Reading one scheme's table against the other transaction is a liability shift you thought you had and do not.

Where these tables come from

Each table is compiled from the published standard: ISO 4217 for currencies, ISO 3166-1 for countries, ISO 18245 for merchant category codes, ISO/IEC 7816-4 for status words, and EMVCo 3-D Secure 2.x for transStatus. Copying from other sites propagates their errors, which is how a wrong minor unit ends up on twenty pages of search results.

ISO 18245 assigns blocks of merchant category codes as well as individual ones, and acquirers add codes inside those blocks that the standard never names. Where a code is unlisted, the MCC lookup reports the block it falls in and says the reading is range-only, rather than naming a business that may not be right.

Encoding is its own problem

Payments messages arrive in more encodings than any other kind of traffic you will handle. The same field can be ASCII on one link, packed BCD on another and EBCDIC on the mainframe leg, and a value that looks like corruption is usually just being read in the wrong one.

The data converter handles all of them in both directions, EBCDIC included, because mainframe acquirers are still there and CP037 is still what they speak. If a field decodes to punctuation and control characters, try it as EBCDIC before concluding the message is broken.