京东网银在线快捷支付接口说明银行.docx
《京东网银在线快捷支付接口说明银行.docx》由会员分享，可在线阅读，更多相关《京东网银在线快捷支付接口说明银行.docx（43页珍藏版）》请在冰点文库上搜索。
京东网银在线快捷支付接口说明银行
快捷支付技术标准
V1.0版
前言
本文档介绍快捷支付的技术标准，其中包括快捷支付的业务模型、安全责任模型、架构模型、业务处理与系统交互方式、报文的语法与语义、网络连接方式、安全规范等。
参与快捷支付业务的各方必须遵守快捷支付技术规范，以实现准确、安全、方便的网上支付与相关业务。
第1章文档概述
1.1介绍
1.1.1快捷支付概述
在互联网支付体系中，持卡人身份验证与资金清算是两个关键问题。
在传统解决方案中，对持卡人的身份验证一般是由持卡人在发卡行提供的身份验证服务器（比如发卡行的网上银行）直接进行，并将身份验证的结果通知商户。
资金清算可能是在身份验证通过之后实时进行清算，也可能是通过专用的资金清算网络单独进行。
这种传统解决方案要求发卡行提供基于互联网的持卡人身份验证服务，并且要求商户在持卡人在进行互联网支付时，将持卡人引导至发卡行进行身份验证。
随着互联网支付的普及，这种模式逐渐显现出一些问题。
其中最突出的问题是持卡人需要访问多个互联网服务站点才能完成一次完整的支付过程。
在多个互联网服务站点之间跳转使用户的交易与支付体验不够流畅。
在这个过程由于网络传输、客户端处理中任何一个失败都会造成支付过程失败。
随着互联网支付的发展，第三方支付平台已经成为互联网支付体系中的重要组成部分。
越来越多的商户不是直接通过银行，而是通过第三方支付平台实现基于互联网支付，利用第三方支付平台提供的快速便捷的支付清算服务，降低接入复杂度、控制互联网支付的成本、提高用户的支付体验。
基于快捷支付的账户安全体系，当持卡人在进行互联网支付时，持卡人可以通过快捷支付账户安全体系进行身份验证，并在身份验证通过时，委托快捷支付代他向银行发出支付指令，实现使用该持卡人委托范围内的银行资金的划拨，完成一次完整的互联网支付。
使用这种方式，在持卡人进行互联网不需要访问多个互联网服务站点，避免输入银行卡号与密码，可以提升用户的互联网支付体验，增加支付成功率，减少用户银行卡号与密码被盗的风险。
与此同时，基于这种信任与委托关系，在快捷支付与银行之间可以合作为持卡人与快捷支付用户提供更多的增值服务，比如商户货款的实时提现服务等。
本文档阐述的快捷支付技术标准，为更加快捷安全的互联网支付结算提供了完全解决方案。
1.1.2目标读者
本文的主要目标读者是快捷支付标准银行方的技术实施人员，其中的部分内容也可供银行的管理与业务人员参考。
1.1.3版本规范
快捷支付标准的版本规范是：
<主版号>.<次版本号>.<修订号>。
本文介绍快捷支付技术标准的1.0.0版。
1.1.4最近修订
版本号
作者
内容提要
核准人
发布日期
1.0.0
xxp
初次版本
2013-05-27
1.2参考标准与文献
第2章快捷支付业务概述
本章介绍快捷支付的业务模型，描述快捷支付业务的主要业务目的，介绍各个参与方的功能与责任，并阐述作为快捷支付安全性基础的安全责任模型。
2.1快捷支付业务模型
2.1.1业务模型
快捷支付的业务目的是充分结合快捷支付在互联网交易服务与市场占用率方面的专长，与银行在资金管理与结算服务上的专长，双方优势互补，为快捷支付与银行的共同用户（其中包括互联网买家与商户）提供整合、快捷、安全的互联网支付与结算解决方案。
快捷支付主要提供在互联网上进行支付时持卡人（作为买家）委托快捷支付使用他在银行卡账户中的资金进行网上支付业务功能。
在网上支付时，资金从买家银行卡账户流入快捷支付的客户保证金账户中.
⏹用户域
用户域中包括了快捷支付业务的主要服务对象，其中包括互联网交易中的买家与商户。
买家使用快捷支付业务进行交易货款支付，商户使用快捷支付业务进行交易货款结算。
无论是买家还是商户，如果需要使用快捷支付业务，必须至少拥有一个快捷支付账户与一张银行卡，并且快捷支付账户与银行卡的姓名与身份证件需要一致。
⏹交易控制域
交易控制域直接为用户域提供互联网交易服务以及与之相关的资金服务，其中包括交易支付时的买家身份验证与授权、为商户提供货款结算服务、监督完整的交易履约过程、为交易各方提供沟通与交互平台等。
在快捷支付业务模型中，交易控制域的主体是快捷支付。
2.1.2核心业务
为了使用快捷支付与银行联合提供的快捷支付服务，用户首先需要与快捷支付和银行签定协议，明确各方的权利与义务，这一过程称为“快捷支付签约”；“快捷支付签约”所形成的数据记录称为“快捷支付签约记录”；签约成功后，快捷支付与银行交互过程中用于识别用户身份及银行卡信息的编号称为“快捷支付协议号”。
在签约成功后，用户就可以使用快捷支付进行方便、安全的网上支付与提现。
为了保证快捷支付业务处理的准确性，快捷支付标准中也规定了各种管理类业务，如批量查询、单笔交易查询、清算对账、签约对账等。
2.1.3贷记卡快捷支付与借记卡快捷支付
快捷支付业务不仅支持借记卡支付业务，同时也支持信用卡支付业务，由于借记卡快捷支付与信用卡快捷支付业务没有实质性的差别，本文将借记卡快捷支付业务与信用卡快捷支付业务整合到一起进行介绍，没有特别说明，所介绍的业务不区分借记卡与信用卡。
下面是信用卡快捷支付与借记卡快捷支付的区别如下表：
借记卡快捷支付
贷记卡快捷支付
是否区分大小额
否
是
是否收费
否
大额收费，小额不收费
2.2快捷支付安全责任模型
2.2.1安全目标
快捷支付支付业务的主要安全目标是，只有经本人用户委托与授权，才能够动用该用户开通快捷支付业务的银行卡账户内的资金，并且用于用户指定的支付目的。
这一安全目标是通过用户、快捷支付与银行三方共同履行责任来保证的。
引入快捷支付安全责任模型，目的在于明确规定各方在保障安全目标时的责任。
2.2.2快捷支付安全责任模型
为了实现安全支付这一目标，用户、快捷支付与银行各自应该履行的责任。
1、用户：
只有本人同时拥有账户号与支付密码。
向快捷支付发起的支付请求代表本人的真实意图。
2、快捷支付：
只有用户发起交易支付请求，并且账户与支付密码验证通过，才能发起支付指令。
只有收到来自英航的账务处理的成功结果，才执行用户请求的交易支付。
3、银行：
只有来之快捷支付的支付指定才能触发快捷业务的账务处理。
给快捷支付的支付反馈真实反馈账务处理结果
快捷服务与额度在用户授权范围内。
从上可知只要快捷支付支付业务的参与者都恰当地履行了自己的责任，即可确保实现快捷支付支付的安全目标。
当用户使用快捷支付时，信任快捷支付履行责任（只有用户发起交易支付请求，并且账户与支付密码验证通过，才能发起快捷支付支付指令）。
这一信任关系与快捷支付现有的用户协议是相容的。
2.2.3责任认定方式
当出现快捷支付安全目标被违背的情况时，为了认定责任，快捷支付与银行必须分别举证自己履行了责任。
如果两方中有一方无法举证自己履行了安全责任模型中规定的责任，则由于本次安全目标违背事件引发的损失由未能举证的一方承担。
如果快捷支付与银行都能够举证自己履行了责任，则表明用户未履行自己的安全责任，损失由用户承担。
由于安全责任模型中信任关系的存在，因此快捷支付无须举证自己履行了责任（只有用户发起交易支付请求，并且账户与支付密码验证通过，才能发起快捷支付支付指令）。
快捷支付技术标准将支持银行与快捷支付举证自己履行了责任。
第3章快捷支付架构
本章介绍快捷支付的技术架构。
描述组成快捷支付系统的各个组件以及它们之间的协作方式。
3.1快捷支付架构目标
3.1.1业务目标
快捷支付架构的目标是在快捷支付业务模型的框架下，实现快捷支付业务的目标、约束与流程，对快捷支付安全与责任模型提供支持。
3.1.2技术目标
除了实现业务目标，快捷支付架构也需要达成一些技术上的目标。
其中最重要的技术目标是开放、简单、安全。
⏹开放
快捷支付标准需要实现快捷支付与各个银行系统的互联，为了方便快捷支付与银行之间的异构平台与系统的互联，快捷支付架构必须基于开放平台与标准，方便跨平台、跨地域的接入。
⏹简单
快捷支付作为一种创新的、以简单、安全、快捷为核心理念的在线支付规范，在使用的方便性和接入的简单性方面，要求超越传统的互联网支付解决方案。
⏹安全
由于快捷支付标准简化了支付流程，并且由快捷支付系统而不是发卡行完成用户身份的验证，因此必须规定严格的安全责任模型，并且通过恰当的技术标准和方法来实现该责任模型。
3.2快捷支付架构模型
3.2.1架构模型
由于不同银行在系统架构上存在差异，本文中以典型的银行系统为例，介绍快捷支付的架构模型。
在快捷支付系统的具体实施与接入中，可以视需要对该架构模型进行修改，增加、删除、分拆或者合并系统中包含的组件。
图3-1快捷支付架构模型
图中显示了实现快捷支付业务涉及到的系统组件。
这些系统组件有些需要全新引入（如银行快捷支付渠道和银行快捷支付业务系统），有些需要在原有系统之上扩展（如银行柜面渠道），有些可以直接使用现有的系统（如银行账务与卡业务系统）。
3.2.2架构组件
快捷支付技术架构中涉及到的系统组件与它们的主要职责如下：
⏹银行快捷支付接入系统
银行快捷支付渠道与快捷支付渠道之间通过安全的信道互联，负责与快捷支付之间安全地交换快捷支付协议报文，验证报文的真实性与合法性，维护快捷支付报文日志，并在快捷支付协议报文与银行快捷支付业务系统所能够理解的交易指令之间进行翻译
银行快捷支付接入系统可以独立搭建，也可以在现有渠道平台上扩展。
⏹银行柜台
银行柜面渠道是银行柜员的工作平台，负责接受银行柜员提交的快捷支付签约请求，并且提供柜员与快捷支付相关的资金对账与清算、客户服务等功能。
银行柜面渠道不直接处理快捷支付业务的核心逻辑，相关处理均翻译成银行快捷支付业务系统所能够理解的交易指令，交给银行快捷支付业务系统进行处理。
一般情况下，可以通过对现有银行柜面渠道系统进行功能扩展来支持快捷支付业务。
⏹银行快捷支付业务系统
银行快捷支付业务系统是快捷支付业务在银行端处理的主要系统，负责接受来自银行快捷支付渠道或者银行柜面渠道的请求、控制快捷支付业务流程、管理快捷支付业务数据、验证快捷支付服务授权与额度等业务规则、构造对银行账务与卡业务系统的交易请求、处理银行账务与卡业务系统的返回结果、并将结果返回给银行快捷支付渠道或银行柜面渠道等
银行快捷支付业务系统可以独立搭建，也可以在现有中间业务平台上扩展。
⏹银行账务与卡业务系统
银行账务与卡业务系统作为银行的核心系统，为快捷支付业务提供基础的客户身份验证、卡片密码验证、资金清算处理等功能。
理想情况下，现有的银行账务与卡业务系统所提供的服务就能够支持快捷支付业务，不需要扩展或者修改银行账务与卡业务系统。
⏹快捷支付前台系统
快捷支付前台系统是快捷支付会员直接使用快捷支付业务功能的入口，引导用户进行快捷支付协议签约、激活，对于已经激活的快捷支付用户，能直接使用快捷支付进行充值，提现，查询银行卡余额，修改快捷支付限额等功能。
是快捷支付业务展示给用户使用的平台。
⏹快捷支付业务系统
快捷支付业务系统目前主要负责处理快捷支付协议及其他非清算类业务处理，负责整个快捷支付签约信息的管理。
非清算类业务功能，包含：
快捷支付cms信息管理，快捷支付限额查询/修改，快捷支付余额查询，快捷支付签约信息查询等。
⏹快捷支付支付/清算系统
快捷支付体系中，支付层负责接收快捷支付清算类业务请求，用户在快捷支付前台系统选择快捷支付进行充值，提现，充退等操作时，前台系统将快捷支付请求发送到支付层，有支付层负责将请求分类记录并发送到清算层，并等待清算层回执处理结果后，通知账务系统完成用户账务操作。
清算层是是快捷支付清算类业务处理的核心系统，收到支付层快捷支付业务请求后，清算层记录快捷支付请求信息，并将请求触发到快捷支付前置系统，由快捷支付前置系统完成快捷支付报文与银行端的交互，完成快捷支付请求处理。
同时，清算层还负责触发快捷支付相关的查询业务，文件处理业务，业务对账业务等。
⏹快捷支付账务/会计/核算系统
账务系统负责快捷支付用户虚拟账户管理，记录用户账户资金流动情况。
会计系统按照标准的会计规则，用复式记账的方式记录用户账户资金借贷关系记录。
核算系统主要负责将银行实际的资金流动与支付的资金流动关系进行核对。
⏹快捷支付会员/认证系统
会员系统记录了快捷支付用户基本的身份信息，在快捷支付业务中，会员系统主要用于获取快捷支付业务处理时所需要的用户信息。
认证系统主要负责完成用户身份信息的认证工作，快捷支付协议激活时，由认证系统自动完成用户实名认证，所以，签约快捷支付是最便捷的实名认证方式。
⏹快捷支付文件系统
快捷支付业务中，有很多地方与银行的交互会使用到文件系统，比如，银行上传签约对账文件，清算类业务/资金对账文件等。
这些文件可能是银行主动上传到我方文件系统，也可能是我方到银行方系统下载后存到文件系统。
⏹快捷支付前置系统
快捷支付前置系统是快捷支付核心业务系统与银行快捷支付接入系统进行交互的桥梁，主要负责交互报文封装，解析，签名，验签；并将报文信息转换为内部系统业务对象返回给业务系统完成快捷支付业务处理。
⏹快捷支付后台管理系统
快捷支付后台管理系统主要使用者是快捷支付结算，运维，客服人员，后台管理系统提供了一系列快捷支付业务相关的管理功能，通过这些功能，支持快捷支付接入可配置化，同时也展示出用户快捷支付使用的相关信息，后台管理功能主要包含：
快捷支付渠道管理，快捷支付文件管理，快捷支付签约信息管理，快捷支付CMS信息管理等。
3.3快捷支付交互模式
在快捷支付业务的技术实现中，快捷支付与银行之间通过交换报文与数据文件来交换业务信息、实现业务流程、控制业务规则。
实现快捷支付业务所需的交互模式可以归纳为请求-应答、单向通知这两种模式，实际业务中可能会将各种交互模式结合起来使用。
下文将介绍这两种交互模式适用的场景与实现方式。
3.3.1请求-应答模式
在请求-应答模式下，一方作为服务提供者，另一方作为服务使用者。
由服务使用者主动向服务提供者发起请求并等待应答，服务提供者接受请求，完成处理，并向服务使用者应答处理结果，服务使用者收到处理结果之后进行后续处理。
请求-应答模式适用于服务使用者需要根据服务提供者的服务应答才能进行正确的后续处理的场景，比如，在快捷支付网上支付业务中，快捷支付作为服务使用者，银行作为服务提供者，快捷支付需要知道银行的支付处理结果之后才能继续交易流程。
图3-2请求-应答模式
3.3.2单向通知模式
在单向通知模式下，一方作为通知发送者，一方作为通知接收者。
发送者发送通知，并保证接收者收到通知。
通知接收者在收到通知之后，立即返回发送者通知已收到。
通知送达之后，发送方与接收方可以独立地进行后续业务处理。
在快捷支付标准中，如果对方进行业务处理所需的时间不可预知时，采用单向通知模式。
图3-3单向通知模式
第4章快捷支付报文结构
快捷支付报文规范是快捷支付技术标准中重要的组成部分，规定了快捷支付与银行之间交换报文的顺序、格式与语义与处理规范。
本章中介绍快捷支付报文的一般结构与公共元素，这些规范适用于所有的快捷支付协议报文。
具体快捷支付业务中使用的报文，在各个业务实现规范中分别进行阐述。
4.1报文结构
快捷支付报文统一采用xml格式。
所有的快捷支付报文均以QPAY作为根元素，每个QPAY元素中可以包含Head和Body元素。
Head元素中包含代表进行的业务的描述属性，比如Code、DateTime等。
Body元素中包含代笔业务的具体属性。
作为约定，业务元素属性均是首字母大写的CamelCase形式。
标记（Tag）
说明
快捷支付报文块开始
报文头开始
报文头内容
报文头结束
报文体开始
报文体内容
报文体结束
快捷支付报文块结束
请求/响应头信息
请求头信息
标记（Tag）
长度
是否必输
说明
请求头信息开始
5
Y
协议版本号
20
Y
报文唯一标识
6
Y
交易码
14
Y
交易时间格式：
yyyyMMDDHHmmss
请求头信息结束
响应头信息
标记（Tag）
长度
是否必输
说明
响应头信息开始
5
Y
协议版本号
20
报文唯一标识以上送标识为准
6
Y
交易码
14
Y
交易时间格式：
yyyyMMDDHHmmss
6
Y
响应码
100
响应信息描述
响应头信息结束
在下文中出现的具体报文格式描述中，“是否必输”列包含的值的含义如下表所示：
符号
含义
请求方约束
服务方约束
Y
Required（必须的）
必须包含该域
必须校验该域是否存在和内容的合法性
C
Conditional（有条件的）
如果条件符合必须包含该域
●当条件满足时，必须校验该域是否存在
●当该域存在时，必须检查其内容的合法性
N或空白
Optional（可选的）
该域可选
当该域存在时，必须检查其内容的合法性
⏹错误代码说明
下表列举了标准的错误代码：
错误代码
错误描述
解释
报文类错误
0000
无效的根元素
根元素无法识别
0001
未定义的交易码
消息不是请求和应答等；或者消息发送给了一个错误的组件
0002
必填项缺失
报文中“是否必输”为Y的参数缺失
0003
协议版本有误
版本号错误
0004
根据规范，一个或多个域不符合格式要求
例如，非数字，或者不是有效的日期格式等等。
0005
银行标识不正确
域中的银行标识不正确
0007
签名无效
报文签名校验不通过
0008
加密密钥不存在
加密密钥不存在
0009
签名密钥不存在
签名密钥不存在
文件类错误
0301
业务日期不正确
业务日期格式不对，一般情况下业务日期必须是昨日，不过系统也支持以前日期的数据处理
查询类错误
0400
支付流水重复
重复的网上支付流水
0401
原支付流水不存在
申请退货的原支付流水不存在
0402
查询范围太大
查询时间跨度太大
0403
查询的交易不存在
查询的交易不存在
用户类错误（可以将错误信息显示给用户）
1000
协议号已经签约成功
1001
快捷支付协议号无效
快捷支付协议号不对应有效的快捷支付签约记录。
1002
快捷支付签约状态不正确
快捷支付签约状态不允许执行当前的业务
1200
身份证已经被使用
身份证已经被其它用户使用，并签约
1201
年龄不满足
如：
用户未满18岁
1202
身份证格式不正确
身份证不是有效的身份证
1203
真实姓名不正确
真实姓名与快捷支付中的不一致
1204
证件类型不正确
证件类型与快捷支付中的不一致
1205
身份证号码不匹配
身份证号码与快捷支付中登记的身份证号码不匹配
1206
认证信息不匹配
认证信息与快捷支付通过认证的信息不匹配
1207
该银行卡号已经成功签约
该银行卡号对应的快捷支付账号已经签约成功。
1301
快捷支付账户不存在
快捷支付账户标识不对应有效的快捷支付账户。
1302
快捷支付账户状态不正确
快捷支付账户的状态不允许签约。
1303
快捷支付账户类型不正确
快捷支付账户的类型不允许签约。
1304
快捷支付账户已经申请
1305
快捷支付账号绑定的快捷支付数量超限
快捷支付账号绑定的银行卡已经超过最大数量。
1306
快捷支付账号通过的认证数量超过最大值
快捷支付账号通过的认证数量超过最大值。
1307
登陆账号无效,
快捷支付账户格式不对
1311
账号无效。
账户未开通快捷支付
1800
银行卡户名不存在
户名不存在
1801
银行卡卡号不存在
银行卡号不存在
1802
户名与银行卡号不匹配
户名与银行卡号不匹配
1803
银行卡号与卡类型不匹配
银行卡号与卡类型不匹配
1804
不支持的银行卡号
不支持的银行卡号
1805
不支持的证件类型
不支持的证件类型
1806
证件号码格式错误
证件号码格式错误
1807
与登记证件类型不匹配
与登记证件类型不匹配
1808
与登记证件号码不匹配
与登记证件号码不匹配
1809
未登记手机号码
未登记手机号码
1810
与登记的手机号码不匹配
与登记的手机号码不匹配
支付类错误
1401
密码校验次数超限
密码校验次数超限
1402
银行卡状态不正确
银行卡状态不正确
1403
银行账户状态不允许该操作
银行账户状态不允许该操作
1404
银行支付校验码输入错误
银行支付校验码输入错误
1405
银行支付校验码失效
支付校验码超过输入时间范围限制，失效
1406
原支付申请流水号已经支付
支付流水号已经支付过
1407
原支付申请流水不存在
支付申请流水不存在
1408
支付密码输入超限
快捷支付支付密码超过输入次数限制
1409
支付异常，请查询银行卡是否已扣款
无法获得发卡核心的响应
银行卡类错误
1601
金额超限
支付金额超过每日限额
1602
余额不足
银行账户中的余额不足以完成支付
1604
银行交易处理中
该笔交易在银行前置系统中状态未知
1605
银行交易失败
该笔交易在银行系统中已经失败，且状态不会再发生变更。
错误具体详情通过ErrorDetail告知。
1607
银行卡卡号不正确
银行卡卡号不正确
信用卡类错误
1701
信用卡冻结
贷记卡已被冻结
1702
信用卡挂失
贷记卡已申请挂失
1703
信用卡不能进行支付
未领卡，未激活，止付，预销户
1704
信用卡透支超限
贷记卡透支超限
管理类错误
2000
快捷支付渠道关闭
没有开通快捷支付业务
2001
服务没有开通
请求的业务没有开通
系统类错误
9000
暂时系统异常
例如，一个请求队列满了。
9001
永久系统异常
例如，无法访问一个重要数据库所在的磁盘。
4.2报文的解析与传输
快捷支付报文的传输使用XMLOverHTTP（S）方式，在HTTP请求/响应体中包含XML形式的报文。
4.2.1报文解析
对XML解析的基本要求如下
⏹版本号检查
用于表示组件支持的协议版本号。
消息版本号必须表示为：
n.n[.n]，其中“n”表示数字。
比如1.0或1.0.1。
在所有的消息中，各组件都必须填写自身支持的协议版本号。
消息版本号不能低于1.0.0。
如果消息版本号低于接收方组件支持的最低版本号，则接收方组件必须返回错误消息，并且设置错误码=0003。
⏹xml解析
为了可以支持后续协议版本，xml解析的实现不要做严格的验证。
特别是需要忽略未被确
升级会员 