京东网银在线快捷支付接口说明_银行.docx

快捷支付技术标准V1.0版前言本文档介绍快捷支付的技术标准，其中包括快捷支付的业务模型、安全责任模型、架构模型、业务处理与系统交互方式、报文的语法与语义、网络连接方式、安全规范等。参与快捷支付业务的各方必须遵守快捷支付技术规范，以实现准确、安全、方便的网上支付与相关业务。目录前言2第1章文档概述51.1介绍51.2参考标准与文献6第2章快捷支付业务概述62.1快捷支付业务模型62.2快捷支付安全责任模型8第3章快捷支付架构93.1快捷支付架构目标93.2快捷支付架构模型103.3快捷支付交互模式14第4章快捷支付报文结构154.1报文结构15请求/响应头信息16请求头信息16响应头信息164.2报文的解析与传输19第5章快捷支付业务实现规范205.1接口实现说明215.2网上签约215.3网上支付225.4单笔撤销255.5单笔退款255.6单笔/批量交易查询295.7清算对账32第6章网络连接规范35第7章安全规范357.1安全威胁357.2数字签名367.3报文日志管理36第8章其它规范378.1异常处理规范378.2错误码规范378.3处理响应时间要求378.4可用性要求37第9章附录379.1快捷支付报文样例379.2快捷支付金额格式379.3快捷支付货币代码表389.4数据字典定义39第1章 文档概述1.1 介绍1.1.1 快捷支付概述在互联网支付体系中，持卡人身份验证与资金清算是两个关键问题。在传统解决方案中，对持卡人的身份验证一般是由持卡人在发卡行提供的身份验证服务器（比如发卡行的网上银行）直接进行，并将身份验证的结果通知商户。资金清算可能是在身份验证通过之后实时进行清算，也可能是通过专用的资金清算网络单独进行。这种传统解决方案要求发卡行提供基于互联网的持卡人身份验证服务，并且要求商户在持卡人在进行互联网支付时，将持卡人引导至发卡行进行身份验证。随着互联网支付的普及，这种模式逐渐显现出一些问题。其中最突出的问题是持卡人需要访问多个互联网服务站点才能完成一次完整的支付过程。在多个互联网服务站点之间跳转使用户的交易与支付体验不够流畅。在这个过程由于网络传输、客户端处理中任何一个失败都会造成支付过程失败。随着互联网支付的发展，第三方支付平台已经成为互联网支付体系中的重要组成部分。越来越多的商户不是直接通过银行，而是通过第三方支付平台实现基于互联网支付，利用第三方支付平台提供的快速便捷的支付清算服务，降低接入复杂度、控制互联网支付的成本、提高用户的支付体验。基于快捷支付的账户安全体系，当持卡人在进行互联网支付时，持卡人可以通过快捷支付账户安全体系进行身份验证，并在身份验证通过时，委托快捷支付代他向银行发出支付指令，实现使用该持卡人委托范围内的银行资金的划拨，完成一次完整的互联网支付。使用这种方式，在持卡人进行互联网不需要访问多个互联网服务站点，避免输入银行卡号与密码，可以提升用户的互联网支付体验，增加支付成功率，减少用户银行卡号与密码被盗的风险。与此同时，基于这种信任与委托关系，在快捷支付与银行之间可以合作为持卡人与快捷支付用户提供更多的增值服务，比如商户货款的实时提现服务等。本文档阐述的快捷支付技术标准，为更加快捷安全的互联网支付结算提供了完全解决方案。1.1.2 目标读者本文的主要目标读者是快捷支付标准银行方的技术实施人员，其中的部分内容也可供银行的管理与业务人员参考。1.1.3 版本规范快捷支付标准的版本规范是：<主版号>.<次版本号>.<修订号>。本文介绍快捷支付技术标准的1.0.0版。1.1.4 最近修订版本号作者内容提要核准人发布日期1.0.0xxp初次版本2013-05-271.2 参考标准与文献第2章 快捷支付业务概述本章介绍快捷支付的业务模型，描述快捷支付业务的主要业务目的，介绍各个参与方的功能与责任，并阐述作为快捷支付安全性基础的安全责任模型。2.1 快捷支付业务模型2.1.1 业务模型快捷支付的业务目的是充分结合快捷支付在互联网交易服务与市场占用率方面的专长，与银行在资金管理与结算服务上的专长，双方优势互补，为快捷支付与银行的共同用户（其中包括互联网买家与商户）提供整合、快捷、安全的互联网支付与结算解决方案。快捷支付主要提供在互联网上进行支付时持卡人（作为买家）委托快捷支付使用他在银行卡账户中的资金进行网上支付业务功能。在网上支付时，资金从买家银行卡账户流入快捷支付的客户保证金账户中.n 用户域用户域中包括了快捷支付业务的主要服务对象，其中包括互联网交易中的买家与商户。买家使用快捷支付业务进行交易货款支付，商户使用快捷支付业务进行交易货款结算。无论是买家还是商户，如果需要使用快捷支付业务，必须至少拥有一个快捷支付账户与一张银行卡，并且快捷支付账户与银行卡的姓名与身份证件需要一致。n 交易控制域交易控制域直接为用户域提供互联网交易服务以及与之相关的资金服务，其中包括交易支付时的买家身份验证与授权、为商户提供货款结算服务、监督完整的交易履约过程、为交易各方提供沟通与交互平台等。在快捷支付业务模型中，交易控制域的主体是快捷支付。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 技术目标除了实现业务目标，快捷支付架构也需要达成一些技术上的目标。其中最重要的技术目标是开放、简单、安全。n 开放快捷支付标准需要实现快捷支付与各个银行系统的互联，为了方便快捷支付与银行之间的异构平台与系统的互联，快捷支付架构必须基于开放平台与标准，方便跨平台、跨地域的接入。n 简单快捷支付作为一种创新的、以简单、安全、快捷为核心理念的在线支付规范，在使用的方便性和接入的简单性方面，要求超越传统的互联网支付解决方案。n 安全由于快捷支付标准简化了支付流程，并且由快捷支付系统而不是发卡行完成用户身份的验证，因此必须规定严格的安全责任模型，并且通过恰当的技术标准和方法来实现该责任模型。3.2 快捷支付架构模型3.2.1 架构模型由于不同银行在系统架构上存在差异，本文中以典型的银行系统为例，介绍快捷支付的架构模型。在快捷支付系统的具体实施与接入中，可以视需要对该架构模型进行修改，增加、删除、分拆或者合并系统中包含的组件。图3-1 快捷支付架构模型图中显示了实现快捷支付业务涉及到的系统组件。这些系统组件有些需要全新引入（如银行快捷支付渠道和银行快捷支付业务系统），有些需要在原有系统之上扩展（如银行柜面渠道），有些可以直接使用现有的系统（如银行账务与卡业务系统）。3.2.2 架构组件快捷支付技术架构中涉及到的系统组件与它们的主要职责如下：n 银行快捷支付接入系统银行快捷支付渠道与快捷支付渠道之间通过安全的信道互联，负责与快捷支付之间安全地交换快捷支付协议报文，验证报文的真实性与合法性，维护快捷支付报文日志，并在快捷支付协议报文与银行快捷支付业务系统所能够理解的交易指令之间进行翻译银行快捷支付接入系统可以独立搭建，也可以在现有渠道平台上扩展。n 银行柜台银行柜面渠道是银行柜员的工作平台，负责接受银行柜员提交的快捷支付签约请求，并且提供柜员与快捷支付相关的资金对账与清算、客户服务等功能。银行柜面渠道不直接处理快捷支付业务的核心逻辑，相关处理均翻译成银行快捷支付业务系统所能够理解的交易指令，交给银行快捷支付业务系统进行处理。一般情况下，可以通过对现有银行柜面渠道系统进行功能扩展来支持快捷支付业务。n 银行快捷支付业务系统银行快捷支付业务系统是快捷支付业务在银行端处理的主要系统，负责接受来自银行快捷支付渠道或者银行柜面渠道的请求、控制快捷支付业务流程、管理快捷支付业务数据、验证快捷支付服务授权与额度等业务规则、构造对银行账务与卡业务系统的交易请求、处理银行账务与卡业务系统的返回结果、并将结果返回给银行快捷支付渠道或银行柜面渠道等银行快捷支付业务系统可以独立搭建，也可以在现有中间业务平台上扩展。n 银行账务与卡业务系统银行账务与卡业务系统作为银行的核心系统，为快捷支付业务提供基础的客户身份验证、卡片密码验证、资金清算处理等功能。理想情况下，现有的银行账务与卡业务系统所提供的服务就能够支持快捷支付业务，不需要扩展或者修改银行账务与卡业务系统。n 快捷支付前台系统快捷支付前台系统是快捷支付会员直接使用快捷支付业务功能的入口，引导用户进行快捷支付协议签约、激活，对于已经激活的快捷支付用户，能直接使用快捷支付进行充值，提现，查询银行卡余额，修改快捷支付限额等功能。是快捷支付业务展示给用户使用的平台。n 快捷支付业务系统快捷支付业务系统目前主要负责处理快捷支付协议及其他非清算类业务处理，负责整个快捷支付签约信息的管理。非清算类业务功能，包含：快捷支付cms信息管理，快捷支付限额查询/修改，快捷支付余额查询，快捷支付签约信息查询等。n 快捷支付支付/清算系统快捷支付体系中，支付层负责接收快捷支付清算类业务请求，用户在快捷支付前台系统选择快捷支付进行充值，提现，充退等操作时，前台系统将快捷支付请求发送到支付层，有支付层负责将请求分类记录并发送到清算层，并等待清算层回执处理结果后，通知账务系统完成用户账务操作。清算层是是快捷支付清算类业务处理的核心系统，收到支付层快捷支付业务请求后，清算层记录快捷支付请求信息，并将请求触发到快捷支付前置系统，由快捷支付前置系统完成快捷支付报文与银行端的交互，完成快捷支付请求处理。同时，清算层还负责触发快捷支付相关的查询业务，文件处理业务，业务对账业务等。n 快捷支付账务/会计/核算系统账务系统负责快捷支付用户虚拟账户管理，记录用户账户资金流动情况。会计系统按照标准的会计规则，用复式记账的方式记录用户账户资金借贷关系记录。核算系统主要负责将银行实际的资金流动与支付的资金流动关系进行核对。n 快捷支付会员/认证系统会员系统记录了快捷支付用户基本的身份信息，在快捷支付业务中，会员系统主要用于获取快捷支付业务处理时所需要的用户信息。认证系统主要负责完成用户身份信息的认证工作，快捷支付协议激活时，由认证系统自动完成用户实名认证，所以，签约快捷支付是最便捷的实名认证方式。n 快捷支付文件系统快捷支付业务中，有很多地方与银行的交互会使用到文件系统，比如，银行上传签约对账文件，清算类业务/资金对账文件等。这些文件可能是银行主动上传到我方文件系统，也可能是我方到银行方系统下载后存到文件系统。n 快捷支付前置系统快捷支付前置系统是快捷支付核心业务系统与银行快捷支付接入系统进行交互的桥梁，主要负责交互报文封装，解析，签名，验签；并将报文信息转换为内部系统业务对象返回给业务系统完成快捷支付业务处理。n 快捷支付后台管理系统快捷支付后台管理系统主要使用者是快捷支付结算，运维，客服人员，后台管理系统提供了一系列快捷支付业务相关的管理功能，通过这些功能，支持快捷支付接入可配置化，同时也展示出用户快捷支付使用的相关信息，后台管理功能主要包含：快捷支付渠道管理，快捷支付文件管理，快捷支付签约信息管理，快捷支付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）说明<QPAY>快捷支付报文块开始<Head>报文头开始 报文头内容</Head>报文头结束<Body>报文体开始报文体内容</Body>报文体结束</QPAY>快捷支付报文块结束请求/响应头信息请求头信息标记（Tag）长度是否必输说明<Head>请求头信息开始<Version>5Y协议版本号<Id>20Y报文唯一标识<TCode>6Y交易码<TDatetime>14Y交易时间格式：yyyyMMDDHHmmss</Head>请求头信息结束响应头信息标记（Tag）长度是否必输说明<Head>响应头信息开始<Version>5Y协议版本号<Id>20报文唯一标识 以上送标识为准<TCode>6Y交易码<TDatetime>14Y交易时间 格式：yyyyMMDDHHmmss<RCode> 6Y响应码<RDesc> 100响应信息描述</Head>响应头信息结束在下文中出现的具体报文格式描述中，“是否必输”列包含的值的含义如下表所示：符号含义请求方约束服务方约束YRequired(必须的)必须包含该域必须校验该域是否存在和内容的合法性CConditional(有条件的)如果条件符合必须包含该域l 当条件满足时，必须校验该域是否存在l 当该域存在时，必须检查其内容的合法性N或空白Optional(可选的)该域可选当该域存在时，必须检查其内容的合法性n 错误代码说明下表列举了标准的错误代码：错误代码错误描述解释报文类错误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 报文的解析与传输快捷支付报文的传输使用XML Over HTTP(S)方式，在HTTP请求/响应体中包含XML形式的报文。4.2.1 报文解析对XML解析的基本要求如下n 版本号检查用于表示组件支持的协议版本号。消息版本号必须表示为：n.n.n ，其中“n” 表示数字。比如1.0或1.0.1。在所有的消息中，各组件都必须填写自身支持的协议版本号。消息版本号不能低于1.0.0。如果消息版本号低于接收方组件支持的最低版本号，则接收方组件必须返回错误消息，并且设置错误码=0003。n xml解析为了可以支持后续协议版本，xml解析的实现不要做严格的验证。特别是需要忽略未被确认的域。所有xml消息必须用“utf-8”编码。n 请求和应答域之id属性匹配请求和应答报文的Head域之id属性必须相同，id是请求方生成的唯一序列号。比如：银行在请求的Head域设置了一个id属性值，则快捷支付在应答里面的Head域的id属性必须和请求的Head域之id值相同。4.2.2 报文传输对HTTPS传输的基本要求如下：n 使用POST发送消息消息请求基于HTTP/HTTPS的POST方式。n HTTP消息头要求HTTP请求与响应消息中必须按照如下要求设置头部域：Content-Length：必须设置成消息体的长度Content-Type：必须设置下面的值：application/xml; charset=utf-8第5章 快捷支付业务实现规范快捷支付业务功能覆盖了从签约、服务与管理的各个方面。签约类的业务负责快捷支付服务协议的建立、调整与撤消，其中包括柜台签约、网上签约、柜台签约撤销、网上撤约、批量签约/撤约、支付限额查询、网上支付限额修改。服务类的业务满足用户互联网交易与资金需求，其中包括网上支付、提现（单笔与批量）、退货（单笔与批量）与银行卡余额查询。管理类业务是为了保证互联网交易的正常进行而引入的，其中包含批量交易查询、单笔交易查询、签约对账与清算对账、中间账户账务明细查询等。本章描述如何通过用户、快捷支付与银行之间的协作实现上述快捷支付业务的流程与规则。同时，本章也规定了在银行快捷支付渠道与快捷支付渠道间的交互模式、交换的报文与文件的结构、语义与处理规范。为了保证快捷支付业务的正常开展，还有一些在银行或快捷支付内部完成的业务流程，比如在银行完成的支付限额修改，以及各种业务报表等，这些业务由于不涉及到快捷支付与银行的交互，因此在本文档中不作具体描述。5.1 接口实现说明序号接口类型实现方式交易类型代码1网上签约必做QP0012网上支付必做QP0053撤销支付必做QP0064实时退款必做QP0075单笔/批量交易查询必做QP0086清算对帐必做QP0095.2 网上签约5.2.1 签约申请相关参数请求标记（Tag）长度是否必输说明<Body>报文体开始<CustType>1Y客户类型<MerchantId>10Y商户编号< PayAcctNo >22Y支付卡号< CardType >1Y卡种，见数据字典定义！< PayerName >30Y户名< PhoneNo >11N手机号码，卡种为信用卡时必填< CertType >2N证件类型<CertNo>30N证件号码<CVV2>3NCvv2 ，卡种为信用卡<ValidDate>4N有效期，卡种为信用卡时必填< Remark1>30预留< Remark2>100预留</Body>报文体结束响应标记（Tag）长度说明<Body>报文体开始<Status>1验证结果，见数据字典定义！< Remark1>30预留< Remark2>100预留</Body>报文体结束5.3 网上支付5.3.1 业务功能快捷支付网上支付业务的主要服务对象是互联网交易中的买家，使买家能够通过快捷支付使用签约银行卡内的资金实现快捷、安全的交易支付。快捷支付负责验证客户持卡人身份与服务权限，并请求银行划拨客户的资金用于互联网交易的支付；银行负责验证由快捷支付发出的支付指令是否在快捷支付签约的业务范围与银行控制的快捷支付支付限额内，并实时扣减签约银行卡内的余额。由于网上支付引起的银行与快捷支付间的资金清算方法由快捷支付清算标准规定。5.3.2 业务规则网上支付业务在执行中需要满足以下约束条件：l 网上支付必须由客户请求，从快捷支付发起。l 网上支付时的资金只能从快捷支付签约时确定的签约银行卡账户中支出，用于同一客户的网上支付。l 网上支付时客户在签约银行卡账户中的资金只能转移到快捷支付公司指定的清算账户中。l 同一支付订单号的快捷支付网上支付交易银行必须保证只能执行一次。l 银行与快捷支付需要保存网上支付相关报文的日志作为解决资金清算不一致的依据。l 银行必须根据客户的意愿做限额控制；l 对于信用卡快捷支付，支付时有大额支付和小额支付之分，银行端接收到支付报文时，需要根据快捷支付报文中的扩展字段来区分大额支付和小额支付。5.3.3 处理流程1. 客户通过互联网在快捷支付商户处购物，并在快捷支付创建交易。2. 客户输入支付密码，并请求快捷支付使用本人快捷支付账户关联的快捷支付签约银行卡为交易支付。3. 快捷支付验证客户身份与快捷支付网上支付请求的合法性，验证项目包含： l 该快捷支付账户的状态允许支付。l 支付密码正确。l 快捷支付服务已激活l 账户安全等级达到快捷支付支付的要求l 当日快捷支付网上支付总额在快捷支付规定的快捷支付每日支付限额内。上述验证中如果有一项不符，则快捷支付拒绝客户的快捷支付网上支付请求，并将客户引导到恰当的快捷支付功能页面。4. 快捷支付生成唯一的快捷支付网上支付订单号，并根据该快捷支付账户签约的快捷支付协议号确定银行、构造“网上支付请求”报文。快捷支付将该报文发送给银行。5. 银行接受“网上支付请求”报文，验证网上支付的合法性。验证项目至少包括： l 快捷支付协议号对应的快捷支付签约记录已成功l 银行卡状态有效l 银行卡余额足够l 银行卡号当日累计的快捷支付支付总额未超过银行规定的每日支付限额上述验证中如果有一项不符，则银行拒绝该请求报文，并返回快捷支付支付失败的原因。6. 银行处理网上支付交易，从快捷支付签约记录中的银行卡账户划付资金至快捷支付资金清算专用账户中，并进行其它关联处理（比如手续费扣减、积分计算等）。7. 银行处理网上支付交易处理成功之后，将交易处理结果通过“网上支付应答”报文返回给快捷支付。8. 快捷支付接收到银行返回的“网上支付应答”报文，从中解析出处理结果。若处理结果显示银行处理成功，则快捷支付为客户进行资金入账，并支付该笔互联网交易。9. 快捷支付向用户显示网上支付的结果。10. 客户查看网上支付的结果。5.3.4 报文格式 请求标记（Tag）长度是否必输说明< Body >报文体开始< CustType >1Y客户类型< MerchantId >10Y商户编号<OrderNo>30Y订单号<OrderAmt>12Y交易金额(单位：分)<Currency>3币种，默认156< PhoneNo >11N手机号码，卡种为信用卡时必填<CustName>30Y姓名（注：针对信用卡该字段无效）< CardType >1Y卡种，见数据字典定义！< CardNo>22Y卡号< CertType >2N证件类型，见数据字典定义！<CertNo>30N证件号码<CVV2>3NCvv2 ，卡种为信用卡（注：针对信用卡该字段无效）< ValidDate>4C有效期，卡种为信用卡时必输</ Body >报文体结束响应标记（Tag）长度说明< Body >报文体开始< MerchantId >10商户编号<FlowNo>20流水号<OrderNo>30订单号<Status>1交易状态，见数据字典定义！< Remark1>30预留字段1< Remark2>100预留字段2</ Body >报文体结束5.4 单笔撤销商户因业务需要，在支付业务未完成清算前，取消支付的过程。如果支付已经完成，则银行会拒绝响应撤消支付请求。处理流程商户发起撤消一笔支付的请求；银行检索支付记录的状态，并进行处理。如果未付则把支付请求撤消，并返回给商户支付请求撤消成功的信息；否则返回商户撤消支付请求失败的信息。交互模式在撤销支付业务中，商户与银行通过请求-应答模式进行交互。报文格式 同单笔退款5.5 单笔退款5.5.1 业务功能对于客户的充值金额，为防止套现或借用快捷支付渠道转帐，快捷支付控制客户不能转入其它银行。为满足客户充值金额返回原充值银行卡的需求，则需要充值退回功能。单笔充值退回必须在快捷支付核实之后，由快捷支付发起。5.5.2 业务规则单笔充值退回业务在执行中需要满足以下约束条件：l 单笔充值退回业务从快捷支付发起。l 单笔充值退回业务必须有对应的快捷支付充值交易。l 快捷支付可以针对90天内的快捷支付充值发起单笔充值退回业务。l 单笔充值退回的金额不能超过对应的快捷支付充值的金额，但可以少于快捷支付充值时的金额；l 针对一笔快捷支付充值，可以进行多次退回，但退回的总金额不能大于该笔快捷支付充值退回的总金额。l 单笔退回的资金只能原路划回快捷支付充值时使用的签约银行卡账户中。l 客户单笔退回时收到的资金只能从快捷支付公司事先约定的清算账户中划拨。l 同一退回订单号的单笔提现交易银行必须保证只能执行一次。l 银行与快捷支付需要保存单笔退回相关报文的日志，作为解决资金清算不一致的凭据。5.5.3 处理流程1. 客户在快捷支付页面对充值金额申请普通提现。2. 提现失败，出现错误提示信息页面和充值退回页面链接入口。3. 快捷支付系统对退货（退回）的合法性进行验证。验证内容包括：l 客户的快捷支付服务状态为激活l 单笔退货的互联网交易是使用快捷支付充值的如果上述验证中有一项不符合，则