1、全面掌握ISO8583报文协议全面掌握ISO8583报文协议全面掌握ISO8583报文协议 我刚进入金融行业时,就知道了IS08583报文协议,我想可能我还没进入这个行业都已经听过了,可知ISO8583的影响力有多大了。最初刚接触它时,确实对其中的一些细节概念不是很清晰,对有些地方比较迷惑。鉴于此,我想很多同行也必然会经历同样得阶段,所以我写下本文,以便大家能够少走一些弯路。同时,我在网上写下我要写“全面掌握ISO8583报文”和“符合CEN/XFS(即WOSA/XFS)规范的SP编写”两篇文章时,很多人都询问我什么时候能够写出来,可知许多人是需要了解这方面的知识的,即使我时间不是很多,也得尽
2、量将这两篇文章写出来,给需要的人提供一些参考。 如果单纯的讲IS08583那些字段的定义,我觉得没有什么意思,标准中已经对每个字段解释的非常详细了,如果你觉得理解英文版的ISO8583规范有些困难,网上也有同行为我们翻译好的中文版ISO8583规范,所以我的目的是达到阅读本文后能够对ISO8583知其然,亦知其所以然,使以前基本没有接触它的人也能够达到掌握ISO8583报文规范。 好了,我们该转入正题了。 最开始时,金融系统只有IBM这些大的公司来提供设备,象各种主机与终端等。在各个计算机设备之间,需要交换数据。我们知道数据是通过网络来传送的,而在网络上传送的数据都是基于0或1这样的二进制数据
3、,如果没有对数据进行编码,则这些数据没有人能够理解,属于没有用的数据。起初的X.25、SDLC以及现在流行的TCP/IP网络协议都提供底层的通讯编码协议,它们解决了最底层的通讯问题,能够将一串字符从一个地方传送到另一个地方。但是,仅仅传送字符串是没有太大意义的,怎样来解析字符串代表什么内容是非常重要的,否则传送一些“0123abcd”的字符串也是无用的乱码。 让我们随着时光回到几十年前的某个时刻,么办,因为你现在解包是当作数据包每个字段都是固定的,用C语言解包时直接依靠指针取固定长度的一串字符做为一个字段。 我们来一一解决这些问题。 第一个问题简单,我在定义ISO8583时除了定义每个字段表示
4、什么,还规定其内容是数字或是字符等即可。考虑可能出现的类型不过有以下几种:字母、数字、特殊字符、年月日等时间、二进制数据。比如我对128个字段中的“商户类型”字段定义其长度是15,同时定义其类型为字母。再精细点,如果“商户类型”里面的数据同时包括数字和字母呢?那我们就定义其类型为字母也可,为数字也可,即一个字段可以同时属于多个类型。 第二个问题稍微复杂点。其本质就是如果我只传128个字段的5个字段,接收方怎么知道我传了哪几个字段给它了。要是我们把剩下的123全部填成0或其他特殊标识,标明该字段不需要使用?这种处理方法没有半点用处,没有解决网络带宽的本质问题,还是要传128个字段。2 4 162
5、 8 256 换个思路,我在报文前面加上个包头,包头里面包含的信息能够让别人知道只传了5个字段。怎样设计这个包头,可以这样,我们用16个字节,即128个bit(一个字节等于8bit)来表示128个字段中的某个字段是否存在。每个bit在计算机的二进制里面不是1就是0,如果是1就表示对应的字段在本次报文中存在,如果是0就是不存在。这样好了,如果别人接收到了ISO8583报文,可以先根据最前面的报文头,就知道紧接着报文头后面的报文有哪些字段,没有哪些字段了。比如,我要发送5个字段,分别属于128个字段中的第2、3、6、8、9字段,我就可以将128bit的报文头填成011001011000000000
6、.,一共128个bit,后面就全是0了。注意其中第2、3、6、8、9位为1,其他都为0。 有了这个128bit的报文头,我们就可以只发送需要的5个字段了。怎样组织报文?先放上这128bit,即2个字节的头,然后在头后面放2、3、6、8、9字段,这些字段紧挨在一起,3和6之间也不需要填上4、5这两个字段了。接收方收到这个报文,它会根据128bit的报文头来解包,它自然知道把第3个字段取出后,就直接在第3字段的后面取第6个字段,每个字段的长度在ISO8583里面都定义好了,很轻松就把数据包解出来了。 这下好了,为了解决上面的第二问题,我们只是在报文中增加了2个字节的数据,就轻松搞定了,我们把这2个
7、字节称为bit map,即位图,用来表示某个位是否存在。不过我们再稍微优化一下,考虑到很多时候报文不需要128个字段这么多,其一半64个字段都不一定能够用完。那我可以将报文头由128bit减到64bit,只有在需要的时候才把剩下的64bit放到报文里面,这样报文长度不又少了1个字节吗? 是个好主意。我们把ISO8583的128个字段中最常见的都放到前64个字段中,那我们可以将处理缩小一倍。这样我一般发送报文时只需发送64bit,即一个字节的报文头,再加上需要的几个字段就可以了。如果有些报文用到64到128之间的字段呢?这个也好办,我把64bit报文头的第一位bit用来代表特殊含义,如果该bit
8、为1,则表示64bit后面跟了剩下的64bit报文头;如果第一位bit为0,则表示64bit后面没有跟剩下的64bit报文头,直接是128个字段中的报文了。那们,接收方会判断一下报头的第一个bit是1还是0,从而知道报文头是64bit还是128bit了,就可以做相应处理。因为报文头第二个64bit属于有时候有,所以我们叫它Extended bit map扩展位图,相应的报文头最开始的64bit我们叫它Primary bit map主位图。我们直接把扩展位图固定放到128个字段的第一个字段,而主位图每个数据包都有,就强制性放在所有128个字段的前面,并不归入128个字段中去。 第三个问题可以考虑
9、这样解决。比如第2个字段是“帐号”,是不定长的,可能有的银行帐号是19位,有的是17位等。我们定ISO8583规范时可以规定第2个字段是25位,这下足够将19和17的情况都包含进来,但是如果以后出现了30位的怎么办?那我们现在将字段定为100位。以后超过100位怎么办,况且如果你只有19位的帐号,我们定义了100位,那81位的数据不是浪费了网络的带宽。看来预先定义一个我们认为比较大的位数是不太好的。 我们这样,对于第2个字段“帐号”,在字段的开头加上“帐号”的长度。比如帐号是0123456789,一共10位,我们变成100123456789,注意前面多了个10,表示后面的10位为帐号。如果你接
10、触过COM里面的BSTR,应该对这种处理比较熟悉了。接收方收到该字段后,它知道ISO8583规定第2个字段“帐号”是变长的,所以会先取前面的2位出来,获取其值,此时为长度,然后根据该长度值知道应该拷贝该字段后面哪几位数据,才是真正的帐号。如果你觉得长度如果只有两位最多只能表示99位长,不太够,我们也定义可以允许前面3位都为长度的变长字段,这样就有999位长,应该够了吧。在规范里面如果我定义某个字段的属性是“LLVAR”,你注意了,其中的LL表示长度,VAR表示后面的数据,两个LL表示两位长,最大是99,如果是三位就是“LLLVAR”,最大是999。这样看我们定义的ISO8583规范文档时直接根
11、据这几个字母就理解某个变长字段的意思了。 该解决的几个问题到这里都解决了,我们来回顾下自己设计的ISO8583规范。其实没有什么,无非是把金融行业可能出现的数据分门别类,排好顺序,接着把它们连接起来,组成一个报文发送出去而已。其中针对该报文的设计进行了一些优化,引入了bit map位图的概念,也算是一个不错的想法。 剩下的工作就简单了,我们就直接收集金融行业可能出现的数据字段类型,分成128个字段类型,如果没有到128个这么多就先保留一些下来,另外考虑到有些人有特殊的要求,我们规定可以将128个字段中的几个字段你自己来定义其内容,也算是一种扩展了。 这样,最后我们就得到了ISO8583规范的那
12、张字段描述表了。想要详细的知道每个字段的含义直接对着表看就可以,比较简单。全文完8583协议编辑词条 摘要ISO8583包(简称8583包)是一个国际标准的包格式,最多由128个字段域组成,每个域都有统一的规定,并有定长与变长之分。8583包前面一段为位图,用来确定包的字段域组成情况。 其中位图是8583包的灵魂,它是打包解包确定字段域的关键, 而了解每个字段域的属性则是填写数据的基础, 1、 位图描述如下: 位图位置:1 格式:定长 类型:B16(二进制16位,16*8=128bit) 描述: 如将位图的第一位设为1,表示使用扩展位图(128个域),否则表示只使用基本位图(64个域)。 如使
13、用某数据域,应在位图中将相应的位设位1,如使用41域,需将位图的41位设为1。 选用条件:如使用65到128域,需设位图域第一位为1 2、变长,定长域说明 如第二域:域名为主帐号, 数据类型为string 长度为22(是长长度不得超过此数) 是个位变长域 由于是位变长,在打包时需在数据域前加上数据的实际长度,如为位,则表示为: 数据值(即前两位为长度) 如第三域:域名为处理码, 数据类型为string 长度为 是个定长域 必须填满位。 附A:ISO8583各域段的说明 1,信息类型(message type)定义 位图位置: 格式:定长 类型:N4 描述: 数据包的第一部分,定义数据包的类型。
14、 数据类型由数据包的发起者设定,应遵循以下要求: 数据包开始部分必须是信息类型; 对不支持的信息类型能给出拒绝应答。 0100授权交易 0110授权交易答复 0200金融交易 0210金融交易答复 0240查询交易 0250查询交易答复 0400冲正交易 0410冲正交易答复 0800管理交易 0810管理交易答复 2,位图(Bit Map) - 基本位图和扩展位图 位图位置:1 格式:定长 类型:B16 描述: 如将位图的第一位设为1,表示使用扩展位图,否则表示只使用基本位图。 如使用某数据域,应在位图中将相应的位设位1,如使用41域,需将位图的41位设为1。 选用条件:如使用65到128域
15、,需设位图域为1 3,Bit02主帐号(Primary Account Number ) 位图位置:02 格式:变长,LLVAR 类型:N.22 描述: 唯一的确认一个用户交易的基本帐号。 由于银行电子服务系统涉及多个应用系统,而帐号长度最多为22位,故将原标准的19长度改为22位。 4, Bit03 处理代码 (Processing Code ) 位图位置:03 格式:定长 类型:N6 描述:用于描述交易对客户帐户造成何种影响的代码。 处理代码和信息码一起可唯一定义一种交易的类型。 处理代码由以下三部分组成: 位置描述 12交易动作码 34付出帐户类型,用于借记类,如查询、代收费、转场交易。
16、 56收入帐户类型,用于代收费、转帐等。 其中: ff : 付出帐户 tt: 收入帐户 * 视主机而定 5,Bit04 交易金额 (Amount, Transaction) 位图位置:04 格式:定长 类型:N12 描述:帐户人要求交易的交易金额,不含任何处理和交易费用。 金额的表示和货币代码有关,应能表示相应货币的最小单位。参ISO4217有关货币代码定义。 如“000000000100”用于表示美元,表示1.00元;如用于表示意大利货币,则表示100里拉。 对于查询等交易,应设交易金额为“000000000000”。 6,Bit07交易日期和时间Transmission Date and
17、Time 位图位置:07 格式:定长,MMDDhhmmss 类型:N10 描述:本地交易日期和时间 7,Bit11系统跟踪号(Systems Trace Audit Number) 位图位置:11 格式:定长 类型:N6 描述:终端交易的跟踪号码。 交易发起终端填写,和“交易日期、时间”、信息类型等合在一起可唯一定义某一个终端的唯一一笔交易。即是说,在同一天,对一终端,同一类交易的系统跟踪号应保证不同。系统跟踪号在交易过程中不能修改。使用此域来匹配请求和通知类交易的返回。 应用系统使用此域来检查收到的授权、金融、自动冲正、结算、管理和网管等类交易的应答包是否是其请求包的应答。 系统跟踪号不用于
18、匹配自动冲正交易,也不用于在预授权消费时匹配前面的预授权交易。参90域。 对于银行电子服务系统,其系统跟踪号是交易流水号。 8,Bit12本地交易时间(Time ,Local Transaction) 位图位置:12 格式:定长,hhmmss 类型:N6 描述:交易在终端上发生的时间。 本地交易时间在交易处理过程中不能改变。在自动冲正,存贮转发时,本地交易时间不能改变。 9,Bit13本地交易日期(Date ,Local Transaction) 位图位置:13 格式:定长,MMDD 类型:N4 描述:交易在终端上发生的时间。 本地交易时间不能改变,在自动冲正、存储转发交易时,本地交易时间也不
19、能改变。 10,Bit14有效期(Date ,Expiration) 位图位置:14 格式:定长,YYMM 类型:N4 描述:卡的有效期,年年月月 由于卡类写磁格式不同,收单行可能提不出卡的有效期,授权机构从卡的二磁道中提取卡的有效期。如卡,无二磁道,收单行应要求手工录入卡的有效期。 选用条件:100、200、400等交易如没有2、3磁道时,一定要有此域。 11,Bit15结算日期(Date ,Settlement) 位图位置:15 格式:定长,MMDD 类型:N4 描述: 银行电子服务系统和主机结算的时间,格式月月日日。 结帐日期前发生的交易参加当天结算。 在结算时,结帐日期也用于计算处理、
20、交易费用。 12,Bit17获取日期(Date ,Capture) 位图位置:17 格式:定长,MMDD 类型:N4 描述:从主机获取交易的记帐日期。通常用于主机和商户清算。 13,Bit18商户类型(Merchants Type) 位图位置:18 格式:定长 类型:N4 描述:定义商户产品和服务类型的代码 商户类型用于金融、授权交易,用于指定服务点的类型。它主要有以下用途: 决定预授权交易得到确认的最长时间; 控制合法限额; 为交易授权处理,控制网络操作规则; 欺诈检测; 用于商户分类报表; 交易费用处理。 根据ISO8583标准,应使用相应的国家标准。 商户类型代码表如下: 商户类型代码行
21、业类型说明 4215邮递服务 4511民航 4722旅游 4782过桥费 4789其他运输服务 4614电信服务 5542加油站 5812餐馆 5999购物 6010金融机构人工现金支付 6011金融机构自动现金支付 6012金融机构各类服务 7011酒店、旅馆 7299各类个人服务:洗衣、美容、 7399各类商业服务:停车场、租车、广告、其他服务 7699各类维修服务:维修、洗车、拖车 7996娱乐:电影、剧院、体育、游戏 8099医疗服务 8111法律服务 8999各类专业服务:会计、教育、装修、工程 选用条件:服务点终端发起的交易一定要有此域。 14,Bit22服务点输入方式(Point
22、-of-Service Entry Mode) 位图位置:22 格式:定长 类型:N3 描述:在服务终端上定义PIN和PAN的输入方式。 服务点输入方式包含以下两个方面组合而成: 位置描述 12在服务终端上PAN有效期输入方式 33在服务终端上PIN的输入方式 PAN的输入方式编码如下: PAN输入方式描述 00不知 01手工 02读磁卡 03条码扫描仪(BAR) 04光学符号阅读器(OCR) 05集成电路卡(IC卡) PIN的输入方式编码如下: PIN输入方式描述 0不知 1终端能接收PIN 2终端不能接收PIN 选用条件:服务点终端发起的交易一定要有此域。 15,Bit25服务点条件代码(
23、Point-of-Service Condition Code) 位图位置:25 格式:定长 类型:N2 描述:定义交易发生的服务点类型 用法说明:下面是CYBERBANK支持的服务点条件代码。 服务点条件代码服务点终端类型 2自动柜员机(ATM) 10银行终端(10) 14POS 20电话银行 16,Bit32收单机构标识码(Acquirer institution Identification) 位图位置:32 格式:LLVAR 类型:N.11 描述:在金融交易中此域表示交易发生的银行机构的标识码 应答数据包必须和请求数据包此域相同。 17,Bit33向前机构标识码(Forwarding
24、Institution Identification Code) 位图位置:33 格式:LLVAR 类型:N.11 描述:在金融交易中此域表示帐户所在的银行机构的标识码 在网管交易800/810中,本域含有交易发起机构的代码。 应答数据包必须和请求数据包此域相同。 18,Bit35二磁道数据(Track 2 Data) 位图位置:35 格式:LLVAR 类型:Z.37 描述:写在卡二磁道的数据。数据组成遵循ISO78111985标准,数据中包含域分隔符,但不包含卡启始、结束符、LRC等。 收卡行应检测卡的二磁道是否符合国际标准。 为支持国际交换收单行应将二磁道中的分隔符换为“”。除此外不能对二
25、磁道数据进行任何修改,如修改PAN的校验字、有效期、服务码等。 19,Bit36三磁道数据(Track 3 Data) 位图位置:36 格式:LLLVAR 类型:Z.104 描述:写在卡三磁道的数据。数据应组成遵循ISO4909标准,数据中包含域分隔符,但不包含卡启始、结束符、LRC等。 注意:长度说明为3位数字长。 20,Bit37检索索引号(Retrieval Reference Number) 位图位置:37 格式:定长 类型:AN12 描述:检索索引号用来在任何时间标识一个金融、授权、自动冲正交易。 检索索引号不要求打印在持卡人的帐单上。它的主要目的是在收单行和授权行之间定义一个数据项
26、用于跟踪和检索交易。授权机构可以将检索索引号打印在客户的对帐单上。 检索索引号由收单行分配。 选用条件:可包含在收单机构的交易请求中。如在交易请求中有,则应答数据中一定应原样返回。 21,Bit38授权码(Authorization Identification) 位图位置:38 格式:定长 类型:AN6 描述:交易授权机构返回的返回代码。 授权码用于在服务点终端上信用卡授权; 授权机构按网络操作规定,可选使用本域。 22,Bit39返回码(Response Code) 位图位置:39 格式:定长 类型:AN2 描述:对一交易定义其处理结果的编码。 返回码用于说明授权机构对金融(授权)交易的处
27、理状态;也用来指明自动冲正交易的冲正原因;还用来指出目标主机已接收到文件修改、结算、管理、网管等交易请求。 返回码应尽可能准确,应尽可能描述清楚所遇到的问题和状态。网络交换主机、收单行主机有可能会按不同的返回码收取不同的交易处理费用,并执行不同的处理过程。 23,Bit41收卡单位终端标识码(Card Acceptor Terminal Identification) 位图位置:41 格式:定长 类型:ANS8 描述:定义在收单单位中定义一个服务终端的标识码,在同一商户中服务终端标识码应唯一。 24,Bit42收卡商户定义码(Card Acceptor Identification Code)
28、 位图位置:42 格式:定长 类型:ANS15 描述:在本地和网络中定义交易单位(商户)的编码。 25,Bit43收卡商户位置(Card Acceptor Location) 位图位置:43 格式:定长 类型:ANS40 描述:在本地和网络中定义收卡单位(商户)的国家、省。城市等。 选用条件:如对外卡网络,一定要包含此域。 26,Bit44附加返回数据(Additional ResponseData) 位图位置:44 格式:LLVAR 类型:ANS.25 描述:在金融(授权)交易中授权机构返回的其他信息。 27,Bit48附加数据-私用(Additional Data-Private) 位图位
29、置:48 格式:LLLVAR 类型:ANS.999 描述:银行电子服务系统使用此域作以下用途 存放批量查询的返回数据 其格式与输出格式表对应 28,Bit49交易货币代码(Currency Code,Transaction) 位图位置:49 格式:定长 类型:AN3 描述:按ISO4217定义的交易货币代码,用来表示“交易金额”(field04)所用的货币种类。 交易货币代码是指在收单单位进行交易所用的交易种类。 29,Bit50结算货币代码(Currency Code,Settlement) 位图位置:50 格式:定长 类型:AN3 描述:按ISO4217定义的结算货币代码,用来表示结算金额
30、、结算处理费、结算交易费等所用的货币种类。 结算货币代码是指在进行结算和清算过程中所用的货币种类。 30,Bit52用户密码(PIN)数据(PIN Data) 位图位置:52 格式:定长 类型:B16 描述:用户在服务终端上交易用于识别用户合法性的一些数字。 PIN在分行主机用分行主机密钥按ANSIX9.8标准加密,形成密文块。 选用条件:如果在终端上输入了密码,就需要此域。 31,Bit53密码相关控制信息(Security Related Control) 位图位置:53 格式:定长 类型:AN16 描述:本域提供有关密码块的附加信息,用于指出用于PIN计算的PIN key,用于MAC计算的MAC key。 本域格式如下表所示: 01格式代码2N“20” 23PIN加密算法2N“01”:DES 45密文块格式2N“01”:ANSI 6PIN密钥索引1N1或2 7MAC密钥索引1N1或2 811MAC检查数据4B 1215填充4N 在BOC信用卡网络中PIN和MAC各使用两个密钥-1号和2密钥,交易中
copyright@ 2008-2022 冰豆网网站版权所有
经营许可证编号:鄂ICP备2022015515号-1