ISO 8583 Tutorial – Introduction for Beginners

本文介绍ISO8583标准的基础知识,包括消息结构、类型标识符、位图及数据元素等内容,帮助读者理解银行及金融交易中ISO8583的使用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

http://jimmod.com/blog/2011/07/25/jimmys-blog-iso-8583-introduction-beginners-tutorial/


ISO 8583 Tutorial article

Introduction

Lately I’ve handle several financial project that allow me to understand bank and financial transaction better.
All (or most?) financial transaction is using ISO 8583 standard, which at first I thought is a complicated standard. But after learn and see how it implemented it’s not as complex as I thought.
In this post I will try to explain (based on my experience :) before I go deeper on the programming side.

Although it’s a ‘standard’ I see that’s many variant for the detail implementation of ISO 8583.

Financial transaction is communication between 2 system through socket connection.
After connection established, each system can send message in ISO 8583 format which commonly will be request and the other system will response.
From my experience the communication will be start with sign on and then the financial transactions.
Periodically an echo message is send to make sure the other system is still alive.

If I break down the flow:

  1. System A open connection to System B (through specific IP and Port).
  2. Connection established.
  3. System A send Sign-On request message.
  4. System B send Sign-on response message.
  5. System A will start send Echo request message periodically (e.g every 1 minute).
  6. System B will send Echo response message when receive Echo request message.
  7. When financial transaction happen, System A will send Transaction request message.
  8. Then System B will send Transaction response message.
  9. If something wrong happen (usually timeout so System A didn’t get the response), System A will send Reversal request message to cancel the previous transaction.
  10. System B will send Reversal response message.

I hope my explaination give clear basic understanding about the flow.
Next the question will be what’s this ISO 8583 message looks like.
We can separate the message into 3 parts:

  • Message Type Identifier
  • Bitmaps
  • Data Elements

ISO8583 - structure

ISO8583 - structure

Message Type Identifier

Message Type Identifier or MTI is 4 digits numeric that describe the message type. It will explain the message function.
Commonly used:
- 02xx : Financial Message (e.g 0200 for request, 0210 for response)
- 04xx : Reversal Message (e.g 0400 for request, 0410 for response)
- 08xx : Network Management Message (e.g 0800 for request, 0810 for response)
* I found more detail & complete list at wikipedia

Bitmaps

Bitmaps is field that contain information about which data element is presence or absence. Based on the variant it could be 16 hexadecimal characters.
An example will make it clear.

The bitmap is:

B220000000100000

If we break down to binary (I hope you understand how to convert hexadecimal to binary:) :

1011001000100000000000000000000000000000000100000000000000000000

Since I’m nice ;) I create graphical illustration.

Bitmap sample

Bitmap sample

You can see that in this bitmap it explain that data element in the message is 1, 3, 4, 7, 11.
There’s special meaning of first bit of bitmap, if it has value of 1 that mean there’s secondary bitmap.
And what the hell is this secondary bitmap?
Since 16 hexadecimal characters will can only contain info of 64 data element, some transactions contain data element number 64 – 128. That mean the 16 hexadecimal characters is not sufficient.
With set the first bit to ’1′ that will inform there’s additional bitmap, which is another 16 hexadecimal characters.
So in this case the full bitmap example should be:
B2200000001000000000000000800000
Convert to binary:
10110010001000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000100000000000000000000000
From the bitmap, data element presence in the message : 3, 4, 7, 11, 105.

Sample Bitmap complete

Sample Bitmap complete

Data Elements

Data Elements is the essense of the whole ISO message, contain information about the transaction (transaction type, amount, customer id, etc).
Each data element have their on format, attribute and length.
Each data element number also have standard purpose, for example DE #4 is transaction amount.
I will explain based on the example above, since this is only introduction I don’t want to confuse beginner reader. In wikipedia there’s full list.
For our examples, the data element list:

  • #3 – Processing code – n 6
  • #4 – Transaction amount – n 12
  • #7 – Transmission date & time – n 10
  • #11 – Systems trace audit number – n 6
  • #44 – Additional response data – an ..25
  • #105 – Reserved for ISO use – ans …999

To make it practical let’s just use example.
We want to send :

  • DE #3 : 201234
  • DE #4 : 10000
  • DE #7 : 1107221830
  • DE #11 : 123456
  • DE #44 : A5DFGR
  • DE #105 : ABCDEFGHIJ 1234567890

Using above value, the data in data elements :

ISO8583 - de

ISO8583 - de

Based on the type each value will be formatted.

  • a : alpha (including blanks)
  • n : numeric value
  • s : special characters
  • x (no dot) : length is x (fixed)
  • .x (one dot) :  max length is x (1 digit in front as length info)
  • ..xx (two dot) :  max length is xx (2 digit in front as length info)
  • …xxx (three dot) :  max length is xxx (3 digit in front as length info)

ISO Message

From above examples the whole ISO message will be :

0200B2200000001000000000000000800000201234000000010000110722183012345606A5DFGR021ABCDEFGHIJ 1234567890

ISO8583 - full

Conclusion

Ok. This article already long enough :)
Actually I always prefer short article, but on this case it’s cannot be to short.
Anyway, I hope this article is clear enough for you.


资源下载链接为: https://pan.quark.cn/s/f989b9092fc5 HttpServletRequestWrapper 是 Java Servlet API 中的一个工具类,位于 javax.servlet.http 包中,用于对 HttpServletRequest 对象进行封装,从而在 Web 应用中实现对 HTTP 请求的拦截、修改或增强等功能。通过继承该类并覆盖相关方法,开发者可以轻松地自定义请求处理逻辑,例如修改请求参数、添加请求头、记录日志等。 参数过滤:在请求到达处理器之前,可以对请求参数进行检查或修改,例如去除 URL 编码、过滤敏感信息或进行安全检查。 请求头操作:可以修改或添加请求头,比如设置自定义的 Content-Type 或添加认证信息。 请求属性扩展:在原始请求的基础上添加自定义属性,供后续处理使用。 日志记录:在处理请求前记录请求信息,如 URL、参数、请求头等,便于调试和监控。 跨域支持:通过添加 CORS 相关的响应头,允许来自不同源的请求。 HttpServletRequestWrapper 通过继承 HttpServletRequest 接口并重写其方法来实现功能。开发者可以在重写的方法中添加自定义逻辑,例如在获取参数时进行过滤,或在读取请求体时进行解密。当调用这些方法时,实际上是调用了包装器中的方法,从而实现了对原始请求的修改或增强。 以下是一个简单的示例,展示如何创建一个用于过滤请求参数的包装器: 在 doFilter 方法中,可以使用 CustomRequestWrapper 包装原始请求: 这样,每当调用 getParameterValues 方法时,都会先经过自定义的过滤逻辑。 HttpServletRequestWrapper 是 Java Web 开发中一个强大的工具,它提供了灵活的扩展性,允许开发者
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值