International Organization For Standardization Payment Cards
International Organization For Standardization Payment Cards
International Organization For Standardization Payment Cards
ISO 8583 Financial transaction card originated messages Interchange message specifications is
the International Organization for Standardization standard for systems that exchange electronic
transactions made by cardholders using payment cards. It has three parts:
Part 2: Application and registration procedures for Institution Identification Codes (IIC) [2]
Part 3: Maintenance procedures for messages, data elements and code values [3]
Introduction
A card-based transaction typically travels from a transaction acquiring device, such as a point-of-sale
terminal or an automated teller machine (ATM), through a series of networks, to a card issuing system
for authorization against the card holder's account. The transaction data contains information derived
from the card (e.g., the account number), the terminal (e.g., the merchant number), the transaction
(e.g., the amount), together with other data which may be generated dynamically or added by
intervening systems. The card issuing system will either authorize or decline the transaction and
generate a response message which must be delivered back to the terminal within a predefined time
period.
ISO 8583 defines a message format and a communication flow so that different systems can exchange
these transaction requests and responses. The vast majority of transactions made at ATMs use ISO
8583 at some point in the communication chain, as do transactions made when a customer uses a card
to make a payment in a store (EFTPOS). In particular, both the MasterCard and Visa networks base
their authorization communications on the ISO 8583 standard, as do many other institutions and
networks. ISO 8583 has no routing information, so is sometimes used with a TPDU header.
Cardholder-originated transactions include purchase, withdrawal, deposit, refund, reversal, balance
inquiry, payments and inter-account transfers. ISO 8583 also defines system-to-system messages for
secure key exchanges, reconciliation of totals, and other administrative purposes.
Although ISO 8583 defines a common standard, it is not typically used directly by systems or
networks. It defines many standard fields (data elements) which remain the same in all systems or
networks, and leaves a few additional fields for passing network specific details. These fields are used
by each network to adapt the standard for its own use with custom fields and custom usages.
The placements of fields in different versions of the standard varies; for example, the currency
elements of the 1987 and 1993 versions are no longer used in the 2003 version, which holds currency
as a sub-element of any financial amount element. As of writing, ISO 8583:2003 has yet to achieve
wide acceptance.
An ISO 8583 message is made of the following parts:
This is a 4 digit numeric field which classifies the high level function of the message. A message type
indicator includes the ISO 8583 version, the Message Class, the Message Function and the Message
Origin, each described briefly in the following sections. The following example (MTI 0110) lists what
each digit indicates:
0xxx -> version of ISO 8583 (for example: 1987 version)
x1xx -> class of the Message (for example: Authorization Message)
xx1x -> function of the Message (for example: Request Response)
xxx0 -> who began the communication (for example: Acquirer)
Third position depicts whether the message type is Request or response. If "xx1x" is the MTI then, it
is "Response" message. and if the MTI is "xx0x", it is "Request" message.
Message class
Position two of the MTI specifies the overall purpose of the message.
Position
Meaning
x0xx
Reserved by ISO
Usage
Determine if funds are available, get an approval but do not
post to account
x1xx
Authorization message
x2xx
Financial messages
Single Message System (SMS), no file exchange after this
x3xx
x4xx
x5xx
Reconciliation Message
x6xx
Administrative Message
x7xx
x8xx
x9xx
Used for secure key exchange, logon, echo test and other
network functions
Message function
Position three of the MTI specifies the message function which defines how the message should flow
within the system. Requests are end-to-end messages (e.g., from acquirer to issuer and back with
timeouts and automatic reversals in place), while advices are point-to-point messages (e.g., from
terminal to acquirer, from acquirer to network, from network to issuer, with transmission guaranteed
over each link, but not necessarily immediately).
Position
xx0x
xx1x
xx2x
xx3x
xx4x
xx5x
xx6x
xx7x
xx8x
xx9x
Meaning
Request
Request response
Advice
Advice Response
Notification
Notification Acknowledgement
Instruction (ISO 8583:2003 only)
Instruction Acknowledgement (ISO 8583:2003 only)
Reserved for ISO use. (Some implementations use for Response acknowledgment)
Reserved for ISO use. (Some implementations use for Negative acknowledgment)
Message origin Position four of the MTI defines the location of the message source within the
payment chain.
Position
xxx0
xxx1
xxx2
xxx3
xxx4
xxx5
Meaning
Acquirer
Acquirer Repeat
Issuer
Issuer Repeat
Other
Other Repeat
Examples Bearing each of the above four positions in mind, an MTI will completely specify what a
message should do, and how it is to be transmitted around the network. Unfortunately, not all ISO
8583 implementations interpret the meaning of an MTI in the same way. However, a few MTIs are
relatively standard:
MTI
Meaning
Usage
Request from a point-of-sale terminal for authorization for a
cardholder purchase
Request response to a point-of-sale terminal for authorization
for a cardholder purchase
When the Point of Sale device breaks down and you have to
sign a voucher
If the advice times out
Confirmation of receipt of authorization advice
Request for funds, typically from an ATM or pinned point-ofsale device
Issuer response to request for funds
e.g. Checkout at a hotel. Used to complete transaction initiated
with authorization request
If the advice times out
Confirmation of receipt of financial advice
File Update/Transfer Advice
0330
0400
0510
0800
Processing Code
The following is a table specifying the message type and processing code for each transaction type.
Transaction
Authorization
Balance Inquiry
Sale
Cash
Void
Mobile Topup
Message Type
0100
0100
0200
0200
0200
0200
Processing Code
00 a0 0x
31 a0 0x
00 a0 0x
01 a0 0x
02 a0 0x
57 a0 0x
Response code
The following table shows response codes and their meanings. [4]
Code
Meaning
00
Successful approval/completion or that V.I.P. PIN verification is valid
01
Refer to card issuer
02
Refer to card issuer, special condition
03
Invalid merchant or service provider
04
Pickup card
05
Do not honor
06
Error
07
Pickup card, special condition (other than lost/stolen card)
10
Partial Approval
11
V.I.P. approval
12
Invalid transaction
Invalid amount (currency conversion field overflow) or amount exceeds maximum for card
13
program
14
Invalid account number (no such number)
15
No such issuer
17
Customer cancellation
19
Re-enter transaction
20
Invalid response
21
No action taken (unable to back out prior transaction)
22
Suspected Malfunction
25
Unable to locate record in file, or account number is missing from the inquiry
28
File is temporarily unavailable
30
Format Error
41
Pickup card (lost card)
43
Pickup card (stolen card)
51
Insufficient funds
52
53
54
55
57
58
59
61
62
63
65
68
75
76
77
78
80
81
82
83
85
91
92
93
94
95
96
B1
N0
N3
N4
N7
P2
P5
P6
Q1
R0
R1
R3
XA
XD
Z3
No checking account
No savings account
Expired card
Incorrect PIN
Transaction not permitted to cardholder
Transaction not allowed at terminal
Suspected fraud
Activity amount limit exceeded
Restricted card (for example, in Country Exclusion table)
Security violation
Activity count limit exceeded
Response received too late
Allowable number of PIN-entry tries exceeded
Unable to locate previous message (no match on Retrieval Reference number)
Previous message located for a repeat or reversal, but repeat or reversal data are inconsistent
with original message
Blocked, first usedThe transaction is from a new cardholder, and the card has not been
properly unblocked.
Visa transactions: credit issuer unavailable. Private label and check acceptance: Invalid date
PIN cryptographic error found (error found by VIC security module during PIN decryption)
Negative CAM, dCVV, iCVV, or CVV results
Unable to verify PIN
No reason to decline a request for account number verification, address verification, CVV2
verification, or a credit voucher or merchandise return
Issuer unavailable or switch inoperative (STIP not applicable or available for this transaction)
Destination cannot be found for routing
Transaction cannot be completed, violation of law
Duplicate Transmission
Reconcile error
System malfunction, System malfunction or certain field error conditions
Surcharge amount not permitted on Visa cards (U.S. acquirers only)
Force STIP
Cash service not available
Cashback request exceeds issuer limit
Decline for CVV2 failure
Invalid biller information
PIN Change/Unblock request declined
Unsafe PIN
Card Authentication failed
Stop Payment Order
Revocation of Authorization Order
Revocation of All Authorizations Order
Forward to issuer
Forward to issuer
Unable to go online
Bitmaps
Within ISO 8583, a bitmap is a field or subfield within a message which indicates which other data
elements or data element subfields may be present elsewhere in a message.
A message will contain at least one bitmap, called the Primary Bitmap which indicates which of Data
Elements 1 to 64 are present. A secondary bitmap may also be present, generally as data element one
and indicates which of data elements 65 to 128 are present. Similarly, a tertiary, or third, bitmap can
be used to indicate the presence or absence of fields 129 to 192, although these data elements are
rarely used.
The bitmap may be transmitted as 8 bytes of binary data, or as 16 hexadecimal characters 0-9, A-F in
the ASCII or EBCDIC character sets.
A field is present only when the specific bit in the bitmap is true. For example, byte '82x is binary
'1000 0010' which means fields 1 and 7 are present in the message and fields 2, 3, 4, 5, 6, and 8 are
not present.
Examples ----Bitmap
4210001102C04804
7234054128C28805
8000000000000001
0000000000000003
(secondary bitmap)
Defines presence of
Fields 2, 7, 12, 28, 32, 39, 41, 42, 50, 53, 62
Fields 2, 3, 4, 7, 11, 12, 14, 22, 24, 26, 32, 35, 37, 41, 42, 47, 49, 53, 62, 64
Fields 1, 64
Fields 127, 128
Abbreviation
a
n
s
an
as
ns
ans
b
z
. or .. or ...
x or xx or xxx
Meaning
Alpha, including blanks
Numeric values only
Special characters only
Alphanumeric
Alpha & special characters only
Numeric and special characters only
Alphabetic, numeric and special characters.
Binary data
Tracks 2 and 3 code set as defined in ISO/IEC 7813 and ISO/IEC 4909 respectively
variable field length indicator, each . indicating a digit.
fixed length of field or maximum length in the case of variable length fields.
Additionally, each field may be either fixed or variable length. If variable, the length of the field will
be preceded by a length indicator.
Type
Fixed
Meaning
no field length used
Where 0 < LL < 100, means two leading digits LL specify the field
LLVAR or (..xx)
length of field VAR
Where 0 < LLL < 1000, means three leading digits LLL specify the field
LLLVAR or (...xxx)
length of field VAR
LL can be 1 or 2 bytes. For example, if compressed as one hex byte,
'27x means there are 27 VAR bytes to follow. If ASCII, the two bytes
LL and LLL are hex or
'32x, '37x mean there are 27 bytes to follow. 3 digit field length LLL
ASCII. A VAR field can be
uses 2 bytes with a leading '0' nibble if compressed, or 3 bytes if ASCII.
compressed or ASCII
The format of a VAR data element depends on the data element type. If
depending of the data
numeric it will be compressed, e.g. 87456 will be represented by 3 hex
element type.
bytes '087456x. If ASCII then one byte for each digit or character is
used, e.g. '38x, '37x, '34x, '35x, '36x.
ISO-defined data elements
Data Field Type
Usage
1
b 64
Bit map (b 128 if secondary is present and b 192 if tertiary is present)
2
n ..19
Primary account number (PAN)
3
n6
Processing code
4
n 12
Amount, transaction
5
n 12
Amount, settlement
6
n 12
Amount, cardholder billing
7
n 10
Transmission date & time
8
n8
Amount, cardholder billing fee
9
n8
Conversion rate, settlement
10
n8
Conversion rate, cardholder billing
11
n6
System trace audit number (STAN)
12
n6
Time, local transaction (hhmmss)
13
n4
Date, local transaction (MMDD)
14
n4
Date, expiration
15
n4
Date, settlement
16
n4
Date, conversion
17
n4
Date, capture
18
n4
Merchant type
19
n3
Acquiring institution country code
20
n3
PAN extended, country code
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
n3
an 12
n3
n3
n2
n2
n1
x+n 8
x+n 8
x+n 8
x+n 8
n ..11
n ..11
ns ..28
z ..37
n ...104
an 12
an 6
an 2
an 3
ans 8
ans 15
43
ans 40
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
an ..25
an ..76
an ...999
an ...999
an ...999
a or n 3
a or n 3
a or n 3
b 64
n 16
an ...120
ans999
ans ...999
ans ...999
ans ...999
ans ...999
ans ...999
ans ...999
ans ...999
ans ...999
b 16
b1
n1
n2
n3
n3
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
n3
n4
n4
n6
n 10
n 10
n 10
n 10
n 10
n 10
n 10
n 10
n 12
n 12
n 12
n 12
n 16
n 16
n 16
n 16
n 42
an 1
an 2
an 5
an 7
an 42
b 64
x+n 16
ans 25
n ..11
n ..11
ans ..17
ans ..28
ans ..28
ans ...100
ans ...999
ans ...999
ans ...999
ans ...999
ans ...999
ans ...999
ans ...999
ans ...999
ans ...999
ans ...999
ans ...999
ans ...999
ans ...999
ans ...999
ans ...999
120
121
122
123
124
125
126
127
128
ans ...999
ans ...999
ans ...999
ans ...999
ans ...999
ans ...999
ans ...999
ans ...999
b 64