Zeta Feature Image

ISO 8583 Simplified: How Card Payments Work

Feb 20, 2024 5 min read

The volume and types of card transactions have surged dramatically with innovation in digital payment systems. If you’re a card portfolio manager or product manager at a financial institution, you’ve been busy enabling your cards for a range of transaction types – contactless card payments using wallets like Apple Pay or Google Pay, POS-based swipe-to-pay or tap-to-pay transactions, e-commerce payments or even cash withdrawals.

However, regardless of the type, there is one single global protocol that powers every card transaction – the ISO 8583. And if you’re responsible for delivering a cutting-edge, seamless payment experience on cards, understanding ISO 8583 can give you a new level of control and insight. For example, understanding the ISO 8583 message format better can help you identify and diagnose authorization delays and fraud flags faster. Importantly, ISO 8583 messages capture rich data which is critical for effective data analytics. Learning how to leverage this can unlock innovations like real-time rewards programs, dynamic transaction controls, or hyper-personalized pricing and fees.

Our blog offers an introduction to the ISO 8583 protocol and explains the message format that ISO 8583 standardizes, highlighting the purpose and format of each segment within the message.

What is ISO 8583?

ISO 8583 is a standard defined by the International Organization for Standardization to facilitate information exchange for transactions using cards. ISO 8583 defines a message format so that different systems involved in a card transaction can exchange information in an interoperable manner. This standard has also evolved over the years to remain updated with newer and safer payment methods. The latest version of this standard is called ISO 8583:2003 and the full specification is available online1.

ISO 8583 today is the global standard using which all the parties in a card transaction exchange information with each other. This includes issuer banks, acquirer banks, network schemes (Visa, Mastercard, Amex, etc.), as well as POS devices. 

ISO 8583 in a typical card payment

When a credit or debit card is used to pay at a store or online, a bunch of things need to happen before a payment confirmation is received:

  1. The Issuing bank (the one that issued the card) needs to verify the cardholder using the card
  2. The Issuer also needs to ensure that there is sufficient balance in the cardholder’s account in order to make the payment, apart from other checks like ensuring the account is not blocked, etc.
  3. The merchant’s bank (the Acquirer) needs this transaction authorization from the Issuer. In case there is insufficient balance in the account or if the cardholder cannot be verified, then the merchant’s bank is intimated to deem the payment unsuccessful.

The complexity here arises from the fact that there are many banks issuing cards and there are many banks issuing merchant accounts. There are also different types of POS device providers (Square dongle, Verifone, Ingenico, etc) and payment mechanisms. Despite this complexity, all the above steps need to be done very quickly in order for the cardholder to have a good payment experience. With the ISO 8583 protocol, it does not matter which issuer or acquirer banks are at either end of a transaction since they all use the same standard to facilitate the payment.

When a cardholder provides card or card details at a merchant, the payment information in ISO 8583 message format travels as shown in Image 1.

Image 1

ISO 8583 Card Payment Journey

The ISO 8583 message travels from a source to a destination. For example, when you dip your card in a POS machine, the POS machine initiates an ISO 8583 message that finally reaches the issuer via the acquirer and the network scheme. In response, the issuer will initiate another ISO 8583 message (indicating success or failure) to respond to the POS machine.

The ISO 8583 message contains the following sections:

  1. Message Type Indicator
    1. This is the part of the message that indicates what the purpose of the message is. For example, a message could be initiated by an acquirer requesting that the payment for a purchase be authorized by the issuer. Or, a message could be a response from the issuer that the payment has been authorized or declined. Similarly, another example could be a message that was initiated by the issuer to reverse a payment (in case of a payment dispute). There are many such purposes covering simple financial information exchange, administrative tasks and settlements. Each of these can be communicated using the message type indicator.
    2. The message type indicator also contains information about who originated the message (acquirer or issuer).
  2. Bitmap
    1. This part of the ISO 8583 message indicates which data elements are actually present. For the party receiving an ISO 8583 message, the bitmap informs what specific information is present or absent. The presence of a data element in a specific message is indicated by a one (1) in the assigned position; a zero (0) indicates the absence of a data element in the assigned position. A bitmap is simply an indexing technique and consists of 64 bits numbered from the left starting with bit 1.
  3. Data Elements
    1. This is the part of the message that contains actual data. There are up to 128 data elements specified in the original ISO 8583:1987 standard and up to 192 data elements in later releases. All these data fields put together cover all the use cases including payments, reversals, settlements, and even administrative activities.
    2. Information about the card number (called primary account number), card expiry date, payment amount, payment date and time, conversion rate, message authentication code (a field that is relevant if the user was asked to enter a password or pin) are all passed as data elements in ISO 8583 and each data element has a defined position (called data field) in the message where it should be present. Each data field can either be of a fixed or variable length.

While the full set of data elements is available online, Image 2 captures some of the main fields to know about.

Image 2

ISO 8583 key data fields

Getting familiar with 0s and 1s

In case you’re wondering how an ISO 8583 message really looks, the following is an actual example of one. Can you spot the card number and payment amount?

01710000160102017100000000000000000000000000000000000100F6E4668128E0F2160000000000000004104421420129771088000000000000000001000000000001060612193161000000610000000005562702594703560500000000061234561B04421420129771088D2702226984F5F1F7F5F9F8F6F9F9F4F0F0E3F0F0F0F0F14040D4F0F0F0F0F1404040404040404040E3C5E2E340D4C5D9C3C8C1D5E3404040404040404040404040D4E4D4C2C1C940404040404040C9D50356035603563A71D9C9F633B7976E01006B9F34034103029F02060000000010009F37041759B99F820258008407A00000000410109F1A0203569C01009F3602000C9F26081D0C9985148B8A2F5F2A0203569F10120114250000044000DAC100000000000000009A03220606950500000000009F3303E0E8E89F2701800635000010000010400000000000000002901826391489650580000000021C01000000000000000000010954954079939602231034727993000000

Were you able to spot the following?

4421420129771088: This is the card number

000000000001: Transaction amount is 1

0606121931: Transaction was initiated on 6th of June at 12h:19m:31s GMT

01710000160102017100000000000000000000000000000000000100F6E4668128E0F2160000000000000004104421420129771088000000000000000001000000000001060612193161000000610000000005562702594703560500000000061234561B04421420129771088D2702226984F5F1F7F5F9F8F6F9F9F4F0F0E3F0F0F0F0F14040D4F0F0F0F0F1404040404040404040E3C5E2E340D4C5D9C3C8C1D5E3404040404040404040404040D4E4D4C2C1C940404040404040C9D50356035603563A71D9C9F633B7976E01006B9F34034103029F02060000000010009F37041759B99F820258008407A00000000410109F1A0203569C01009F3602000C9F26081D0C9985148B8A2F5F2A0203569F10120114250000044000DAC100000000000000009A03220606950500000000009F3303E0E8E89F2701800635000010000010400000000000000002901826391489650580000000021C01000000000000000000010954954079939602231034727993000000

That is it for now. Be sure to check out our next blog on contactless card payments and how tokenization keeps your card information safe during online checkouts!

Footnotes
  1. ISO.org, Interchange Message Specifications

About Author
author profile pic
Director, Product
Bharathi Shekar is a Director of Product at Zeta and leads a product portfolio covering payments and data. An engineer turned product manager, he has over 20 years of experience leading product and engineering teams. Bharathi is a passionate and hands-on creator and is credited with 17 patents and 4 defensive publications. Prior to Zeta, Bharathi led [Read more]

Related Articles
Stay connected! Subscribe to our newsletter