CEB8583报文接口说明

CEB8583报文接口说明
1 概述
1.1 前言
目前国内各大A TM厂家提供不同的A TM接口标准。

由于缺乏规范和控制，严重地阻碍了金融电子化的实施。

为了改变这种工作方式，在此规范一个终端接口标准。

这个接口标准具有以下几个特点：
1、标准化：所有交易使用国际金融标准ISO8583。

2、规范化：所有交易及控制都提供明确的流程。

3、公开性：所有的加密算法都明确规定。

为了改变终端软件的质量，减少各家用户的协调工作，任何一家终端厂家必须严格遵守此终端标准。

我们希望通过努力，使各大银行逐步具备自己的终端规范。

1.2 应用范围
本文件描述服务器网络的外部报文格式和交易过程的报文流程，供入网单位开发接口程序时使用。

ISO8583是国际标准化组织推荐用于交换中心和成员行主机通讯的报文格式，本手册介绍服务器网络对ISO8583标准的解释和实现。

在阅读本文时，用户应参考ISO8583（1987）文本。

1.3 支持的通信协议
TCP/IP
1.4 网络构成说明
主机
CRS DDN/FR
/X.25
A TM CDM ……
……
网络拓扑结构图
2 交易术语、符号说明
2.1 消息类型说明
ISO8583标准定义了几类消息来确定交易类型，在服务器系统中使用的报文类型有以下几种：
除03XX、08XX、90XX报文类型外的其它所有报文类型都需要MAC校验。

02XX
02XX类消息用于金融请求，被批准的金融交易的请求消息可用于立即对持卡人帐户的记帐处理。

包括：
ATM/柜台-- 存款、取款，余额查询，（本系统内帐户间）转帐，IC卡圈存、圈提、代交费、发卡等。

注：以上交易需要提供密码。

02XX支持的信息：
0200 金融交易请求，0200消息要求对方以0210消息作为其应答。

0201 金融交易请求的重发，0201消息要求对方以0210消息作为其应答。

0210 金融交易请求应答，对0200金融交易请求必须用它来回答。

03XX
03XX类消息用于在服务器和终端之间传送文件更新数据。

根据终端的不同要求，服务器接收终端的文件数据或向终端传送其需要的文件更新数据。

0300 终端上传文件或服务器下传文件的请求。

必须以0310作为对本类报文的应答。

0310 对0300的应答。

04XX
04XX类信息用于执行对先前已请求进行的交易全部或部分冲正。

04XX类冲正信息是由终端发起的，而调整交易信息则由人工产生。

下列是04XX信息：
0400 冲正通知，终端未在预定的时间内接到服务器发送的交易应答时，需要对未完成的交易进行冲正，此时发送0400消息。

0400要求一个0410消
息作为应答。

0410 冲正通知应答。

这是对0400冲正通知消息必须的应答。

08XX
08XX消息用于服务器和终端之间的文件传输通知、签到、签退和密钥更新，每个终端都要在每日交易开始前或每日日终时向服务器申请更新密钥，以保证下一个工作日交易的安全性，双方要用相同的传输密钥对这些工作密钥进行加密或解密。

08XX支持的消息种类如下：
0800 文件传输开始通知、文件传输结束通知、签到、签退、密钥更新请求，要求以0810作为回答。

0810 是对0800消息必须的应答。

90XX
90XX消息用于服务器和终端之间的管理报文，终端需要定时向服务器汇报自己的状态，如钞箱状态等，以提供服务器对其进行管理的依据。

服务器也向终端发送监控命令，用于查询终端设备的状态、开启、关闭某些终端，查询终端的统计数据等。

9000 终端的定时汇报报文，不需要应答。

9000 服务器向终端发送监控命令，需要9010做应答。

9010 终端对服务器的监控命令给予应答的报文。

91XX
91XX消息用于卡片管理（包括修改用户个人密码、查询明细等）、商户管理、机构柜员管理等管理类交易，支持的消息种类如下：
9100 交易请求，要求以9110作为应答。

9101 重发，要求以9110作为应答。

9110 服务器对9100和9101的回答。

在本规格说明书中，消息和报文都是指上述各类消息。

这二个术语可替换使用。

全二进制0
2.3
法。

约定（
字段采用属性后加上长度的方法来描述，下表定义这些属性的含义：字段类型属性（Field Type attribute）
对数据字段更详细的描述可在位图定义一章中找到。

字段长度(Field Length)
表示法含义
-digit(s) 固定长度位数。

例如，n-10表示10位长的数字字段
示例：an-10表示10位臵长的数字字符字段。

…digit(s)可变长度位数。

示例：n…4表示最长为4个数字的可变长数字字段。

示例：an…7表示最长为7个数字位的可变长数字字符字段。

LLVAR 该写法表示数据字段包括包括两个子域，第一个子域为2位长（LL），表示其后所跟数据的长度。

第二个子域的长度位LL位。

VAR表示子域中的数据
部分。

注意整个字段总长度变为LL+2。

例如：an..25 LLV AR表示此字段最
长可达25位。

实际位数在第一个子域中表示。

LLLVAR 除长度子域为三以外，含义和LLV AR一样。

数据表示方法
●所有数据ASCII显示格式表示，字符集合的确定取决于配臵情况。

示例：
ans 5 =”123AB” → 31 32 33 41 42 (HEXA)
●所有数据类型为“b”（二进制）的字段按照其十六进制数值显示表示法编码。

示例：
b8 = 0x34 → 34(HEXA)
●数据中给出的所有长度均表示需要的逻辑位数。

示例：
n-12=12个数字
●所有类型为n的数字字段在8583报文中将采用BCD压码。

示例：
n6=”980812” → 98 08 12 (HEXA)
●所有类型为n的数字字段的数据在8583报文中均采用右对齐，前面空位补零。

示例：长度为3的数据‚156‛的数据在报文中为：
n3=”156” → 01 56 (HEXA)
●在8583报文中，所有类型为LLV AR的字段长度占用一个字节，类型为LLLVAR字段
长度为两个字节。

示例：下面数据的长度分别为8、16、15、15，变长字段的类型分别为LLV AR和LLLV AR。

ans..16=”1234567A”→08 31 32 33 34 35 36 37 41 (HEXA)
n..19=”1234567890123456”→10 12 34 56 78 90 12 34 56 (HEXA)
n..19=”123456789012345”→0F 01 23 45 67 89 01 23 45 (HEXA)
n…999=”123456789012345”→00 0F 01 23 45 67 89 01 23 45(HEXA)
●所有其它类型的字段，若为固定长度，则采用左对齐，其后空位以空格填充。

示例：
ans6=”123AB” → 31 32 33 41 42 20 (HEXA)
●当某字段表示金额时，格式中不带小数点。

示例：
金额23.47表示为2347。

2.4 名词解释
Debit与Credit
●为了避免混淆，下面给出Debit交易及Credit交易的精确定义。

这些定义是针对信用
卡网络而言的，尽管它们也是行业中普遍使用的解释。

●Debit交易是指持卡人必须输入个人密码的交易，本定义与卡类型及访问帐户无关，例
如，插入ATM的信用卡做的是Debit交易，本定义与带有PIN交易的处理是一致的：Debit交易可立即对其目标帐户进行借记或贷记。

●Credit交易可以不需要持卡人的个人密码，本定义与卡类型及访问帐户无关，这类交
易主要是用于信用卡，虽然在某些情况下也允许用于扣款卡（与场所有关的选项）。

除非提及扣款卡或信用卡，所有用到Debit交易和Credit交易术语的都与上述定义一致。

下面定义适用于不同的卡类型：
●信用卡是用于访问信用帐户（如Visa、MasterCard、Amex帐户）的磁条卡。

信用卡有
效性授权是针对此类卡的交易。

信用卡交易可以不用个人密码，即可能是Debit交易的一部分。

●借记卡是用于访问持卡人银行帐户的磁条卡，只有在帐户中还有资金或发卡行授予持
卡人一定的信用度的情况下，针对此类卡的交易才会被授权。

●双重性质卡（Dual Purpose Card）是既可作为信用卡交易又可作为扣款卡使用的磁条
卡，具体情况由持卡人选择的帐户性质确定。

交易类型与终端类型
●连到服务器的一些终端只能产生特定类型的交易，例如：如果规定ATM只能产生Debit
交易，那么服务器就不允许ATM进行信用交易，另一些终端则能产生两种交易类型，例如，POS能够根据持卡人支付方式的选择产生Debit或信用交易。

3 交易功能及流程
3.1 ATM交易功能及流程
3.1.1 ATM签到及交换密钥过程
签到
密钥交换
状态报告
启动条件：
ATM开机或重新建立链路时，需进行密钥交换及签到过程。

过程说明：
ATM与服务器采用client/server结构，ATM为client端，服务器为server端。

具体步骤如下：
1.ATM向服务器发送0800进行签到。

2.服务器在收到签到后，向A TM发送签到允许响应0810，并将本台ATM的签到状
态登记在设备汇总信息表中。

3.ATM向服务器发送0800进行交换密钥请求。

4.服务器在收到密钥请求后，向ATM发送鉴别密钥（MAC Key）和密码密钥（PIN
Key）响应（0810）。

5.ATM端在收到服务器密钥后，检验密钥是否正确。

如正确则向服务器发出
9000ATM状态信息表示签到，不正确则重复1、2步骤。

3.1.2 ATM联机交易过程
正常交易
冲正交易
冲正交易失败处理
重发交易处理
启动条件：
ATM在接收到需主机授权方能进行的交易时，启动此过程。

过程说明：
正常交易：
1.ATM在收到卡交易、非金融交易后，将交易请求用0200/9000报文传送给服务器。

2.服务器在收到交易请求后，进行交易处理并回响应报文0210/9010给ATM。

3.ATM收到响应后，如果为肯定响应则完成交易，如果为否定响应则拒绝交易。

冲正交易：（需要冲正的交易类型）
1.ATM接收交易响应时超时，接收响应报文时，线路故障或收到肯定响应信息后处
理有误时，将拒绝此笔交易并自动组成冲正报文0400发到服务器。

2.服务器在收到ATM冲正请求后，检查交易是否成功并发送冲正响应报文0410。

3.如果ATM再次收到不明信息或交易超时，ATM将停止冲正交易。

在下笔顾客插
卡进行交易之前，重新冲正前笔交易。

如果冲正成功则完成下笔交易，如果冲
正失败，则提示顾客‚网络故障，无法交易‛，重新开始步骤3。

重发交易：（需要重发的交易类型）
1、ATM接收交易响应超时，接收响应报文时线路故障或收到肯定响应信息后处理
有误时，经操作员手工确认需要重发后自动组成重发报文0201/9001发送到服务
器。

2、服务器在收到A TM重发请求后，检查交易是否成功并发送重发响应报文
0210/9010。

3、如果ATM再次收到不明信息或交易超时，ATM将停止重发交易。

存款交易：（可把实现存款操作的设备称为CDM）
1、ATM/CDM接到存款请求，将存入的钞票和金融卡进行检查，如果钞票及其总额、金融卡都不存在可疑的问题，就将钞票接收，向服务器发送存款请求，同时打印存款凭证给存款用户。

2、如果在指定时间内没有接到服务器的应答，则ATM/CDM将该笔交易记入重发交易流水文件，定时发送，直到交易成功或者日终开始。

3、如果在日终开始，交易仍未成功，则ATM/CDM会上传该笔交易的流水，由服务器进行手工调帐。

3.1.3 ATM签退
启动条件：
ATM操作员决定暂时停止ATM的运转。

过程说明：
1.ATM向服务器发起0800申请签退。

2.服务器在收到签退请求报文后，回响应响应报文0810给发起请求者，同时将设备
汇总信息表中该设备的状态修改为‚签退‛状态。

3.1.4 ATM日终文件传输过程
启动条件：
1)ATM人工启动此过程，完成ATM与服务器的交易明细、黑名单、金融卡设臵参
数、ATM运行参数等文件的传输。

文件传输可以选择如上图所示的联机报文传输方式，也可以采用第六章介绍的大
文件传输方式。

2)服务器通过远程日终命令通知A TM进行日终工作，此时ATM应处于暂停服务
状态。

过程说明：
1.ATM在完成帐务结算后，将使用0800请求报文启动与服务器的日终处理。

2.服务器在收到日终请求报文后，回响应响应报文0810并准备日终传输文件。

3.ATM收到响应报文后，将通过0300报文上传A TM端的交易明细和其它信息给服
务器。

4.服务器在收到0300报文并确定报文无误后，回响应报文0310。

5.如果信息在一笔0300报文中无法全部上传，可重复步骤3、4。

6.ATM在完成上传交易信息后，将ATM端信息版本号使用0300交易上传服务器。

7.服务器在收到A TM端版本号后，将需更新的A TM信息使用0310下传ATM。

8.如果信息在一笔0300报文中无法将全部信息下传，可重复步骤6、7。

9.在全部信息传送完毕后，A TM端将使用0800报文进行签退请求。

10.服务器在收到签退请求报文后，回响应报文0810完成签退。

3.1.5 ATM通知管理过程
启动条件：
ATM定时启动此过程，完成A TM状况上传。

过程说明：
ATM主动向服务器发送通知报文，以使服务器了解ATM的状态。

3.1.6 ATM管理交易过程
A TM管理信息
启动条件：
1）服务器由人工启动此过程，完成ATM状况查询。

2）ATM根据下传的参数，定时报告其运行状况。

过程说明：
1.服务器使用9000报文请求A TM上传管理信息。

2.ATM在收到9000请求报文后，组织响应报文9010上传服务器。

3.1.7 ATM不明信息处理过程
启动条件：
无。

过程说明：
ATM不明信息处理
1.服务器收到不明信息将使用Session Header报文头将信息传回ATM。

2.ATM重发交易信息0201/9001。

服务器不明信息处理
根据交易类型的不同选择发起冲正交易或者重发交易。

4 交易报文格式
概述
本章定义了服务器所支持的每个报文和它的结构，它的格式是：
Bit # 字段号，也叫位图号。

Field Name 所定义的字段名。

Req. 条件，指该字段在报文中出现的必要性（m，c，o）。

请看下页的详细定义。

Format 格式
请看下页的详细定义。

Attribute 属性
请看下页的详细定义。

Description 对字段及其必要性的解释
要求（Requirement）
必须字段（m----mandatory）
不管该字段的内容是否为空，它必须在报文中出现，服务器需要该字段。

可选择字段（o----optional）
报文中可以有也可以没有该字段，服务器不需要它。

有些专业行因为系统的需要可能会用到它，等等。

条件字段（c----conditonal）
条件字段，在一定条件下出现于报文中（例如，如果第4和第5位元的字段同时存在，则报文中就要有第126位元的字段）。

无论是必须的、条件的，还是可选择的，成员单位必须随时准备接收报文中列出的所有字段。

发出的报文中则必须包含所有的必须字段和适当的条件字段。

是否使用可选择字段则依外部网络或成员单位的需要而定。

01xx Message Format 4.1 0100/0101 Message（终端发送至服务器的报文）
为以下3种交易而定义：
✧终端的预授权
✧终端的预授权取消
4.2 0110 Message（服务器发送至终端的报文）对0100报文相关交易的回应报文的定义。

02xx Message Format 4.3 0200/0201 Message（终端发送至服务器的报文）
4.4 0210 Message（服务器发送至终端的报文）
03xx Message Format 4.5 0300 Message（终端发送至服务器的报文）
4.6 0310 Message（服务器发送至终端的报文）
04xx Message Format 4.7 0400 Message（终端发送至服务器的报文）
用于定义交易冲正，包括的冲正交易为7个，它们是：
✧磁条卡取款冲正
✧磁条卡转帐冲正
✧磁条卡消费冲正
✧磁条卡调帐冲正
✧IC卡电子存折圈存冲正
✧IC卡电子存折圈提冲正
4.8 0410 Message（服务器发送至终端的报文）
08xx Message Format 0800报文提供开始日终处理、结束日终处理、网络签到、签退、密钥更新等功能。

4.9 0800/0810 Message（日终处理开始、结束）
用于服务器和终端之间的开始日终处理和结束日终处理。

4.10 0800/0810 Message（设备签到报文）设备签到0800报文请求：
设备签到0810报文回应：
4.11 0800/0810 Message（签退报文）签退0800报文：
签退0810报文：
4.12 0800/0810 Message（密钥更新报文）更新密钥0800报文：
更新密钥0810报文：
90xx Message Format 4.13 9000 Message
服务器对终端的管理报文，其中的管理包括：服务器查询终端设备状态，启动一台终端，关闭一台终端，查询一台终端的交易统计数据、终端即时日终、终端定时状态上传、终端故障通知等。

4.15 9010 Message
终端对服务器管理请求报文的回应。

91xx Message Format 4.16 9100 Message（磁条卡修改密码请求报文）
4.17 9110 Message（磁条卡修改密码的回应报文）
4.18 9100 Message（终端发送至服务器的报文）
4.19 9110 Message（服务器发送至终端的报文）
5 报文说明
ATM终端联机报文包含四个组成部分：报文头（Sessiong Head）、报文类型标识符（Message Type Identifier）、位图（Bitmap）和报文域（Message Field）。

其结构如下图所示：
图1 报文组成
报文头是报文的第一个数据元素。

报文头与报文类型标识、位图和报文域一块组成了一个完整的报文。

报文类型标识是报文的第二个数据元素，是最高级别报文类型定义，定义了报文一般性分类，比如是金融类报文还是管理类报文。

报文类型标识符长度是四个字节。

每个报文都要求有报文类型标识符。

位图定义了哪些报文域会出现在报文中。

位图区包含两个位图。

位图一定义域2到域64，位图二定义域65到域128。

报文域构成了报文的主体，参照ISO 8583定义进行了裁剪，其中部分域的格式和内容银联进行了重新定义。

5.1 报文头（Sessiong Head）
Session Head ( 会晤报文头 )
格式：ans-8
长度：8个字节
描述：
服务器系统内部使用的报文头，所有的消息都需要该字段，其定义如下表所示。

注意：在终端组织该会晤报文头用于发送交易请求时，前面3个字节按照规定填写，后面5个字节填写‘0’。

服务器回应报文的会晤报文处理结果定义如下：
系统会晤报文处理结果a-1 报文处理结果
0 正常
1 数据格式错误应用协议规则定义如下：
系统会晤报文应用协议规则a-1 1 本行业务
y 中间业务
z 金卡业务、外卡业务。