担保支付解决方案.doc

上传人:b****1 文档编号:238214 上传时间:2022-10-07 格式:DOC 页数:19 大小:221.50KB
下载 相关 举报
担保支付解决方案.doc_第1页
第1页 / 共19页
担保支付解决方案.doc_第2页
第2页 / 共19页
担保支付解决方案.doc_第3页
第3页 / 共19页
担保支付解决方案.doc_第4页
第4页 / 共19页
担保支付解决方案.doc_第5页
第5页 / 共19页
点击查看更多>>
下载资源
资源描述

担保支付解决方案.doc

《担保支付解决方案.doc》由会员分享,可在线阅读,更多相关《担保支付解决方案.doc(19页珍藏版)》请在冰豆网上搜索。

担保支付解决方案.doc

北京锐融天下信息技术有限公司

担保支付解决方案

目录

第一章概述 3

1. 项目背景 3

第二章需求描述及分析 3

1. 需求描述 3

2. 需求分析 4

第三章总体设计 5

1. 总体设计目标 5

2. 总体设计原则 6

3. 总体逻辑架构设计 6

第四章详细设计 7

1. 功能设计 7

2. 接口设计 11

3. 组件说明 14

文档修订记录

版本

状态

简要说明

修订

日期

人员

说明:

1.版本栏中填入版本编号或者更改记录编号。

2.状态分为三种状态:

A——增加;M——修改;D——删除。

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账户。

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

Ø延期通知接收:

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

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

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

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 幼儿教育 > 唐诗宋词

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1