62-prefixed PAN and asked "is this standard ISO 8583?" Either way, the useful first move is not a field-by-field comparison โ it's realising that "the UnionPay spec" refers to three different layers, and the answer changes depending on which layer you mean. This article sticks to what public, verifiable sources establish: for actual field definitions and values, always defer to the specification your counterparty hands you.
| Layer | What it is | Public? |
|---|---|---|
| ISO 8583 the international standard | ISO's financial transaction messaging standard โ MTI, bitmaps, data elements โ in three editions: 1987, 1993, 2003 | The text is sold by ISO, but the structure is long-established public knowledge |
| China's public standards layer GB/T 15150 + JR/T 0055 | GB/T 15150, the Chinese national standard that adopts ISO 8583:1987 verbatim; and JR/T 0055 Technical specifications on bankcard interoperability, a five-part financial industry standard issued by the People's Bank of China and drafted with China UnionPay | Public โ listed (and partly downloadable in full) on official government standards platforms |
| The interchange interface spec what integrations actually follow | The specification UnionPay issues to connecting institutions. Message headers, encoding conventions, private-field layouts, response-code tables, per-transaction field matrices โ all the implementation detail lives here | Not public โ provided by your counterparty once you have an agreement in place |
When people ask "how does UnionPay 8583 differ from the standard?", they usually want the third layer โ and that layer is a commercial specification, not public, and not covered here. What public sources can settle is the first two layers and how the three relate. For building an accurate mental model, that turns out to be enough.
ISO 8583 encodes its edition in the first digit of the MTI:
| Edition | MTI starts | Notes |
|---|---|---|
| 1987 | 0 | The most widely deployed edition; most card network messages anchor here |
| 1993 | 1 | Revised several field definitions โ the classic example being the response code growing from 2 to 3 characters |
| 2003 | 2 | A major restructure, rarely adopted by live networks |
Which edition anchors the UnionPay ecosystem is verifiable through an official chain: GB/T 15150-1994 is China's identical adoption (idt) of ISO 8583:1987, still in force (reaffirmed at its 2024 review), and JR/T 0055 lists GB/T 15150 among its normative references. In other words, the public standards layer under China's bankcard interoperability system is anchored to the 1987 edition.
That anchor yields two firm conclusions: messages in this ecosystem carry four-digit MTIs starting with 0 (the familiar 0100 / 0200 / 0800 family), and the response code (DE39) is two characters โ the same footing as most international networks, which also anchor to 1987. So "UnionPay messages are a whole different animal" is a myth: the skeleton is standard ISO 8583:1987 โ MTI, bitmaps, data elements. The differences live below the skeleton, in the implementation conventions covered in section 4.
Card range: 62. The leading digits of a card number come from the ISO/IEC 7812 issuer identification (IIN/BIN) scheme, and UnionPay cards beginning with 62 is a public allocation under that scheme โ common industry knowledge, and the quickest visual hint that a message may involve a UnionPay card. More in BIN / IIN in ISO 8583.
Chip layer: PBOC, aligned with EMV. UnionPay chip cards follow JR/T 0025, the China financial integrated circuit card specifications โ known in the industry as the PBOC specifications, with full texts retrievable on People's Bank of China websites. Its debit/credit application shares its lineage with EMV, so DE55 carries ordinary BER-TLV chip data: 9F26, 95, 9B and friends appear as usual, and a generic TLV parser takes it apart. The chip data is the least exotic part of a UnionPay message.
Standard field grammar. Since the anchor is the 1987 edition, the standard-defined fields โ PAN, processing code, amount, STAN, RRN and the rest โ are documented territory. See the complete data element list; no private document required.
None of the following has an authoritative public version โ it belongs to the interface specification (layer three):
Searching for "UnionPay interface documentation" quickly lands on open.unionpay.com โ the UnionPay Open Platform. Those documents describe merchant- and partner-facing HTTPS APIs (form/JSON payloads with signature verification) for online payments and industry integrations. They are not the institution-to-institution 8583 interface. The two systems solve different problems, and their fields don't map onto each other โ reading Open Platform docs against an 8583 dump is a category error. Flip side: if what you're actually building is merchant-side online acceptance, the Open Platform docs are exactly where you should be, and ISO 8583 is not your problem.
Everything above traces to official or public channels you can check yourself:
๐ Got a message and want to check the skeleton? Paste it into the parser tool โ MTI, bitmaps and standard fields come apart instantly; private fields are shown as raw data. Related: Reading ISO 8583, the complete field list.