担保支付解决方案Word格式.doc

担保支付解决方案Word格式.doc

《担保支付解决方案Word格式.doc》由会员分享，可在线阅读，更多相关《担保支付解决方案Word格式.doc（19页珍藏版）》请在冰点文库上搜索。

3.在简要说明栏中填写变更的内容和变更的范围。

4.表中所有日期格式为：

YYYYMMDD

第一章概述

1.项目背景

随着电子商务的蓬勃发展，自支付宝推出担保支付后，其他第三方支付平台陆续效仿并推出自己的担保支付。

担保支付在约束收款方的同时，保障了付款方的权益，促使交易及时有效的完成，大大提高了交易的成功率，截止目前大多数第三方支付平台均已支持担保支付。

XX支付核心业务平台目前已经存在的担保支付为两方商城模式，需对系统现有的功能按照三方担保支付模式进行整改，整改后支付平台会员可在开通担保支付的商城通过担保方式进行付款。

第二章需求描述及分析

1.需求描述

1）业务需求描述

由于目前大多数第三方支付平台都已经推出了担保支付，担保支付已经不再是一项吸引客户的特色服务，而是立足第三方支付市场必备的基础服务。

以此来看推出担保支付不仅可以为现有商城开展其他相关交易提供更便捷的支付方式；

对于潜在的商城，担保支付也已是其接入的必要条件。

2）功能需求描述

i.支付网关提供如下功能：

Ø

订单支付：

XXX提供订单支付功能，该功能通过接口形式实现，需商城对接XXX担保支付接口。

订单状态查询：

XXX提供订单状态查询功能，该功能通过接口形式实现，需商城对接订单查询接口。

支付结果通知：

XXX通过接口的形式实现支付结果通知功能。

已发货通知接收：

XXX需提供已发货通知接收接口用于接收商城已发货通知。

退款通知接收：

XXX需提供退款接口接收商城退款通知

延期申请通知接收：

XXX需提供延期付款申请接口用于接收延期付款申请，且在个人、企业会员系统中对担保支付订单提供延期付款申请操作

确认收货通知接收：

XXX需提供确认收货接口接收用户在商城确认收货通知，且在个人、企业会员系统中对担保支付订单提供确认收货对操作

延期确认通知接收：

XXX需提供延期付款确认接口用于接收延期付款确认，且在商户系统中对担保支付订单提供延期付款确认操作

延期拒绝通知接收：

XXX需提供延期付款拒绝接口用于接收延期付款拒绝，且在商户系统中对担保支付订单提供延期付款拒绝操作

ii.个人会员系统提供如下功能：

通知卖家发货：

客户支付成功后可通过此功能通知卖家发货，支付平台将此通知发送至商城，由商城通知卖家发货。

申请延期付款：

付款方付款到支付平台成功后，如收款方未发货或者付款方未收到货时可以在会员系统申请延期付款。

确认收货：

付款方收到货物后可在会员系统进行确认收货。

iii.企业会员系统提供如下功能：

iv.自动服务系统：

商户结算：

支付平台按商户的结算周期对商户进行资金结算。

延期付款确认：

支付平台对默认付款时间已到且申请延期付款未进行处理的订单进行延期付款确认操作。

默认收货：

支付平台对默认付款时间已到的订单进行默认收货操作。

资金解冻：

支付平台对退款保障期已到的订单进行资金解冻，对商户实体账户中的收付款双方手续费收入解冻。

对于已经支付成功的订单，支付平台会通过自动服务通知商城，以便商城安排发货。

关于仲裁：

卖方双方发生争议，由商城进行争议处理，如需全额退款或部分退款则调用退款接口，支付平台不承担相应责任。

2.需求分析

1）业务需求分析

对于商城会员若使用担保支付必须在支付平台注册账户，并通过签约将商城账户和支付平台账户进行绑定；

XX支付提供三种方式进行绑定，一是通过批量导入的形式（自动签约）登记入库，二是通过批量录入客户信息，客户进行信息完善，之后自行签约，三是通过会员自己注册支付平台账户然后进行签约。

批量导（录）入的客户需按支付平台模板提供客户信息，导（录）入后，客户需进行信息完善；

客户自行注册XXX账户需要进行手动签约完成绑定。

商城使用导（录）入方式则需开发对应的完善信息功能，若使用客户自行注册的方式则需开发对应的签约/解约功能。

2）功能需求分析

支付：

商城通过该接口跳转至支付平台网关，客户进行网银付款（需区分普通订单），付款成功后，支付平台对商户收取支付手续费，该手续费记入商户手续费账户，商户对收付款双方收取的手续费记入商户实体账户，货款记入平台担保在途账户。

订单支付成功（失败）后，支付平台会通知商城订单状态，若订单状态为成功，商城可以通知收款方发货。

商城如果未收到支付结果通知，可以查询该订单状态，建议商户在已发货通知、退款通知等操作前先查询该订单状态是否与商城中的状态一致。

发货：

商城通过“已发货通知”接口通知支付平台将该笔订单置为“已发货”状态。

退款：

商城通过“退款通知”接口通知支付平台向付款方进行退款，若该笔订单状态为“已支付，未发货”和“已发货，未确认收货”，则直接将货款由平台担保在途账户退回至付款方XXX账户，若订单状态为“已收货”但退款保障期未到（每个商城退款保障期不同），则从收款方XXX账户退回到付款方XXX账户，其他状态不予退款，由商城自行解决，退款时是否退回支付订单时产生的手续费根据商户接入时的设置的参数进行操作。

延期：

商城通过“延期通知”接口通知支付平台进行延期付款申请（每个商城的默认付款时间不同）；

会员也可以通过会员系统申请延期付款，支付平台需后台通知商城。

商城通过“确认收货”接口跳转至支付平台，输入正确的支付密码后支付平台进行确认收货处理，会员也可以通过会员系统进行确认收货，支付平台需后台通知商城该订单已确认收货，对应货款由平台担保在途账户划拨至收款人的XXX账户，该笔资金处于冻结状态，待退款保障期（每个商户自由设置）结束时资金解冻。

延期确认：

商城通过“延期确认通知”接口通知支付平台进行延期付款申请确认（每个商城的默认付款时间不同）。

延期拒绝：

商城通过“延期拒绝通知”接口通知支付平台进行延期付款申请拒绝（每个商城的默认付款时间不同）。

结算：

对于担保支付的商户，结算周期应大于或等于（延期次数+1）*默认付款时间+退款保障期，其中延期次数、默认付款时间、退款保障期均为商户接入时设定。

对于已经发货的订单，在默认付款时间到期时付款方未申请延期，系统按付款方默认收货处理。

此时，货款由平台担保在途账户划拨至收款方XXX账户，并处于冻结状态。

对于已经确认收货的订单，在退款保障期结束时未申请退款，系统则将该货款解冻，收款方可以进行提现等其他操作，此外将对应的商户实体账户中的手续费进行解冻。

第三章总体设计

1.总体设计目标

通过对现有两方担保模式接口按照系统统一标准进行完善，在业务上分离系统现有的仲裁权，仲裁行使权交由商城，支付平台按照商城最终仲裁结果进行相应处理（退款或部分退款）。

2.总体设计原则

统一性：

担保支付接口设计遵循系统其他接口设计标准

可靠性：

由于系统接口均采用一致的加密方式，因此在传输过程中高度可靠、安全

可扩展性：

接口设计预留部分域以便于接口升级以及扩展

3.总体逻辑架构设计

付款方在商城下单，选择XXX付款，页面跳转至XXX支付网关，支付完成后平台通知商城支付结果，若此时付款方需要退款，则可在商城申请退款，若付款方未申请退款，收款方可在商城进行发货，商城通知支付平台该笔订单已经发货，此时付款方可在商城申请退款。

默认付款时间在商户接入时设定，在此期间若付款方未收到货，可以申请延期付款（延期次数参数可配），延期付款申请和确认收货可以在商城或会员系统操作，操作后均需要通知对方订单状态变化，延期付款申请审核可以在商城或商户系统操作，付款方确认收货后即进入退款保障期，在此期间可以在商城发起退款，商城通知支付平台做相应处理，退款保障期过支付平台不再受理退款。

详细操作如下图所示：

第四章详细设计

1.功能设计

1）支付网关：

商城组装报文通过表单形式提交至支付平台，表单包含要素：

商户代码、商户前台通知URL、商户后台通知URL、订单号、订单金额（）、付款方手续费金额、收款方手续费金额、收款账户（商城账户）、预留域。

支付平台接收报文进行验证，验证失败提示相应错误信息，验证通过后对交易数据（订单金额、收款账户）进行验证，失败返回相应错误信息，通过后生成一笔支付订单，客户选择账户付款或者银行付款，付款失败，系统分别通过前、后台通过支付结果通知接口告知支付结果，对于未支付的订单可以再次发起付款，对于失败的订单不允许再次操作；

付款成功，同样通过前、后台通过支付结果通知接口告知商城支付成功，当前该订单的状态为“已付款，待发货”，并将该笔订单对应的货款由付款方划拨到平台担保在途账户

商城组装报文发送至订单状态查询接口，请求报文要素：

商户代码、订单号、预留域，支付平台接收查询请求进行报文验证，通过后返回订单数据，返回报文要素：

商户代码、订单号、交易流水号、订单金额、付款方手续费、收款方手续费、支付成功时间、订单状态、预留域

在支付成功或者失败时用于通知商城，包含要素：

商户代码、订单号、交易流水号、订单金额、付款方手续费、收款方手续费、支付成功时间、订单状态、预留域，若商城收到支付结果通知报文，并且订单支付成功，则商城需通知收款方发货。

商城组装报文通过后台通知支付平台，报文要素：

商户代码、订单号、交易流水号、物流公司名称、发货单号、物流类型、发货时间、预留域。

支付平台接收报文后进行验证，验证失败返回相应错误信息，验证通过后对交易数据（商户代码、订单号、支付流水号、订单状态）进行核实，失败返回相应错误信息，成功则将该笔订单置为“已发货”状态。

若订单为已付款，待发货状态：

商城可以组装退款报文，通知支付平台发起退款，支付平台收到请求后对报文进行验证，验证失败返回相应错误信息，验证通过后交易数据（商户代码、订单号、支付流水号、订单金额、退款金额、订单状态）进行核实对该订单进行退款操作，退款报文包含要素：

商户代码、订单号、支付流水号、订单金额、退款金额、预留域，资金由担保在途账户划转到付款方XXX账户。

若订单为“已发货，未签收”状态：

该状态的订单退款处理同“已付款，待发货”状态订单一样。

若订单为“交易成功”且在退款保障期限内：

退款只能从商城发起，相关要求同上，资金从收款方XXX账户划拨至付款方XXX账户。

其他状态订单不予退款，其中是否退回支付订单产生的手续费（以及商户向收付款双方收取的手续费）根据商户接入时的设置操作。

延期通知接收：

若订单为已付款待发货、延期付款申请通过、延期付款申请拒绝状态：

商户代码、订单号、支付流水号、预留域，预留域字段值为：

40。

支付平台接收请求后验证报文，失败返回相应错误信息，验证通过后对交易数据（商户代码、订单号、支付流水号、订单状态、延期次数）进行核实，失败返回相应错误信息，成功后将订单进行延期，延期次数在商城接入时设定。

商城组装确认收货报文后台通知支付平台，报文要素：

商户代码、订单号、支付流水号、预留域。

支付平台接收请求后验证报文，验证失败返回相应的错误信息，验证通过后对交易数据（商户代码、订单号、支付流水号、订单状态）进行核实，失败返回相应错误信息，核实通过则将订单置为成功状态，相应对货款由平台担保在途账户划拨至收款方XXX账户。

确认收货后开始计算退款保障期，保障期内货款一直处于冻结状态，退款保障期在商户接入时设置，退款保障期过，收款方账户的该笔资金进行解冻。

延期通过通知接收：

若订单为延期付款申请状态：

41。

42。

2）个人会员系统：

付款方（个人会员）付款成功后，可以在个人会员系统手动触发通知卖家发货，支付平台将通知直接发送至商城，由商城通知收款方发货，报文要素同支付结果通知。

付款方（个人会员）付款成功后，如果收款方未发货或者收款方已发货付款方未收货，默认付款时间即将到期，付款方可以在个人会员系统申请延期付款，支付平台向商城发起申请，商城审核后通过支付网关的延期通知接口通知支付平台将订单延期，报文要素同支付网关的延期通知接口。

若付款方已收货，可通过个人会员系统进行确认收货，支付平台向商城发起确认收货通知，商城收到通知，同步返回成功，若商城未收到通知可自行查询订单状态。

3）企业会员系统：

付款方（企业会员）付款成功后，可以在企业会员系统手动触发通知卖家发货，支付平台将通知直接发送至商城，由商城通知收款方发货，报文要素同支付结果通知。

付款方（企业会员）付款成功后，如果收款方未发货或者收款方已发货付款方未收货，默认付款时间即将到期，付款方可以在企业会员系统申请延期付款，支付平台向商城发起申请，商城审核后通过支付网关的延期通知接口通知支付平台将订单延期，报文要素同支付网关的延期通知接口。

若付款方已收货，可通过企业会员系统进行确认收货，支付平台向商城发起确认收货通知，商城收到通知，同步返回成功，若商城未收到通知可自行查询订单状态。

4）自动服务：

目前系统为全额结算和扎差结算两种方式，对于担保支付商户仍采用系统原有处理方式，进行全额结算时只记录手续费，对于扎差结算则收取该结算周期内订单产生的手续费，结算产生的手续费计入手续费收入科目。

如果付款方截至默认付款期结束仍未进行确认收货，系统会按付款方默认收货处理，并通知商城，付款方已收货。

延期付款通过：

如果收款方截至默认付款期结束仍未对付款方提出延期付款申请的订单进行处理，系统会按付收款方默认延期付款申请通过处理。

对于已收货的订单，系统在该笔订单的退款保障期结束后会自动将收款方XXX账户的货款解冻，解冻后收款方可做它用，对于商户实体账户中的收付款双方手续费收入同时解冻。

对于已经支付成功的订单支付平台一般会实时通知商城支付结果，若由于网络原因导致通知发送失败，自动服务会重新发送支付结果通知。

5）内部管理系统：

个人退款审核：

由于担保支付退款是由商城进行最终裁定，因此需屏蔽个人退款审核中担保支付订单的退款申请审核。

企业退款审核：

由于担保支付退款是由商城进行最终裁定，因此需屏蔽企业退款审核中担保支付订单的退款申请审核。

退款文件下载：

支付平台处理担保支付的退款是根据商城的退款结果操作，且资金是由担保在途账户或者收款方XXX账户划回到付款方XXX账户，因此不需要下载退款文件。

。

6）商户服务系统：

延期请求管理：

由于是否延期是商城进行裁定，并将结果通过接口的方式通知支付平台，商户服务系统中的延期请求管理保留，整改为在商城和支付平台网络不稳定时手动触发延期申请处理的应急方式，非特殊情况，不推荐商城采用此方式，由商户服务系统触发的延期由商城自行承担相应的责任。

退款请求管理：

由于退款是商城发起，并将退款结果通过接口的方式通知支付平台，商户服务系统中的退款请求管理保留，整改为在商城和支付平台网络不稳定时手动触发退款的应急方式，非特殊情况，不推荐商城采用此方式，由商户服务系统触发的退款由商城自行承担相应的责任。

发货管理：

由于发货是商城发起，并通过接口的方式通知支付平台，商户服务系统中的发货管理保留，整改为在商城和支付平台网络不稳定时手动触发发货的应急方式，非特殊情况，不推荐商城采用此方式，由商户服务系统触发的发货由商城自行承担相应的责任。

退款查询：

区分担保支付订单和普通订单，担保支付订单状态显示问题。

退款管理：

屏蔽担保支付订单退款功能，退款请求补发功能在退款请求管理中实现。

2.接口设计

接口设计标准遵循系统现有接口对开发标准，支付请求以组装表单的方式发送至XX支付平台，参数名称与参数值大小写敏感。

报文格式如下表所示：

字段名称

字段命名

说明

接口名称

interfaceName

详见组件说明interfaceName

版本号

version

详见组件说明version

交易数据

tranData

详见详细接口交易数据定义

签名数据

merSignMsg

详见组件说明merSignMsg

商户代码

merchantId

详见组件说明merchantId

1）支付接口：

tranData交易数据格式定义：

域名称

域定义

订单号

orderNo

详见orderNo

订单金额

orderAmt

详见orderAmt

商户前台通知URL

returnUrl

详见returnUrl

商户后台通知URL

notifyUrl

详见notifyUrl

收款账户

receiveAcc

详见receiveAcc

收款方手续费金额

payFeeAmt

详见payFeeAmt

付款方手续费金额

recFeeAmt

详见recFeeAmt

币种

curType

详见curType

商品名称

goodsName

详见goodsName

预留域

backup

详见backup

2）支付结果通知接口：

支付流水号

payFlowNo

详见payFlowNo

支付成功时间

succTime

详见succTime

订单状态

orderState

详见orderState

3）订单状态查询接口：

tranData交易数据定义：

4）发货接口：

请求tranData交易数据格式定义：

物流公司名称

logisticsName

详见logisticsName

物流单号

logisticsOrderNo

详见logisticsOrderNo

物流类型

logisticsType

详见logisticsType

发货时间

dispatchTime

详见dispatchTime

响应tranData交易数据格式定义：

响应码

returnCode

详见returnCode

响应信息

returnMess

详见returnMess

5）退款接口：

退款金额

refundAmt

详见refundAmt

6）延期接口：

延期原因

delayReason

详见delayReason

状态码：

40

7）确认收货接口：

8）延期确认接口：

41

响应tranData交易数据格式定