支付平台系统方案.ppt

上传人:boatfragile160 文档编号:366951 上传时间:2018-09-26 格式:PPT 页数:34 大小:3.83MB
下载 相关 举报
支付平台系统方案.ppt_第1页
第1页 / 共34页
支付平台系统方案.ppt_第2页
第2页 / 共34页
支付平台系统方案.ppt_第3页
第3页 / 共34页
支付平台系统方案.ppt_第4页
第4页 / 共34页
支付平台系统方案.ppt_第5页
第5页 / 共34页
亲,该文档总共34页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述

1、支付平台系统方案,雷敏 2009年2月,目录,支付平台的建设原则 支付平台系统结构 支付平台涉及的系统 支付平台引起交易流程变化 各个系统的分工界面及相关原则 支付的路线图 2.5G以上客户端接入系统结构,支付平台建设的原则,业务与支付分离,支付与业务相对独立。 用户直接与支付平台接触,不论是通过2.5G以上客户端还是2G以下客户应用。 对账由支付网关统一负责出具基础账务信息。,支付系统结构-功能,账户系统,对账系统,结算系统,支付平台,开户,通道,功能,扣款,冲正,撤销,退货,充值,提现,转账,计费,记账,调账,嗖付,全网话费,小额话费,手机钱包,网银,移动积分,银行对账,商户对账,机构对账

2、,查询,记账,调账,查询,中间业务层,商品逻辑判断,向商户下订单,获取货物信息,2.5G以上客户端,向用户发货,2G以下客户端,预授权,订单支付,特色业务,用户请求购物,通道,WEB,WAP,KJAVA,通道,SMS,IVR,USSD,功能,支付请求,确认支付,信息校验,银行列表,冲正请求,撤销请求,退货请求,查询请求,充值,提现,转账,确认支付,银行结算,商户结算,机构结算,通知商户逻辑,支付结果通知,向商户请求下订单,支付系统结构-逻辑,支付平台涉及到的系统,2.5G以上客户端接入层:WEB、WAP、KJAVA等 2G以下客户端接入层:SMS、IVR、USSD等 接入逻辑层:EJB(JBO

3、SS)、商户接入前置(APPlication) 中间业务层:话费业务服务、异步充值计费服务、话费续费服务、银行卡业务服务 支付逻辑层:支付网关、账户系统 外围支撑系统:用户自服务、用户受理、商户自服务、对账系统、结算退费系统,支付平台涉及到的系统,支付管理服务 支付鉴权 风控控制 签名、验签等 支付平台/网银平台 支付 冲正 退款 嗖付账户子系统 账户账务功能 转账 提现 余额查询 明细查询,支付平台涉及到的系统,银行卡前置 银联 直连银行网银前置 银联 直连银行 第三方支付(IPS) 嗖付前置小额前置 各移动小额前置,支付平台架构图,支付平台架构图-业务系统,业务系统 支付业务子系统 嗖付业

4、务子系统 商户通知子系统 支付业务子系统 标准订单支付 商品订购系统 微支付 嗖付业务子系统 转账 提现 余额查询 明细查询 通知商户子系统 通知商户支付结果,支付业务系统结构图,支付平台辅助系统,重复通知商户服务 重复通知商户交易结果 查询银行掉单服务 目前只有网银掉单查询服务 按业务类型扩充掉单查询服务 自服务系统 商户自服务 用户自服务 支付服务接入系统 Web支付服务 Wap支付服务 客户端支付服务,支付平台清结算系统,对账 支付与银行对账 支付与业务对账 业务与商户对账 清算 平台与银行清算 平台与商户清算 差错处理 差错补记 差错退款,支付平台运营支撑系统,财务系统 结算、转账、运

5、营报表。 客服系统 交易查询 投诉处理 平台管理 权限管理 基本信息管理 短信模板管理 参数配置 监控系统 异常监控 交易监控 系统监控,支付平台引起交易和处理流程变化,交易流程变化 业务系统完成订单处理后,向支付网关发起扣费请求 由支付网关向用户发起确认支付 用户确认支付信息首先进入支付网关,支付网关完成扣费通知业务系统扣费结果,业务系统再进行发货处理 支付与业务处理的变化 支付与业务分别有自己的订单表和交易表 用户确认支付后,扣款动作发生前的逻辑判断需要转移到支付网关 业务系统需要接收支付网关的扣款结果通知,然后完成支付结果通知和发货的动作。 接入系统的变化 接入系统不处理核心的订单逻辑,

6、分别由业务系统和支付网关完成。 接入系统不向用户发起离线的支付确认信息。 接入系统是支付接入与业务接入的整合,账户系统,账户系统主要提供用户账户的开通功能,形成客户号与主账号1:1的关系,摒弃原先的客户号-手机号-主账号的关联关系,将客户信息转移到外围管理 账户系统提供记账功能,主要为充值、提现、转账、扣款等功能提供账务处理功能,提供调账功能,主要为差错、冲正、撤销、退货等提供账务处理功能 账户系统提供分期付款的预授权功能,具有资金冻结、解冻等功能 账户系统对外提供账户查询功能。,对账系统,负责完成交易与银行、移动、嗖付的对账。 负责处理完成与银行交易差错。 负责处理标准商户的对账,含有商户直

7、接请求支付网关和业务请求支付网关2部分,非标准的由业务补充对账信息。,支付网关,支付网关提供基础的扣费、冲正、撤销、退货功能。 支付网关为全网话费提供基础的计费功能。 支付网关提供嗖付账户的充值、提现、转账及余额查询功能。 支付网关提供各省BOSS系统用户资料的查询功能。 支付网关提供各个银行的相关用户信息的查询功能。 支付网关为B2B业务提供记账功能。 支付网关涵盖嗖付、手机钱包、全网话费、小额话费、移动积分等支付通道。,中间业务层,负责接收胖客户端和瘦客户端的用户业务请求。 负责商品逻辑的判断和业务系统订单及业务订购关系的处理。 负责向商户下订单和商品、订单金额的确认。 负责向支付网关发送

8、扣款请求。 负责接收支付网关的扣款结果通知。 负责向业务平台接入的商户发送支付结果通知,并向用户发送货物信息,监控整个物流过程。 负责向支付网关发送冲正、撤销请求。 负责接收支付网关的冲正、撤销处理结果通知。 负责向支付网关发送记账请求。,客户端接入逻辑,负责商户、用户身份的认证。 负责向用户展现其可用于支付该商品、订单的支付方式列表。 负责向支付网关或者业务系统分发支付请求。 负责向用户展现订单支付结果。 负责引导用户注册嗖付账户。 负责引导用户返回商户订单系统。 负责接收用户确认支付的信息,并将其加密转交给支付网关。 负责接收商户的冲正、撤销、退货请求,并转交给支付网关,同时接收响应并返回

9、给商户。 负责接收商户的订单支付状态查询请求,并转交给支付网关,同时接收响应并返回给商户。,通知商户逻辑,负责接收支付平台发送给商户的支付结果通知,并将其发送给商户,同时接收响应返回给支付网关。 负责接收业务系统发送给商户的支付结果通知,并将其发送给商户,同时接收响应返回给业务系统。 负责接收业务系统发送给商户的下订单请求,并将其发送给商户,同时接收响应返回给业务系统。,2.5G以上客户端业务流程,业务模式一:合作/自有业务,手机用户通过UMPAY的客户端软件使用UMPAY内置自 有合作业务,进行电子交易.,2.5G以上客户端业务流程,业务流程一,2.5G以上客户端业务流程,业务模式二:支付标

10、准商户接入业务,2.5G以上客户端业务流程,业务模式二:支付标准商户接入业务,此模式下有两种实现方式: 方式一:在支付标准商户接入业务中,支付内容提供商户通 UMPAY终端应用接入平台为用户提供商品或服务等内容资 源,丰富UMPAY终端应用接入平台资源,UMPAY终端应 用接入平台为其提供统一的接入,两个平台通过通讯接口 进行交互。 方式二:在支付标准商户接入业务中,UMPAY终端应用接入平台 给商户提供订单支付功能(用户在商户的客户端中下单, 在UMPAY终端中支付.),2.5G以上客户端业务流程,业务模式二:支付标准商户接入业务,此模式下有两种实现方式的具体实现: 方式一:对于普通商品或服

11、务,支付内容提供方将支付内容预先提供给UMPAY终端应用接入平 台,将商品或服务的信息录入UMPAY终端应用接入平台,这样对于普通商品浏览, UMPAY终端应用接入平台不需要转发至支付内容提供方,对于特殊商品或服务(商品内 容信息较多,变更频繁等),UMPAY终端应用接入平台只存储维护其列表信息(商品或服务 编号,名称,请求转发地址),给客户端提供查看商品或服务列表信息服务(列表信息中每条 记录均包含请求转发内容),将浏览商品详细信息请求发送至支付内容提供方,通过客户端 与支付内容提供方以及UMPAY终端应用接入平台之间的报文交互,完成订购支付流程。 UMPAY支付系统将支付结果,对帐信息通知

12、给UMPAY合作商户,完成对帐清结算。 方式二:UMPAY终端应用接入平台不存储任何商户的商品信息.用户使用商户客户端,在商户系统下订货订单后(注:商户向平台下支付订单),商户客户 端启动(传递订单等参数)UMPAY客户端,用户操作界面完全由UMPAY客户端接管,用户在 UMPAY客户端中完成支付后,提醒用户回到商户客户端取货.,2.5G以上客户端业务流程,业务流程二,方式一: 两步支付:下单+确认支付,2.5G以上客户端业务流程,业务流程二,方式一: 一步支付,2.5G以上客户端业务流程,业务流程二,方式二:,2.5G以上客户端接入系统结构-服务端,2.5G以上客户端接入系统结构-客户端,2

13、.5G以上客户端接入系统安全框架,2.5G以上客户端接入系统安全框架,解决通信过程中的鉴权,数据完整性,数据机密性和不可否认性: 传输安全:SSL/TLS和HTTPS对网络连接进行加密. 数据加密:采用3DES来加密传输的机密数据,RSA算法来加密3DES的密匙. 鉴权:由于私匙与公匙是一一对应的,并且私匙只有用户才能够持有,因此实际上私匙成为了用户的身份的唯一标志,就像一般的用户名/密码一样可以在鉴权过程中识别用户身份. 数据完整性:数据完整性主要是保证内容不被篡改。在数字签名的流程中,接收方在收到签名及其原始消息后,会按照消息原文再生成一次摘要,然后与用公匙解密的摘要进行对比验证. 不可否认性:因为特定的签名信息只能由某个用户通过私匙进行签名,而不能由任何其他人实现,因此用户无法否认经过自己签名的信息. 动态密钥: 3DES数据加密密钥 RSA签名验签密钥时效性,失效需更新,2.5G以上接入应用结构,

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

当前位置:首页 > 办公文档 > 方案计划

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1