8583报文解析

合集下载

报文解析学习——8583设计原理

报文解析学习——8583设计原理

8583报文设计原理ISO8583报文(简称8583包)又称8583报文是一个国际标准的包格式,最多由128个字段域组成,每个域都有统一的规定,并有定长与变长之分。

8583包前面一段为位图,用来确定包的字段域组成情况。

其中位图是8583包的灵魂,它是打包、解包确定字段域的关键。

而了解每一个字段域的属性则是填写数据的基础。

POS终端上送POS中心的消息报文结构包括TPDU、报文头和应用数据三部分:——TPDU说明:长度为10个字节,压缩时用BCD码表示为5个字节长度的数值。

——报文头说明:总长度为12字节,压缩时用BCD码表示为6个字节长度的数值。

——应用数据说明:一般长度都是4个字节,压缩时用BCD码表示为2个字节的长度的数值。

所以,上述报文中前五个字节为TPDU,即60 00 03 00 00 (红线标注)报文头占用六个字节,即60 31 00 31 07 30 (蓝线标注)应用数据占用两个字节,即02 00 也就是"0200"。

应用数据部分指定消息类型(例如余额查询、消费等交易等消费类型)(黑线标注)应用数据之后的若干个字节表示位图。

首先取第十四个字节,即0x30,转化为二进制00110000,在该字节的第一位为0(从左往右)表示当前报文中只需要包括64个域(用8个字节表示),也就是从当前字节开始连续8个字节为位图(包括当前字节),如果要包括128个域(用16个字节表示),该位为1。

《1》位图分析:(bit map 域指定了哪些域存在。

域是从1开始的)取表示位图的8个字节即30 20 04 C0 20 C0 98 11转化为二进制为:00110000 00100000 00000100 11000000 00100000 11000000 10011000 00010001位图中为1的位置即代表相应的域,在上面的二进制位中从左往右有第3位、第4位、第11位、第22位、第25位、第26位、第35位、第41位、第42位、第49位、第52位、第53位、第60位、第64位。

8583报文39域对照码

8583报文39域对照码

8583报文39域对照码对应答码的处理交易返回POS终端时都有39 域,POS终端和终端操作员根据应答码要采取相应的操作,可以把操作分为以下几类:A:交易成功B:交易失败,可重试C:交易失败,不需要重试D:交易失败, 终端操作员处理E:交易失败,系统故障,不需要重试注1:如果 39 域的内容不能在下表中找到,就显示“交易失败”注2:如果POS交易的批次号和网络中心批次号不一致时应答码会填“77”,此时POS机应当提示操作员重新签到,再作交易。

表 C.1 应答码表代码意义类别原因/采取的措施POS显示的内容00 承兑或交易成功 A 承兑或交易成功交易成功01 查发卡行 C 查发卡行交易失败,请联系发卡行02 查发卡行的特殊条件 C 可电话向发卡行查询交易失败,请联系发卡行03 无效商户 C 商户需要在银行或中心登记商户未登记04 没收卡 D 操作员没收卡没收卡,请联系收单行05 不予承兑 C 发卡不予承兑交易失败,请联系发卡行06 出错 E 发卡行故障交易失败,请联系发卡行07 特殊条件下没收卡 D 特殊条件下没收卡没收卡,请联系收单行09 请求正在处理中 B 重新提交交易请求交易失败,请重试12 无效交易 C 发卡行不支持的交易交易失败,请重试13 无效金额 B 金额为0 或太大交易金额超限,请重试14 无效卡号 B 卡种未在中心登记或读卡号有误无效卡号,请联系发卡行15 无此发卡行 C 此发卡行未与中心开通业务此卡不能受理19 重新送入交易 C 刷卡读取数据有误,可重新刷卡交易失败,请联系发卡行20 无效应答 C 无效应答交易失败,请联系发卡行21 不做任何处理 C 不做任何处理交易失败,请联系发卡行22 怀疑操作有误 C POS状态与中心不符,可重新签到操作有误,请重试23 不可接受的交易费 C 不可接受的交易费交易失败,请联系发卡行25 未能找到文件上记录 C 发卡行未能找到有关记录交易失败,请联系发卡行30 格式错误 C 格式错误交易失败,请重试31 银联不支持的银行 C 此发卡方未与中心开通业务此卡不能受理33 过期的卡 D 过期的卡,操作员可以没收过期卡,请联系发卡行34 有作弊嫌疑 D 有作弊嫌疑的卡,操作员可以没收没收卡,请联系收单行35 受卡方与安全保密部门联系 D 有作弊嫌疑的卡,操作员可以没收没收卡,请联系收单行36 受限制的卡 D 有作弊嫌疑的卡,操作员可以没收此卡有误,请换卡重试37 受卡方呼受理方安全保密部门(没收卡)D 有作弊嫌疑的卡,操作员可以没收没收卡,请联系收单行38 超过允许的PIN试输入D 密码错次数超限,操作员可以没收密码错误次数超限代码意义类别原因/采取的措施POS显示的内容39 无此信用卡账户 C 可能刷卡操作有误交易失败,请联系发卡行40 请求的功能尚不支持 C 发卡行不支持的交易类型交易失败,请联系发卡行41 丢失卡 D 挂失的卡,操作员可以没收没收卡,请联系收单行42 无此账户 B 发卡行找不到此账户交易失败,请联系发卡方43 被窃卡 D 被窃卡,操作员可以没收没收卡,请联系收单行44 无此投资账户 C 可能刷卡操作有误交易失败,请联系发卡行51 无足够的存款 C 账户内余额不足余额不足,请查询52 无此支票账户 C 无此支票账户交易失败,请联系发卡行53 无此储蓄卡账户 C 无此储蓄卡账户交易失败,请联系发卡行54 过期的卡 C 过期的卡过期卡,请联系发卡行55 不正确的PIN C 密码输错密码错,请重试56 无此卡记录 C 发卡行找不到此账户交易失败,请联系发卡行57 不允许持卡人进行的交易 C 不允许持卡人进行的交易交易失败,请联系发卡行58 不允许终端进行的交易 C 该商户不允许进行的交易终端无效,请联系收单行或银联59 有作弊嫌疑 C 交易失败,请联系发卡行60 受卡方与安全保密部门联系 C 交易失败,请联系发卡行61 超出取款金额限制 C 一次交易的金额太大金额太大62 受限制的卡 C 交易失败,请联系发卡行63 违反安全保密规定 C 违反安全保密规定交易失败,请联系发卡行64 原始金额不正确 C 原始金额不正确交易失败,请联系发卡行65 超出取款次数限制 C 超出取款次数限制超出取款次数限制66 受卡方呼受理方安全保密部门C 受卡方呼受理方安全保密部门交易失败,请联系收单行或银联67 捕捉(没收卡) C 捕捉(没收卡)没收卡68 收到的回答太迟 C 发卡行规定时间内没有回答交易超时,请重试75 允许的输入PIN次数超限 C 允许的输入PIN次数超限密码错误次数超限77 需要向网络中心签到D POS批次与网络中心不一致请向网络中心签到79 脱机交易对账不平 C POS终端上传的脱机数据对账不平POS终端重传脱机数据90 日期切换正在处理 C 日期切换正在处理交易失败,请稍后重试91 发卡行或银联不能操作 C 电话查询发卡方或银联,可重作交易失败,请稍后重试92 金融机构或中间网络设施找不到或无法达到C电话查询发卡方或网络中心,可重作交易失败,请稍后重试93 交易违法、不能完成 C 交易违法、不能完成交易失败,请联系发卡行94 重复交易 C 查询网络中心,可重新签到作交易交易失败,请稍后重试95 调节控制错 C 调节控制错交易失败,请稍后重试96 系统异常、失效 C 发卡方或网络中心出现故障交易失败,请稍后重试97 POS终端号找不到D 终端未在中心或银行登记终端未登记,请联系收单行或银联98 银联收不到发卡行应答 E 银联收不到发卡行应答交易超时,请重试99 PIN格式错 B 可重新签到作交易校验错,请重新签到A0 MAC 校验错 B 可重新签到作交易校验错,请重新签到。

全面掌握ISO8583报文协议

全面掌握ISO8583报文协议

全面掌握ISO8583报文协议我刚进入金融行业时,就知道了IS08583报文协议,我想可能我还没进入这个行业都已经听过了,可知ISO8583的影响力有多大了。

最初刚接触它时,确实对其中的一些细节概念不是很清晰,对有些地方比较迷惑。

鉴于此,我想很多同行也必然会经历同样得阶段,所以我写下本文,以便大家能够少走一些弯路。

同时,我在网上写下我要写“全面掌握ISO8583报文”和“符合CEN/XFS(即WOSA/XFS)规范的SP编写”两篇文章时,很多人都询问我什么时候能够写出来,可知许多人是需要了解这方面的知识的,即使我时间不是很多,也得尽量将这两篇文章写出来,给需要的人提供一些参考。

如果单纯的讲IS08583那些字段的定义,我觉得没有什么意思,标准中已经对每个字段解释的非常详细了,如果你觉得理解英文版的ISO8583规范有些困难,网上也有同行为我们翻译好的中文版ISO8583规范,所以我的目的是达到阅读本文后能够对ISO8583知其然,亦知其所以然,使以前基本没有接触它的人也能够达到掌握ISO8583报文规范。

好了,我们该转入正题了。

最开始时,金融系统只有IBM这些大的公司来提供设备,象各种主机与终端等。

在各个计算机设备之间,需要交换数据。

我们知道数据是通过网络来传送的,而在网络上传送的数据都是基于0或1这样的二进制数据,如果没有对数据进行编码,则这些数据没有人能够理解,属于没有用的数据。

起初的X.25、SDLC以及现在流行的TCP/IP网络协议都提供底层的通讯编码协议,它们解决了最底层的通讯问题,能够将一串字符从一个地方传送到另一个地方。

但是,仅仅传送字符串是没有太大意义的,怎样来解析字符串代表什么内容是非常重要的,否则传送一些“0123abcd”的字符串也是无用的乱码。

让我们随着时光回到几十年前的某个时刻,假设我们被推到历史的舞台上,由我们来设计一个通用报文协议,来解决金融系统之间的报文交换,暂且称该协议叫做ISO8583协议。

8583报文

8583报文

[精彩] 8583问题 作者:lcunix发表于:2006-02-19 00:03:51【发表评论】【查看原文】【C/C++讨论区】【关闭】各位高手能否详细的解释一下8583协议htldm回复于:2003-08-31 22:15:18ISO8583包(简称8583包)是一个国际标准的包格式,最多由128个字段域组成,每个域都有统一的规定,并有定长与变长之分。

8583包前面一段为位图,用来确定包的字段域组成情况。

其中位图是8583包的灵魂,它是打包解包确定字段域的关键,而了解每个字段域的属性则是填写数据的基础,1、位图描述如下:位图位置:1格式:定长类型:B16(二进制16位,16*8=128bit)描述:如将位图的第一位设为'1',表示使用扩展位图(128个域),否则表示只使用基本位图(64个域)。

如使用某数据域,应在位图中将相应的位设位'1',如使用41域,需将位图的41位设为'1'。

选用条件:如使用65到128域,需设位图域第一位为'1'2、每个域的定义如下:typedef struct ISO8583{int bit_flag; /*域数据类型0 -- string, 1 -- int, 2 -- binary*/char *data_name; /*域名*/int length; /*数据域长度*/int length_in_byte;/*实际长度(如果是变长)*/int variable_flag; /*是否变长标志0:否 2:2位变长,3:3位变长*/int datatyp; /*0 -- string, 1 -- int, 2 -- binary*/char *data; /*存放具体值*/int attribute; /*保留*/} ISO8583;ISO8583 Tbl8583[128] ={/* FLD 1 */ {0,"BIT MAP,EXTENDED ", 8, 0, 0, 2, NULL,0},/* FLD 2 */ {0,"PRIMARY ACCOUNT NUMBER ", 22, 0, 2, 0, NULL,0},/* FLD 3 */ {0,"PROCESSING CODE ", 6, 0, 0, 0, NULL,0},/* FLD 4 */ {0,"AMOUNT, TRANSACTION ", 12, 0, 0, 1, NULL,0},/* FLD 5 */ {0,"NO USE ", 12, 0, 0, 0, NULL,0},/* FLD 6 */ {0,"NO USE ", 12, 0, 0, 0, NULL,0},/* FLD 7 */ {0,"TRANSACTION DATE AND TIME ", 10, 0, 0, 0, NULL,0},/* FLD 8 */ {0,"NO USE ", 8, 0, 0, 0, NULL,0},/* FLD 9 */ {0,"NO USE ", 8, 0, 0, 0, NULL,0},/* FLD 10 */ {0,"NO USE ", 8, 0, 0, 0, NULL,0},/* FLD 11 */ {0,"SYSTEM TRACE AUDIT NUMBER ", 6, 0, 0, 1, NULL,0},/* FLD 12 */ {0,"TIME, LOCAL TRANSACTION ", 6, 0, 0, 0, NULL,0},/* FLD 13 */ {0,"DATE, LOCAL TRANSACTION ", 4, 0, 0, 0, NULL,0},/* FLD 14 */ {0,"DATE, EXPIRATION ", 4, 0, 0, 0, NULL,0},/* FLD 15 */ {0,"DATE, SETTLEMENT ", 4, 0, 0, 0, NULL,0},/* FLD 16 */ {0,"NO USE ", 4, 0, 0, 0, NULL,0},/* FLD 17 */ {0,"DATE, CAPTURE ", 4, 0, 0, 0, NULL,0},/* FLD 18 */ {0,"MERCHANT'S TYPE ", 4, 0, 0, 0, NULL,0},/* FLD 19 */ {0,"NO USE ", 3, 0, 0, 0, NULL,0},/* FLD 20 */ {0,"NO USE ", 3, 0, 0, 0, NULL,0},/* FLD 21 */ {0,"NO USE ", 3, 0, 0, 0, NULL,0},/* FLD 22 */ {0,"POINT OF SERVICE ENTRY MODE ", 3, 0, 0, 0, NULL,0},/* FLD 23 */ {0,"NO USE ", 3, 0, 0, 0, NULL,0},/* FLD 24 */ {0,"NO USE ", 3, 0, 0, 0, NULL,0},/* FLD 25 */ {0,"POINT OF SERVICE CONDITION CODE ", 2, 0, 0, 0, NULL,0},/* FLD 26 */ {0,"NO USE ", 2, 0, 0, 0, NULL,0},/* FLD 27 */ {0,"NO USE ", 1, 0, 0, 0, NULL,0},/* FLD 28 */ {0,"field27 ", 6, 0, 0, 0, NULL,0},/* FLD 29 */ {0,"NO USE ", 8, 0, 1, 0, NULL,0},/* FLD 30 */ {0,"NO USE ", 8, 0, 1, 0, NULL,0},/* FLD 31 */ {0,"NO USE ", 8, 0, 1, 0, NULL,0},/* FLD 32 */ {0,"ACQUIRER INSTITUTION ID. CODE ", 11, 0, 2, 0, NULL,0},/* FLD 33 */ {0,"FORWARDING INSTITUTION ID. CODE ", 11, 0, 2, 0, NULL,0}, /* FLD 34 */ {0,"NO USE ", 28, 0, 2, 0, NULL,0},/* FLD 35 */ {0,"TRACK 2 DATA ", 37, 0, 2, 0, NULL,0},/* FLD 36 */ {0,"TRACK 3 DATA ",104, 0, 3, 0, NULL,0},/* FLD 37 */ {0,"RETRIEVAL REFERENCE NUMBER ", 12, 0, 0, 0, NULL,0},/* FLD 38 */ {0,"AUTH. IDENTIFICATION RESPONSE ", 6, 0, 0, 0, NULL,0},/* FLD 39 */ {0,"RESPONSE CODE ", 2, 0, 0, 0, NULL,0},/* FLD 40 */ {0,"NO USE ", 3, 0, 0, 0, NULL,0},/* FLD 41 */ {0,"CARD ACCEPTOR TERMINAL ID. ", 8, 0, 0, 0, NULL,0},/* FLD 42 */ {0,"CARD ACCEPTOR IDENTIFICATION CODE ", 15, 0, 0, 0, NULL,0}, /* FLD 43 */ {0,"CARD ACCEPTOR NAME LOCATION ", 40, 0, 0, 0, NULL,0},/* FLD 44 */ {0,"ADDITIONAL RESPONSE DATA ", 25, 0, 2, 0, NULL,0},/* FLD 45 */ {0,"NO USE ", 76, 0, 2, 0, NULL,0},/* FLD 46 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 47 */ {0,"field47 ",999, 0, 3, 0, NULL,0},/* FLD 48 */ {0,"ADDITIONAL DATA --- PRIVATE ",999, 0, 3, 0, NULL,0},/* FLD 49 */ {0,"CURRENCY CODE,TRANSACTION ", 3, 0, 0, 0, NULL,0},/* FLD 50 */ {0,"CURRENCY CODE,SETTLEMENT ", 3, 0, 0, 0, NULL,0},/* FLD 51 */ {0,"NO USE ", 3, 0, 0, 0, NULL,0},/* FLD 52 */ {0,"PERSONAL IDENTIFICATION NUMBER DATA ", 8, 0, 0, 2, NULL,0}, /* FLD 53 */ {0,"SECURITY RELATED CONTROL INformATION", 16, 0, 0, 0, NULL,0}, /* FLD 54 */ {0,"ADDITIONAL AMOUNTS ",120, 0, 3, 0, NULL,0},/* FLD 55 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 56 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 57 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 58 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 59 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 60 */ {0,"NO USE ", 5, 0, 3, 0, NULL,0},/* FLD 61 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 62 */ {0,"NO USE ", 11, 0, 3, 0, NULL,0},/* FLD 63 */ {0,"NO USE ", 11, 0, 3, 0, NULL,0},/* FLD 64 */ {0,"MESSAGE AUTHENTICATION CODE FIELD ", 8, 0, 0, 2, NULL,0},/* FLD 65 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 66 */ {0,"NO USE ", 1, 0, 0, 0, NULL,0},/* FLD 67 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 68 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 69 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 70 */ {0,"SYSTEM MANAGEMENT INformATION CODE ", 3, 0, 0, 0, NULL,0}, /* FLD 71 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 72 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 73 */ {0,"NO USE ", 6, 0, 0, 0, NULL,0},/* FLD 74 */ {0,"NUMBER OF CREDITS ", 10, 0, 0, 0, NULL,0},/* FLD 75 */ {0,"REVERSAL NUMBER OF CREDITS ", 10, 0, 0, 0, NULL,0},/* FLD 76 */ {0,"NUMBER OF DEBITS ", 10, 0, 0, 0, NULL,0},/* FLD 77 */ {0,"REVERSAL NUMBER OF DEBITS ", 10, 0, 0, 0, NULL,0},/* FLD 78 */ {0,"NUMBER OF TRANSFER ", 10, 0, 0, 0, NULL,0},/* FLD 79 */ {0,"REVERSAL NUMBER OF TRANSFER ", 10, 0, 0, 0, NULL,0},/* FLD 80 */ {0,"NUMBER OF INQUIRS ", 10, 0, 0, 0, NULL,0},/* FLD 81 */ {0,"AUTHORIZATION NUMBER ", 10, 0, 0, 0, NULL,0},/* FLD 82 */ {0,"NO USE ", 12, 0, 0, 0, NULL,0},/* FLD 83 */ {0,"CREDITS,TRANSCATION FEEAMOUNT ", 12, 0, 0, 0, NULL,0},/* FLD 84 */ {0,"NO USE ", 12, 0, 0, 0, NULL,0},/* FLD 85 */ {0,"DEBITS,TRANSCATION FEEAMOUNT ", 12, 0, 0, 0, NULL,0},/* FLD 86 */ {0,"AMOUNT OF CREDITS ", 16, 0, 0, 0, NULL,0},/* FLD 87 */ {0,"REVERSAL AMOUNT OF CREDITS ", 16, 0, 0, 0, NULL,0},/* FLD 88 */ {0,"AMOUNT OF DEBITS ", 16, 0, 0, 0, NULL,0},/* FLD 89 */ {0,"REVERSAL AMOUNT OF DEBITS ", 16, 0, 0, 0, NULL,0},/* FLD 90 */ {0,"ORIGINAL DATA ELEMENTS ", 42, 0, 0, 0, NULL,0},/* FLD 91 */ {0,"FILE UPDATE CODE ", 1, 0, 0, 0, NULL,0},/* FLD 92 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 93 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 94 */ {0,"SERVICE INDICATOR ", 7, 0, 0, 0, NULL,0},/* FLD 95 */ {0,"REPLACEMENT AMOUNTS ", 42, 0, 0, 0, NULL,0},/* FLD 96 */ {0,"NO USE ", 8, 0, 0, 0, NULL,0},/* FLD 97 */ {0,"AMOUNT OF NET SETTLEMENT ", 16, 0, 0, 0, NULL,0},/* FLD 98 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 99 */ {0,"SETTLEMENT INSTITUTION ID ", 11, 0, 2, 0, NULL,0},/* FLD 100 */ {0,"RECVEING INSTITUTION ID ", 11, 0, 2, 0, NULL,0},/* FLD 101 */ {0,"FILENAME ", 17, 0, 2, 0, NULL,0},/* FLD 102 */ {0,"ACCOUNT IDENTIFICATION1 ", 28, 0, 2, 0, NULL,0},/* FLD 103 */ {0,"ACCOUNT IDENTIFICATION2 ", 28, 0, 2, 0, NULL,0},/* FLD 104 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 105 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 106 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 107 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 108 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 109 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 110 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 111 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 112 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 113 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 114 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 115 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 116 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 117 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 118 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 119 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 120 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 121 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 122 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 123 */ {0,"NEW PIN DATA ", 8, 0, 3, 2, NULL,0},/* FLD 124 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 125 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 126 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 127 */ {0,"NO USE ",999, 0, 3, 0, NULL,0},/* FLD 128 */ {0,"MESSAGE AUTHENTICATION CODE FIELD ", 8, 0, 0, 2, NULL,0}, };3、变长,定长域说明如第二域:域名为主帐号,数据类型为string长度为22(是长长度不得超过此数)是个2位变长域由于是2位变长,在打包时需在数据域前加上数据的实际长度,如为19位,则表示为:19+数据值(即前两位为长度)如第三域:域名为处理码,数据类型为string长度为6是个定长域必须填满6位。

8583报文解析实例

8583报文解析实例

8583报文解析实例8583报文解析实例:以下是主机从网控器收到的消费数据包(用二位十六进制数表示一个字节):0201 0630 30 30 30 3000 06 30 30 30 30 30 31| 03 22备注:|…|之间是8583数据包(|是人为加的);颜色只作为各个域区分,没其他含义。

解包分析:02 表示是数据开始01 06 表示后面数据长度为106个字节(在06到结束符03之间,不包括03字符,即8583包)60 00 07 08 08 是网控tpdu的地址02 00 8583包开始,表示交易信息码 message_id消费信息码为020030 20 05 00 20 c0 02 01 是数据包的位图,8个字节,64位,3的二进制0011第一位为0,所以没有扩展位图,二进制展开后如下域有信息: 3 4 11 22 24 35 41 42 52 60 61 6203 是数据结束??31 是crc校验:02后面开始,即从01开始到03之间字??节(包括03)异或的结果。

??数据元解包分析:实据元是从位图后开始,到03结束之前。

位图分析有3 4 11 22 24 35 41 42 52 60 61 62 域的信息格式说明:a表示字符,n表示数字,s表示特殊字符,b二进制数据第3域:名称:处理代码格式:n6(固定长度为6的数字)截取字符:00 40 00原始数据:“004000”。

第4域:名称:交易金额格式:n12截取字符:00 00 00 00 99 80原始数据:99.80第11域:名称:系统流水号格式:n6截取字符:00 00 01原始数据:000001第22域:名称:服务点方式格式:n3截取字符:00 21原始数据: “021”第24域:名称:国际网络识别符格式:n3截取字符:00 03原始数据:“003”第35域:名称:第2磁道数据格式:llvar长度为37,取整后有19个字符截取字符:37 62 14 02 10 00 07 41 50 78 d1 56 07 12 20 10 00 00 00 00原始数据:62 14 02 10 00 07 41 50 78 d1 56 07 12 20 10 00 00 00 0第41域:名称:终端号格式:ans8 (字母,数字,特殊字符皆可,长度为8)截取字符:31 32 33 34 35 36 37 38原始数据:“12345678”第42域:名称:商户号格式:ans15截取字符:30 34 33 20 20 20 20 20 20 20 20 20 20 20 20原始数据:“043”第52域:名称:个人密码格式:b64 (表示二进制数据64位)截取字符:c5 8e b2 00 18 03 1e 9a原始数据:c5 8e b2 00 18 03 1e 9a第60域:名称:保留使用(实际存放pos的批次号)格式:lllvar长度为00 06截取字符:00 06 30 30 30 30 30 31原始数据:“000001”第61域:名称:保留使用(实际存放操作员和操作员密码)格式:lllvar长度为00 06截取字符:00 06 30 30 30 30 30 30原始数据:“000000”00操作员,0000密码第62域:名称:保留使用(实际存放pos的票据号)格式:lllvar长度为00 06截取字符:00 06 30 30 30 30 30 31原始数据:“000001”。

系统报文精品解析讲稿

系统报文精品解析讲稿

金融系统ISO8583报文精品解析讲稿ISO8583报文理解,举个例子就是农行与VISA网络之间通讯,各个银行间通讯,ATM或POS通讯都是这个ISO8583报文。

再比如第三方支付网银在线与银行之间的通讯报文也是8583。

1234567891011121314面贴片元件的手工焊接技巧现在越来越多的电路板采用表面贴装元件,同传统的封装相比,它可以减少电路板的面积,易于大批量加工,布线密度高。

贴片电阻和电容的引线电感大大减少,在高频电路中具有很大的优越性。

表面贴装元件的不方便之处是不便于手工焊接。

为此,本文以常见的PQFP封装芯片为例,介绍表面贴装元件的基本焊接方法。

一、所需的工具和材料焊接工具需要有25W的铜头小烙铁,有条件的可使用温度可调和带ESD保护的焊台,注意烙铁尖要细,顶部的宽度不能大于1mm。

一把尖头镊子可以用来移动和固定芯片以及检查电路。

还要准备细焊丝和助焊剂、异丙基酒精等。

使用助焊剂的目的主要是增加焊锡的流动性,这样焊锡可以用烙铁牵引,并依靠表面张力的作用光滑地包裹在引脚和焊盘上。

在焊接后用酒精清除板上的焊剂。

二、焊接方法 1.在焊接之前先在焊盘上涂上助焊剂,用烙铁处理一遍,以免焊盘镀锡不良或被氧化,造成不好焊,芯片则一般不需处理。

2.面贴片元件的手工焊接技巧现在越来越多的电路板采用表面贴装元件,同传统的封装相比,它可以减少电路板的面积,易于大批量加工,布线密度高。

贴片电阻和电容的引线电感大大减少,在高频电路中具有很大的优越性。

表面贴装元件的不方便之处是不便于手工焊接。

为此,本文以常见的PQFP封装芯片为例,介绍表面贴装元件的基本焊接方法。

一、所需的工具和材料焊接工具需要有25W的铜头小烙铁,有条件的可使用温度可调和带ESD保护的焊台,注意烙铁尖要细,顶部的宽度不能大于1mm。

一把尖头镊子可以用来移动和固定芯片以及检查电路。

还要准备细焊丝和助焊剂、异丙基酒精等。

使用助焊剂的目的主要是增加焊锡的流动性,这样焊锡可以用烙铁牵引,并依靠表面张力的作用光滑地包裹在引脚和焊盘上。

ISO8583报文解包和组包

ISO8583报文解包和组包
IS08583报文协议包的解析和封装java源代码
javabytestringexceptionnulllist
一:IS08583包介绍:
ISO8583包(简称8583包)是一个国际标准的包格式,最多由128个字段域组成,每个域都有统一的规定,并有定长与变长之分。
8583包前面一段为位图,用来确定包的字段域组成情况。其中位图是8583包的灵魂,它是打包解包确定字段域的关键, 而了解每个字段域的属性则是填写数据的基础。
{37,1,12,0},
{39,1,2,0},
{40,2,50,2},
{41,1,8,0},
{48,1,52,3},
{120,2,128,3},
};

四:定义BitMapiso类
类说明:此类提供解析请求包和封装信息包两个方法,例如:
package com.lottery.pos.utils;
map = new byte[16];
System.arraycopy(realbody, 0, map, 0, 16);
} else {
map = map8;
}
boolean[] bmap = LoUtils.getBinaryFromByte(map);
System.arraycopy(realbody, tmplen, nextData, 0,nextData.length);
tmplen += nextData.length;
} else {
nextData = new byte[config[bit][2]];
byte[] map8 = new byte[8];

ISO8583报文协议详解

ISO8583报文协议详解

ISO8583报文协议详解ISO8583包(简称8583包)是一个国际标准的包格式,最多由128个字段域组成,每个域都有统一的规定,并有定长与变长之分。

8583包前面一段为位图,用来确定包的字段域组成情况。

其中位图是8583包的灵魂,它是打包解包确定字段域的关键,而了解每个字段域的属性则是填写数据的基础.1、位图描述如下:位图位置:1格式:定长类型:B16(二进制16位,16*8=128bit)描述:如将位图的第一位设为'1',表示使用扩展位图(128个域),否则表示只使用基本位图(64个域)。

如使用某数据域,应在位图中将相应的位设位'1',如使用41域,需将位图的4 1位设为’1’。

选用条件:如使用65到128域,需设位图域第一位为'1’2、每个域的定义如下:typedef struct ISO8583{int bit_flag; /*域数据类型0 —- string, 1 —- int,2 —— binary*/char *data_name; /*域名*/int length;/*数据域长度*/int length_in_byte;/*实际长度(如果是变长)*/int variable_flag; /*是否变长标志0:否2:2位变长, 3:3位变长*/int datatyp; /*0 —- string,1 —- int,2 —- binary*/char *data;/*存放具体值*/int attribute;/*保留*/}ISO8583;ISO8583 Tbl8583[128]={/*FLD 1 */ {0,”BIT MAP,EXTENDED ", 8, 0,0, 2,NULL,0},/* FLD 2 */ {0,"PRIMARY ACCOUNT NUMBER ”, 22,0,2, 0, NULL,0},/* FLD 3 */ {0,"PROCESSING CODE ",6, 0, 0,0,NULL,0},/*FLD 4 */ {0,”AMOUNT,TRANSACTION ",12,0, 0,1, NULL,0},/*FLD 5 */ {0,"NO USE ",12,0, 0,0,NULL,0},/*FLD 6 */ {0,”NO USE ", 12,0, 0,0,NULL,0},/* FLD 7 */ {0,"TRANSACTION DATE AND TIME ", 10,0, 0, 0,NULL,0},/* FLD 8 */ {0,”NO USE ”, 8, 0,0,0, NULL,0},/*FLD 9 */ {0,"NO USE ”, 8,0,0,0, NULL,0},/*FLD 10 */ {0,”NO USE ",8, 0, 0,0, NULL,0},/*FLD 11 */ {0,”SYSTEM TRACE AUDIT NUMBER ”, 6, 0,0,1,NULL,0},/*FLD 12 */ {0,”TIME,LOCAL TRANSACTION ", 6, 0,0,0, NULL,0},/* FLD 13 */ {0,”DA TE, LOCAL TRANSACTION ”,4,0,0, 0, NULL,0},/* FLD 14 */ {0,”DATE, EXPIRATION ", 4, 0, 0,0, NULL,0},/*FLD 15 */ {0,"DA TE,SETTLEMENT ”,4,0,0, 0, NULL,0},/* FLD 16 */ {0,”NO USE ”, 4,0, 0,0, NULL,0},/*FLD 17 */ {0,”DATE,CAPTURE ", 4, 0,0,0, NULL,0},/* FLD 18 */ {0,”MERCHANT'S TYPE ", 4,0,0, 0, NULL,0},/* FLD 19 */ {0,”NO USE ",3, 0, 0,0, NULL,0},/* FLD 20 */ {0,"NO USE ”,3,0, 0, 0, NULL,0},/*FLD 21 */ {0,"NO USE ”,3, 0,0, 0,NULL,0},/*FLD 22 */ {0,"POINT OF SERVICE ENTRY MODE ", 3, 0, 0,0,NULL,0},/* FLD 23 */ {0,”NO USE ”,3, 0,0, 0,NULL,0},/* FLD 24 */ {0,”NO USE ",3,0, 0, 0, NULL,0},/* FLD 25 */ {0,"POINT OF SERVICE CONDITION CODE ”, 2,0,0,0,NULL,0},/*FLD 26 */ {0,”NO USE ", 2, 0,0,0, NULL,0},/*FLD 27 */ {0,”NO USE ”, 1,0,0, 0,NULL,0},/* FLD 28 */ {0,"field27 ", 6, 0,0, 0, NULL,0},/*FLD 29 */ {0,”NO USE ”, 8,0, 1, 0, NULL,0},/* FLD 30 */ {0,"NO USE ”, 8,0,1,0, NULL,0},/* FLD 31 */ {0,”NO USE ",8,0,1,0,NULL,0},/* FLD 32 */ {0,"ACQUIRER INSTITUTION ID. CODE ”,11,0, 2, 0,NULL,0},/*FLD 33 */ {0,"FORW ARDING INSTITUTION ID. CODE ",11,0,2, 0, NULL,0},/*FLD 34 */ {0,"NO USE ", 28,0,2, 0, NULL,0},/* FLD 35 */ {0,”TRACK 2 DATA ”, 37,0,2,0, NULL,0},/* FLD 36 */ {0,”TRACK 3 DATA ",104,0, 3,0, NULL,0},/* FLD 37 */ {0,”RETRIEV AL REFERENCE NUMBER ",12, 0,0,0,NULL,0},/*FLD 38 */ {0,”AUTH. IDENTIFICATION RESPONSE ”,6, 0, 0, 0,NULL,0},/* FLD 39 */ {0,"RESPONSE CODE ", 2,0,0, 0, NULL,0},/*FLD 40 */ {0,”NO USE ”,3, 0, 0, 0, NULL,0},/* FLD 41 */ {0,”CARD ACCEPTOR TERMINAL ID。

解析ISO8583报文实例

解析ISO8583报文实例

解析ISO8583报文实例(Pos应用)现在我们有ISO8583报文如下(十六进制表示法):60 00 03 00 00 60 31 00 31 07 30 02 00 30 20 04 C0 20 C0 98 11 00 00 00 00 00 00 00 00 01 00 03 49 02 10 00 12 30 62 25 82 21 12 99 63 01 5D 15 11 10 10 00 00 35 36 38 35 32 33 31 34 32 33 35 32 31 34 35 32 36 38 35 39 32 33 36 31 35 36 C6 24 83 4D 36 7E 9E 9E 20 00 00 00 00 00 00 00 00 13 22 00 00 08 00 05 00 36 37 41 32 32 39 39 41第一步POS终端上送POS中心的消息报文结构包括TPDU、报文头和应用数据三部分:——TPDU说明:长度为10个字节,压缩时用BCD码表示为5个字节长度的数值。

——报文头说明:总长度为12字节,压缩时用BCD码表示为6个字节长度的数值。

——应用数据说明:一般长度都是4个字节,压缩时用BCD码表示为2个字节的长度的数值。

所以上述报文中前五个字节为TPDU,即60 00 03 00 00报文头占用六个字节,即60 31 00 31 07 30应用数据占用2个字节,即02 00 也就是"0200"——0200金融类请求消息:●POS查询请求。

●POS消费请求。

●POS消费撤销请求。

●POS预授权完成(请求)请求。

●POS预授权完成撤销请求。

●电子现金脱机消费请求。

●分期付款消费请求。

●分期付款消费撤销请求。

●基于PBOC电子钱包/电子现金的IC圈存类交易请求。

●磁条卡现金充值请求。

第二步分析位图:首先取第十四个字节,即0x30 ,转化为二进制为0011 0000,在该字节的第一位为0(从左往右)表示当前报文中只需包括64个域,也就是从当前字节开始连续8个字节为位图(包括当前字节),如要包括128个域,该位为1。

测试socket协议的loadrunner脚本(8583协议)8583报文解析

测试socket协议的loadrunner脚本(8583协议)8583报文解析

Pos机收单系统性能压力测试实战Socket协议测试Loadrunner脚本+8583报文解析Action:#define _EOF '#'#include "lrs.h"Action(){char *recvbuf;int recvlen=0;int rc;lr_start_transaction("Trans_1");lrs_set_recv_timeout (60,0);lr_start_transaction("Conn_1");rc=lrs_create_socket("socket0","TCP","LocalHost=0","RemoteHost=192.168.205.150:7001",LrsLastArg);//RemoteHost处填入被测程序所在服务器IPlr_output_message("%d",rc);if (rc != 0 ) {lr_end_transaction("Conn_1", LR_FAIL);lr_end_transaction ("Trans_1", LR_FAIL);return 0;}lr_end_transaction("Conn_1", LR_PASS);//判断socket是否链接成功的事务lr_rendezvous("集合点");lrs_send("socket0","buf0", LrsLastArg);lrs_receive ("socket0","buf1",LrsLastArg);lrs_get_last_received_buffer("socket0",&recvbuf,&recvlen);if(recvlen==130)lr_end_transaction("Trans_1", LR_PASS);elselr_end_transaction ("Trans_1", LR_FAIL);//判断返回信息的长度是否正确,recvlen处填入预期返回信息的长度lrs_close_socket("socket0");return 0;}Data.ws:;WSRData 2 1send buf0 211"\x00\xD1"//报文xx"\x60\x00\x09\x00\x00"//TPDU信息"\x4C\x52\x49\x00\x1C\x00\x00\x00\x21\x58\x77\x96\x98\x00\x00\x00\x21\x 58\x77\x09\x79\x58\x00\x09\x49\x00\x06\x00\x00\x00\x22\x00\x30"//主被叫号码"\x01\x00""\x02\x00"//信息类型"\x70\x38\x05\x80\x30\xC0\x80\x19"//位图"\x19\x09\x55\x10\x04\x91\x00\x01\x35\x38\x52"//卡号"\x00\x00\x00"//处理代码"\x00\x00\x00\x00\x02\x00"//交易金额"\x00\x00\x14"//系统跟踪号"\x16\x41\x32"//本地交易时间"\x05\x20"//本地交易日期"\x00\x22"//服务点输入方式"\x00\x09"//NETWORK INTERNATIONAL IDENTIFIEER"\x14"//服务点条件代码"\x37\x09\x55\x10\x04\x91\x00\x01\x35\x38\x52\xD0\x00\x02\x20\x36\x00\x 60\x00\x00"//二磁道数据"\x01\x04\x99\x95\x51\x00\x49\x10\x00\x13\x53\x85\x2D\x15\x61\x56\x00\x 00\x00\x00\x00\x00\x00\x03\x00\x00\x00\x21\x41\x41\x40\x00\x01\xD0\x00\x00\ x00\x00\x00\x0D\x00\x00\x00\x00\x00\x00\xD0\x00\x00\x00\x36\x00\x60\x00"//三磁道数据"\x32\x30\x31\x30\x30\x36\x30\x31"//收卡单位终端标识码"\x30\x30\x34\x31\x31\x30\x30\x34\x35\x31\x31\x30\x30\x31\x32"//收卡商户定义码"\x01\x56"//交易货币代码"\x00\x00"//RESERVED PRIVATE"\x00\x15\x30\x30\x30\x30\x30\x31\x30\x30\x31\x30\x30\x30\x30\x30\x32"//RESERVED PRIVATE"\x61\x54\x70\xE7\x33\x6D\xB5\x48"//消息认证码recv buf1 130-1发送报文原文:00DCC030C852D852D4001D0000D035470E7336DB548是16进制的,每两位代表一个字符,所以在Loadrunner里面发送数据的应该每两位前面家转义符“\x”来代表16进制。

8583报文详解

8583报文详解

全面掌握ISO8583报文最开始时,金融系统只有IBM这些大的公司来提供设备,象各种主机与终端等。

在各个计算机设备之间,需要交换数据。

我们知道数据是通过网络来传送的,而在网络上传送的数据都是基于0或1这样的二进制数据,如果没有对数据进行编码,则这些数据没有人能够理解,属于没有用的数据。

起初的X.25、SDLC以及现在流行的TCP/IP网络协议都提供底层的通讯编码协议,它们解决了最底层的通讯问题,能够将一串字符从一个地方传送到另一个地方。

但是,仅仅传送字符串是没有太大意义的,怎样来解析字符串代表什么内容是非常重要的,否则传送一些“0123abcd”的字符串也是无用的乱码。

让我们随着时光回到几十年前的某个时刻,假设我们被推到历史的舞台上,由我们来设计一个通用报文协议,来解决金融系统之间的报文交换,暂且称该协议叫做ISO8583协议。

此时,技术是在不断的前行,当初IBM一支独秀的局面好像已经不妙了,各种大小不一的公司都进入金融行业以求能有所斩获,呈一片百花齐放的局面。

我们怎样来设计一个报文协议,能够将这些如雨后春笋般出现的所有公司都纳入进来,其实也不是一件很简单的事。

我们还是先一步步的来考虑吧。

金融行业其实涉及到的数据内容并不是成千上万,无法统计,恰恰相反,是比较少的。

我们都可以在心底数得过来,象交易类型、帐号、帐户类型、密码、交易金额、交易手续费、日期时间、商户代码、2磁3磁数据、交易序列号等,把所有能够总结出来的都总结起来不过100个左右的数据。

那我们可以首先简单的设计ISO8583,定义128个字段,将所有能够考虑到的类似上面提到的“帐号”等金融数据类型,按照一个顺序排起来,分别对应128个字段中的一个字段。

每个数据类型占固定的长度,这个顺序和长度我们都事先定义好。

这样就简单了,要发送一个报文时,就将128个字段按照顺序接起来,然后将接起来的整串数据包发送出去。

任何金融软件收到ISO8583包后,直接按照我们定义的规范解包即可,因为整个报文的128个字段从哪一位到哪一位代表什么,大家都知道,只要知道你的数据包是ISO8583包即可,我们都已经定义好了。

ISO8583各域详解

ISO8583各域详解

ISO8583各域详解ISO8583各域详解8583协议的报文域编码格式分为:BINARY、CHAR、NUMERIC、LLVAR、LLLVAR、LLLVAR_NUMERIC这几种格式。

BINARY采用二进制编码(8位二进制数编码为一个字节)。

CHAR、LLVAR、LLLVAR为ASC(即正常的getBytes(Encoding))编码。

NUMERIC、LLLVAR_NUMERIC采用BCD(半个字节表示一个10进制数,每两位编码为一个字节)编码。

CHAR、BINARY、NUMERIC都需要指定长度。

NUMERIC右对齐、左补零。

LLVAR域前加一个字节的字节长度(采用bcd编码)。

LLLVAR域前加两个字节的字节长度(采用bcd编码)。

LLLVAR_NUMERIC域前加两个字节的长度(注:非字节长度,而是数字的长度,即字节长度的两倍)(采用bcd编码)。

代码中会在IsoField setValue时进行格式化,组装报文时计算LLVAR等域长。

ISO8583域说明ATM、前置机间通讯采用ISO8583 包格式。

以下是位元、报文等的定义。

1、信息类型(message type)定义格式:定长类型:N4描述:数据包的第一部分,定义数据包的类型。

数据类型由数据包的发起者设定,应遵循以下要求:数据包开始部分必须是信息类型;对不支持的信息类型能给出拒绝应答。

0100授权交易0110授权交易答复0200金融交易0210金融交易答复0250查询交易答复0400冲正交易0410冲正交易答复0800管理交易0810管理交易答复2、位图(Bit Map) - 基本位图和扩展位图位图位置:01格式:定长类型:B16描述:如将位图的第一位设为’1’,表示使用扩展位图,否则表示只使用基本位图。

如使用某数据域,应在位图中将相应的位设位’1’,如使用41域,需将位图的41位设为’1’。

选用条件:如使用65到128域,需设位图域为’1’3、Bit02主帐号(Primary Account Number )位图位置:02格式:变长,LLVAR类型:N..22描述:唯一的确认一个用户交易的基本帐号。

ISO8583各域详解--整理版..

ISO8583各域详解--整理版..

ISO8583各域详解8583协议的报文域编码格式分为:BINARY、CHAR、NUMERIC、LLVAR、LLLVAR、LLLVAR_NUMERIC这几种格式。

BINARY采用二进制编码(8位二进制数编码为一个字节)。

CHAR、LLVAR、LLLVAR为ASC(即正常的getBytes(Encoding))编码。

NUMERIC、LLLVAR_NUMERIC采用BCD(半个字节表示一个10进制数,每两位编码为一个字节)编码。

CHAR、BINARY、NUMERIC都需要指定长度。

CHAR类型左对齐、右补空格。

NUMERIC右对齐、左补零。

LLVAR域前加一个字节的字节长度(采用bcd编码)。

LLLVAR域前加两个字节的字节长度(采用bcd编码)。

LLLVAR_NUMERIC域前加两个字节的长度(注:非字节长度,而是数字的长度,即字节长度的两倍)(采用bcd编码)。

代码中会在IsoField setValue时进行格式化,组装报文时计算LLVAR等域长。

ISO8583域说明ATM、前置机间通讯采用ISO8583 包格式。

以下是位元、报文等的定义。

位元定义: (注:带*号的本行没用)位元数据元名称格式属性会晤报文头An8报文类型an4- (主位图) B641 (扩展位图) B642 主帐号LLVAR n..193 处理代码n64 交易金额n125 清算金额n126* 持卡人签单金额n127 传输日期和时间MMDDhhmmss n108* 持卡人签单手续金额n89 清算兑换率n810* 持卡人签单兑换率n811 系统跟踪审计号n812 本地交易日期和时间YYMMDDhhmmss n613 本地交易日期YYMM n414* 截止日期YYMM n415 结算日期YYMMDD n616* 兑换日期MMDD n417* 受理日期MMDD n418 商户类型n419* 代理机构国家代码n320* 主帐号国家代码n321* 发送机构国家代码n322* 服务点输入方式an1223 卡顺序号n324 卡种类n325 服务点条件代码n426* 受卡方业务代码n427* 批准代码长度n128 交易手续费X+n 829 地区代码N830* 原始金额n24 31* 代理方参考数据LLVAR Ans..9932 受理行标识代码LLVAR n..1133 发送方标识代码LLVAR n..11 34* 扩展的主帐号LLVAR ns..2835 第二磁道数据LLVAR z..3736 第三磁道数据LLLVAR z..104 37* 检索参考号Anp1238 授权代码Anp639 响应代码An2 40* 服务代码n341 终端代码Ans1542 终端标识Ans1543 受卡方名称/地点Ans..4044 附加响应数据LLVAR Ans..25 45* 第一磁道数据LLVAR Ans..76 46* 手续费金额LLLVAR Ans..204 47* 附加数据——国家LLLVAR Ans..99948 附加数据LLLVAR Ans..99949 交易贷币代码n350 结算贷币代码n351* 持卡人签单贷币代码a3或n3 52 个人识别号(PIN)B6453* 安全控制信息LLVAR b..48 54 附加金额LLLVAR An..120 55* 集成电路卡系统数据LLLVAR b..48 56* 原始数据元LLVAR n..35 57* 授权生命周期代码n358* 授权代理机构标识代码LLVAR n..11 59* 传输数据LLLVAR Ans..99960 附加数据LLLVAR Ans..99961 附加数据LLLVAR Ans..99962 主机交易检索号LLLVAR Ans..99963 附加数据LLLVAR Ans..99964 报文鉴别代码字段B6465* 保留给ISO使用b866* 原始手续费金额LLLVAR Ans..204 67* 扩展的付款数据n268* 接收机构国家代码n369* 清算机构国家代码n370 网络管理信息代码n371 报文编号N472* 数据记录LLLVAR Ans..999 73* 动作日期YYMMDD n674* 贷记笔数n1075* 撤消贷记笔数n1076* 借记笔数n1077* 撤消借记笔数n1078* 转帐笔数n1079* 撤消转帐笔数n1080* 查询笔数n1081* 授权笔数n1082* 撤消查询笔数n1083* 付款笔数n1084* 撤消付款笔数n1085* 手续费收取笔数n1086* 贷记金额n1687* 撤消贷记金额n1688* 借记金额n1689* 撤消借记金额n1690 原始交易数据N4291 文件更新代码An192* 交易发起机构国家代码n393* 交易终点机构标识代码LLVAR n..11 94* 交易发卢机构标识代码LLVAR n..11 95 替换金额an..42 96* 密钥管理数据LLLVAR b..999 97* 净对帐金额x+n16 98* 收款人Ans25 99* 清算机构标识代码LLVAR an..11 100 接收机构标识代码LLVAR n..11 101 文件名称LLVAR Ans..17 102 转出帐户帐号LLVAR Ans..28 103 转入帐户帐号LLVAR Ans..28 104 交易描述LLLVAR Ans..999 105* 反向贷记金额n16 106* 反向借记金额n16 107* 反向贷记笔数n10 108* 反向借记笔数n10 109* 手续费贷记金额LLVAR Ans..84 110* 手续费借记金额LLVAR Ans..84 111* 保留给ISO使用LLLVAR Ans..999 112* 保留给ISO使用LLLVAR Ans..999 113* 保留给ISO使用LLLVAR Ans..999 114* 保留给ISO使用LLLVAR Ans..999 115* 保留给ISO使用LLLVAR Ans..999 116* 保留给国家使用LLLVAR Ans..999 117* 保留给国家使用LLLVAR Ans..999 118* 保留给国家使用LLLVAR Ans..999 119* 保留给国家使用LLLVAR Ans..999 120* 保留给国家使用LLLVAR Ans..999 121* 保留给国家使用LLLVAR Ans..999 122* 保留给国家使用LLLVAR Ans..999 123* 保留给民间使用LLVAR Ans..999 124* 保留给民间使用LLVAR Ans..999 125 新个人标识号B64 126* 保留给民间使用LLVAR ans..999 127* 保留给民间使用LLVAR ans..999128 报文鉴别代码字段B641、信息类型(message type)定义位图位置:-格式:定长类型:N4描述:数据包的第一部分,定义数据包的类型。

ISO8583各域详解--整理版知识讲解

ISO8583各域详解--整理版知识讲解

I S O8583各域详解--整理版ISO8583各域详解8583协议的报文域编码格式分为:BINARY、CHAR、NUMERIC、LLVAR、LLLVAR、LLLVAR_NUMERIC这几种格式。

BINARY采用二进制编码(8位二进制数编码为一个字节)。

CHAR、LLVAR、LLLVAR为ASC(即正常的getBytes(Encoding))编码。

NUMERIC、LLLVAR_NUMERIC采用BCD(半个字节表示一个10进制数,每两位编码为一个字节)编码。

CHAR、BINARY、NUMERIC都需要指定长度。

CHAR类型左对齐、右补空格。

NUMERIC右对齐、左补零。

LLVAR域前加一个字节的字节长度(采用bcd编码)。

LLLVAR域前加两个字节的字节长度(采用bcd编码)。

LLLVAR_NUMERIC域前加两个字节的长度(注:非字节长度,而是数字的长度,即字节长度的两倍)(采用bcd编码)。

代码中会在IsoField setValue时进行格式化,组装报文时计算LLVAR等域长。

ISO8583域说明ATM、前置机间通讯采用 ISO8583 包格式。

以下是位元、报文等的定义。

位元定义: (注:带*号的本行没用)1、信息类型(message type)定义位图位置:-格式:定长类型:N4描述:数据包的第一部分,定义数据包的类型。

数据类型由数据包的发起者设定,应遵循以下要求:数据包开始部分必须是信息类型;对不支持的信息类型能给出拒绝应答。

0100授权交易0110授权交易答复0200金融交易0210金融交易答复0240查询交易0250查询交易答复0400冲正交易0410冲正交易答复0800管理交易0810管理交易答复2、位图(Bit Map) - 基本位图和扩展位图位图位置:01格式:定长类型:B16描述:如将位图的第一位设为'1',表示使用扩展位图,否则表示只使用基本位图。

如使用某数据域,应在位图中将相应的位设位'1',如使用41域,需将位图的41位设为'1'。

ISO8583各域详解--整理版

ISO8583各域详解--整理版

ISO8583各域详解8583协议的报文域编码格式分为:BINARY、CHAR、NUMERIC、LLVAR、LLLVAR、LLLVAR_NUMERIC这几种格式。

BINARY采用二进制编码(8位二进制数编码为一个字节)。

CHAR、LLVAR、LLLVAR为ASC(即正常的getBytes(Encoding))编码。

NUMERIC、LLLVAR_NUMERIC采用BCD(半个字节表示一个10进制数,每两位编码为一个字节)编码。

CHAR、BINARY、NUMERIC都需要指定长度。

CHAR类型左对齐、右补空格。

NUMERIC右对齐、左补零。

LLVAR域前加一个字节的字节长度(采用bcd编码)。

LLLVAR域前加两个字节的字节长度(采用bcd编码)。

LLLVAR_NUMERIC域前加两个字节的长度(注:非字节长度,而是数字的长度,即字节长度的两倍)(采用bcd编码)。

代码中会在IsoField setValue时进行格式化,组装报文时计算LLVAR等域长。

ISO8583域说明ATM、前置机间通讯采用ISO8583 包格式。

以下是位元、报文等的定义。

位元定义: (注:带*号的本行没用)位元数据元名称格式属性会晤报文头An8报文类型an4- (主位图) B641 (扩展位图) B642 主帐号LLVAR n..193 处理代码n64 交易金额n125 清算金额n126* 持卡人签单金额n127 传输日期和时间MMDDhhmmss n108* 持卡人签单手续金额n89 清算兑换率n810* 持卡人签单兑换率n811 系统跟踪审计号n812 本地交易日期和时间YYMMDDhhmmss n613 本地交易日期YYMM n414* 截止日期YYMM n415 结算日期YYMMDD n616* 兑换日期MMDD n417* 受理日期MMDD n418 商户类型n419* 代理机构国家代码n320* 主帐号国家代码n321* 发送机构国家代码n322* 服务点输入方式an1223 卡顺序号n324 卡种类n325 服务点条件代码n426* 受卡方业务代码n427* 批准代码长度n128 交易手续费X+n 829 地区代码N830* 原始金额n24 31* 代理方参考数据LLVAR Ans..9932 受理行标识代码LLVAR n..1133 发送方标识代码LLVAR n..11 34* 扩展的主帐号LLVAR ns..2835 第二磁道数据LLVAR z..3736 第三磁道数据LLLVAR z..104 37* 检索参考号Anp1238 授权代码Anp639 响应代码An2 40* 服务代码n341 终端代码Ans1542 终端标识Ans1543 受卡方名称/地点Ans..4044 附加响应数据LLVAR Ans..25 45* 第一磁道数据LLVAR Ans..76 46* 手续费金额LLLVAR Ans..204 47* 附加数据——国家LLLVAR Ans..99948 附加数据LLLVAR Ans..99949 交易贷币代码n350 结算贷币代码n351* 持卡人签单贷币代码a3或n3 52 个人识别号(PIN)B6453* 安全控制信息LLVAR b..48 54 附加金额LLLVAR An..120 55* 集成电路卡系统数据LLLVAR b..48 56* 原始数据元LLVAR n..35 57* 授权生命周期代码n358* 授权代理机构标识代码LLVAR n..11 59* 传输数据LLLVAR Ans..99960 附加数据LLLVAR Ans..99961 附加数据LLLVAR Ans..99962 主机交易检索号LLLVAR Ans..99963 附加数据LLLVAR Ans..99964 报文鉴别代码字段B6465* 保留给ISO使用b866* 原始手续费金额LLLVAR Ans..204 67* 扩展的付款数据n268* 接收机构国家代码n369* 清算机构国家代码n370 网络管理信息代码n371 报文编号N472* 数据记录LLLVAR Ans..999 73* 动作日期YYMMDD n674* 贷记笔数n1075* 撤消贷记笔数n1076* 借记笔数n1077* 撤消借记笔数n1078* 转帐笔数n1079* 撤消转帐笔数n1080* 查询笔数n1081* 授权笔数n1082* 撤消查询笔数n1083* 付款笔数n1084* 撤消付款笔数n1085* 手续费收取笔数n1086* 贷记金额n1687* 撤消贷记金额n1688* 借记金额n1689* 撤消借记金额n1690 原始交易数据N4291 文件更新代码An192* 交易发起机构国家代码n393* 交易终点机构标识代码LLVAR n..11 94* 交易发卢机构标识代码LLVAR n..11 95 替换金额an..42 96* 密钥管理数据LLLVAR b..999 97* 净对帐金额x+n16 98* 收款人Ans25 99* 清算机构标识代码LLVAR an..11 100 接收机构标识代码LLVAR n..11 101 文件名称LLVAR Ans..17 102 转出帐户帐号LLVAR Ans..28 103 转入帐户帐号LLVAR Ans..28 104 交易描述LLLVAR Ans..999 105* 反向贷记金额n16 106* 反向借记金额n16 107* 反向贷记笔数n10 108* 反向借记笔数n10 109* 手续费贷记金额LLVAR Ans..84 110* 手续费借记金额LLVAR Ans..84 111* 保留给ISO使用LLLVAR Ans..999 112* 保留给ISO使用LLLVAR Ans..999 113* 保留给ISO使用LLLVAR Ans..999 114* 保留给ISO使用LLLVAR Ans..999 115* 保留给ISO使用LLLVAR Ans..999 116* 保留给国家使用LLLVAR Ans..999 117* 保留给国家使用LLLVAR Ans..999 118* 保留给国家使用LLLVAR Ans..999 119* 保留给国家使用LLLVAR Ans..999 120* 保留给国家使用LLLVAR Ans..999 121* 保留给国家使用LLLVAR Ans..999 122* 保留给国家使用LLLVAR Ans..999 123* 保留给民间使用LLVAR Ans..999 124* 保留给民间使用LLVAR Ans..999 125 新个人标识号B64 126* 保留给民间使用LLVAR ans..999 127* 保留给民间使用LLVAR ans..999128 报文鉴别代码字段B641、信息类型(message type)定义位图位置:-格式:定长类型:N4描述:数据包的第一部分,定义数据包的类型。

银联ISO8583报文解析过程

银联ISO8583报文解析过程

银联ISO8583报⽂解析过程主密钥:aabbccddeeff112233445566778899001、从签到报⽂中获取⼯作密钥,包括MACKEY明⽂,PINKEY明⽂签到:12-03-31 16:38:09---->[Receive]02 00 91 60 00 03 00 00 60 31 00 31 54 32 08 00 00 20 00 00 00 C0 00 16 00 00 39 31 32 33 34 35 36 37 36 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 00 11 00 00 00 03 00 30 00 29 53 65 71 75 65 6E 63 65 20 4E 6F 31 36 33 30 38 31 30 33 38 35 4E 4C 32 34 37 35 33 36 00 03 30 31 20 03 11TDUP:60 00 03 00 00 60报⽂头:31 00 31 54 32数据类型:08 00位图:00 20 00 00 00 C0 00 16(0000 0000 0010 0000 0000 0000 0000 0000 0000 0000 1100 0000 0000 0000 0001 0110)11域(受卡⽅系统跟踪号):00 00 3941域(受卡机终端标识码):31 32 33 34 35 36 37 3642域(受卡⽅标识码):31 32 33 34 35 36 37 38 39 30 31 32 33 34 3560域(⾃定义域):00 11 00 00 00 03 00 3062域(⾃定义域):00 29 53 65 71 75 65 6E 63 65 20 4E 6F 31 36 33 30 38 31 30 33 38 35 4E 4C 32 34 37 35 33 3663域(⾃定义域):00 03 30 31 2012-03-31 16:38:09---->[Send]02 01 21 60 00 00 00 03 60 31 00 31 54 32 08 10 00 38 00 01 0A C0 00 14 00 00 39 16 38 09 03 31 08 01 03 10 00 30 34 36 38 37 39 30 38 37 35 36 34 30 30 31 32 33 34 35 36 37 36 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 00 11 00 00 00 03 00 30 00 40 8B 3D 47 86 55 51 F1 FB 54 8F D4 72 5C C5 0A 57 FF EF A8 D9 8B 3D 47 86 55 51 F1 FB 00 00 00 00 00 00 00 00 6F B2 3E AD 03 41TDUP: 60 00 00 00 03 60报⽂头: 31 00 31 54 32数据类型:08 10位图: 00 38 00 01 0A C0 00 14 (0000 0000 0011 1000 0000 0000 0000 0001 0000 1010 1100 0000 0000 0000 0001 0100)11域(受卡⽅系统跟踪号):00 00 3912域(受卡⽅所在地时间):16 38 0913域(受卡⽅所在地⽇期):03 3132域(受理⽅标识码):08 01 03 10 0037域(检索参考号):31 32 33 34 35 36 37 38 39 30 31 32 33 34 3539域(应答码): 30 3041域(受卡机终端标识码): 31 32 33 34 35 36 37 3642域(受卡⽅标识码):31 32 33 34 35 36 37 38 39 30 31 32 33 34 3560域(⾃定义域):00 11 00 00 00 03 00 3062域(⾃定义域):00 40 8B 3D 47 86 55 51 F1 FB 54 8F D4 72 5C C5 0A 57 FF EF A8 D9 8B 3D 47 86 55 51 F1 FB 00 00 00 00 00 00 00 00 6F B2 3E AD(PIN的16个密⽂)(checkvalue)(MAC的8个密⽂)(checkvalue)PINKEY⼯作密钥明⽂:1122334455667788 9900112233445566 将PINKEY⼯作密钥与0X 00 00 00 00 00 00 00 00进⾏3DES运算得:FFEFA8D9 607ED326MACKEY⼯作密钥明⽂:1122334455667788 将MACKEY⼯作密钥与0X 00 00 00 00 00 00 00 00进⾏3DES运算得:6FB23EAD 0534752B2、根据上⾯得到的MACKEY,PINKEY,计算出⽤户输⼊的密码,以及计算出这个报⽂的MAC值。

ISO8583各域详解--整理版

ISO8583各域详解--整理版

ISO8583各域详解8583协议的报文域编码格式分为:BINARY、CHAR、NUMERIC、LLVAR、LLLVAR、LLLVAR_NUMERIC这几种格式。

BINARY采用二进制编码(8位二进制数编码为一个字节)。

CHAR、LLVAR、LLLVAR为ASC(即正常的getBytes(Encoding))编码。

NUMERIC、LLLVAR_NUMERIC采用BCD(半个字节表示一个10进制数,每两位编码为一个字节)编码。

CHAR、BINARY、NUMERIC都需要指定长度。

CHAR类型左对齐、右补空格。

NUMERIC右对齐、左补零。

LLVAR域前加一个字节的字节长度(采用bcd编码)。

LLLVAR域前加两个字节的字节长度(采用bcd编码)。

LLLVAR_NUMERIC域前加两个字节的长度(注:非字节长度,而是数字的长度,即字节长度的两倍)(采用bcd编码)。

代码中会在IsoField setValue时进行格式化,组装报文时计算LLVAR等域长。

ISO8583域说明ATM、前置机间通讯采用ISO8583 包格式。

以下是位元、报文等的定义。

1、信息类型(message type)定义位图位置:-格式:定长类型:N4描述:数据包的第一部分,定义数据包的类型。

数据类型由数据包的发起者设定,应遵循以下要求:数据包开始部分必须是信息类型;对不支持的信息类型能给出拒绝应答。

0100授权交易0110授权交易答复0200金融交易0210金融交易答复0240查询交易0250查询交易答复0400冲正交易0410冲正交易答复0800管理交易0810管理交易答复2、位图(Bit Map) - 基本位图和扩展位图位图位置:01格式:定长类型:B16描述:如将位图的第一位设为'1',表示使用扩展位图,否则表示只使用基本位图。

如使用某数据域,应在位图中将相应的位设位'1',如使用41域,需将位图的41位设为'1'。

ISO8583金融报文详细分析

ISO8583金融报文详细分析

ISO8583金融报文详细分析ISO8583金融报文详细分析2011-08-26 14:23转载至网络,自己编辑了一下。

向原作者表示感谢,写的很详细。

不要以为我这篇文章是告诉你什么是8583,告诉你map的原理,然后分析各个域是什么意思,格式如何, 再有详细一点的甚至告诉你如何写程序等等. 不是, 之所以不写上面这些,基于两点:1 太多的人写这些了, 网上一搜8583,出来的文章都是关于这些的.2 作用不大, 因为这些规范上都有, 大家一看规范就明白了, 我写了也是无用.我篇文章适合两类人看:1 对8583报文非常熟悉,属于这一领域的资深工程师, 为什么这一类人要看呢, 因为他们看了,可以给我提一些意见和建议.2 看了很多遍规范,但是还有一些细节不是很明白.好,我要开始了.8583报文大部分情况下用在POS终端与后台收单系统的数据交换, 一般情况下(请注意这里的用词)一段完整的报文由以下几个部分组成图1不同的应用领域, 上面几个部分在长度和格式上有一些差别, 有一些应用甚至前面的"长度"部分没有.所以如果等一下你看到下面一些数据的长度或格式跟你的不一样,不要惊讶.先说说"长度"部分, 一般占两个字节, 表示报文的总长度(即"报文头"+"数据"部分的长度), 这两个字节在报文里的表示方法因系统与终端的协议不同而不同. 一般有两种:1 BCD方法, 比如报文的总长度是134字节, 那么在实际的报文中, 这两个字节为"01h,34h"(注意16进制)2 实际的计算的长度, 比如还是134长度的字节, 实际的报文中,两个字节为"00h, 86h"(注意也是16进制,00h*256+86h = 134d).然后说说"报文头", 这一部分不同的系统应用差别也不小, 但一般这部分中会包含TPDU, 这个TPDU决定了终端与系统之间的网络协议. TPDU是一个10位的数字, 实际传输的报文, 有些用ASCII表示这10位数字, 有些用BCD表示, 举个例子:TPDU是"6000120000",如果用ASCII表示, 报文中的字节是"36h,30h,30h,30h,31h,32h,30h,30h,30h,30h"(10个字节).如果用BCD表示, 报文中的字节如下:"60h,00h,12h,00h,00h"(5个字节).重头戏来了, "数据"部分.这一部分就是8583了, 我上面说了,我这篇文章只写别人没写过的东西,so.....,直接上例子.一段8583报文."02 00 70 20 00 00 20 C0 82 00 19 06 20 51 32 00 00 00 02 61 20 60 00 00 00 00 00 02 00 00 00 00 73 37 06 20 51 32 00 00 00 02 61 20 d1 91 12 01 00 00 00 00 00 30 30 30 30 31 31 31 31 31 30 32 32 35 30 31 35 33 31 31 31 31 31 31 01 56 00 44 9f 26 08 92 b6 ae 9a 9b 10 2e d6 9f 27 01 80 9f 10 13 07 01 01 03 a0 a0 10 01 0a 01 00 00 00 10 37 51 3a 22 be"这是一串实际传输的报文, 上面显示的是这些数据的16进制表示.你准备好了吗,我要开始分析了.<02 00>这个是信息类型(MTI), 是一个四位的数字, 这里为"0200", 传输时用BCD表示即为"02h,00h"(如果用ASCII呢?看看上面的内容). 这个四位数字,每一位都有它的意义,第一位:8583 version number第二位:message class第三位:message sub-class第四位:transaction originator就不翻译了,毕竟本来就是老外的东西, 自己理解吧.<70 20 00 00 20 C0 82 00>bit map域, 指示哪些域存在, 我们用windows自带的计算器计算出它对应的二进制是1110000001000000000000000000000001000001100000010 00001000000000, 由此可以看出下面几个域存在:2, 3, 4, 11, 35, 41, 42, 49, 55.<19 06 20 51 32 00 00 00 02 61 20>field 2, 账号, n..19, LLVAR, 一字节表示长度(19), 账号是19位, 前面补0后, 用10字节BCD表示.<60 00 00>field 3, 处理码, n6, 定长, 用3字节BCD表示<00 00 00 02 00 00>field 4, 交易金额, n12, 定长, 用6字节BCD表示, 这里的金额是200.00元<00 00 73>field 11, 流水号, n6, 定长, 用3字节BCD表示.流水号为"000073".<37 06 20 51 32 00 00 00 02 61 20 d1 91 12 01 00 00 00 00 00>field 35, 二磁道数据, z..35, LLVAR, 一字节表示长度(37), 后面是19字节BCD表示的磁道数据<30 30 30 30 31 31 31 31>field 41, 终端号, ans8, 定长, ASCII表示, 这里终端号为"00001111"<31 30 32 32 35 30 31 35 33 31 31 31 31 31 31>field 42, 商户号, ans15, 定长, ASCII表示, 这里商户号为"102250153111111"<01 56>field 49, 货币代码, n3, 定长, 前面补0后,用两字节BCD表示, 这里货币代码为"156"<00 44 9f 26 08 92 b6 ae 9a 9b 10 2e d6 9f 2701 80 9f 10 13 07 01 01 03 a0 a0 10 01 0a 0100 00 00 10 37 51 3a 22 be>field 55, 这是IC卡交易的相关数据, 最大长度是255, 这一域用的IC卡数据一般在PBOC/EMV规范里都有自己的定义(包括格式), 所以,一般在报文里的格式跟它们在PBOC/EMV里定义的一致.一般是TLV(tag+lenght+value)表示一个数据.简单介绍一下数据的意义."00 44":长度, 表示44个字节"9f 26 08 92 b6 ae 9a 9b 10 2e d6":应用密文(application cryptogram), TLV, b8"9f 27 01 80":密文信息数据(cryptogram information data), TLV, b1"9f 10 13 07 01 01 03 a0 a0 10 01 0a 01 00 00 00 10 37 51 3a 22 be":发卡行应用数据(issuer application data), TLV, 变长,最大32字节,b..32.。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

8583报文解析
8583报文解析是指对银行卡交易中所使用的8583报文进行分析和解码的过程。

8583报文是一种二进制格式的结构化数据,在银行卡交易中扮演着重要的角色。

通过对8583报文的解析,可以获取交易中所包含的必要信息,如交易类型、交易金额、交易时间等,从而实现交易的成功。

8583报文由多个域(field)组成,每个域包含了特定的信息。

其中,前4个域为固定域,分别为消息类型标识符、位图、主帐号(PAN)、交易处理码。

后续的域则根据交易类型的不同而有所变化,如消费交易会包含卡有效期、商户号、终端号等域。

对于每个域,都有特定的长度和格式要求,例如主帐号域为16位数字字符,交易金额域为12位数字字符等。

在解析8583报文时,需要先解析出位图域,确定哪些域存在于该报文中。

然后根据位图的内容,按照顺序解析出各个域的信息。

在解析过程中,需要注意各个域之间的关联关系和数据类型的转换。

总之,8583报文解析是银行卡交易中必不可少的环节,对于保障交易的正确进行具有重要作用。

- 1 -。

相关文档
最新文档