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

1、快捷支付技术标准V1.0版前言本文档介绍快捷支付的技术标准，其中包括快捷支付的业务模型、平安责任模型、架构模型、业务处理与系统交互方式、报文的语法与语义、网络连接方式、平安标准等。参与快捷支付业务的各方必须遵守快捷支付技术标准，以实现准确、平安、方便的网上支付与相关业务。目录 TOC o 1-3 h z u HYPERLINK l _Toc357775966 前言 PAGEREF _Toc357775966 h 2 HYPERLINK l _Toc357775967 第1章文档概述 PAGEREF _Toc357775967 h 5 HYPERLINK l _Toc357775968 1.1介

2、绍 PAGEREF _Toc357775968 h 5 HYPERLINK l _Toc357775969 1.2参考标准与文献 PAGEREF _Toc357775969 h 6 HYPERLINK l _Toc357775970 第2章快捷支付业务概述 PAGEREF _Toc357775970 h 6 HYPERLINK l _Toc357775971 2.1快捷支付业务模型 PAGEREF _Toc357775971 h 6 HYPERLINK l _Toc357775972 2.2快捷支付平安责任模型 PAGEREF _Toc357775972 h 8 HYPERLINK l _To

3、c357775973 第3章快捷支付架构 PAGEREF _Toc357775973 h 9 HYPERLINK l _Toc357775974 3.1快捷支付架构目标 PAGEREF _Toc357775974 h 9 HYPERLINK l _Toc357775975 3.2快捷支付架构模型 PAGEREF _Toc357775975 h 10 HYPERLINK l _Toc357775976 3.3快捷支付交互模式 PAGEREF _Toc357775976 h 14 HYPERLINK l _Toc357775977 第4章快捷支付报文结构 PAGEREF _Toc357775977

4、 h 15 HYPERLINK l _Toc357775978 4.1报文结构 PAGEREF _Toc357775978 h 15 HYPERLINK l _Toc357775979 请求/响应头信息 PAGEREF _Toc357775979 h 16 HYPERLINK l _Toc357775980 请求头信息 PAGEREF _Toc357775980 h 16 HYPERLINK l _Toc357775981 响应头信息 PAGEREF _Toc357775981 h 16 HYPERLINK l _Toc357775982 4.2报文的解析与传输 PAGEREF _Toc357

5、775982 h 19 HYPERLINK l _Toc357775983 第5章快捷支付业务实现标准 PAGEREF _Toc357775983 h 20 HYPERLINK l _Toc357775984 5.1接口实现说明 PAGEREF _Toc357775984 h 21 HYPERLINK l _Toc357775985 5.2网上签约 PAGEREF _Toc357775985 h 21 HYPERLINK l _Toc357775986 5.3网上支付 PAGEREF _Toc357775986 h 22 HYPERLINK l _Toc357775987 5.4单笔撤销 PA

6、GEREF _Toc357775987 h 25 HYPERLINK l _Toc357775988 5.5单笔退款 PAGEREF _Toc357775988 h 25 HYPERLINK l _Toc357775989 5.6单笔/批量交易查询 PAGEREF _Toc357775989 h 29 HYPERLINK l _Toc357775990 5.7清算对账 PAGEREF _Toc357775990 h 32 HYPERLINK l _Toc357775991 第6章网络连接标准 PAGEREF _Toc357775991 h 35 HYPERLINK l _Toc35777599

7、2 第7章平安标准 PAGEREF _Toc357775992 h 35 HYPERLINK l _Toc357775993 7.1平安威胁 PAGEREF _Toc357775993 h 35 HYPERLINK l _Toc357775994 7.2数字签名 PAGEREF _Toc357775994 h 36 HYPERLINK l _Toc357775995 7.3报文日志管理 PAGEREF _Toc357775995 h 36 HYPERLINK l _Toc357775996 第8章其它标准 PAGEREF _Toc357775996 h 37 HYPERLINK l _Toc3

8、57775997 8.1异常处理标准 PAGEREF _Toc357775997 h 37 HYPERLINK l _Toc357775998 8.2错误码标准 PAGEREF _Toc357775998 h 37 HYPERLINK l _Toc357775999 8.3处理响应时间要求 PAGEREF _Toc357775999 h 37 HYPERLINK l _Toc357776000 8.4可用性要求 PAGEREF _Toc357776000 h 37 HYPERLINK l _Toc357776001 第9章附录 PAGEREF _Toc357776001 h 37 HYPERL

9、INK l _Toc357776002 9.1快捷支付报文样例 PAGEREF _Toc357776002 h 37 HYPERLINK l _Toc357776003 9.2快捷支付金额格式 PAGEREF _Toc357776003 h 37 HYPERLINK l _Toc357776004 9.3快捷支付货币代码表 PAGEREF _Toc357776004 h 38 HYPERLINK l _Toc357776005 9.4数据字典定义 PAGEREF _Toc357776005 h 39文档概述介绍快捷支付概述在互联网支付体系中，持卡人身份验证与资金清算是两个关键问题。在传统解决方

10、案中，对持卡人的身份验证一般是由持卡人在发卡行提供的身份验证效劳器比方发卡行的网上银行直接进行，并将身份验证的结果通知商户。资金清算可能是在身份验证通过之后实时进行清算，也可能是通过专用的资金清算网络单独进行。这种传统解决方案要求发卡行提供基于互联网的持卡人身份验证效劳，并且要求商户在持卡人在进行互联网支付时，将持卡人引导至发卡行进行身份验证。随着互联网支付的普及，这种模式逐渐显现出一些问题。其中最突出的问题是持卡人需要访问多个互联网效劳站点才能完成一次完整的支付过程。在多个互联网效劳站点之间跳转使用户的交易与支付体验不够流畅。在这个过程由于网络传输、客户端处理中任何一个失败都会造成支付过程失

11、败。随着互联网支付的开展，第三方支付平台已经成为互联网支付体系中的重要组成局部。越来越多的商户不是直接通过银行，而是通过第三方支付平台实现基于互联网支付，利用第三方支付平台提供的快速便捷的支付清算效劳，降低接入复杂度、控制互联网支付的本钱、提高用户的支付体验。基于快捷支付的账户平安体系，当持卡人在进行互联网支付时，持卡人可以通过快捷支付账户平安体系进行身份验证，并在身份验证通过时，委托快捷支付代他向银行发出支付指令，实现使用该持卡人委托范围内的银行资金的划拨，完成一次完整的互联网支付。使用这种方式，在持卡人进行互联网不需要访问多个互联网效劳站点，防止输入银行卡号与密码，可以提升用户的互联网支付

12、体验，增加支付成功率，减少用户银行卡号与密码被盗的风险。与此同时，基于这种信任与委托关系，在快捷支付与银行之间可以合作为持卡人与快捷支付用户提供更多的增值效劳，比方商户货款的实时提现效劳等。本文档阐述的快捷支付技术标准，为更加快捷平安的互联网支付结算提供了完全解决方案。目标读者本文的主要目标读者是快捷支付标准银行方的技术实施人员，其中的局部内容也可供银行的管理与业务人员参考。版本标准快捷支付标准的版本标准是：.。本文介绍快捷支付技术标准的版。最近修订版本号作者内容提要核准人发布日期1.0.0 xxp初次版本2021-05-27参考标准与文献快捷支付业务概述本章介绍快捷支付的业务模型，描述快捷支

13、付业务的主要业务目的，介绍各个参与方的功能与责任，并阐述作为快捷支付平安性根底的平安责任模型。快捷支付业务模型业务模型快捷支付的业务目的是充分结合快捷支付在互联网交易效劳与市场占用率方面的专长，与银行在资金管理与结算效劳上的专长，双方优势互补，为快捷支付与银行的共同用户其中包括互联网买家与商户提供整合、快捷、平安的互联网支付与结算解决方案。快捷支付主要提供在互联网上进行支付时持卡人作为买家委托快捷支付使用他在银行卡账户中的资金进行网上支付业务功能。在网上支付时，资金从买家银行卡账户流入快捷支付的客户保证金账户中.用户域用户域中包括了快捷支付业务的主要效劳对象，其中包括互联网交易中的买家与商户。

14、买家使用快捷支付业务进行交易货款支付，商户使用快捷支付业务进行交易货款结算。无论是买家还是商户，如果需要使用快捷支付业务，必须至少拥有一个快捷支付账户与一张银行卡，并且快捷支付账户与银行卡的姓名与身份证件需要一致。交易控制域交易控制域直接为用户域提供互联网交易效劳以及与之相关的资金效劳，其中包括交易支付时的买家身份验证与授权、为商户提供货款结算效劳、监督完整的交易履约过程、为交易各方提供沟通与交互平台等。在快捷支付业务模型中，交易控制域的主体是快捷支付。核心业务为了使用快捷支付与银行联合提供的快捷支付效劳，用户首先需要与快捷支付和银行签定协议，明确各方的权利与义务，这一过程称为“快捷支付签约；

15、“快捷支付签约所形成的数据记录称为“快捷支付签约记录；签约成功后，快捷支付与银行交互过程中用于识别用户身份及银行卡信息的编号称为“快捷支付协议号。在签约成功后，用户就可以使用快捷支付进行方便、平安的网上支付与提现。为了保证快捷支付业务处理的准确性，快捷支付标准中也规定了各种管理类业务，如批量查询、单笔交易查询、清算对账、签约对账等。 贷记卡快捷支付与借记卡快捷支付快捷支付业务不仅支持借记卡支付业务，同时也支持信用卡支付业务，由于借记卡快捷支付与信用卡快捷支付业务没有实质性的差异，本文将借记卡快捷支付业务与信用卡快捷支付业务整合到一起进行介绍，没有特别说明，所介绍的业务不区分借记卡与信用卡。下面

16、是信用卡快捷支付与借记卡快捷支付的区别如下表：借记卡快捷支付贷记卡快捷支付是否区分大小额否是是否收费否大额收费，小额不收费快捷支付平安责任模型平安目标快捷支付支付业务的主要平安目标是，只有经本人用户委托与授权，才能够动用该用户开通快捷支付业务的银行卡账户内的资金，并且用于用户指定的支付目的。这一平安目标是通过用户、快捷支付与银行三方共同履行责任来保证的。引入快捷支付平安责任模型，目的在于明确规定各方在保障平安目标时的责任。快捷支付平安责任模型为了实现平安支付这一目标，用户、快捷支付与银行各自应该履行的责任 。用户：只有本人同时拥有账户号与支付密码。 向快捷支付发起的支付请求代表本人的真实意图。

17、快捷支付：只有用户发起交易支付请求，并且账户与支付密码验证通过，才能发起支付指令。 只有收到来自英航的账务处理的成功结果，才执行用户请求的交易支付。银行：只有来之快捷支付的支付指定才能触发快捷业务的账务处理。 给快捷支付的支付反应真实反应账务处理结果 快捷效劳与额度在用户授权范围内。从上可知只要快捷支付支付业务的参与者都恰当地履行了自己的责任，即可确保实现快捷支付支付的平安目标。当用户使用快捷支付时，信任快捷支付履行责任只有用户发起交易支付请求，并且账户与支付密码验证通过，才能发起快捷支付支付指令。这一信任关系与快捷支付现有的用户协议是相容的。责任认定方式当出现快捷支付平安目标被违背的情况时，

18、为了认定责任，快捷支付与银行必须分别举证自己履行了责任。如果两方中有一方无法举证自己履行了平安责任模型中规定的责任，那么由于本次平安目标违背事件引发的损失由未能举证的一方承当。如果快捷支付与银行都能够举证自己履行了责任，那么说明用户未履行自己的平安责任，损失由用户承当。由于平安责任模型中信任关系的存在，因此快捷支付无须举证自己履行了责任只有用户发起交易支付请求，并且账户与支付密码验证通过，才能发起快捷支付支付指令。快捷支付技术标准将支持银行与快捷支付举证自己履行了责任。快捷支付架构本章介绍快捷支付的技术架构。描述组成快捷支付系统的各个组件以及它们之间的协作方式。快捷支付架构目标业务目标快捷支付

19、架构的目标是在快捷支付业务模型的框架下，实现快捷支付业务的目标、约束与流程，对快捷支付平安与责任模型提供支持。技术目标除了实现业务目标，快捷支付架构也需要达成一些技术上的目标。其中最重要的技术目标是开放、简单、平安。开放快捷支付标准需要实现快捷支付与各个银行系统的互联，为了方便快捷支付与银行之间的异构平台与系统的互联，快捷支付架构必须基于开放平台与标准，方便跨平台、跨地域的接入。简单快捷支付作为一种创新的、以简单、平安、快捷为核心理念的在线支付标准，在使用的方便性和接入的简单性方面，要求超越传统的互联网支付解决方案。平安由于快捷支付标准简化了支付流程，并且由快捷支付系统而不是发卡行完成用户身份

20、的验证，因此必须规定严格的平安责任模型，并且通过恰当的技术标准和方法来实现该责任模型。快捷支付架构模型架构模型由于不同银行在系统架构上存在差异，本文中以典型的银行系统为例，介绍快捷支付的架构模型。在快捷支付系统的具体实施与接入中，可以视需要对该架构模型进行修改，增加、删除、分拆或者合并系统中包含的组件。图3-1 快捷支付架构模型图中显示了实现快捷支付业务涉及到的系统组件。这些系统组件有些需要全新引入如银行快捷支付渠道和银行快捷支付业务系统，有些需要在原有系统之上扩展如银行柜面渠道，有些可以直接使用现有的系统如银行账务与卡业务系统。架构组件快捷支付技术架构中涉及到的系统组件与它们的主要职责如下：

21、银行快捷支付接入系统银行快捷支付渠道与快捷支付渠道之间通过平安的信道互联，负责与快捷支付之间平安地交换快捷支付协议报文，验证报文的真实性与合法性，维护快捷支付报文日志，并在快捷支付协议报文与银行快捷支付业务系统所能够理解的交易指令之间进行翻译银行快捷支付接入系统可以独立搭建，也可以在现有渠道平台上扩展。银行柜台银行柜面渠道是银行柜员的工作平台，负责接受银行柜员提交的快捷支付签约请求，并且提供柜员与快捷支付相关的资金对账与清算、客户效劳等功能。银行柜面渠道不直接处理快捷支付业务的核心逻辑，相关处理均翻译成银行快捷支付业务系统所能够理解的交易指令，交给银行快捷支付业务系统进行处理。一般情况下，可以

22、通过对现有银行柜面渠道系统进行功能扩展来支持快捷支付业务。银行快捷支付业务系统银行快捷支付业务系统是快捷支付业务在银行端处理的主要系统，负责接受来自银行快捷支付渠道或者银行柜面渠道的请求、控制快捷支付业务流程、管理快捷支付业务数据、验证快捷支付效劳授权与额度等业务规那么、构造对银行账务与卡业务系统的交易请求、处理银行账务与卡业务系统的返回结果、并将结果返回给银行快捷支付渠道或银行柜面渠道等银行快捷支付业务系统可以独立搭建，也可以在现有中间业务平台上扩展。银行账务与卡业务系统银行账务与卡业务系统作为银行的核心系统，为快捷支付业务提供根底的客户身份验证、卡片密码验证、资金清算处理等功能。理想情况下

23、，现有的银行账务与卡业务系统所提供的效劳就能够支持快捷支付业务，不需要扩展或者修改银行账务与卡业务系统。快捷支付前台系统快捷支付前台系统是快捷支付会员直接使用快捷支付业务功能的入口，引导用户进行快捷支付协议签约、激活，对于已经激活的快捷支付用户，能直接使用快捷支付进行充值，提现，查询银行卡余额，修改快捷支付限额等功能。是快捷支付业务展示给用户使用的平台。快捷支付业务系统快捷支付业务系统目前主要负责处理快捷支付协议及其他非清算类业务处理，负责整个快捷支付签约信息的管理。非清算类业务功能，包含：快捷支付cms信息管理，快捷支付限额查询/修改，快捷支付余额查询，快捷支付签约信息查询等。快捷支付支付/

24、清算系统快捷支付体系中，支付层负责接收快捷支付清算类业务请求，用户在快捷支付前台系统选择快捷支付进行充值，提现，充退等操作时，前台系统将快捷支付请求发送到支付层，有支付层负责将请求分类记录并发送到清算层，并等待清算层回执处理结果后，通知账务系统完成用户账务操作。清算层是是快捷支付清算类业务处理的核心系统，收到支付层快捷支付业务请求后，清算层记录快捷支付请求信息，并将请求触发到快捷支付前置系统，由快捷支付前置系统完成快捷支付报文与银行端的交互，完成快捷支付请求处理。同时，清算层还负责触发快捷支付相关的查询业务，文件处理业务，业务对账业务等。快捷支付账务/会计/核算系统账务系统负责快捷支付用户虚拟

25、账户管理，记录用户账户资金流动情况。会计系统按照标准的会计规那么，用复式记账的方式记录用户账户资金借贷关系记录。核算系统主要负责将银行实际的资金流动与支付的资金流动关系进行核对。快捷支付会员/认证系统会员系统记录了快捷支付用户根本的身份信息，在快捷支付业务中，会员系统主要用于获取快捷支付业务处理时所需要的用户信息。认证系统主要负责完成用户身份信息的认证工作，快捷支付协议激活时，由认证系统自动完成用户实名认证，所以，签约快捷支付是最便捷的实名认证方式。快捷支付文件系统快捷支付业务中，有很多地方与银行的交互会使用到文件系统，比方，银行上传签约对账文件，清算类业务/资金对账文件等。这些文件可能是银行

26、主动上传到我方文件系统，也可能是我方到银行方系统下载后存到文件系统。快捷支付前置系统快捷支付前置系统是快捷支付核心业务系统与银行快捷支付接入系统进行交互的桥梁，主要负责交互报文封装，解析，签名，验签；并将报文信息转换为内部系统业务对象返回给业务系统完成快捷支付业务处理。快捷支付后台管理系统快捷支付后台管理系统主要使用者是快捷支付结算，运维，客服人员，后台管理系统提供了一系列快捷支付业务相关的管理功能，通过这些功能，支持快捷支付接入可配置化，同时也展示出用户快捷支付使用的相关信息，后台管理功能主要包含：快捷支付渠道管理，快捷支付文件管理，快捷支付签约信息管理，快捷支付CMS信息管理等。快捷支付交

27、互模式在快捷支付业务的技术实现中，快捷支付与银行之间通过交换报文与数据文件来交换业务信息、实现业务流程、控制业务规那么。实现快捷支付业务所需的交互模式可以归纳为请求-应答、单向通知这两种模式，实际业务中可能会将各种交互模式结合起来使用。下文将介绍这两种交互模式适用的场景与实现方式。请求-应答模式在请求-应答模式下，一方作为效劳提供者，另一方作为效劳使用者。由效劳使用者主动向效劳提供者发起请求并等待应答，效劳提供者接受请求，完成处理，并向效劳使用者应答处理结果，效劳使用者收到处理结果之后进行后续处理。请求-应答模式适用于效劳使用者需要根据效劳提供者的效劳应答才能进行正确的后续处理的场景，比方，在

28、快捷支付网上支付业务中，快捷支付作为效劳使用者，银行作为效劳提供者，快捷支付需要知道银行的支付处理结果之后才能继续交易流程。图3-2 请求-应答模式单向通知模式在单向通知模式下，一方作为通知发送者，一方作为通知接收者。发送者发送通知，并保证接收者收到通知。通知接收者在收到通知之后，立即返回发送者通知已收到。通知送达之后，发送方与接收方可以独立地进行后续业务处理。在快捷支付标准中，如果对方进行业务处理所需的时间不可预知时，采用单向通知模式。图3-3 单向通知模式快捷支付报文结构快捷支付报文标准是快捷支付技术标准中重要的组成局部，规定了快捷支付与银行之间交换报文的顺序、格式与语义与处理标准。本章中

29、介绍快捷支付报文的一般结构与公共元素，这些标准适用于所有的快捷支付协议报文。具体快捷支付业务中使用的报文，在各个业务实现标准中分别进行阐述。报文结构快捷支付报文统一采用xml格式。所有的快捷支付报文均以QPAY作为根元素，每个QPAY元素中可以包含Head和Body元素。Head元素中包含代表进行的业务的描述属性，比方Code、DateTime等。Body元素中包含代笔业务的具体属性。作为约定，业务元素属性均是首字母大写的CamelCase形式。标记Tag说明快捷支付报文块开始报文头开始 报文头内容报文头结束报文体开始报文体内容报文体结束快捷支付报文块结束请求/响应头信息请求头信息标记Tag长

30、度是否必输说明请求头信息开始5Y协议版本号20Y报文唯一标识6Y交易码14Y交易时间格式：yyyyMMDDHHmmss请求头信息结束响应头信息标记Tag长度是否必输说明响应头信息开始5Y协议版本号20报文唯一标识 以上送标识为准6Y交易码14Y交易时间 格式：yyyyMMDDHHmmss 6Y响应码 100响应信息描述响应头信息结束在下文中出现的具体报文格式描述中，“是否必输列包含的值的含义如下表所示：符号含义请求方约束效劳方约束YRequired(必须的)必须包含该域必须校验该域是否存在和内容的合法性CConditional(有条件的)如果条件符合必须包含该域当条件满足时，必须校验该域是否存

31、在当该域存在时，必须检查其内容的合法性N或空白Optional(可选的)该域可选当该域存在时，必须检查其内容的合法性错误代码说明下表列举了标准的错误代码：错误代码错误描述解释报文类错误0000无效的根元素根元素无法识别0001未定义的交易码消息不是请求和应答等；或者消息发送给了一个错误的组件0002必填项缺失报文中“是否必输为Y的参数缺失0003协议版本有误版本号错误0004根据标准，一个或多个域不符合格式要求例如，非数字，或者不是有效的日期格式等等。0005银行标识不正确域中的银行标识不正确0007签名无效报文签名校验不通过0008加密密钥不存在加密密钥不存在0009签名密钥不存在签名密钥不

32、存在文件类错误0301业务日期不正确业务日期格式不对，一般情况下业务日期必须是昨日，不过系统也支持以前日期的数据处理查询类错误0400支付流水重复重复的网上支付流水0401原支付流水不存在申请退货的原支付流水不存在0402查询范围太大查询时间跨度太大0403查询的交易不存在查询的交易不存在用户类错误可以将错误信息显示给用户1000协议号已经签约成功1001快捷支付协议号无效快捷支付协议号不对应有效的快捷支付签约记录。1002快捷支付签约状态不正确快捷支付签约状态不允许执行当前的业务1200身份证已经被使用身份证已经被其它用户使用，并签约1201年龄不满足如：用户未满18岁1202身份证格式不正

33、确身份证不是有效的身份证1203真实姓名不正确真实姓名与快捷支付中的不一致1204证件类型不正确证件类型与快捷支付中的不一致1205身份证号码不匹配身份证号码与快捷支付中登记的身份证号码不匹配1206认证信息不匹配认证信息与快捷支付通过认证的信息不匹配1207该银行卡号已经成功签约该银行卡号对应的快捷支付账号已经签约成功。1301快捷支付账户不存在快捷支付账户标识不对应有效的快捷支付账户。1302快捷支付账户状态不正确快捷支付账户的状态不允许签约。1303快捷支付账户类型不正确快捷支付账户的类型不允许签约。1304快捷支付账户已经申请1305快捷支付账号绑定的快捷支付数量超限快捷支付账号绑定的

34、银行卡已经超过最大数量。1306快捷支付账号通过的认证数量超过最大值快捷支付账号通过的认证数量超过最大值。1307登陆账号无效, 快捷支付账户格式不对1311账号无效。账户未开通快捷支付1800银行卡户名不存在户名不存在1801银行卡卡号不存在银行卡号不存在1802户名与银行卡号不匹配户名与银行卡号不匹配1803银行卡号与卡类型不匹配银行卡号与卡类型不匹配1804不支持的银行卡号不支持的银行卡号1805不支持的证件类型不支持的证件类型1806证件号码格式错误证件号码格式错误1807与登记证件类型不匹配与登记证件类型不匹配1808与登记证件号码不匹配与登记证件号码不匹配1809未登记 号码未登记

35、 号码1810与登记的 号码不匹配与登记的 号码不匹配支付类错误1401密码校验次数超限密码校验次数超限1402银行卡状态不正确银行卡状态不正确1403银行账户状态不允许该操作银行账户状态不允许该操作1404银行支付校验码输入错误银行支付校验码输入错误1405银行支付校验码失效支付校验码超过输入时间范围限制，失效1406原支付申请流水号已经支付支付流水号已经支付过1407原支付申请流水不存在支付申请流水不存在1408支付密码输入超限快捷支付支付密码超过输入次数限制1409支付异常，请查询银行卡是否已扣款无法获得发卡核心的响应银行卡类错误1601金额超限支付金额超过每日限额1602余额缺乏银行账

36、户中的余额缺乏以完成支付1604银行交易处理中该笔交易在银行前置系统中状态未知1605银行交易失败该笔交易在银行系统中已经失败，且状态不会再发生变更。错误具体详情通过ErrorDetail告知。1607银行卡卡号不正确银行卡卡号不正确信用卡类错误1701信用卡冻结贷记卡已被冻结1702信用卡挂失贷记卡已申请挂失1703信用卡不能进行支付未领卡，未激活，止付，预销户1704信用卡透支超限贷记卡透支超限管理类错误2000快捷支付渠道关闭没有开通快捷支付业务2001效劳没有开通请求的业务没有开通系统类错误9000暂时系统异常例如，一个请求队列满了。9001永久系统异常例如，无法访问一个重要数据库所在

37、的磁盘。报文的解析与传输快捷支付报文的传输使用XML Over (S)方式，在 请求/响应体中包含XML形式的报文。报文解析对XML解析的根本要求如下版本号检查用于表示组件支持的协议版本号。消息版本号必须表示为：n.n.n ，其中“n 表示数字。比方1.0或。在所有的消息中，各组件都必须填写自身支持的协议版本号。消息版本号不能低于1.0.0。如果消息版本号低于接收方组件支持的最低版本号，那么接收方组件必须返回错误消息，并且设置错误码=0003。xml解析为了可以支持后续协议版本，xml解析的实现不要做严格的验证。特别是需要忽略未被确认的域。所有xml消息必须用“utf-8编码。请求和应答域之i

38、d属性匹配请求和应答报文的Head域之id属性必须相同，id是请求方生成的唯一序列号。比方：银行在请求的Head域设置了一个id属性值，那么快捷支付在应答里面的Head域的id属性必须和请求的Head域之id值相同。报文传输对 S传输的根本要求如下：使用POST发送消息消息请求基于 / S的POST方式。 消息头要求 请求与响应消息中必须按照如下要求设置头部域：Content-Length：必须设置成消息体的长度Content-Type：必须设置下面的值：application/xml; charset=utf-8快捷支付业务实现标准快捷支付业务功能覆盖了从签约、效劳与管理的各个方面。签约类的

39、业务负责快捷支付效劳协议的建立、调整与撤消，其中包括柜台签约、网上签约、柜台签约撤销、网上撤约、批量签约/撤约、支付限额查询、网上支付限额修改。效劳类的业务满足用户互联网交易与资金需求，其中包括网上支付、提现单笔与批量、退货单笔与批量与银行卡余额查询。管理类业务是为了保证互联网交易的正常进行而引入的，其中包含批量交易查询、单笔交易查询、签约对账与清算对账、中间账户账务明细查询等。本章描述如何通过用户、快捷支付与银行之间的协作实现上述快捷支付业务的流程与规那么。同时，本章也规定了在银行快捷支付渠道与快捷支付渠道间的交互模式、交换的报文与文件的结构、语义与处理标准。为了保证快捷支付业务的正常开展，

40、还有一些在银行或快捷支付内部完成的业务流程，比方在银行完成的支付限额修改，以及各种业务报表等，这些业务由于不涉及到快捷支付与银行的交互，因此在本文档中不作具体描述。接口实现说明序号接口类型实现方式交易类型代码1网上签约必做QP0012网上支付必做QP0053撤销支付必做QP0064实时退款必做QP0075单笔/批量交易查询必做QP0086清算对帐必做QP009网上签约签约申请相关参数请求标记Tag长度是否必输说明报文体开始1Y客户类型10Y商户编号22Y支付卡号1Y卡种，见数据字典定义！30Y户名11N 号码，卡种为信用卡时必填2N证件类型30N证件号码3NCvv2 ，卡种为信用卡4N有效期，

41、卡种为信用卡时必填30预留100预留报文体结束响应标记Tag长度说明报文体开始1验证结果，见数据字典定义！30预留100预留报文体结束网上支付业务功能快捷支付网上支付业务的主要效劳对象是互联网交易中的买家，使买家能够通过快捷支付使用签约银行卡内的资金实现快捷、平安的交易支付。快捷支付负责验证客户持卡人身份与效劳权限，并请求银行划拨客户的资金用于互联网交易的支付；银行负责验证由快捷支付发出的支付指令是否在快捷支付签约的业务范围与银行控制的快捷支付支付限额内，并实时扣减签约银行卡内的余额。由于网上支付引起的银行与快捷支付间的资金清算方法由快捷支付清算标准规定。业务规那么网上支付业务在执行中需要满足

42、以下约束条件：网上支付必须由客户请求，从快捷支付发起。网上支付时的资金只能从快捷支付签约时确定的签约银行卡账户中支出，用于同一客户的网上支付。网上支付时客户在签约银行卡账户中的资金只能转移到快捷支付公司指定的清算账户中。同一支付订单号的快捷支付网上支付交易银行必须保证只能执行一次。银行与快捷支付需要保存网上支付相关报文的日志作为解决资金清算不一致的依据。银行必须根据客户的意愿做限额控制；对于信用卡快捷支付，支付时有大额支付和小额支付之分，银行端接收到支付报文时，需要根据快捷支付报文中的扩展字段来区分大额支付和小额支付。处理流程客户通过互联网在快捷支付商户处购物，并在快捷支付创立交易。客户输入支

43、付密码，并请求快捷支付使用本人快捷支付账户关联的快捷支付签约银行卡为交易支付。快捷支付验证客户身份与快捷支付网上支付请求的合法性，验证工程包含： 该快捷支付账户的状态允许支付。支付密码正确。快捷支付效劳已激活账户平安等级到达快捷支付支付的要求当日快捷支付网上支付总额在快捷支付规定的快捷支付每日支付限额内。上述验证中如果有一项不符，那么快捷支付拒绝客户的快捷支付网上支付请求，并将客户引导到恰当的快捷支付功能页面。快捷支付生成唯一的快捷支付网上支付订单号，并根据该快捷支付账户签约的快捷支付协议号确定银行、构造“网上支付请求报文。快捷支付将该报文发送给银行。银行接受“网上支付请求报文，验证网上支付的

44、合法性。验证工程至少包括： 快捷支付协议号对应的快捷支付签约记录已成功银行卡状态有效银行卡余额足够银行卡号当日累计的快捷支付支付总额未超过银行规定的每日支付限额上述验证中如果有一项不符，那么银行拒绝该请求报文，并返回快捷支付支付失败的原因。银行处理网上支付交易，从快捷支付签约记录中的银行卡账户划付资金至快捷支付资金清算专用账户中，并进行其它关联处理比方手续费扣减、积分计算等。银行处理网上支付交易处理成功之后，将交易处理结果通过“网上支付应答报文返回给快捷支付。快捷支付接收到银行返回的“网上支付应答报文，从中解析出处理结果。假设处理结果显示银行处理成功，那么快捷支付为客户进行资金入账，并支付该笔

45、互联网交易。快捷支付向用户显示网上支付的结果。客户查看网上支付的结果。报文格式 请求标记Tag长度是否必输说明报文体开始1Y客户类型10Y商户编号30Y订单号12Y交易金额(单位：分)3币种，默认15611N 号码，卡种为信用卡时必填30Y姓名注：针对信用卡该字段无效1Y卡种，见数据字典定义！22Y卡号2N证件类型，见数据字典定义！30N证件号码3NCvv2 ，卡种为信用卡注：针对信用卡该字段无效4C有效期，卡种为信用卡时必输报文体结束响应标记Tag长度说明报文体开始10商户编号20流水号30订单号1交易状态，见数据字典定义！30预留字段1100预留字段2报文体结束单笔撤销商户因业务需要，在支

46、付业务未完成清算前，取消支付的过程。如果支付已经完成，那么银行会拒绝响应撤消支付请求。处理流程商户发起撤消一笔支付的请求；银行检索支付记录的状态，并进行处理。如果未付那么把支付请求撤消，并返回给商户支付请求撤消成功的信息；否那么返回商户撤消支付请求失败的信息。交互模式在撤销支付业务中，商户与银行通过请求-应答模式进行交互。报文格式 同单笔退款单笔退款业务功能对于客户的充值金额，为防止套现或借用快捷支付渠道转帐，快捷支付控制客户不能转入其它银行。为满足客户充值金额返回原充值银行卡的需求，那么需要充值退回功能。单笔充值退回必须在快捷支付核实之后，由快捷支付发起。业务规那么单笔充值退回业务在执行中需

47、要满足以下约束条件：单笔充值退回业务从快捷支付发起。单笔充值退回业务必须有对应的快捷支付充值交易。快捷支付可以针对90天内的快捷支付充值发起单笔充值退回业务。单笔充值退回的金额不能超过对应的快捷支付充值的金额，但可以少于快捷支付充值时的金额；针对一笔快捷支付充值，可以进行屡次退回，但退回的总金额不能大于该笔快捷支付充值退回的总金额。单笔退回的资金只能原路划回快捷支付充值时使用的签约银行卡账户中。客户单笔退回时收到的资金只能从快捷支付公司事先约定的清算账户中划拨。同一退回订单号的单笔提现交易银行必须保证只能执行一次。银行与快捷支付需要保存单笔退回相关报文的日志，作为解决资金清算不一致的凭据。处理

48、流程客户在快捷支付页面对充值金额申请普通提现。提现失败，出现错误提示信息页面和充值退回页面链接入口。快捷支付系统对退货退回的合法性进行验证。验证内容包括：客户的快捷支付效劳状态为激活单笔退货的互联网交易是使用快捷支付充值的如果上述验证中有一项不符合，那么快捷支付系统拒绝该笔快捷支付单笔退回请求。快捷支付系统临时冻结客户快捷支付账户内与单笔退货金额等量的资金。快捷支付系统产生唯一的快捷支付单笔退货订单号，并根据该快捷支付账户签约的快捷支付协议号确定银行、构造“单笔退货请求报文。快捷支付将该报文发送给银行。银行接受“单笔退货请求报文，从报文中解析出退货指令的要素，并对其进行合法性验证。验证内容包括

49、： 快捷支付协议号对应有效的快捷支付签约记录快捷支付签约银行卡状态有效原始快捷支付网上支付订单号对应的快捷支付支付交易存在，且时间在90天内针对该交易进行快捷支付退货的累计金额不大于原始快捷支付支付订单号对应的快捷支付网上支付交易的总金额本次单笔退货订单号之前未执行过。上述验证中如果有一项不符，那么银行拒绝单笔退货请求，返回快捷支付单笔退货不成功的原因。银行处理单笔退货交易，从快捷支付资金清算专用账户中实时划付资金至客户的快捷支付签约银行卡账户中，并进行其它关联处理比方消费积分扣减。银行处理单笔退货交易成功之后，将交易处理结果通过“单笔退货应答报文返回给快捷支付。快捷支付接收到银行返回的“单笔

50、退货应答报文，从中解析出处理结果。假设处理结果显示银行处理成功，那么快捷支付解冻客户因退货临时冻结的资金，并扣减客户快捷支付账户中的余额。假设处理结果显示银行处理失败，那么快捷支付直接解冻客户因退货临时冻结的资金，不变动客户快捷支付账户中的余额。交互模式在单笔退货业务中，快捷支付与银行通过请求-应答模式交互。在单笔退货流程的第5步，快捷支付作为效劳使用者向银行发送 “单笔退货请求报文，在流程第8步，银行作为效劳提供者向快捷支付返回“单笔退货应答报文。图6-20 单笔退款交互模式报文格式请求标记Tag长度是否必输说明报文体开始1Y客户类型10Y商户编号2Y交易类型16;/撤消支付18;/实时退款

51、30Y原订单号12N退款金额 (单位：分)类型为“退款时必填！30预留字段1100预留字段2报文体结束响应标记Tag长度说明报文体开始10商户编号20流水号30原订单号1交易状态，见数据字典定义！30预留字段1100预留字段2报文体结束单笔/批量交易查询业务功能快捷支付批量查询由快捷支付发起，向银行查询一定时间段范围内全部或指定一组订单号的支付、提现或退货交易的处理状态。当由于网络或系统故障产生掉单快捷支付发出了快捷支付请求报文，但没有收到银行的应答报文时，快捷支付可以使用快捷支付批量交易查询业务得到银行的交易状态，并使用该状态对快捷支付交易进行恢复处理。这样做，可以及时恢复客户的交易，提升客

52、户体验。业务规那么批量查询查询业务在执行中需要满足以下约束条件：只有快捷支付支付和快捷支付单笔退货及撤销交易是可以查询的。银行端返回成功的交易状态代表账务成功，返回失败的代表账务失败。银行端只返回账务处理主机有明确结果的交易状态,不明确的不用返回。银行必须保证返回的快捷支付交易的处理状态与实际状态一致。快捷支付以银行返回的查询结果信息为准调整快捷支付端的交易状态，快捷支付交易的处理状态一旦进入成功状态或者失败状态，那么银行端不允许改变。快捷支付发起的快捷支付批量交易查询的时间段是当日的任一精确到秒的时间段，时间段的起止时间是快捷支付公司发起的交易指令中的时间。对于支付交易查询，返回的结果里面必

53、须是所有成功的支付流水，失败的不能返回。而且下面的STATUS也不要填写，这个状态是供提现查询使用的，如果需要填写，必须保证是成功状态0001。银行端必须实现按照时间段查询，时间段加上流水号，流水号这三种方式查询对于信用卡快捷支付，快捷支付发起批量查询时，使用扩展字段标明本次查询请求是针对大额的还是针对小额的；银行处理完成，返回查询结果通知时，同样需要在扩展字段标明查询结果属于大额还是小额。(查询请求和查询结果通知报文中大小额标识，针对本次查询，不用于流水明细)处理流程批量查询查询的处理流程如下：快捷支付系统根据未得到银行应答的快捷支付交易请求，确定当日的某个需要实时查询的交易时间段、交易类型

54、与交易订单号列表。快捷支付系统以该时间段、交易类型与交易单号列表构造“批量查询查询请求报文，并发送给银行。银行收到“批量查询查询请求报文之后，验证查询起始时间与结束时间是否在允许范围内。如果不在允许范围内，那么银行拒绝快捷支付的批量查询查询通知。银行向快捷支付返回“批量查询查询接受报文，表示已接受快捷支付批量交易查询请求。快捷支付接到“批量查询查询接受报文之后，完成请求发送工作。快捷支付不同步等待批量查询查询结果。银行根据查询请求中的交易类型、交易时间段与交易订单号列表，查询这些交易的实际执行结果。银行将交易的实际执行结果组装成“批量查询查询结果报文，以单向通知的方式发送给快捷支付。如果通知失

55、败，银行需要有恰当的重试策略。快捷支付接收到批量查询查询结果之后，根据结果逐条交易进行恢复处理。交互模式快捷支付与银行通过请求-应答模式交互。报文格式请求标记Tag长度是否必输说明报文体开始10Y商户编号1Y查询类型0：当日1：历史30Y订单号或者打款号30预留字段1100预留字段2报文体结束响应标记Tag长度说明报文体开始10商户编号60商户名称循环域开始单笔开始30订单号或打款号20交易流水号2交易类型，见数据字典定义12交易金额(单位：分)14交易日期时间12已退款金额(单位：分)12已预授权完成金额(单位：分)1交易状态，见数据字典定义单笔结束循环体结束30预留字段1100预留字段2报

56、文体结束清算对账业务功能从快捷支付发起的快捷支付网上支付退货交易的执行结果以银行返回给快捷支付的交易应答为准。当发生网络丧失报文或系统故障时，银行返回给快捷支付的交易应答有可能丧失，造成客户签约银行卡账户中的资金变动与快捷支付账户中的资金变动不一致。除了交易应答丧失产生清算不一致的情况下，还可能因为其它原因比方系统中的缺陷，或者人为因素产生清算不一致。快捷支付清算对账业务的目的是发现用户签约银行卡账户与快捷支付账户中的资金变动不一致的情况，并确定原因与处理方法。快捷支付清算对账业务一般一天进行一次，获取由银行在T日终核对完成之后提供T日0:00-24:00所有涉及到资金变动的快捷支付交易的明细

57、数据，与快捷支付T日的快捷支付交易数据进行比对，找出不一致的交易记录。对于由于银行交易应答丧失造成的快捷支付不一致的交易记录，由快捷支付进行恢复处理。对于由于其它原因产生清算不一致的情况，根据快捷支付收到的银行交易应答内容确定资金处理过失的一方，并由该方进行账务调整处理。如果由银行方的资金处理过失造成清算过失，那么按照快捷支付清算标准中规定的过失处理方法进行清算过失处理。业务规那么清算对账业务在执行中需要满足以下约束条件：银行提供的T日0:00-24:00变化的快捷支付交易明细数据需要与银行的账务处理一致。T日快捷支付交易净额需要与银行清算给快捷支付的T日快捷支付款项净额相同。当清算对账完成后

58、，并完成过失处理之后，双方直至T日的所有快捷支付交易引起的资金变动必须一致。对于信用卡快捷支付清算对账，银行在通知快捷支付做清算对账时，需要将大额信用卡和小额信用卡对应的清算流水生成到不同的清算文件中，在发送清算对账通知时，需要在报文的扩展字段中标明文件中的流水信息属于大额还是小额。处理流程清算对账的处理流程如下所示：快捷支付收到“清算对账报文后，从银行提供的清算对账文件中解析出每一条快捷支付交易记录，与自己在该对账日期的所有快捷支付交易记录进行逐笔核对。找出并生成以下三类交易记录的清单。A：银行有，但快捷支付没有的交易记录B：快捷支付有，但银行没有的交易记录C：双方都有，但内容不一致的交易记

59、录快捷支付对不一致的快捷支付交易记录进行恢复与处理。对于A类交易记录，快捷支付进行交易恢复，使快捷支付对该笔交易的资金处理与银行一致。对于B类交易记录与C类交易记录，快捷支付人工介入处理，通过核对原始的银行应答指令，找出原因并确定该由哪方进行订正。如果存在需要银行进行调整的交易记录，那么快捷支付线下提供应银行的需要调整的交易记录清单，以及原始的银行应答指令，由银行在人工核实之后进行处理。交互模式快捷支付与银行通过请求-应答模式交互。报文格式请求标记Tag长度是否必输说明报文体开始10Y商户编号8Y对账日期yyyyMMdd30预留字段1100预留字段2报文体结束响应I长度说明报文体开始10商户编

60、号8对账日期30订单号或打款号20流水号14交易时间yyyyMMddHHmmss12交易金额 以分为单位2交易类型，见数据字典定义1交易状态 ，见数据字典定义100预留字段30100报文体结束网络连接标准快捷支付渠道与银行快捷支付渠道之间的平安信道建立方式与高层网络连接协议。平安标准在快捷支付业务流程与标准中，已经采用了大量的规那么来降低快捷支付业务的平安风险，如快捷支付签约客户的实名制；快捷支付业务的资金流动量、流动途径与方向的业务规那么等。因此，本章主要从技术角度阐述快捷支付系统中可能出现的平安威胁，以及通过技术标准来躲避平安风险的方式。平安威胁快捷支付系统涉及到快捷支付与银行通过公众互联