财付通合作银行一点通技术标准v1.4


1 财付通合作银行一点通技术标准 1.4 版 2 前言 本文档介绍合作银行网上一点通的技术标准,其中包括合作银行网上一点通的业务模型、安全责任模型、架 构模型、业务处理与系统交互方式、报文的语法与语义、网络连接方式、安全规范等。 参与合作银行网上一点通业务的各方必须遵守合作银行网上一点通技术规范,以实现准确、安全、方便的网 上支付与相关业务。 合作银行网上一点通由财付通科技有限公司提出并制定。 3 目录 财付通合作银行一点通技术标准 .................................................................................................. 1 前言 ............................................................................................................................................................................... 2 目录 ............................................................................................................................................................................... 3 第 1 章 文档概述 ................................................................................................................................................... 5 1.1 介绍 ........................................................................................................................................................... 5 第 2 章 合作银行网上一点通概述 ....................................................................................................................... 6 2.1 合作银行网上一点通模型 ....................................................................................................................... 6 2.2 网上支付安全责任模型 ........................................................................................................................... 8 第 3 章 合作银行网上一点通架构 ..................................................................................................................... 10 3.1 网上支付架构目标 ................................................................................................................................. 10 3.2 网上支付架构模型 ................................................................................................................................. 10 3.3 网上支付交互模式 ................................................................................................................................. 13 第 4 章 网上支付报文结构 ................................................................................................................................. 16 4.1 报文基本规则约定 ................................................................................................................................. 16 4.2 报文结构 ................................................................................................................................................. 16 4.3 报文分类 ................................................................................................................................................. 17 4.4 报文扩展 ................................................................................................................................................. 18 4.5 通用报文 ................................................................................................................................................. 18 4.6 报文的解析与传输 ................................................................................................................................. 22 第 5 章 文件交换规范 ......................................................................................................................................... 23 5.1 文件访问路径 ......................................................................................................................................... 23 5.2 文件命名规范 ......................................................................................................................................... 23 5.3 文件压缩 ................................................................................................................................................. 23 5.4 文件加密 ................................................................................................................................................. 24 5.5 文件摘要 ................................................................................................................................................. 24 5.6 文件上传规则 ......................................................................................................................................... 24 第 6 章 合作银行网上一点通实现规范.............................................................................................................. 25 6.1 客户签约 ................................................................................................................................................. 25 6.2 客户撤消签约 ......................................................................................................................................... 36 6.3 签约信息查询(P1) ............................................................................................................................. 42 6.4 客户鉴权(P1) ..................................................................................................................................... 45 6.5 支付限额查询(P1) ............................................................................................................................. 47 6.6 支付(P0) ............................................................................................................................................. 49 6.7 单笔提现(P0) ..................................................................................................................................... 54 6.8 银行卡余额查询(P2) ......................................................................................................................... 58 6.9 签约对账(P0) ..................................................................................................................................... 60 6.10 清算对账(P0) ................................................................................................................................. 63 6.11 单笔支付订单查询(P0) ..................................................................................................................... 67 6.12 批量支付订单查询(P1) ................................................................................................................. 70 4 6.13 内部账户查询(P0)(如果是内部账户方式是必须的) ................................................................ 72 6.14 数字证书公钥交换 ............................................................................................................................. 75 第 7 章 网络连接规范 ......................................................................................................................................... 77 7.1 VPN 连接 ................................................................................................................................................ 77 第 8 章 安全规范 ................................................................................................................................................. 79 8.1 安全威胁 ................................................................................................................................................. 79 8.2 数字签名 ................................................................................................................................................. 80 8.3 报文日志管理 ......................................................................................................................................... 82 第 9 章 其它规范 ................................................................................................................................................. 83 9.1 异常处理规范 ......................................................................................................................................... 83 9.2 错误码规范 ............................................................................................................................................. 83 9.3 处理响应时间要求 ................................................................................................................................. 83 9.4 可用性要求 ............................................................................................................................................. 83 第 10 章 附录 ......................................................................................................................................................... 83 10.1 网上支付报文格式 DTD .................................................................................................................... 83 10.2 网上支付金额格式 ............................................................................................................................. 87 10.3 网上支付货币代码表 ......................................................................................................................... 87 5 第1章 文档概述 1.1 介绍 1.1.1 网上支付概述 在互联网支付体系中,持卡人身份验证与资金清算是两个关键问题。在传统解决方案中,对持卡人的身份验 证一般是由持卡人在发卡行提供的身份验证服务器(比如发卡行的网上银行)直接进行,并将身份验证的结果通 知商户。资金清算可能是在身份验证通过之后实时进行清算,也可能是通过专用的资金清算网络单独进行。 这种传统解决方案要求发卡行提供基于互联网的持卡人身份验证服务,并且要求商户在持卡人进行互联网支 付时,将持卡人引导至发卡行进行身份验证。随着互联网支付的普及,这种模式逐渐显现出一些问题。其中最突 出的问题是持卡人需要访问多个互联网服务站点才能完成一次完整的支付过程。在多个互联网服务站点之间跳转 使用户的交易与支付体验不够流畅。在这个过程由于网络传输、客户端处理中任何一个失败都会造成支付过程失 败。 随着互联网支付的发展,第三方支付平台已经成为互联网支付体系中的重要组成部分。越来越多的商户不是 直接通过银行,而是通过第三方支付平台实现基于互联网支付,利用第三方支付平台提供的快速便捷的支付清算 服务,降低接入复杂度、控制互联网支付的成本、提高用户的支付体验。 基于财付通的账户安全体系,当持卡人在进行互联网支付时,持卡人可以通过财付通账户安全体系进行身份 验证,并在身份验证通过时,委托财付通代他发出支付指令,实现使用该持卡人委托范围内的银行资金的划拨, 完成一次完整的互联网支付。使用这种方式,持卡人在进行网上支付时不需要访问多个互联网服务站点,避免输 入银行卡号与密码,可以提升用户的互联网支付体验,增加支付成功率,减少用户银行卡号与密码被盗的风险。 与此同时,基于这种信任与委托关系,在财付通和银行之间可以合作为持卡人与合作银行用户提供更多的增值服 务。 本文档阐述的合作银行网上一点通技术标准,为更加快捷安全的互联网支付结算提供了完全解决方案。 1.1.2 目标读者 本文的主要目标读者是合作银行网上一点通标准银行方的技术实施人员,其中的部分内容也可供银行的管理 与业务人员参考。 1.1.3 版本规范 合作银行网上一点通标准的版本规范是:<主版号>.<次版本号>.<模板号>。本文介绍合作银行网上一点通技 术标准的 1.4.0 版。 6 1.1.4 文档约定  需求优先级别,本需求规格说明将所有需求分为三个级别,其详细描述如下 名称 说明 P0 必须实现的需求,如果不实现,将影响整个一点通业务的完整等,导致一点通的核心 业务将无法实现。 P1 强烈建议实现的需求,不会影响到核心需求,但是如果实现,将大大提高用户体验。 P2 建议实现的需求,可以提高用户体验,吸引更多的客户。 第2章 合作银行网上一点通概述 本章介绍网上支付的业务模型,描述合作银行网上一点通的主要业务目的,介绍各个参与方的功能与责任, 并阐述作为网上支付安全性基础的安全责任模型。 2.1 合作银行网上一点通模型 2.1.1 业务模型 合作银行网上一点通的业务目的是充分结合财付通在互联网交易服务与市场占用率方面的专长,与银行在资 金管理与结算服务上的专长,双方优势互补,为财付通与银行的共同用户(其中包括互联网买家与商户)提供整 合、快捷、安全的互联网支付与结算解决方案。 合作银行网上一点通主要提供在互联网上进行支付时持卡人(作为买家)委托财付通使用他在银行卡账户中 的资金进行网上支付,以及持卡人(作为商户)委托财付通将他在财付通账户中的资金提现到他的银行卡账户中 这两大业务功能。 围绕这一业务目标,合作银行网上一点通的业务模型如下图所示: 7 用户域 资金清算域 交易控制域 买家 商户 银行 支付平 台 互联网交易服务 清算服务 银行金融服务 合作银行网上一点通模型 从上图中可以看出,合作银行网上一点通业务划分成用户域、交易控制域与资金清算域。资金可以在合作银 行网上一点通的三个域间进行双向的流动,在网上支付时,资金从买家银行卡账户流入财付通的客户保证金账户 中;在网上支付提现时,资金可以从财付通的客户保证金账户流入卖家的银行卡账户中。在资金转移的过程中, 财付通为用户提供包含交易担保在内的各种互联网交易服务,而银行为用户提供银行卡账户管理、现金业务等各 种金融服务。合作银行网上一点通通过三个域之间的协作实现畅通无阻的互联网交易服务以及与之相关的资金流 服务。  用户域 用户域中包括了合作银行网上一点通的主要服务对象,其中包括互联网交易中的买家与商户。买家使用合作 银行网上一点通进行交易货款支付,商户使用合作银行网上一点通进行交易货款结算。无论是买家还是商户,如 果需要使用合作银行网上一点通,必须至少拥有一个财付通账户与一张银行卡,并且财付通账户与银行卡的姓名 与身份证件需要一致。  交易控制域 交易控制域直接为用户域提供互联网交易服务以及与之相关的资金服务,其中包括交易支付时的买家身份验 证与授权、为商户提供货款结算服务、监督完整的交易履约过程、为交易各方提供沟通与交互平台等。在合作银 行网上一点通模型中,交易控制域的主体是财付通。  资金清算域 资金清算域管理用户(包括买家与商户)的实际资金账户,为用户提供银行金融服务。资金清算域也为交易 控制域提供资金清算服务,完成交易支付与货款结算时的实际资金转移。在合作银行网上一点通模型中,资金清 算域的主体是银行。 8 2.1.2 核心业务 为了使用财付通平台和合作银行联合提供的网上支付服务,用户首先需要与合作银行和财付通平台签定协 议,明确各方的权利与义务,这一过程称为网上支付签约。 在签约之后,用户就可以使用一点通进行方便、安全的网上支付与提现。 为了保证合作银行网上一点通处理的准确性,网上支付标准中也规定了各种管理类业务,如实时交易查询与 清算对账等。 2.2 网上支付安全责任模型 2.2.1 安全目标 网上支付业务的主要安全目标是,只有经用户本人委托与授权,才能够动用该用户开通合作银行网上一点通 的银行卡账户内的资金,并且用于用户指定的支付目的。 这一安全目标是通过用户、合作银行与财付通平台三方共同履行责任来保证的。引入网上支付安全责任模型, 目的在于明确规定各方在保障安全目标时的责任。 2.2.2 网上支付安全责任模型 下图给出了网上一点通支付的安全责任模型,给出了为了实现安全支付这一目标,用户、合作银行与财付通 平台各自应该履行的责任 。 9 用户域 资金清算域 交易控制域 买家 商户 银行 财付 通 信任 1. 只有本人同时拥有帐户号与支付密码 2. 向财付通发起的支付请求代表本人的真 实意图 1. 只有用户发起交易支付 请求,并且帐户与支付密 码验证通过,才能发起一 点通支付指令 2. 只有收到来自银行的资 金清算或账务处理的成功 结果,才执行用户请求的 交易支付 1. 只有来自财付通的支付指令 才能触发支付业务的资金清算 或账务处理 2. 给财付通的支付反馈真实反 馈资金清算或账务处理结果 3. 支付业务的服务与额度在用 户授权范围内 从上图中可以推导出,只要网上支付业务的参与者都恰当地履行了自己的责任,即可确保实现网上支付的安 全目标。图中的信任关系代表当用户使用财付通时,信任财付通履行责任 1(只有用户发起交易支付请求,并且 账户与支付密码验证通过,才能发起网上支付指令)。这一信任关系与财付通平台现有的用户协议是相容的。 2.2.3 责任认定方式 当出现网上支付安全目标被违背的情况时,为了认定责任,合作银行与财付通必须分别举证自己履行了责任。 如果两方中有一方无法举证自己履行了安全责任模型中规定的责任,则由于本次安全目标违背事件引发的损失由 未能举证的一方承担。如果合作银行与财付通都能够举证自己履行了责任,则表明用户未履行自己的安全责任, 损失由用户承担。由于安全责任模型中信任关系的存在,因此财付通无须举证自己履行了责任 1(只有用户发起 交易支付请求,并且账户与支付密码验证通过,才能发起网上支付指令)。 网上支付技术标准将支持银行与财付通举证自己履行了责任。 10 第3章 合作银行网上一点通架构 本章介绍财付通合作银行一点通的技术架构。描述组成一点通支付系统的各个组件以及它们之间的协作方 式。 3.1 网上支付架构目标 3.1.1 业务目标 财付通合作银行网上一点通架构的目标是在合作银行网上一点通模型的框架下,实现合作银行网上一点通的 目标、约束与流程,对网上支付安全与责任模型提供支持。 3.1.2 技术目标 除了实现业务目标,合作银行网上一点通架构也需要达成一些技术上的目标。其中最重要的技术目标是开放、 简单、安全。  开放 合作银行网上一点通标准需要实现财付通与各个银行系统的互联,为了方便财付通与银行之间的异构平台与 系统的互联,网上支付架构必须基于开放平台与标准,方便跨平台、跨地域的接入。  简单 合作银行网上一点通作为一种创新的、以简单、安全、快捷为核心理念的在线支付规范,在使用的方便性和 接入的简单性方面,要求超越传统的互联网支付解决方案。  安全 由于合作银行网上一点通标准简化了支付流程,并且由财付通系统而不是发卡行完成用户身份的验证,因此 必须规定严格的安全责任模型,并且通过恰当的技术标准和方法来实现该责任模型。 3.2 网上支付架构模型 3.2.1 架构模型 由于不同银行在系统架构上存在差异,本文中以典型的银行系统为例,介绍合作银行网上一点通的架构模型。 在网上支付系统的具体实施与接入中,可以视需要对该架构模型进行修改,增加、删除、分拆或者合并系统中包 含的组件。 11 银行 银行柜 面渠道 银行一 点通平 台渠道 银行(一点通)支付平 台业务系统 银行账务与卡业务系统 财付通 财付通一 点通平台 渠道 财付通 网站渠 道 财付通 后台渠 道 财付通一点 通文件系统 财付通一点 通业务系统 财付通账务与会员系统 银行柜员 用户 财付通工 作人员 银行网 上银行 渠道 财付通合作银行一卡通架构模型 图中显示了实现财付通合作银行网上一点通涉及到的系统组件。这些系统组件有些需要全新引入(如合作银 行网上一点通渠道和支付平台系统),有些需要在原有系统之上扩展(如银行柜面渠道、银行网上银行渠道),有 些可以直接使用现有的系统(如银行账务与卡业务系统)。 3.2.2 架构组件 网上支付技术架构中涉及到的系统组件与它们的主要职责如下:  银行一点通平台渠道 银行一点通平台渠道与财付通一点通平台渠道之间通过安全的信道互联,负责与财付通平台之间安全地 交换网上支付协议报文,验证报文的真实性与合法性,维护网上支付报文日志,并在银行一点通协议报文与 银行支付平台业务系统所能够理解的交易指令之间进行翻译。 银行一点通平台渠道可以独立搭建,也可以在现有渠道平台上扩展。 12  银行柜面渠道 银行柜面渠道是银行柜员的工作平台,负责接受银行柜员提交的合作银行网上一点通签约请求,并且提 供柜员与网上支付相关的资金对账与清算、客户服务等功能。银行柜面渠道不直接处理合作银行网上一点通 的核心逻辑,相关处理均翻译成银行合作银行网上一点通系统所能够理解的交易指令,交给银行支付平台业 务系统进行处理。 一般情况下,可以通过对现有银行柜面渠道系统进行功能扩展来支持合作银行网上一点通。  银行网上银行渠道 网上银行是指银行通过信息网络提供金融服务,包括传统银行业务和因信息技术应用带来的新兴业务。 网上银行业务不仅仅是传统银行产品简单向网上的转移,其它服务方式和内涵发生了一定的变化,而且由于 信息技术的应用,又产生了全新的业务品种。财付通合作银行一点通业务可以通过客户网上签约、解约,以 方便客户。网上银行渠道也不直接处理合作银行网上一点通核心逻辑,相关处理均翻译成合作银行网上一点 通系统所能够理解的交易指令,交给银行支付平台业务系统进行处理。 一般情况下,可以通过对现有银行网银渠道系统进行功能扩展来支持合作银行网上一点通。  银行(一点通)支付平台业务系统 银行(一点通)支付平台业务系统是合作银行网上一点通银行端业务处理的主要系统,负责接受来自银 行一点通平台渠道、银行柜面渠道或者银行网银渠道的请求、控制合作银行网上一点通流程、管理合作银行 网上一点通数据、验证网上支付服务授权与额度等业务规则、构造对银行账务与卡业务系统的交易请求、处 理银行账务与卡业务系统的返回结果、并将结果返回给银行网上支付渠道、银行柜面渠道、银行网银渠道等。 银行合作银行网上一点通系统可以独立搭建,也可以在现有中间业务平台上扩展。  银行账务与卡业务系统 银行账务与卡业务系统作为银行的核心系统,为合作银行网上一点通提供基础的客户身份验证、卡片密 码验证、资金清算处理等功能。 理想情况下,现有的银行账务与卡业务系统所提供的服务就能够支持合作银行网上一点通,不需要扩展 或者修改银行账务与卡业务系统。  财付通一点通平台渠道 财付通一点通平台渠道是财付通提供的合作银行一点通业务的接入点,负责与银行一点通平台渠道之间 通过安全信道交换网上支付协议报文,验证报文的真实性与合法性,维护网上支付报文日志,并在网上支付 协议报文与财付通一点通文件系统和业务系统所能理解的交易指令之间进行翻译。  财付通一点通业务系统 财付通一点通业务系统是一点通业务在财付通端业务处理的主要系统,负责接受一点通平台渠道、财付 通网站渠道或者财付通后台渠道的请求、控制支付平台网上支付流程、管理支付平台网上支付数据、验证网 上支付服务授权与额度等业务规则、构造对财付通平台账务与会员系统的交易请求、处理财付通平台核心业 务系统的返回结果、并将结果返回给财付通一点通平台渠道、网站渠道或后台渠道等。  财付通文件服务系统 某些一点通业务的实现中,涉及到银行与财付通平台交换数据文件。为了降低银行端的开发复杂性与成 本,在网上支付架构中,由财付通平台统一提供网上支付文件服务系统,处理合作银行网上一点通相关的文 件上传、下载与管理等功能。  财付通网站渠道 财付通网站是财付通用户使用支付服务的主要渠道之一。  财付通后台渠道 财付通后台渠道是财付通后台工作人员处理财付通平台服务、结算等业务的主要渠道。  财付通账务与会员系统 财付通账务与会员系统作为财付通的核心系统,为财付通网上支付提供基础的客户信息管理、身份验证、 客户虚拟账户管理、资金处理等功能。 13 3.3 网上支付交互模式 在合作银行网上一点通的技术实现中,合作银行与支付平台之间通过交换报文与数据文件来交换业务信息、 实现业务流程、控制业务规则。 实现合作银行网上一点通所需的交互模式可以归纳为请求-应答、单向通知、文件上传与文件下载这四种模式。 下文将介绍这四种交互模式适用的场景与实现方式。 3.3.1 请求-应答模式 在请求-应答模式下,一方作为服务提供者,另一方作为服务使用者。由服务使用者主动向服务提供者发起请 求并等待应答,服务提供者接受请求,完成处理,并向服务使用者应答处理结果,服务使用者收到处理结果之后 进行后续处理。 请求-应答模式适用于服务使用者需要根据服务提供者的服务应答才能进行正确的后续处理的场景,比如,在 网上支付业务中,财付通平台作为服务使用者,银行作为服务提供者,财付通平台需要知道银行的支付处理结果 之后才能继续交易流程。 3.3.2 单向通知模式 在单向通知模式下,一方作为通知发送者,一方作为通知接收者。发送者发送通知,并保证接收者收到通知。 通知接收者在收到通知之后,立即返回发送者通知已收到。通知送达之后,发送方与接收方可以独立地进行后续 业务处理。 在网上支付标准中,如果对方进行业务处理所需的时间不可预知时,采用单向通知模式。单向通知模式可以 单独使用,也可以作为其它交互模式的一部分使用,比如在文件下载、文件上传模式中应用了单向通知模式。 14 3.3.3 文件下载模式 在文件下载模式中,一方作为文件提供者,另一方作为文件使用者。文件提供者首先生成文件,然后通知文 件使用者,通知信息中包含该文件的下载位置等信息。文件使用者接到通知之后,下载文件并根据文件内容进行 后续的业务处理。 文件下载模式的特点是文件提供者拥有文件服务系统。由于网上支付架构中,文件服务系统是由财付通平台 统一提供的,因此,文件下载模式适用于由财付通平台向银行发起的批量业务处理请求,如批量退货等。 3.3.4 文件上传模式 在文件上传模式中,一方作为文件提供者,另一方作为文件使用者。文件提供者首先生成文件,然后将文件 上传给文件提供者。在文件上传完成之后,文件提供者通知文件使用者,通知信息中包含文件的上传位置与其它 信息。文件使用者接到通知之后,根据文件内容进行后续的业务处理。 文件上传模式的特点是文件使用者拥有文件服务系统。由于网上支付架构中,文件服务系统是由财付通平台 15 统一提供的,因此,文件上传模式适用于由银行向财付通平台发起的批量业务处理请求,如签约对账、清算对账 等。 16 第4章 网上支付报文结构 合作银行网上一点通报文规范是网上支付技术标准中重要的组成部分,规定了合作银行与财付通平台之间交 换报文的顺序、格式、语义与处理规范。本章中介绍网上支付报文的一般结构与公共元素,这些规范适用于所有 的网上支付协议报文。具体合作银行网上一点通中使用的报文,在各个业务实现规范中分别进行阐述。 4.1 报文基本规则约定 在请求-应答模式中,当请求在应答方成功完成时,须采用具体业务的成功报文进行响应;当请求因系统或业 务原因不能得到满足时,应答方须采用 4.5.1 所述的错误消息统一报文格式进行应答,不可采用具体业务的成功 报文进行响应。 4.2 报文结构 合作银行网上一点通报文统一采用 xml 格式(见附录)。所有的网上支付报文均以 Tenpay 作为根元素,每个 Tenpay 元素中可以包含多个 Message 元素。Message 元素中包含代表具体的业务的元素,比如 CSReq、CSRes 等。 每个业务元素由一系列属性元素构成,不同的业务元素中包含的属性元素有所不同。对于涉及到签约状态修改或 者资金变动的业务元素,必须要有与之匹配的 Signature 元素进行数字签名。 作为约定,Tenpay 元素、Message 元素与业务元素均是首字母大写的 CamelCase 形式,所有的属性元素均是 首字母小写的 CamelCase 形式。 以柜台签约报文为例,请求报文的格式如下: 17 应答报文格式如下: 在下文中出现的具体报文格式描述中,“出现要求”列包含的值的含义如下表所示: 值 含义 请求方约束 服务方约束 R Required(必须的) 必须包含该域 必须校验该域是否存在和内容的合法性 C Conditional(有条件的) 如果条件符合必须包 含该域  当条件满足时,必须校验该域是否存在  当该域存在时,必须检查其内容的合法性 O Optional(可选的) 该域可选 当该域存在时,必须检查其内容的合法性 具体的报文格式请参见附录 1。 4.3 报文分类 合作银行网上一点通协议中的报文按照交互模式的不同,分为以下几类:  服务请求类报文 服务请求类报文用于请求-应答交互模式,由服务使用者向服务提供者发送。服务请求类报文的命令规范 是 XXReq,其中 XX 是报文代表的业务的首字母缩略,Req 是 Request 的缩写。比如对于柜台签约请求报文, 命名为 CSReq,代表 Card Sign Request。  服务应答类报文 服务应答类报文用于请求-应答交互模式,由服务提供者向服务使用者返回。服务应答类报文的命令规范 是 XXRes,其中 XX 是报文代表的业务的首字母缩略,Res 是 Response 的缩写。比如对于柜台签约应答报文, 命名为 CSRes,代表 Card Sign Response。  通知类报文 通知类报文用于单向通知交互模式,由通知发送者向通知接收者发送。通知类报文的命令规范是 XXNotify,其中 XX 是报文代表的业务的首字母缩略。比如对于“签约对账”通知报文,命名为 SCNotify, 代表 Sign Check Notify。  通用报文 通用报文适用于所有的合作银行网上一点通。网上支付协议中有两种通用报文,一种是 Error 报文,用 于返回处理错误;另一种是 NotifyAccept,代表单向通知已被接受。 对于业务相关的服务请求类、服务应答类与通知类报文的具体格式,将放在具体的业务实现规范中加以 描述。报文的通用结果与通用报文将在本章描述。 18 4.4 报文扩展 报文扩展用于未来协议的扩展,表示任何需要但尚未定义在网上支付早期协议的消息域中的数据。报文扩展 数据为 XML 数据格式或者 Base64 编码的二进制数据格式,包含下表所列属性: 属性名称 属性特征 含义 id 必填属性 报文扩展域元素的唯一标识 critical 可选属性 布尔值,用于告诉报文接收方是否只有理解了报文扩展域中的内容才能理解 整个报文中的内容。 属性 critical 的值为小写的 true 或 false。如果只有理解了报文扩展域中的内容才能理解整个报文中的内容, 那么报文扩展域就应被视为关键性的,且 critical 属性值应该设置为“true”;否则报文扩展域就被视为非关键性的, 且 critical 属性值应该设置为“false”。 报文的接收方可以将 critical 属性视为可选属性,如果该属性未提供,将该属性缺省视为“false”。但是为了 保证交互有效性,即使该属性的值为“false”,报文的发送方也必须包含该属性。如果一个报文扩展域是关键性 的,报文的所有接收者都必须能够识别并处理该报文扩展域。如果一个报文扩展域是是非关键性的,报文的接收 者可以忽略不能识别或处理的报文扩展。 4.5 通用报文 4.5.1 错误消息报文 Error  功能 用来当请求或者应答不能被正确处理时返回。  Error 域 下表列举了 Error 消息域的定义: 中文域名 对应 DTD 元素 类型 出现要求 说明 版本号 version char(7) R 目前版本”1.4.0” 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见 数字签名 错误代码 errorCode char(4) R 错误描述 errorMessage char(256) R 详细错误信息 errorDetail char(512) O 服务方代码 vendorCode char(256) O 消息创建者特有的代码 消息扩展 Extension O  示例: 19  错误代码说明 下表列举了标准的错误代码: 错误代码 错误描述 解释 程序类错误 0000 无效的根元素 根元素无法识别 0001 未定义的消息域 消息不是 CSReq、CSRes 等;或者消息发送给了一个错误的组 件 0002 必填域缺失 0003 无法识别关键域 0004 根据规范,一个或多个域不 符合格式要求 例如,非数字,或者不是有效的日期格式等等。 0005 银行标识不正确 instId 域中的银行标识不正确 0006 协议版本有误 0007 签名无效 报文签名校验不通过 0008 加密密钥不存在 加密密钥不存在 0009 签名密钥不存在 签名密钥不存在 0300 文件格式不正确 系统导入文件时发现格式不对,导入失败 0301 业务日期不正确 业务日期格式不对,一般情况下业务日期必须是昨日,不过系 统也支持以前日期的数据处理 0302 文件已锁定 当文件上传通知发送後,不允许再次上传相同文件 0303 文件不存在 下载文件时,找不到指定的文件 0304 文件无法解密 上传的文件无法正确解密 0305 文件已处理 对于不允许重复处理的业务的文件,如果已处理过,就发生此 错误 0306 文件无法解压缩 上传的文件无法正确解压缩 0307 文件无法删除 上传文件无法删除 0308 文件摘要不正确 文件上传通知报文中的文件摘要不正确 0400 支付流水重复 重复的网上支付流水 0401 原支付流水不存在 申请退货的原支付流水不存在 0402 查询范围太大 查询时间跨度太大 20 用户类错误(可以将错误信息显示给用户) 1000 协议号已经签约成功 1001 一点通签约协议号无效 一点通签约协议号不对应有效的网上支付签约记录。 1002 网上支付签约状态不正确 网上支付签约状态不允许执行当前的业务 1200 身份证已经被使用 身份证已经被其它用户使用,并签约 1201 年龄不满足 如:用户未满 18 岁 1202 身份证格式不正确 身份证不是有效的身份证 1203 真实姓名不正确 真实姓名与合作银行中的不一致 1204 证件类型不正确 证件类型与合作银行中的不一致 1205 身份证号码不匹配 身份证号码与合作银行中登记的身份证号码不匹配 1206 认证信息不匹配 认证信息与合作银行通过认证的信息不匹配 1207 该银行卡号已经成功签约 该银行卡号对应的合作银行账号已经签约成功。 1301 财付通账户不存在 财付通账户标识(email)不对应有效的合作银行账户。 1302 财付通账户状态不正确 财付通账户的状态不允许签约。 1303 财付通账户类型不正确 财付通账户的类型不允许签约。 1304 财付通账户已经申请 1305 财付通账号绑定的网上支付 数量超限 财付通账号绑定的银行卡已经超过最大数量。 1306 合作银行账号通过的认证数 量超过最大值 财付通账号通过的认证数量超过最大值。 1401 密码校验次数超限 密码校验次数超限 1402 银行卡状态不正确 银行卡状态不正确 1403 银行账户状态不允许该操作 银行账户状态不允许该操作 1404 银行支付校验码输入错误 银行支付校验码输入错误 1405 银行支付校验码失效 支付校验码超过输入时间范围限制,失效 1406 原支付申请流水号已经支付 支付流水号已经支付过 1407 原支付申请流水不存在 支付申请流水不存在 1408 支付密码输入超限 合作银行支付密码超过输入次数限制 1601 金额超限 支付金额超过每日限额 1602 余额不足 银行账户中的余额不足以完成支付 1603 合作银行在该银行提现金额 不足 1604 银行交易处理中 该笔交易在银行前置系统中状态未知 1605 银行交易失败 该笔交易在银行系统中已经失败,且状态不会再发生变更。错 误具体详情通过 ErrorDetail 告知。 管理类错误 2000 网上支付渠道关闭 没有开通合作银行网上一点通 2001 服务没有开通 请求的业务没有开通 21 系统类错误 9000 暂时系统异常 例如,一个请求队列满了。 9001 永久系统异常 例如,无法访问一个重要数据库所在的磁盘。 4.5.2 NotifyAccept 报文  功能 用来代表单向通知已被接受。  消息域 下表列举了消息域的定义 中文域名 对应 DTD 元素 类型 出现要求 说明 版本号 version char(7) R 目前版本”1.4.0” 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字 签名 服务方代码 vendorCode char(256) O 通知接受人特有的代码 消息扩展 Extension O  示例 4.5.3 FileAccept 报文  功能 用来代表文件上传已被接受。  消息域 下表列举了消息域的定义 中文域名 对应 DTD 元素 类型 出现要求 说明 版本号 version char(7) R 目前版本”1.4.0” 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 22 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字 签名 服务方代码 vendorCode char(256) O 通知接受人特有的代码 消息扩展 Extension O  示例 4.6 报文的解析与传输 网上支付报文的传输使用 XML Over HTTP(S)方式,在 HTTP 请求/响应体中包含 XML 形式的报文。 4.6.1 报文解析 对 XML 解析的基本要求如下:  版本号检查 用于表示组件支持的协议版本号。消息版本号必须表示为:n+.n+[.n+] ,其中 “n” 表示数字, 表 示一个或多个。比如 1.0.0 或 1.4.0。在所有的消息中,各组件都必须填写自身支持的协议版本号。消息版本 号不能低于 1.4.0。如果消息版本号低于接收方组件支持的最低版本号,则接收方组件必须返回 Error 消息, 并且设置错误码=6。  xml 解析 为了可以支持后续协议版本,xml 解析的实现不要做严格的验证。特别是需要忽略未被确认的域。 所有 xml 消息必须用“utf-8”编码。  Message 域之 id 属性匹配 请求和应答报文的 Message 域之 id 属性必须相同,id 是请求方生成的唯一序列号。比如:银行在 CSReq 的Message域设置了一个id属性值,则支付平台在CSRes里面的Message域的id属性必须和CSReq的Message 域之 id 值相同。 4.6.2 报文传输 对 HTTPS 传输的基本要求如下: 23  使用 POST 发送消息 消息请求基于 HTTP/HTTPS 的 POST 方式。  HTTP 消息头要求 HTTP请求与响应消息中必须按照如下要求设置头部域: „Content-Length:‟必须设置成消息体的长度 „Content-Type:‟必须设置下面的值:application/xml; charset=utf-8 第5章 文件交换规范 5.1 文件访问路径 网上支付文件服务器的访问 URL 格式如下: http(s)://file.oneclick.tenpay.com/file/action/instId/yyyymmdd/filename?certId=xxxx&sign=xxxxxx, 其中:  http(s)://file.oneclick.tenpay.com/file/ — 网上支付文件系统的根路径(域名暂定)。  action — 操作类型(如:upload 表示上传、download 表示下载)。  instId — 银行机构代码(合作银行统一分配、管理)。  yyyymmdd — 文件业务日期(如:清算日期)。  filename — 遵循业务文件命名规范的文件名。  certId — 签名证书 ID,详情见证书获取规范。  sign — 使用 certId 指定的证书对“/action/instId/yyyymmdd/filename”进行签名,对签名结果进行 Base64 编 码获得的字符串。 注:文件上传时,文件通过附件方式上传。如果文件上传成功,服务器返回 FileAccept 报文,如果文件上传失败, 服务器返回 Error 报文。 5.2 文件命名规范 文件命名规范对文件名称进行统一的规划,以达到从文件名称上区分不同业务文件的目的。文件命名规范: filetype_yyyymmdd_sequence.zip,其中:  filetype — 文件类型,如:TSCF——签约对账文件;TCCF——清算对账文件;TBRF——批量退货请 求文件;TBRRF——批量退货结果文件等。  yyyymmdd — 文件业务日期(如:清算日期)。  sequence — 批次号。 5.3 文件压缩 传输前需要压缩成 zip 格式。 24 5.4 文件加密 对压缩后的文件,需要加密之后再传输。加密时采用三重 DES 对称加密算法 3DES。加密密钥按事先约定方式 分发。 5.5 文件摘要 对加密后的文件进行摘要,摘要不包含在文件中,通过文件上传通知报文传送。摘要算法使用标准 SHA1 算 法,结果表示成 40 位 16 进制大写字母数字串。 5.6 文件上传规则 文件上传完成后,文件上传者发送文件上传通知报文给对方。在发送文件上传通知报文前,文件上传方可以 再次发送相同文件名的文件覆盖原来的文件。文件上传方一旦发送了文件上传通知报文,文件系统不允许再次上 传该文件。 25 第6章 合作银行网上一点通实现规范 合作银行网上一点通功能覆盖了从签约、服务与管理的各个方面。签约类的业务负责网上支付服务协议的建 立、调整与撤消,其中包括柜台/在线签约、柜台/在线签约撤销、离柜签约、支付限额查询等。服务类的业务满 足用户互联网交易与资金清算需求,其中包括网上支付、提现(单笔与批量)与支付平台卡余额查询。管理类业 务是为了保证互联网交易的正常进行而引入的,其中包含实时交易查询、签约对账与清算对账。 本章描述如何通过用户、合作银行与财付通平台之间的协作实现上述合作银行网上一点通的流程与规则。同 时,本章也规定了在银行一点通平台渠道与财付通一点通平台渠道间的交互模式、交换的报文与文件的结构、语 义与处理规范。 为了保证合作银行网上一点通的正常开展,还有一些在银行或支付平台内部完成的业务流程,比如在银行完 成的支付限额修改,以及各种业务报表等,这些业务由于不涉及到合作银行与财付通平台的交互,因此在本文档 中不作具体描述。 6.1 客户签约 6.1.1 业务功能 持有银行卡与财付通账户的客户,可以至银行或网上在线主动申请签约合作银行网上一点通。签约过程通过 银行与财付通平台对客户身份的验证,建立客户、他所持有的银行卡与他所持有的财付通账户之间的关联,并确 定网上支付服务的限额。 为了方便客户签约,吸引更多的客户到一点通业务,我们应该提供多种途径的签约方式,具体包含如下处理 流程中说明的几类: 6.1.2 处理流程 6.1.2.1 柜台签约流程(P0) 持有银行卡和财付通账户的客户,可以到银行柜台申请合作银行一点通业务。签约过程通过银行和财付通平 台的交互对客户的身份验证,建立客户、他所持有的银行卡和他所持有的财付通账户之间的关联,并确定网上一 点通支付的限额。 处理流程 26 柜台签约 柜员 银行业务系统 财付通业务系统客户 14.核对回单,银 行操作完成 11.登记签约要素并返回结 果 10.验证姓名、证件号码、 财付通账户号信息 9.生成一点通签约请求报 文,通知财付通 8.生成一点通协议号 7.银行系统验证签约要素合 法性 5.用户输入银行卡 密码 3.柜员核对证件是 否与本人相符 4.录入签约要素 2.提交申请表、银 行卡和证件给银行 柜员 1.填写柜台签约申 请表 12.银行登记签约要素 13.签约结束,打印 回单 6.提交签约请求 15.用户在线登录财付通 16.客户查找到银行签约 记录,输入支付密码, 激活银行一点通签约 17.财付通校验用户密码即 其它签约信息,激活签约 记录 1) 客户到银行柜台申请开通财付通一点通支付业务,填写财付通一点通业务签约申请表,其中必须填写如下内 容:姓名、证件类型、证件号码、银行卡号码和财付通账户号。 2) 提交填写好的一点通签约申请表、银行卡和身份证给银行柜员 3) 银行柜员核对用户身份证件是否与申请人相符 4) 银行柜员录入柜面签约申请要素, 5) 客户输入银行卡密码 27 6) 银行柜员提交该请求到银行后台服务系统处理 7) 银行系统对签约申请要素进行合法性验证,其中至少包括:  银行卡状态有效  卡密码正确  银行卡允许开通网上支付 上述验证中如果有一项不符,则银行系统拒绝客户的签约请求。 8) 银行系统针对银行卡与客户资料信息,生成唯一的一点通签约协议号。 9) 银行系统以一点通签约协议号、签约时间、客户姓名、证件类型、证件号码、财付通账号、以及其它客户信 息等柜台签约要素构造“签约请求报文”通过安全的网络连接(VPN 和/或双向 SSL 的 HTTPS)提交给财付通 平台。 10) 财付通平台对签约要素进行合法性验证。 11) 财付通登记签约要素到财付通后台数据库中并标志该协议号状态为“银行已签约”,并向银行系统返回“签 约应答报文”。 合法验证内容至少包括:  一点通签约协议号格式有效  一点通签约协议号唯一  财付通账号存在  财付通账号状态正常  财付通账号的姓名与客户姓名相符  如果财付通账号中已经设置了证件类型与证件号码,则必须与客户证件类型与证件号码相符。 上述验证中,如果有任何一项不符,则财付通平台系统拒绝该签约申请,并向银行系统应答 Error 报文,报 告合法性验证不通过的原因。 12) 银行接收财付通平台的签约应答报文,如果应答报文表示财付通验证通过,则银行登记签约要素到银行业务 系统。 13) 银行系统返回签约结果给前台柜员,银行柜员打印签约回单。 14) 客户核对签约回单,正确无误后银行方操作完成。 15) 客户在线登录财付通。 16) 客户在线查询到银行签约记录(状态为未激活),客户输入支付密码,请求激活一点通签约。 财付通验证用户支付密码即其它签约要素,激活一点通签约。客户柜台签约所以步骤完成。 28 6.1.2.2 在线签约流程(P1) 持有银行卡和财付通账户的客户,可以通过在线登录到合作银行网银系统和财付通系统申请合作银行一点通 业务。签约过程通过银行和财付通平台的交互对客户的身份验证,建立客户、他所持有的银行卡和他所持有的财 付通账户之间的关联,并确定网上一点通支付的限额。 处理流程 29 在线签约 银行银行业务系统财付通业务系统客户 6.银行显示签约要素输入页 面给用户 15.用户查看结果,签约完 成 14.银行显示签约结果信息 11.验证姓名、证件号码、 财付通账户号信息 9.生成一卡通签约协议号 7.用户输入签约要素,如: 银行卡号、银行卡密码、网 银密码等 5.校验用户支付密码,并跳 转用户到银行签约页面4.用户输入支付密码 3.财付通显示用户信息,并 要求用户输入支付密码 2.用户选择银行,发起一点 通签约申请 1.用户登录财付通 8.银行系统验证签约要素 合法性 10.生成一点通请求报文,通 知财付通 12.登记签约要素并返回结 果给银行 13.银行登记签约要素 1) 客户登录财付通网站,申请财付通账户,预留以下信息:姓名、证件类型、证件号码、手机号码等。 2) 客户在财付通网站上,选择“申请一点通”功能选项,申请绑定一点通,一点通预登记客户信息到后台数据 库,待银行返回发送签约通知消息好在确认签约。 30 3) 财付通显示客户信息,并要求用户输入支付密码。 4) 客户输入财付通支付密码。 5) 财付通校验客户支付密码,并跳转客户页面到相应银行网银系统。(支付密码的校验不是必须的,由财付通 根据业务需要自行决定。) 6) 银行网银系统显示签约要素输入页面。 7) 客户根据银行网站指引,输入一点通签约要素(如:姓名、证件类型、证件号码、银行卡号码、卡密码、网 银密码等),进行在线一点通签约。 8) 银行系统验证用户输入的签约要素的合法性。 9) 银行系统针对银行卡与客户资料信息,生成唯一的一点通签约协议号。 10) 银行系统以一点通签约协议号、签约时间、客户姓名、证件类型、证件号码、以及其它客户信息等签约要素 构造“签约请求报文”通过安全的网络连接(VPN,专线和/或双向 SSL 的 HTTPS)通知财付通平台。 11) 财付通平台对签约要素进行合法性验证, 12) 财付通登记签约要素到财付通后台数据库中并标志该协议状态为“银行以签约”,激活一点通支付业务,并 向银行系统返回“签约应答报文”。 13) 银行接收财付通平台的签约应答报文,如果应答报文表示财付通验证通过,则银行登记签约要素到银行业务 系统。 14) 银行通过网银页面显示结果给客户。 15) 客户查看结果,签约完成。 注:客户也可以直接从银行网银页面发起签约请求而不用先登录财付通网站,客户通过银行网站发起签约请求时, 需要在银行网页输入财付通账号,银行可以实时也可以批量将用户签约信息通知财付通。财付通登记用户签约要 素,但用户仍然需要稍后登录财付通,激活签约申请。 6.1.2.3 离柜签约流程(P2) 持有银行卡和财付通账户的客户,可以通过离柜的方式,向财付通市场推广人员提交合作银行一点通业务申 请。后者在收到客户的书面申请后,将客户的申请信息录入财付通系统,验证客户的身份信息,建立客户、他所 持有的银行卡和他所持有的财付通账户之间的关联,并确定网上一点通支付的限额。 处理流程 31 离柜签约 财付通市场人员 财付通业务系统客户 1.填写一点通签约申请 表 3.核对证件是否与本人 相符 2.将填好的申请表及身 份证提交给财付通市场 人员 4.录入签约要素到财付 通后台服务系统 5.财付通系统验证签约 要素合法性 7.财付通发送通知消息 给客户 8.客户接收并核对签约 确认信息. 6.财付通登记签约要素 1) 客户按照财付通市场推广人员提供的一点通业务签约申请表,填写签约要素信息,其中必须包内含如下内容: 客户姓名、证件类型、证件号码、银行卡号码、财付通账户、手机号码等信息,并签字确认。 2) 客户提交签约申请表以及身份证给财付通相关人员。 3) 财付通相关人员核对证件是否与本人相符。 4) 财付通相关人员通过财付通后台管理服务,录入客户的一点通签约申请信息。 5) 财付通后台业务系统验证用户信息的合法性,并保留客户签约申请单作为用户确认的法律依据。 6) 财付通登记客户签约要素信息。 7) 由于是离柜、离线签约,财付通根据需要还可以通过某种方式将签约结果通知客户,如手机短信方式。(是 否通知,以及以何种方式通知,财付通可以根据自身业务调整。) 8) 用户接收签约通知消息,确认签约成功。 注:财付通可以将经客户签字确认的签约申请表递交给银行,由银行盖章确认之后,签约申请方可生效,财付通 也可以不给银行客户申请表,而是和银行签订统一的代扣协议,用户在财付通请求一点通支付时,财付通将用户 的银行帐号、姓名、证件类型、证件号码发送给银行,由银行校验通过之后才接收支付请求。 32 6.1.3 业务规则  签约接口可重入 财付通平台收到银行签约请求,但此请求的客户已签约,且银行请求的签约要素与财付通登记的签约要素完 全一致,财付通返回签约成功报文。  身份实名认证  签约客户、银行卡持卡人与财付通账户所有人必须是同一人。签约关系一旦成立,则参与合作银行网上 财付通支付客户信息将不可变更,直至签约关系终止。(用户一旦做了实名认证,将不得申诉改变身份 信息。)  实名认证是强制执行的,如果用户没有通过实名认证,将不能进行一点通支付、提现等操作。实现实名 认证的方式有如下几种途径: 1) 对于柜面、在线签约方式,银行方在收到用户签约申请并验证通过后,在发送给财付通的通知报文 中包含客户的姓名、证件类型、证件号码信息,财付通系统将此信息和用户登记到财付通的身份信 息进行比较,如果两者完全一致,实名认证通过。 2) 对于柜面、在线签约方式,如果银行出于保护客户隐私的需要,不方便提供明文的客户身份信息, 也可将客户的姓名、证件类型、证件号码组成的序列进行签名后发送给财付通,财付通使用同样签 名方式,将客户登记在财付通的身份信息的签名和银行的签名比较,两者一致,实名认证通过。 3) 对于离柜签约方式,由于签约时未进行实名认证,所以在支付时,用户必须输入付款的银行账户, 财付通将客户姓名、证件类型、证件号码以及银行账户信息同时发送给银行,银行验证以上信息和 客户在银行登记的信息完全一致,才能接受支付请求。(支付和实名认证同时进行)  客户银行签约通知方式 客户在银行签约时,银行需要将客户的签约要素通知财付通,财付通必须登记以上签约要素,客户方可进行 一点通支付、提现等操作。银行通知财付通的方式有两种: 1) 实时通知,银行在客户签约时,实时连线将客户的签约要素通知财付通,财付通进行实时验证,建立签 约关系。 2) 非实时通知(批量通知),银行定期生成客户一定时间段内的签约记录文件(一般每日日终生成当日的 记录),通过安全的方式提交签约记录文件给财付通,财付通导入用户签约文件,验证签约要素,建立 签约关系。  银行签约时无财付通账户 如果用户在银行签约时,没有开通财付通账户,银行也可以接受用户的签约请求。 1) 签约时,客户需要提供一个唯一的账户,如:QQ 号、Email 地址或手机号等。 33 2) 银行需要通知财付通用户签约要素信息。 3) 财付通登记签约要素信息,但此签约记录状态为“未激活”。 4) 用户可以在银行签约之后,用他在银行签约时提供的唯一账户注册为财付通账户,并将此账户与签约记 录关联并激活。 5) 用户注册财付通账户时提供的姓名、证件类型、证件号码信息必须与他在银行签约时提供的信息完全一 致。  签约协议号规则 签约协议号统一由银行方生成,且必须唯一,具体要求如下:  包含银行代码,可以从一点通签约协议号标识出银行。  包含银行卡号、客户姓名、证件类型、证件号码的验证信息,当上述信息中任何一项发生改变,一点通 签约协议号均不再有效。  无法从一点通签约协议号中获知银行卡号、用户姓名、证件类型与证件号码。  满足上述要求的一点通签约协议号生成标准由网上支付技术标准规定,为了使各个银行生成的签约协议 号符合上述规则,财付通需要给银行提供统一的签约协议号生成 API。  银行跳转 URL 参数 对于客户在财付通方发起的在线签约请求,财付通在验证客户信息之后,会引导客户跳转到银行网上银行页 面进行银行方的签约,在跳转银行方的 URL 中,应包含如下参数,以便在银行通知财付通时能唯一确定对应的请 求记录: uin: 客户财付通账户,银行方需要包含此字段到通知报文中。 bindserialno: 绑定序列号,银行方需要包含此字段到通知报文中。 url: 签约成功后回跳财付通的 URL。 merchant: 银行分配给财付通的商户号。 6.1.4 交互模式 在银行签约业务中,银行与财付通平台通过请求-应答模式交互。 在柜台/在线签约业务流程过程中,银行作为服务使用者向财付通平台发送 “签约申请”报文 CSReq,财付 通平台作为服务提供者向银行返回“签约应答”报文 CSRes。 34 支付平台 6.1.5 报文格式  签约请求报文 CSReq(Card Sign Request) CSReq 是从银行向财付通平台发起的签约请求报文。 中文域名 对应DTD元素 类型 出现 要求 说明 版本号 version char(7) R 目前版本号:”1.4.0” 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字签名 交易日期和时间 date char(17) R YYYYMMDD HH:MM:SS 一点通签约协议号 signNo char(32) R 对于同一财付通帐号、同一银行卡此协议号必须 唯一,其生成规则参见 6.1.6 一点通签约协议号 规范 银行卡号 cardNo char(32) R 银行卡卡号或其最后六位(至少 4 位) 银行卡类型 cardType char(1) R D 代表借记卡 C 代表贷记卡 U 代表联名卡 O 其他 客户姓名 name char(30) R 性别 gender Char(1) O M 代表男,F 代表女 证件类型 certType char(1) R 1:身份证 证件号码 certNo char(19) R 35 身份信息 Hash 值 identityHash Char(40) C 正常情况下,银行需要将用户的姓名、证件类型、 证件号码发送给财付通做实名认证。如果银行出 于保护用户隐私的需要,也可将用户姓名、证件 类型、证件号码的 Hash 值发送给财付通进行实 名认证。 财付通平台帐号 uin char(65) R 财付通平台帐号 财付通绑定序列号 bindSerialno Char(20) R/O 如果是财付通完整发起的签约请求,客户在跳转 银行时,财付通会附加该序列号到跳转 URL 中, 银行签约完成后,需要将次字段包含在本通知报 文中传给财付通 消息扩展 Extension O  签约应答报文 CSRes(Card Sign Response) CSRes 财付通平台返回给银行的 CSReq 应答。 中文域名 对应DTD元素 类型 出现 要求 说明 版本号 version char(7) R 目前版本号:”1.4.0” 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字签名 一点通签约协议号 signNo char(32) R 来自 CSReq 消息扩展 Extension O 6.1.6 一点通签约协议号规范 一点通签约协议号在合作银行网上一点通中用于确定并校验唯一的银行卡持有者、合作银行用户与财付通平 台账户。一点通签约协议号在签约时由银行按照一点通签约协议号生成规范生成,并在银行与财付通平台同时记 录。 一点通签约协议号是一个 32 位,由数字 0-9,以及字母 A-F 组成的字符串,其格式如下: <1 位版本号><6 位卡 BIN><2 位银行自定义位><3 位扩展位><19 位个人账户信息 Hash 值><1 位校验位> 其中:  1 位版本号:这 1 位代表一点通签约协议号编码规则的版本,目前为 1。  6 位卡 BIN:即银行卡号的前 6 位,代表发卡行的 BIN(Bank Identification Number)。  2 位银行自定义位:这 2 位由银行自行定义和使用,其中每一位必须为数字 0-9 或者字母 A-F。  3 位扩展位:这 3 位留作以后扩展,目前必须均为 0。  19 位 Hash:是“银行卡号|用户姓名|证件类型|证件号码|Hash 种子”字符串经 MD5 散列后的值,以 16 进制 字母大写形式表示。Hash 的种子由银行自行设定并秘密保管。  1 位校验位:由模 10 “隔位乘 2 加”校验数算法计算得出。 模 10“隔位乘 2 加”校验数的计算步骤如下:  步骤 1:从右边第 1 个 16 进制数字(0-9,A-F)开始每隔一位乘以 2。  步骤 2:将步骤 1 中得到的乘积的各位数字与原号码中未乘 2 的各位数字相加。  步骤 3:将步骤 2 中得到的数字按 10 取模,得到一个 10 进制数字。 36  步骤 4:将步骤 3 中得到的数字按 10 取补。 从步骤 4 中得到的数字就是校验位。 注:本协议号规范仅公银行参考,财付通仅要求签约协议号码长度必须为 32 个字符长度、且银行方必须保 证其生成的签约协议号唯一。银行方可自行确定自身的协议号生成规则。 6.2 客户撤消签约 6.2.1 业务功能 已签约客户可以到银行柜台或网银撤销签约。签约撤销业务解除签约银行卡与财付通平台账户之间的关联, 废除签约时建立的财付通一点通网上支付、提现等。 37 6.2.2 处理流程 6.2.2.1 柜台撤销签约(P0) 柜台撤销签约 财付通业务系统银行业务系统银行柜员客户 1.填写柜台撤销签 约申请表 2.提交申请表、银 行卡和证件给银行 柜员 3.柜员核对证件是 否与本人相符 4.录入撤销签约要 素 5.客户输入银行卡 密码 6.提交撤销签约请 求 7.验证撤销签约要素合 法性 8.生成撤销签约请求报 文,通知财付通 11.验证撤销签约要素 12.将签约记录标记为 “银行已撤销” 13.返回撤销签约结果 給银行 14.将签约记录标记为 “已撤销” 12.撤销签约完成, 打印回单 13.核对回单,交易 结束 1) 已经签约财付通合作银行一点通业务的客户,可以到银行柜台提交撤销签约申请单撤销签约,需要填写的信 息包括:客户姓名、银行卡号、证件类型、证件号码、财付通帐号。 2) 客户提交申请单、银行卡和证件给银行柜员。 3) 银行柜员核对信息,确认证件是否与本人相符。 4) 银行柜员根据客户填写的信息查找签约协议,并输入撤销签约要素。 5) 客户输入银行卡密码。 6) 银行柜员提交撤销签约请求给银行后台业务系统处理。 38 7) 银行后台业务系统在对用户的撤销签约请求进行合法性验证。 8) 银行业务系统生成撤销签约请求报文,通知财付通。 9) 财付通验证用户撤销签约请求信息。 10) 财付通查找出对应的签约协议,将其状态标志为“银行已撤销签约”。 11) 财付通返回结果给银行。 12) 银行后台业务系统将客户的签约记录标记为“已撤销”。 13) 银行柜员打印回单给客户。 14) 客户核对回单,撤销签约交易结束。 6.2.2.2 在线撤销签约(银行发起)(P1) 在线撤销签约(银行发起) 财付通业务系统银行业务系统客户 1.用户登录银行网银服务 2.查找财付通一点通签约 记录,发起撤销请求 3.验证撤销签约要素合法 性 4.生成撤销签约请求报 文,通知财付通 8.将签约记录标记为“已 撤销” 6.将签约记录标记为 “银行已撤销” 5.验证撤销签约要素 7.返回撤销签约结果給 银行 9.显示撤销签约结果给用 户 10.查看并核对撤销签约结 果,交易结束 1) 客户登录银行网银系统服务。 2) 查找到财付通一点通业务签约记录,选择“撤销签约”功能提交撤销签约请求,按照网上银行系统的引导, 输入必要的验证信息(如:网银密码、银行卡密码等)。 39 3) 银行后台业务系统在对用户的撤销签约请求进行合法性验证之后。 4) 银行后台业务系统生成撤销签约请求报文,通知财付通撤销用户的签约记录。 5) 财付通验证用户撤销签约请求信息。 6) 财付通查找出对应的签约协议,将其状态标志为“银行已撤销签约”。 7) 财付通并返回撤销签约结果给银行。 8) 银行后台业务系统在收到财付通的确认信息之后,修改银行方后台数据库,将客户的签约记录设置为“已撤 销”状态。 9) 银行返回处理结果给客户。 10) 客户查看并核对撤销签约结果,交易结束。 6.2.2.3 在线撤销签约(财付通发起)(P1) 在线撤销签约(财付通发起) 财付通业务系统 银行业务系统客户 1.客户登录财付通网站 2.选择要撤销的一点通签 约记录,输入支付密码, 发起撤销签约请求 3.验证用户的撤销签约要 素合法性 4.生成撤销签约请求报 文,通知银行 5.验证撤销签约要素 6.将客户签约记录标记 为“已撤销” 7.返回撤销签约结果給 财付通 8.将签约记录标记为“银 行已撤销” 9.显示撤销签约结果给用 户 10.查看并核对撤销签约结 果,交易结束 1) 客户登录财付通。 40 2) 客户查找到财付通一点通业务签约记录,选择“撤销签约”功能提交撤销签约请求,客户将按照财付通撤销 签约流程,输入必要的验证信息(如:支付密码,但是输入支付密码不是必须的,由产品组根据需要决定。)。 3) 财付通后台业务系统在对用户的撤销签约请求进行合法性验证之。 4) 财付通生成撤销签约请求报文,通知银行撤销用户的签约记录。 5) 银行后台业务系统在收到财付通发送过来的用户撤销请求信息之后,验证请求信息的合法性。 6) 银行后台业务系统查找到对应的用户签约记录,将其状态设置为“已撤销”。 7) 银行返回处理结果给财付通。 8) 财付通验证银行返回信息,如果处理成功,则将客户对应的签约信息设置为“银行已撤销”。如果银行返回 失败,则财付通撤销签约失败,客户需要重试。 9) 财付通显示撤销签约结果给客户。 客户查看并核对撤销签约结果,撤销签约交易结束。 6.2.3 业务规则  撤销签约接口可重入,即:财付通平台收到银行撤销签约请求,但此协议号已经撤销签约,返回撤销签约成 功报文。  撤销签约后,银行与财付通双方均应知晓该网上财付通支付合约关系已终止,不再提供与之相关的任何财付 通网上支付,是否同时终止该客户由于合作银行一点通网上支付的其它业务,由银行与财付通平台自行规定。  银行无撤销签约通知给财付通的处理 由于某些银行技术或业务上的限制,可能无法发送客户撤销签约请求给财付通,在此情况下,用户在银 行方撤销签约后,可以登录财付通网站系统,查找到对应的一点通签约记录,主动将其设置为“银行已撤销” 状态,以方便客户再次申请同一银行的其它银行卡的一点通业务。  银行给财付通的撤销签约请求发送失败的处理 如果银行在接受客户的撤销签约请求后,由于任何原因,无法将通知发送给财付通系统(如:银行网络 连接问题、财付通系统故障等),银行业务系统可以忽略此信息而继续处理客户的撤销请求,将银行方用户 的签约记录设置为“已撤销”状态。 银行将在日终生成签约变动对账单,财付通将在 T + 1 日进行对账,保持客户签约信息在财付通系统和 银行系统之间的一致性。  用户在银行方撤销签约后,可以登录财付通网站系统,查找到对应的一点通签约记录,主动将其设置为“银 行已解约”状态,以方便客户再次申请统一银行的其它银行卡的一点通业务。 41 6.2.4 交互模式 在柜台和银行网银发起的撤销签约中,银行与财付通通过单项通知模式交互,银行作为服务使用者向财付通 发送撤销签约通知报文 CSCNotify,财付通以通知接受报文 NotifyAccept 返回给银行。随后,双方进行后续处理。 银行 财付通 签约撤销通知报文CSCNotify() 撤销财付通端签约() 撤销签约通知已收到() 撤销银行端卡通签约() 在财付通发起的撤销签约中,财付通与银行通过请求应答模式交互,财付通作为服务使用者向银行发送撤销 签约请求报文 CSCReq,银行收到请求后,验证请求报文并将请求报文中指定的签约记录设置为“已撤销”状态, 并返回财付通撤销签约应答报文 CSCRes 银行财付通 “撤销签约”请求报文CSCReq() 验证请求报文() 撤销银行端签约() “撤销签约”应答报文CSCRes() 撤销财付通端签约() 6.2.5 报文格式  “撤消签约”通知报文 CSCNotify(Card Sign Cancel Notify) “撤消签约”通知报文 CSCNotify 是银行向财付通平台发起的撤销签约通知报文。 中文域名 对应 DTD 元素 类型 出现 要求 说明 版本号 version char(7) R 目前版本号:”1.4.0” 42 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字签名 交易日期和时间 date char(17) R YYYYMMDD HH:MM:SS 一点通签约协议号 signNo char(32) R 消息扩展 Extension O  “撤销签约”请求报文 CSCReq(Card Sign Cancel Request) “撤销签约”请求报文 CSCReq 是财付通向银行发起的撤销签约请求报文。 报文格式与“撤销签约”通知报文 CSCNotify 相同。  “撤销签约”应答报文 CSCNRes(Card Sign Cancel Response) CSCNRes 财付通平台返回给银行的 CSCNReq 应答。 中文域名 对应 DTD 元素 类型 出现 要求 说明 版本号 version char(7) R 目前版本号:”1.4.0” 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字签名 一点通签约协议号 signNo char(32) R 消息扩展 Extension O 6.3 签约信息查询(P1) 财付通向银行查询某个协议号的签约状态。 43 6.3.1 处理流程 签约信息查询 银行业务系统财付通业务系统财付通客服 1.输入签约协议号,发起 查询请求 2.验证请求合法性,生成 签约信息查询请求报文 3.发送请求报文给银行 4.银行验证查询签约信息 请求报文的合法性 5.根据签约协议号查询签 约信息 6.生成签约信息查询应答 报文,返回签约状态给财 付通 7.验证银行应答报文 8.显示查询结果9.查看结果 1) 财付通管理或客服人员登录财付通后台管理系统,输入客户签约协议号,发起签约信息查询请求。 2) 财付通后台服务系统验证请求合法性,生成签约信息查询请求报文。 3) 财付通发送签约信息查询请求报文给银行,发送的请求信息至少包括签约协议号。 4) 银行系统验证合法性。 5) 银行系统查找该订单对应的签约记录。 6) 银行系统生成签约信息查询应答报文,返回签约状态信息给财付通。 7) 财付通后台业务系统显示查询结果。 8) 查询人员查看结果。 6.3.2 业务规则  财付通可向银行实时查询,确定当日的某个协议号的签约情况。 44  银行系统验证请求合法性,如果没有此签约协议号则返回错误报文,有则返回协议号对应的签约情况。 6.3.3 报文格式  “签约信息查询”请求报文 CSQReq 签约信息查询请求报文 CSQReq 是向银行发起的查询请求。 中文域名 对应 DTD 元素 类型 出现 要求 说明 版本号 version char(7) R 目前版本号:”1.4.0” 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字 签名 交易日期 date char(17) R 签约协议号 signNo char(32) R 消息扩展 Extension O  “签约信息查询”应答报文 CSQRes 签约信息查询应答报文 CSQRes 是银行返回的查询应答。 中文域名 对应 DTD 元素 类型 出现 要求 说明 版本号 version char(7) R 目前版本号:”1.4.0” 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字 签名 签约标志 flag char(1) R 0-尚未签约 1-已经签约 2 – 签约已撤销 银行卡号 cardNo char(6) R 银行卡卡号最后六位 签约协议号 signNo char(32) R 银行卡类型 cardType Long(1) R D 代表借记卡 C 代表贷记卡 O 其他 客户姓名 name Long(30) R 性别 gender char(1) R M 代表男 F 代表女 证件类型 certType char(1) R 1:身份证 证件号码 certNo char(19) R 身 份 信 息 Hash 值 identityHash Char(40) C 正常情况下,银行需要将用户的姓名、证件 类型、证件号码发送给财付通做实名认证。 如果银行出于保护用户隐私的需要,也可将 用户姓名、证件类型、证件号码的 Hash 值发 送给财付通进行实名认证。 财付通平台帐号 uin char(65) R 财付通平台帐号 消息扩展 Extension O 45 6.4 客户鉴权(P1) 6.4.1 处理流程 客户鉴权 银行业务系统财付通业务系统客户 1.客户登录财付通 2.客户发起支付请求或其 它业务请求 3.开始执行客户交易请求 4.执行请求过程中,判断 需要进行客户鉴权 5.生成客户鉴权请求报 文,发送给银行 6.银行验证鉴权请求报文 7.执行鉴权逻辑 8.生成鉴权请求应答报 文,返回结果给财付通9.验证鉴权应答报文 10.财付通根据鉴权结果决 定是否继续执行客户请求 1) 客户登录财付通 2) 客户请求执行支付或其它业务请求。 3) 财付通开始执行交易请求 4) 财付通在执行请求的过程中,判断需要进行客户鉴权。 5) 财付通生成客户鉴权请求报文,发送给银行。请求信息至少包含:客户姓名、交易日期、证件类型、证 件号码等。 46 6) 银行验证鉴权请求报文。 7) 银行执行鉴权逻辑,根据证件号码查询客户信息,判断户名正确性。 8) 银行生成鉴权请求应答报文,返回结果给财付通。 9) 财付通验证鉴权结果请求报文。 10) 财付通根据鉴权结果决定是否继续执行客户请求 6.4.2 业务规则  当用户需要执行某些需要验证用户的身份信息的支付请求时(如:基金购买等),而在客户签约时没有 对财付通账户的身份信息和银行账户的身份信息的一致性进行校验时,需要发起该请求。  银行根据证件号码查询客户信息,判断户名正确性,返回结果。 6.4.3 报文格式  “客户鉴权”请求报文 CAReq(Customer Authentification Request) 客户鉴权请求报文 CAReq 是向银行发起的鉴权请求。 中文域名 对应 DTD 元素 类型 出现 要求 说明 版本号 Version char(7) R 目前版本号:”1.4.0” 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字签名 客户姓名 Name char(30) R 交易日期 Date char(17) R 证件类型 certType char(1) R 1:身份证 证件号 certNo char(19) R 银行卡号 cardNo char(32) O 可选,如果不为空,则银行也需要核对银行卡号是否存 在。 消息扩展 Extension O  “客户鉴权”应答报文 CARes(Customer Authentification Response) 客户鉴权应答报文 CARes 是银行返回的鉴权应答。 中文域名 对应 DTD 元素 类型 出现 要求 说明 版本号 version char(7) R 目前版本号:”1.4.0” 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字签名 47 鉴权结果 result char(1) R 0 - 鉴权成功 1 - 鉴权失败 2 - 非我行客户 消息扩展 Extension O 6.5 支付限额查询(P1) 6.5.1 业务功能 客户每日可以网上支付的总金额有一定的限制。客户每日支付限额由合作银行与财付通平台根据业务策略与 客户要求进行双重设置与控制。 客户可以通过财付通平台查询银行端的网上支付限额。 6.5.2 处理流程 支付限额查询 银行业务系统财付通业务系统客户 1.登录财付通,输入支付 密码查询支付限额 2.验证用户请求合法性 3.生成支付限额查询请求 报文,发送给银行 4.验证支付限额查询请求 的合法性 5.查询限额,生成应答报 文,返回给财付通5.验证应答报文 6.显示结果7.查看结果 1) 用户登录财付通支付平台,输入支付密码查询支付限额。 2) 财付通验证查询合法性。 3) 财付通生成支付限额查询请求报文,发送请求给银行。 4) 银行验证支付请求限额查询请求的合法性。 5) 银行查询该用户当日支付限额,并返回结果给财付通。 48 6) 财付通显示客户当日支付限额给客户。 7) 客户查看结果。 6.5.3 业务规则  客户只能查询自己的银行端的网上支付限额。 6.5.4 交互模式 在支付限额查询业务中,合作银行与财付通平台通过请求-应答模式交互。 支付平台 6.5.5 报文格式  “支付限额查询”请求报文 PLQReq (Payment Limit Query Request) 支付限额查询请求报文 PLQReq 是财付通平台向银行发起的每日限额查询请求。 中文域名 对应 DTD 元素 类型 出现 要求 说明 版本号 version char(7) R 目前版本号:”1.4.0” 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字签名 交易日期和时间 date char(17) R YYYYMMDD HH:MM:SS 一点通签约协议号 signNo char(32) R 消息扩展 Extension O  “支付限额查询”应答报文 PLQRes (Payment Limit Query Response) 支付限额查询应答报文 PLQRes 是银行返回给财付通平台 PLQReq 的应答。 49 中文域名 对应 DTD 元 素 类型 出现 要求 说明 版本号 version char(7) R 目前版本号:”1.4.0” 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字签名 一点通签约协议号 signNo char(32) R 交易货币代码 currency char(3) R 日累计限额 limitAmount Long (12) R 见金额格式说明,每日总的累计限额。 单笔支付限额 singleLimitA mount 一点通单笔支付限额。 消息扩展 Extension O 6.6 支付(P0) 6.6.1 业务功能 网上支付业务的主要服务对象是互联网交易中的买家,使买家能够通过财付通平台使用签约银行卡内的资金 实现快捷、安全的网上交易。 财付通平台负责验证客户持卡人身份与服务权限,并请求银行划拨客户的资金用于互联网交易;银行负责验 证由财付通平台发出的财付通指令是否在签约的业务范围与银行控制的支付限额内,并实时扣减签约银行卡内的 余额。 由于网上支付引起的银行与财付通平台间的资金清算方法由清算标准规定。 50 6.6.2 处理流程 一点通网上支付 财付通业务系统 银行业务系统客户 1.互联网购物 3.验证用户支付密码及其一 点通支付的合法性 4.发送手机验证码到用户手机 并提示用户输入手机验证码 6.验证用户输入的手机验证 码 7.发送网上一点通支付请求 报文给银行 8.验证一点通支付的合法性 9.网上支付处理/入账 11.财付通入账并完成交易 支付 12.显示支付结果给用户13.用户查看支付结果 2.用户输入支付密码 5.用户输入手机验证码 10.生成支付应答报文,返 回支付结果给财付通 1) 客户通过互联网在财付通平台商户网站购物,并在财付通平台创建交易。 2) 客户输入财付通支付密码,请求财付通平台使用本人财付通账户关联的签约银行卡进行支付。 3) 财付通验证客户身份和一点通网上支付请求的合法性,验证项目包含:  客户的财付通账户的状态允许支付。  支付密码正确。 51  客户已签约一点通业务。  客户的财付通账户安全等级达到一点通支付的需求。  当日一点通网上支付总额在财付通规定的一点通每日支付限额内。 上述验证中如果有一项不符,则财付通拒绝客户的一点通网上支付请求,并将客户引导到恰当的财付通功能 页面。 4) 财付通发送手机验证码到客户手机,并提示客户输入手机验证码。 5) 客户接收到手机验证码之后,输入手机验证码。 6) 财付通验证用户输入的手机验证码。 7) 财付通根据标准生成网上一点通支付请求报文并发送给银行。 8) 银行验证支付请求报文的合法性,验证项目至少包括:  一点通协议号对应的一点通签约记录状态为已签约。  银行卡状态有效。  银行卡余额足够。  银行卡当日累计的网上支付总额未超过银行规定的每日支付限额。 上述验证中如果有一项不符,则银行拒绝该请求报文,并返回财付通一点通支付失败的原因。 9) 银行处理网上支付请求,将支付签约记录中的银行卡账户的相应资金划拨到资金清算专用账户,并进行其它 关联处理(比如手续费计算,积分计算等)。 10) 银行生成支付应答报文,返回支付结果给财付通。 11) 财付通验证支付应答报文,入账并完成交易支付。 12) 显示支付结果给用户。 13) 查看支付结果。 注: 由于用户支付是已经输入了支付密码,所以手机验证的过程不是必需的。有财付通根据用户支付请求 的类型和金额决定是否需要对用户进行手机验证。 6.6.3 业务规则  网上支付必须由客户请求,从财付通发起。  网上支付的资金只能从签约时约定银行卡账户中支出,用于同一客户的网上支付交易。  网上支付时客户在签约银行卡账户中的资金只能转移到财付通公司指定的清算账户中。  同一支付订单号的网上支付交易必须保证只能执行一次。 52  银行和财付通平台需要保存网上支付相关报文的日志作为解决资金清算不一致的依据。  银行必须根据客户的意愿做限额限制。  发送给用户的手机验证码必须由财付通发出并进行验证,银行需要验证财付通支付请求报文的合法性以及用 户是否已经签约等信息。  如果客户在银行申请一点通签约时没有申请财付通账户,或者由于银行系统的原因,没有将客户签约信息发 送给财付通平台,财付通将无法知道客户是否已与银行签约,客户可以在此输入签约订单号或者签约银行卡 号,财付通根据客户的输入组装支付请求报文,尝试到银行支付。如果支付能成功,说明客户已到银行签约。 (P2 需求)  如果客户采用离柜签约的方式,那么银行将没有登记客户的签约要素,在财付通发送给银行的请求报文中, 需要包含用户的姓名、证件类型、证件号码和银行账户号。如果银行不支持此种方式的接口,那么财付通将 不能支持离柜签约以及在此协议下的支付方式。 6.6.4 交互模式 在网上支付过程中,财付通平台与银行通过请求-应答模式交互。 财付通 银行 “网上支付”请求报文CPReq 处理网上支付交易 “网上支付”应答报文CPRes 后续业务处理 6.6.5 报文格式 如果客户是通过银行方签约(柜台或在线),则在签约时已经进行了实名认证,所以支付时可以直接根据 签约订单号进行。 如果客户是通过离柜方式签约,那么客户为进行实名认证,所以财付通发送给银行的支付请求报文必须 包含客户身份信息(客户姓名,证件类型,证件号码)。 所以,支付请求/应答报文存在两种格式: 53 6.6.5.1 签约协议号支付报文格式  “网上支付”报文 CPReq(Card Payment Request) 网上支付处理报文 CPReq(Card Payment Request) 是从财付通平台向银行发起的支付请求。 中文域名 对应 DTD 元素 类型 出现 要求 说明 版本号 version char(7) R 目前版本号:”1.4.0” 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字签名 流水号 serialNo char(32) R 对应财付通平台的支付订单号。 交易日期和时间 date char(17) R YYYYMMDD HH:MM:SS 协议号 signNo char(32) R 交易金额 amount Long(12) R 见金额格式说明 交易货币代码 currency char(3) R 见货币代码表 消息扩展 Extension O  “网上支付”应答报文 CPRes(Card Payment Response) 网上支付应答报文 CPRes 是银行返回给财付通平台 CPReq 的应答。 中文域名 对应 DTD 元素 类型 出现 要求 说明 版本号 version char(7) R 目前版本号:“1.4.0” 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字签名 流水号 serialNo char(32) R 财付通流水号,与CPReq报文的流水号相同 协议号 signNo char(32) R 来自 CPReq 交易金额是否透 支 overdraft char(1) R 交易金额是否通过透支获得(A 全部透支 P 部分透支 N 无透支) 消息扩展 Extension O 6.6.5.2 实名认证+支付报文格式  “网上认证 + 支付”请求报文 ACPReq(Authentification And Card Payment Request) “网上认证 + 支付”请求报文 ACPReq(Authentification And Card Payment Request)是从财付通平台向银行发起的 支付请求。 中文域名 对应 DTD 元素 类型 出现 要求 说明 版本号 version char(7) R 目前版本号:”1.4.0” 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字签名 流水号 serialNo char(32) R 对应财付通平台的支付订单号 交易日期和时间 date char(17) R YYYYMMDD HH:MM:SS 银行卡号 cardNo char(32) R 银行卡卡号 54 客户姓名 name char(30) R 证件类型 certType char(1) R 1:身份证 证件号码 certNo char(19) R 交易金额 amount Long(12) R 见金额格式说明 交易货币代码 currency char(3) R 见货币代码表 消息扩展 Extension O  “网上认证 + 支付”应答报文 ACPRes(Authentification And Card Payment Response) 网上支付应答报文 ACPRes 是银行返回给财付通平台 ACPReq 的应答。 中文域名 对应 DTD 元素 类型 出现 要求 说明 版本号 version char(7) R 目前版本号:“1.4.0” 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字签名 流水号 serialNo char(32) R 财付通流水号 交易金额是否透 支 overdraft char(1) R 交易金额是否通过透支获得(A 全部透支 P 部分透支 N 无透支) 消息扩展 Extension O 6.7 单笔提现(P0) 6.7.1 业务功能 网上支付单笔提现业务的主要服务对象是互联网交易中的商户,使商户能够通过支付平台将其通过交易所得 的资金从支付平台账户快速转移到他的网上支付签约银行卡账户内。 支付平台负责验证客户的身份与服务权限,确保其是支付平台账户与支付平台卡的所有人,并请求银行划拨 资金至该用户的银行卡账户中;银行负责验证由支付平台发出的提现指令是否在网上支付签约的业务范围,并实 时增加签约银行卡内的余额,并扣减网上支付资金清算账户中的款项。 由于单笔提现引起的银行与支付平台间的资金清算方法由网上支付清算标准规定。网上支付单笔提现适用于 要求实时提现的商户。 55 6.7.2 处理流程 单笔提现 银行业务系统财付通业务系统客户 1.客户登录财付通 2.输入支付密码、提现金 额,请求一点通快速提现 3.验证提现请求合法性, 如:支付密码、金额等信息 4.冻结客户请求提现的相应 金额 5.生成快速提现请求报文, 发送给银行 6.银行验证快速提现请求的 合法性 7.从财付通保证金账户划拨 资金到用户的签约账户 8.生成单笔快速提现应答报 文,返回给财付通 9.财付通验证银行应答报文扣减 财付通账户余额(如果失败,不 解冻财付通账户余额) 10.显示结果給用户11.查看快速提现结果 1) 客户登录财付通。 2) 客户输入支付密码、提现金额,请求财付通合作银行一点通快速提现。 3) 财付通验证客户提现请求的合法性,验证项目包含:  该财付通账户的状态是否允许提现。  支付密码正确。  一点通业务已签约。  提现金额不大于财付通账户内的可用余额。 56  账户安全等级达到一点通提现的要求。  当日一点通提现次数与总金额在财付通规定的一点通每日提现限次与限额之内。  其它财付通定义的针对一点通提现的业务规则。 4) 财付通冻结客户请求提现的相应金额。 5) 财付通生成快速提现请求报文,发送給银行。 6) 银行验证快速提现请求的合法性,验证项目至少包括:  一点通签约协议号对应的签约记录状态为已签约。  银行卡状态有效。  银行卡余额足够。  银行卡号当日累计的一点通提现次数、总金额未超过银行规定的每日提现限次与限额。  该笔请求的订单号之前未背执行过。 7) 银行执行资金划拨,从财付通保证金账户划拨相应的资金到用户的签约账户中。 8) 银行根据资金划拨的结果,生成单笔快速提现请求的应答报文,发送给财付通。 9) 财付通验证银行的应答报文。但不论银行划拨资金成功或者失败,财付通都不解冻或扣减客户的财付通 账户的余额。用户账户余额的解冻或者扣减将在 T + n 日收到银行提交回来的对账单之后,在施行解冻 或者资金扣除。 10) 财付通显示提现结果给用户 11) 用户查看并确认结果。 6.7.3 业务规则  网上单笔提现业务只能由客户请求,并从财付通平台发起。  提现的资金只能划付到客户的网上支付签约银行卡账户中。  提现的资金只能从事先约定的网上支付资金清算账户中划拨。  提现的资金不能超过合作银行与支付平台对每日提现额度的限制。  提现的资金不能超过客户在支付平台账户中的可用余额。  同一提现订单号的单笔提现交易必须保证只能执行一次。  银行与财付通平台需要保存双方与提现相关的报文日志作为解决资金清算不一致的凭据。  单笔提现适用于对提现实时性要求较高的客户,一般来说,提现资金可以实时到账。  如果客户对资金实时性要求不高,可以采用批量提现方式,这种提现方式与财付通目前的批量提现方式相同。 57 6.7.4 交互模式 在单笔提现业务中,合作银行与支付平台通过请求-应答模式交互。 在单笔提现流程中,财付通平台作为服务使用者向银行发送 “单笔提现”请求报文 SWReq,银行作为服务 提供者向支付平台返回“单笔提现”应答报文 SWRes。 支付平台 这两种报文的结构如下节所示。 6.7.5 报文格式  “单笔提现”请求报文 SWReq(Single Withdraw Request) 单笔提现请求报文 SWReq 是支付平台向银行发起的单笔提现请求。 中文域名 对应DTD元素 类型 出现 要求 说明 版本号 version char(7) R 目前版本号:”1.4.0” 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字签 名 流水号 serialNo char(19) R 交易日期和时间 date char(17) R YYYYMMDD HH:MM:SS 一点通签约协议号 signNo char(32) R 交易金额 amount Long(12) R 见金额格式说明 交易货币代码 currency char(3) R 消息扩展 Extention O 58  “单笔提现”应答报文 SWRes(Single Withdraw Response) 单笔提现应答报文 SWRes 是银行返回给支付平台 SWReq 的应答。 中文域名 对应DTD元素 类型 出现 要求 说明 版本号 version char(7) R 目前版本号:”1.4.0” 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字签 名 流水号 serialNo char(19) R 提现流水号 消息扩展 Extention O 6.8 银行卡余额查询(P2) 6.8.1 业务功能 客户能够在通过财付通平台身份验证之后,直接通过财付通平台查询属于网上支付签约银行卡中的可用余额 与卡状态。 6.8.2 处理流程 银行卡余额查询 银行业务系统财付通业务系统客户 1.登录财付通,输入支付密码 请求查询签约银行卡余额 5.查询客户签约银行卡余 额,卡状态,返回财付通 2.验证用户请求合法性 7.显示结果 3.生成签约银行卡余额查 询请求报文,发送给银行 6.验证应答报文 4.验证签约银行卡余额查 询请求的合法性 8.查看结果 1) 客户登录财付通,输入支付密码请求查询签约银行卡余额。 2) 财付通验证用户请求的合法性,主要验证信息包含:支付密码、用户已签约、客户财付通账户的身份信 59 息与银行签约银行卡账户信息一致。 3) 财付通生成签约银行卡余额查询请求报文,发送給银行。 4) 银行验证签约银行卡余额查询请求报文的合法性。 5) 银行查询客户签约银行卡余额即状态,返回给财付通。 6) 财付通验证应答报文。 7) 财付通显示查询结果。 8) 客户查看查询结果。 6.8.3 业务规则  客户只能查询属于他本人的财付通一点通签约银行卡账户中的可用余额与卡状态。  银行需要提供网上支付签约银行卡在查询时的实时可用余额与卡状态。 6.8.4 交互模式 在银行卡余额查询业务中,合作银行与支付平台通过请求-应答模式交互。 在银行卡余额查询流程中,支付平台作为服务使用者向银行发送 “余额查询”请求报文 BQReq,银行作为 服务提供者向支付平台返回“余额查询”应答报文 BQRes。 支付平台 6.8.5 报文格式  “余额查询”请求报文 BQReq(Balance Query Request) 60 余额查询请求报文 BQReq 是支付平台向银行发起的账户余额查询请求。 中文域名 对应 DTD 元素 类型 出现 要求 说明 版本号 version char(7) R 目前版本号:”1.4.0” 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字签名 交易日期和时间 date char(17) R YYYYMMDD HH:MM:SS 一点通签约协议 号 signNo char(32) R 交易货币代码 currency Char(3) R 消息扩展 Extension O  “余额查询”应答报文 BQRes(Balance Query Response) 余额查询应答报文 BQRes 是银行向支付平台返回的账户余额查询应答。 中文域名 对应 DTD 元素 类型 出现 要求 说明 版本号 version char(7) R 目前版本号:”1.4.0” 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字签名 一点通签约协议 号 signNo char(32) R 账户余额 balance Long(12) R 见金额格式说明 交易货币代码 currency char(3) R 账户状态 status char(10) O N-正常状态 L-挂失状态 B-冻结状态 消息扩展 Extension O 6.9 签约对账(P0) 6.9.1 业务功能 如果合作银行与财付通平台的网上支付签约状态不一致,则客户无法进行基于一点通的网上支付、提现、退 货等业务。网上支付签约对账业务的目的是使合作银行与财付通平台分别维护的网上支付签约状态一致。 网上支付签约对账业务一般一天进行一次。由银行在 T+1 日主动向支付平台提供银行 T 日 0:00-24:00 间变化 的签约数据。支付平台根据银行提供的签约数据与财付通 T 日的签约数据进行比对,找出状态不一致的签约记录。 对双方不一致的签约记录,一律以银行的签约状态为准修改支付平台的签约状态(离柜签约除外)。 61 6.9.2 处理流程 签约对账 财付通银行 1.在T+1日生成T日0:00 – 24:00签约变动记录 2.上传签约记录到财付通文件 服务系统 3.发送签约对账通知报文 4.核对T日签约变动记录 5.修正签约不一致的记录 1) 银行在 T + 1 日将 T 日 0:00 – 24:00 间所有变动的一点通签约记录生成一个文件并保存。 2) 银行按照事先约定的上传 URL 与文件名格式向支付平台上传一点通签约对账文件。 3) 银行以签约对账日期、时间与文件名等信息构造“签约对账”通知报文,告知财付通平台签约对账文件 已上传。如果发送失败,银行应当有恰当的充实策略。 4) 财付通平台收到“签约对账”通知报文后,从银行提供的签约对账文件中解析出每一条签约记录,与自 己在该对账日期所有变动的签约记录进行逐笔核对。找出并生成以下三类签约记录清单:  A: 银行有,但支付平台没有的签约变动记录。  B: 支付平台有,但银行没有的签约变动记录。  C: 双方都有,但签约记录不一致的签约变动记录。 5) 修正签约记录,针对不同的签约变动记录,做出不同的修正:  A: 支付平台进行签约状态修正,保证支付平台的签约记录与银行的签约记录一致。  B: 支付平台使自己的签约变动记录失效。  C: 无法由系统自动判定,因此由财付通后台管理人员人工介入,找出原因并确定修正方式。 62 6.9.3 业务规则  银行提供的签约变动记录需要与财付通的签约变动记录在时间区间上一致。  银行需要在 T + 1 日上午 9:00 之前主动向财付通平台提供 T 日网上支付签约数据文件。  当一点通签约对账完成并进行签约状态订正之后,双方直到 T 日所有一点通签约记录的状态必须一致。 6.9.4 交互模式 在签约对账业务中,银行与支付平台通过文件上传模式交互。 在签约对账处理流程的第 2、3 步,银行作为文件提供者向支付平台上传文件,并发送 “签约对账”通知 SCNotify。 支付平台 6.9.5 报文格式  “签约对账”通知报文 SCNotify (Sign Check Notify) 签约对账通知报文 SCNotify 是银行向支付平台发起的签约对账通知请求。 中文域名 对应 DTD 元 素 类型 出现 要求 说明 版本号 version char(7) R 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字签名 交易日期和时间 date char(17) R YYYYMMDD HH:MM:SS 63 文件名称 fileName char(30) R TSCF_yyyymmdd_sequence.zip(见文件命名规范), 其中 yyyymmdd 是对账日期。 对账日期 signDate char(8) R YYYYMMDD 文件摘要 digest char(40) R 见文件摘要 消息扩展 Extension O 6.9.6 文件格式  文件格式 文件格式采用 CSV(Comma-Separated Variable)标准。  “签约对账”文件结构 签约对账文件的每一行代表一条变动的签约记录,由多个域组成,各个域的内容如下表所示。 中文名称 出现要求 备注 一点通签约协议号 R 银行卡号 R 银行卡类型 R 客户姓名 R 性别 O M 代表男 F 代表女 证件类型 R 1:身份证 证件号码 R 身份信息 Hash 值 R/O 如果没有证件类型、证件号码,则此字段为必须的字段 财付通帐号 R 绑定序列号 O/R 最近签约状态 R S 签约 C 撤销 47D5EBFEDB8847D39B40F5AE21205B2C,000019,D,姓名 1,M,1,429827197905072618,,3869823,,S 47D5EBFEDB8847D39B40F5AE21205B2D,000020,D,姓名 2,M,1,429827197905072619,,3869823,,S 47D5EBFEDB8847D39B40F5AE21205B2E,000021,D,姓名 3,M,1,429827197905072620,,3869825,,S 47D5EBFEDB8847D39B40F5AE21205B2F,000022,D,姓名 4,M,1,429827197905072621,,3869826,,C 47D5EBFEDB8847D39B40F5AE21205B2G,000023,D,姓名 5,M,1,429827197905072622,,3869827,,C 47D5EBFEDB8847D39B40F5AE21205B2H,000024,D,姓名 6,M,1,429827197905072623,,3869828,,S 47D5EBFEDB8847D39B40F5AE21205B2I,000025,D,姓名 7,F,1,429827197905072624,,3869829,2101201005191234,S 6.10 清算对账(P0) 6.10.1 业务功能 从支付平台发起的网上支付、提现与退货交易的执行结果以银行返回给支付平台的交易应答为准。当发生网 络丢失报文或系统故障时,银行返回给支付平台的交易应答有可能丢失,造成客户签约银行卡账户中的资金变动 与支付平台账户中的资金变动不一致。除了交易应答丢失产生清算不一致的情况下,还可能因为其它原因(比如 系统中的缺陷,或者人为因素)产生清算不一致。 64 网上支付清算对账业务的目的是发现用户签约银行卡账户与支付平台账户中的资金变动不一致的情况,并确 定原因与处理办法。 网上支付清算对账业务一般一天进行一次,由银行在T 日终核对完成之后主动向支付平台提供T 日0:00-23:59 所有涉及到资金变动的网上支付交易的明细数据,与支付平台 T 日的网上支付交易数据进行比对,找出不一致的 交易记录。对于由于银行交易应答丢失造成的支付平台不一致的交易记录,由支付平台进行恢复处理。对于由于 其它原因产生清算不一致的情况,根据支付平台收到的银行交易应答内容确定资金处理差错的一方,并由该方进 行账务调整处理。如果由银行方的资金处理差错造成清算差错,则按照合作银行网上一点通清算标准中规定的差 错处理方法进行清算差错处理。 6.10.2 处理流程 清算对账 银行 财付通 2.上传清算对账文件到财付通 文件服务系统 3.发送清算对账通知报文 1.在T+1日生成T日0:00 – 24:00清算记录 4.核对T日网上支付、体现与退 款流水 5.数据恢复与修正 1) 银行在 T 日日终后,将 T 日 0:00 – 24:00 间与财付通之间发生的网上支付、提现与退款的网上交易记 录生成清算对账文件并保存。不同交易性质的网上交易保存在同一个清算对账文件中,按照交易性质、 交易时间排序。 2) 银行按照事先约定的上传 URL 与文件名格式向支付平台上传清算对账文件。如果上传文件失败,银行应 当有恰当的重试策略。 3) 银行以清算对账日期、时间与文件名等信息构造“清算对账通知报文”,告知财付通平台清算对账文件 已上传。如果发送失败,银行应当有恰当的重试策略。 4) 财付通平台收到“清算对账通知报文”后,从银行提供的清算对账文件中解析出每一条交易记录,与本 系统在该对账日期内的所有网上交易进行逐笔核对。生成以下三类差错记录的清单: 65  A:银行有,但支付平台没有的交易记录  B:支付平台有,但银行没有的交易记录  C:双方都有,但内容不一致的交易记录 5) 财付通平台针对不一致的网上支付交易差错记录进行恢复与处理。  对于 A 类交易记录,支付平台进行交易恢复,保证合作银行对该笔交易的资金处理与支付平台一致。  对于 B 类交易记录与 C 类交易记录,支付平台人工介入处理,通过核对原始的银行应答指令,找出 原因并确定该由哪方进行订正。如果存在需要银行进行调整的交易记录,则支付平台线下提供给银 行的需要调整的交易记录清单,以及原始的银行应答指令,由银行在人工核实之后进行处理。 6.10.3 业务规则  清算对账业务在执行中需要满足以下约束条件:  银行提供的 T 日 0:00-24:00 变化的网上交易明细数据需要与支付平台的账务处理一致。  银行在 T+1 日上午 9:00 点之前主动向支付平台提供 T 日网上支付交易明细数据文件。  T 日网上支付交易净额需要与支付平台清算给合作银行的 T 日网上支付款项净额相同。  当清算对账完成后,并完成差错处理之后,双方直至 T 日的所有网上支付交易引起的资金变动必须一致。  清算方式请详见《合作银行网上一点通之结算标准》。 6.10.4 交互模式 在清算对账业务中,银行与支付平台通过文件上传模式交互。 在清算对账处理流程的第 2、3 步,银行作为文件提供者向支付平台上传文件,并发送 “清算对账”通知报 文 CCNotify。 66 支付平台 6.10.5 报文格式  “清算对账”通知报文 CCNotify(Clearing Check Notify) 清算对账通知报文 CCNotify 是银行向支付平台发起的清算对账通知请求。 中文域名 对应 DTD 元 素 类型 出现 要求 说明 版本号 version char(7) R 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字签名 交易日期和时间 date char(17) R YYYYMMDD HH:MM:SS 文件名称 fileName char(30) R TCCF_yyyymmdd_sequence.zip (见文 件 命 名 规 范),其中 yyyymmdd 是对账日期。 对账日期 clearingDate char(8) R YYYYMMDD 文件摘要 digest char(40) R 见文件摘要 消息扩展 Extension O 6.10.6 文件格式  文件格式 文件格式采用 CSV(Comma-Separated Variable)标准。  “清算对账”文件结构 清算对账文件由汇总项与明细项两部分组成。 汇总项为文件第一行,其中包含以下各项: 中文名称 备注 处理成功总金额 本批处理成功的总金额,格式见 金额格式说明 处理成功总笔数 本批处理成功的总笔数 67 处理失败总笔数 本批处理失败的总笔数 明细项从文件第二行开始直到文件结束,其中每一行包含以下各项: 中文名称 备注 流水号(订单号) 合作银行公司流水号 交易日期 YYYYMMDD HH:MM:SS 交易类型 0 提现; 1 支付; 2 退货 一点通签约协议号 手续费 见金额格式说明 交易金额 见金额格式说明 交易货币代码 原流水号 退货交易时必填 原交易日期 退货交易时必填 处理状态 Y 成功;N 失败 失败原因 如果处理状态为失败,则描述失 败的原因。 6.11 单笔支付订单查询(P0) 6.11.1 业务功能 财付通发起的向银行查询某个特定的订单号的支付信息及支付状态。 68 6.11.2 处理流程 单笔支付订单查询 银行业务系统财付通业务系统财付通客服 7.验证银行应答报文 1.输入支付订单号,发起 查询请求 2.验证请求合法性,生成 支付订单查询请求报文 8.显示查询结果9.查看结果 4.银行验证查询订单信息 请求报文的合法性 6.生成签约信息查询应答 报文,返回订单信息 5.根据订单号查询订单信 息 3.发送请求报文给银行 1) 财付通管理或客服人员登录财付通后台管理系统,输入支付订单号,发起支付订单查询请求。 2) 财付通后台服务系统验证请求合法性,生成支付订单查询请求报文。 3) 财付通发送支付订单查询请求报文给银行,发送的请求信息至少包括支付订单协议号。 4) 银行系统验证合法性。 5) 银行系统查找该支付订单号对应的信息。 6) 银行系统生成支付订单查询应答报文,返回订单支付信息给财付通。 7) 财付通后台业务系统显示查询结果。 8) 查询人员查看结果。 6.11.3 业务规则  财付通可向银行实时查询,确定当日的某笔支付订单号的支付情况。 69  银行系统验证合法性,如果没有此订单号则返回错误报文,有则返回相应订单的详细信息。 6.11.4 交互模式 在单笔支付订单查询过程中,财付通和银行以请求-应答方式进行交互。财付通作为服务的使用者,向银行方 发送“单笔订单查询”请求报文(Single Order Query Request),银行方作为服务的提供者,向财付通返回“单笔 订单查询”应答报文(Single Order Query Response)。 财付通 银行 “单笔订单查询”请求报文SOQReq 处理订单查询请求 “单笔订单查询”应答报文SOQRes 6.11.5 报文格式  “单笔订单查询”请求报文 SOQReq(Single Order Query Request) “单笔订单查询”请求报文 SOQReq(Single Order Query Request)是从财付通平台向银行发起的单笔订单查 询请求: 中文域名 对应 DTD 元素 类型 出现 要求 说明 版本号 version char(7) R 目前版本号:”1.4.0” 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字签名 流水号 serialNo char(32) R 对应财付通平台的支付订单号 订单日期 orderDate char(8) R 要查询的订单日期,YYYYMMDD 交易日期和时间 date char(17) R YYYYMMDD HH:MM:SS 消息扩展 Extension O  “单笔订单查询”应答报文 SOQRes(Single Order Query Response) “单笔订单查询”应答报文是银行返回给财付通的订单查询应答报文: 中文域名 对应 DTD 元素 类型 出现 要求 说明 版本号 version char(7) R 目前版本号:“1.4.0” 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字签名 流水号(订单号) serialNo char(32) R 财付通订单流水号 70 订单日期 orderDate char(45) R YYYYMMDD HH:MM:SS 交易类型 transType char(1) R 0 提现; 1 支付; 2 退货 一点通签约协议号 signNo Char(32) R 必须(离柜签约支付交易除外) 交易金额 amount Long(12) R 见金额格式说明 交易货币代码 currency char(3) R 见货币代码表 处理状态 status Char(1) R Y 成功;N 失败;U 未知状态(交易单正在处理 中) 失败原因 cause Char(255) O 描述订单失败原因 消息扩展 Extension O 6.12 批量支付订单查询(P1) 6.12.1 业务功能 由财付通发起的,查询某个时间段内所有成功的支付订单的清单信息。 6.12.2 处理流程 批量支付订单查询 银行业务系统财付通业务系统 1.财付通系统生成查询某个时间段内 成功的支付订单清单的请求报文 2.银行验证财付通请求报文,验证请 求参数的合法性 3.银行生成指定时间段内成功的支付 订单清单表 4.银行组装查询应答报文返回财付通5.验证应答报文的合法性 6.根据银行返回的成功的支付订单信 息进行后续处理,如及时对账和调整 等。 1) 财付通系统生成查询某个时间段内成功的支付订单清单的请求报文,为了避免对银行系统造成过大压 力,可以对查询的时间段长度做严格规定,如不能查询超过一个小时时间内的订单清单。 71 2) 银行验证财付通请求报文,验证请求参数的合法性。 3) 银行生成请求报文中指定时间段内成功的支付清单表。 4) 银行组装查询应答报文并返回财付通。 5) 财付通验证应答报文的合法性。 6) 财付通根据银行返回的成功的支付订单信息进行后续处理,如及时对账和调账等。 6.12.3 业务规则  财付通可向银行实时查询,或许当日某个时间段内所有成功的支付订单列表。 6.12.4 交互模式 在多笔支付订单查询过程中,财付通和银行以请求-应答方式进行交互。财付通作为服务的使用者,向银行方 发送“多笔订单查询”请求报文(Multiple Order Query Request),银行方作为服务的提供者,向财付通返回“多 笔订单查询”应答报文(Multiple Order Query Response)。 财付通 银行 “多笔订单查询”请求报文MOQReq 处理订单查询请求 “多笔订单查询”应答报文MOQRes 6.12.5 报文格式  “多笔订单查询”请求报文 MOQReq(Multiple Order Query Request) “多笔订单查询”请求报文 MOQReq(Multiple Order Query Request)是从财付通平台向银行发起的多笔订 单查询请求: 中文域名 对应 DTD 元素 类型 出现 要求 说明 版本号 version char(7) R 目前版本号:”1.4.0” 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字签名 订单开始时间 startTime char(17) R yyyyMMdd HH:mm:ss 72 订单结束时间 endTime char(17) R yyyyMMdd HH:mm:ss,为了防止对银行的压力过 大,可以限制最大的查询时间范围不能超过1小时。 交易日期和时间 date char(17) R YYYYMMDD HH:MM:SS 消息扩展 Extension O  “多笔订单查询”应答报文 MOQRes(Multiple Order Query Response) “多笔订单查询”应答报文是银行返回给财付通的多笔查询应答报文: 中文域名 对应 DTD 元素 类型 出现 要求 说明 版本号 version char(7) R 目前版本号:“1.4.0” 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字签名 订单数据 orderData Node R 包含如下格式的订单明细数据: 【订单明细】 【订单明细】 ...... 【订单明细】 【订单明细】格式与清算对账文件的明细格式相 同。 消息扩展 Extension O 6.13 内部账户查询(P0)(如果是内部账户方式是必须的) 6.13.1 业务功能 对于有些银行,由于财务方面的限制,财付通公司无法在对应的银行开立对外的用于一点通支付业务的资金 清算对公账户。对于此种情况,银行可以专门开设一个内部临时账户给财付通进行资金清算,但银行必须提供给 财付通一个用于查询该内部账户余额及变动情况的查询接口。 73 6.13.2 处理流程 内部账户余额查询 银行业务系统财付通业务系统 5.验证应答报文的合法性 4.银行组装查询应答报文返回财付通 3.银行查询财付通内部账户余额 1.财付通生成内部账户余额查询请求 报文 6.根据银行返回的成功的内部账户余 额进行后续处理,如对账等。 2.银行验证财付通内部账户余额查询 请求报文的合法性 1) 财付通生成内部账户余额查询请求报文。 2) 银行验证财付通内部账户余额查询请求报文的合法性。 3) 银行查询财付通内部账户余额。 4) 银行组装查询应答报文返回财付通。 5) 验证应答报文的合法性。 6) 根据银行返回的成功的内部账户余额进行后续处理,如对账等。 6.13.3 业务规则  财付通端为及时掌握银行端待清算账户的资金变动情况,需要能查到银行端每个清算日的相关资金账户信 息。  银行端需要能让财付通查到每个清算日财付通内部账户的可用余额和借贷发生额。  若财付通在银行开有清算账户,有其它途径可以查到该财付通资金清算账户状态的,可以不做此功能。 74 6.13.4 交互模式 在内部账户余额查询过程中,财付通和银行以请求-应答方式进行交互。财付通作为服务的使用者,向银行方 发送“内部账户查询”请求报文 IAQReq(Internal Account Query Request),银行方作为服务的提供者,向财付通 返回“内部账户查询”应答报文 IAQRes(Internal Account Query Response)。 财付通 银行 “内部账户余额查询”请求报文IAQReq 处理内部账户余额查询请求 “内部账户余额查询”应答报文IAQRes 6.13.5 报文格式  “内部账户查询”请求报文 IAQReq(Internal Account Query Request) “内部账户查询”请求报文 IAQReq 是财付通发起的向银行查询财付通一点通内部账户相关信息的查询请求。  “内部账户查询”应答报文 IAQRes(Internal Account Query Response) “内部账户查询”应答报文 IAQRes 是银行查询到的财付通一点通内部账户相关信息的结果返回。 中文域名 对应 DTD 元素 类型 出现 要求 说明 版本号 version char(7) R 目前版本号:”1.4.0” 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字签名 交易日期 date Char(17) R YYYYMMDD HH:MM:SS( 银行账务日期 bankDate char(8) R YYYYMMDD 交易货币代码 currency char(3) R 消息扩展 Extension 75 6.14 数字证书公钥交换 6.14.1 业务功能 数字证书公钥交换的主要目的是为了方便银行或财付通更新用于报文签名的数字证书公钥。当一点通系统中 任何一个机构(银行或财付通)的数字证书过期或私钥泄漏后,需要申请一个新的数字证书,同时,使用该功能 将新数字证书的公钥通知给对方。 中文域名 对应 DTD 元素 类型 出现 要求 说明 版本号 version char(7) R 目前版本号:”1.4.0” 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字签名 银行账务日期 bankDate char(8) R YYYYMMDD 交易货币代码 Currency char(3) R 前日可用余额 balance Long(12) R 见金额格式说明,上个清算日中间账户轧差金额 可用余额 dbalance Long(12) R 见金额格式说明,当前中间账户可用余额 当日借方发生额 ddbalance Long(12) O 见金额格式说明 当日贷方发生额 dcbalance Long(12) O 见金额格式说明 消息扩展 Extension 76 6.14.2 业务流程 数字证书公钥交换 银行财付通 1.申请新的数字证书 2.导出新证书Base64编 码的X.509证书到文件 3.发送数字证书公钥交换 请求报文(CPKEReq) 4.检查新证书ID是否已经 存在 5.保存数字证书的内容 6.返回数字证书公钥交换 应到报文CPKERes7.完成 这里以财付通证书更新为例,银行方的证书更新与此相同。 1. 财付通原来的数字证书即将过期,财付通生成一个新的数字证书。 2. 财付通后台维护人员从新申请的数字证书中导出 X.509 格式的公钥到.cer 文件中。 3. 财付通发送“数字证书公钥交换”报文给银行系统。 4. 银行系统判断 newCertId 是否已经存在,如果已经存在,返回 Error 报文。 5. 银行报文新数字证书的 ID 极其内容。 6. 银行返回数字证书公钥交换应答报文给财付通。 7. 证书交换完成。 6.14.3 业务规则  新生成的数字证书标识必须保证不与已经存在的数字证书标识发生重复。  财付通方将 X.509 公钥文件的内容以 byte 的方式发送给财付通,财付通负责保存该内容并和对应的证书 ID 相关联。 6.14.4 报文格式  “数字证书公钥交换”请求报文 CPKEReq(Certificate Public Key Exchange Request) 77  “数字证书公钥交换”应答报文 CPKERes(Certificate Public Key Exchange Response) 第7章 网络连接规范 本章描述合作银行网上一点通渠道与财付通网上一点通渠道之间的安全信道建立方式与高层网络连接协议。 7.1 VPN 连接 通过 VPN 连接财付通网上一点通渠道服务器与合作银行网上一点通渠道服务器的方式如下图所示。在这种 连接方式中,所有的网上支付报文与文件传输都通过 VPN 信道,使用 HTTP 协议在双方的网上支付渠道服务器 之间进行。 中文域名 对应 DTD 元素 类型 出现 要求 说明 版本号 version char(7) R 目前版本号:”1.4.0” 机构标识 instId char(16) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字签名 交易日期 date char(17) R YYYYMMDD HH:MM:SS( 新数字证书标识 newCertId char(16) R 新数字证书标识 新数字证书公钥内容 newCert Base64 R 新的数字证书公钥文件的内容经过Base64编码后 的字符串形式 消息扩展 Extension 中文域名 对应 DTD 元素 类型 出现 要求 说明 版本号 version char(7) R 目前版本号:”1.4.0” 机构标识 instId char(6) R 报文发送方的机构标识,见数字签名 数字证书标识 certId char(16) R 对报文进行签名的数字证书标识,见数字签名 新数字证书标识 newCertId Char(16) R 新数字证书标识 消息扩展 Extension 78 银行核心业务系统 银行支付 业务系统 银行 内部防火墙 银行一点通 渠道服务器 财付通一点通 渠道服务器 财付通 内部防火墙 财付通支付 业务系统 财付通 文件服务器 财付通 核心业务系统 HTTP 报文签名 银行 财付通 在这种连接方式中,通信方验证与信道加密是通过 VPN 实现的。所有涉及到签约状态变动与资金处理的交 易报文与文件,仍通过应用层报文数字签名方式以防交易否认。 79 第8章 安全规范 在合作银行网上一点通流程与规范中,已经采用了大量的规则来降低合作银行网上一点通的安全风险,如网 上支付签约客户的实名制;合作银行网上一点通的资金流动量、流动途径与方向的业务规则等。因此,本章主要 从技术角度阐述网上支付系统中可能出现的安全威胁,以及通过技术规范来规避安全风险的方式。 8.1 安全威胁 网上支付系统涉及到合作银行与财付通平台通过公众互联网络交换信息与指令。因此,在网上支付安全规范 中,我们主要对来自网络的安全威胁进行分析。对于来自内部系统与人员的安全风险,由银行与支付平台现有的 安全体系来保障。 来自网络的安全威胁主要有以下几种:  信息泄密 网上支付报文中交换的客户信息与交易指令均有私密性要求。在网上支付技术规范中,需要确保在网络传输 中对客户与交易信息私密性的保护。 解决方案:将双方的的通信信道进行加密(见网络连接规范)。  交易指令篡改 如果网络中传输的网上支付交易指令被入侵者截获并篡改,就会造成资金处理出现错误,给合作银行网上一 点通参与方造成损失。因此,在网络传输中,需要保证指令完整性。 解决方案:使用数字证书对对报文中的业务数据进行签名(见数字签名)。  交易指令伪造 如果有入侵者冒充支付平台或者银行发起交易指令,就会造成资金在未得到支付平台网上支付参与方的授权 下发生流动,给银行、支付平台或客户带来损失。因此,在网络传输与系统处理中,需要保证指令的真实性。 解决方案:使用数字证书对对报文中的业务数据进行签名(见数字签名)。  交易指令否认 当发生交易纠纷时,双方需要通过交易指令确定责任方。网上支付安全规范中需要为交易指令防否认提供技 术支持。 解决方案:使用数字证书对对报文中的业务数据进行签名(见数字签名),银行与支付平台均应保留涉及资 金变动的交易报文日志(见报文日志管理)。  交易指令重播 入侵者也可能尝试通过截获网络中传输的网上支付交易指令,并多次重播的方式试图发起未经授权的网上支 付交易。在网上支付技术规范中,需要防止交易指令重播引起的未授权交易。 解决方案:凡涉及到资金变动的交易指令,流水号必须唯一。银行与支付平台均需要保证同一流水号的交易 指令只能执行一次。 80 8.2 数字签名 8.2.1 数字签名要求 必须采用本节所述方法对 Tenpay 消息进行数字签名。签名规范遵循 XML-Signature Syntax and Processing, W3C Recommendation 规范(http://www.w3.org/TR/xmldsig-core/)。 Tenpay 协议使用分离签名(Detached signature),即 元素与被签名的元素(如:CSReq/CSRes 等) 各自独立存在。被签名的元素和 元素包含在同一文档中。签名元素通过当地引用(如‟# CSReq1234‟) 被引用。被签名的元素内容包括从 CSReq/CSRes 等开始标签的开始括号开始到 CSReq/CSRes 等结束标签的结束 括号为止的内容。 签名结构图 Tenpay 签名的产生必须满足下列表格中定义的元素内容和算法要求。 表1 XML Signature Profile 元素 要求 Signature 没有KeyInfo实例;没有Object实例 CanonicalizationMethod 元素为空,但出现Algorithm属性 SignatureMethod 元素为空,但出现Algorithm属性 Transforms 存在且都包含一个Transform的实例 Transform 元素为空,但出现Algorithm属性 DigestMethod 元素为空,但出现Algorithm属性 KeyInfo 不出现。 表2 XML 签名算法 算法类型 标识符 Canonicalization http://www.w3.org/TR/2001/REC-xml-cl4n-20010315 Digest http://www.w3.org/2000/09/xmldsig#shal Encoding http://www.w3.org/2000/09/xmldsig#base64 Signature http://www.w3.org/2000/09/xmldsig#rsa-sha1 81 Transform http://www.w3.org/2000/09/xmldsig#enveloped-signature 8.2.2 证书存取规范 由于Tenpay报文中的Signature不包含KeyInfo信息,证书需要通过其他方式获得。在被签名的元素(如: CSReq/CSRes等)中都包含两个元素,其中: 标签中的数据表示报文发送方的机构代码,银行机构代码由财付通统一颁发、管理; 标签中的数据表示证书ID,证书ID由密钥生成机构根据证书ID生成规则生成,证书ID的生成规则如下: 位数(共16位) 0-5 6-12 14-15 含义 instId yyyymmdd sequence 说明 机构代码 证书生成日期 序列号 同一机构可以拥有多张证书,证书拥有机构通过线下方式将用于认证您的公钥证书(Base64编码X.509格式) 及证书ID发送给使用方。 报文接收方根据报文中的元素内容获得报文发送机构代码及证书ID,然后根据这两个信 息从本地获得校验签名所需要的证书。 8.2.3 规范化要求 注意:规范化是 “XML-Signature Syntax and Processing, W3C Recommendation”中的要求之一,也叫作xmldsig。 Xmldsig 表示计算同样文档的摘要必须使用规范化的方法。 8.2.4 签名的 XML 命名空间 消息的签名必须被声明在一个缺省的命名空间:http://www.w3.org/2000/09/xmldsig#中。 示例: 1.4.0 20100330 11:51:39 JHCB 123456 201003301234567890 123456 D 李四 M 1 111111111111111 shenhysz@hotmail.com 13688888888 82
深圳南山区
测试
4t79dXZ7/BQqgiBdkziaKTUslVU= RyWMXvxlhmLuOIOvGSIkpV1iRV400F1B2W0zmW9nc5qfvfNMtpyp+uNwksBUjcO8H//NW4GvxcDd KMuuc6k5MDMH1E4OUg+624FUY23qs3R2ztubtD3MU7xk4f0iq9L16GK4ZBeID/Lyj6CxjaCcp3Fu K1CznNj4Kr+qRLtxx+s=
8.3 报文日志管理 为了做到交易指令防否认,银行与支付平台均应保留涉及资金变动的交易报文日志,日志中包括完整的报文、 报文签名、接收时间以及源 IP 地址。保存时间不小于 90 天。 交易报文日志应该妥善管理,避免泄密或者被破坏。 83 第9章 其它规范 9.1 异常处理规范 凡是报文验证不通过,或者业务处理失败,统一返回通用错误报文 Error。 通用错误报文 Error 的格式参见 4.5.1 节。 9.2 错误码规范 错误码包含两部分,一部分是标准错误码,由网上支付标准规定,参见 4.5.1 节。另一部分是服务商特定代 码,由服务商自行规定。 9.3 处理响应时间要求 所有由客户发起的单笔类型报文处理,都会在 5 秒内给请求方响应。 对于实时交易查询,银行在收到查询请求之后的 1 分钟内发送查询结果通知。 9.4 可用性要求 银行与支付平台的网上支付服务应该达到 99.99%的可用性。 第10章 附录 10.1 网上支付报文格式 DTD 85 86 87 10.2 网上支付金额格式 用货币单位的最小单位表示的金额,其中不包含任何标点,最多 12 位。 例如:如果交易金额为 123.45RMB,则该项内容为 12345。 10.3 网上支付货币代码表 网上支付报文中的货币代码(currency 元素)的取值遵照国家标准 GB/T 12406-1996《表示货币和资金的代码》, 该标准中规定了代表货币和资金的三个字母代码和与之等价的三位数字代码的结构,说明了货币单位与货币之间 十进制的关系,确立了维护代理机构的建立过程,并详细说明了代码应用方法。 根据 GB/T 12406-1996,网上支付货币代码字段使用的 3 位定长数字如下表所示。 国家、地区名称 货币名称 货币代码 中国 人民币元 156 中国香港 港元 344 中国澳门 澳门元 446 美国 美元 840 英国 英镑 826 法国 法国法郎 250 88 德国 马克 278 俄罗斯 卢布 810 日本 日元 392 加拿大 加元 124 瑞士 瑞士法郎 756 瑞典 瑞典克朗 752 意大利 意大利里拉 380 西班牙 西班牙比塞塔 724 葡萄牙 葡萄牙埃斯库多 620 荷兰 荷兰盾 528 比利时 比利时法郎 056 芬兰 马克 246 挪威 挪威克朗 578 希腊 德拉克马 300 奥地利 先令 040 丹麦 丹麦克朗 208 澳大利亚 澳大利亚元 036 新西兰 新西兰元 554 巴西 克鲁赛罗 076 南非 兰特 710 埃及 埃及镑 818 伊拉克 伊拉克第纳尔 368 伊朗 伊朗里亚尔 364 沙特阿拉伯 沙特里亚尔 682 科威特 科威特第纳尔 414 阿联酋 UAE 迪拉姆 784 泰国 铢 764 新加坡 新加坡元 702 印尼 卢比 360 马来西亚 马来西亚林吉特 458 菲律宾 菲律宾比索 608 南朝鲜 圆 410 印度 印度卢比 356
还剩87页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 20 金币 [ 分享pdf获得金币 ] 3 人已下载

下载pdf

pdf贡献者

hl_java

贡献于2011-04-18

下载需要 20 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf