建设银行约惠安徽的订单怎么取消 你可以带着你的身份证银行卡去他们的建设银行柜台,然后让他们的工作人员帮你直接取消订单就可以了千万不要自己私下操作,鈳能会导致一些错误 中国建设银行(简称建设银行或建行,最初行名为中国人民建设银行1996年3月26日更名为中国建设银行)成立于1954年(甲午姩)10月1日,是股份制商业银行是国有五大商业银行之一。中国建设银行主要经营领域包括公司银行业务、个人银行业务和资金业务 |
摘要: 支付产品模块是按照支付場景来为业务方提供支付服务这个模块一般位于支付网关之后,支付渠道之前 它根据支付能力将不同的支付渠道封装成统一的接口,通过支付网关来对外提供服务所以,从微服务的角度支付产品本身也是一个代理模式的微服务,它透过支付网关响应业务方请求 进荇一些统一处理后,分发到不同的支付渠道去执行最后将执行结果做处理后,通过支付网关再回传给业务方
支付产品模块是按照支付場景来为业务方提供支付服务。这个模块一般位于支付网关之后支付渠道之前。 它根据支付能力将不同的支付渠道封装成统一的接口通过支付网关来对外提供服务。所以从微服务的角度,支付产品本身也是一个代理模式的微服务它透过支付网关响应业务方请求, 进荇一些统一处理后分发到不同的支付渠道去执行,最后将执行结果做处理后通过支付网关再回传给业务方。
支付产品在支付系统参考架构图中之位置请看下图所示:
在不同的公司由于接入渠道和应用的差异,对支付产品分类略有不同综合支付场景和流程,支付产品可以分为如下几类:
支付产品是由支付系统对支付渠道进行封装而对业务方提供的支付能力整体上来说,可以提供如下支付产品:
用户在完成绑卡之后在支付的时候,不需要再输入卡或者身份信息仅需要输入支付密码就可以完成支付。对于小额度的支付甚至可以开通小额免密,直接完成支付 这种支付方式不会打断用户的体验,是目前主要的在线支付方式一般快捷支付产品是通過封装银行或者第三方支付平台提供的快捷支付接口或者代付接口来实现的。
用户在支付的时候需要跳转到银行网银页面来完荿支付。在网银页面需要输入用户的卡号和身份信息。这种支付方式会中断用户当前的体验一般仅用于PC Web上的支付。 网银支付是封装银荇提供的网银支付来实现
协议支付也称代收或者代扣,代收指渠道授权商户可以从用户的银行账户中扣款一般用于定期扣款,不用于日常消费比如水电煤气、有线电视费。协议支付是通过封装银行、第三方支付提供的代扣或者快捷接口来实现
使用微信、支付宝等第三方支付平台来完成支付。使用时一般需要用户预先安装支付平台系统(手机上),注册并登录到第三方支付平台並且已经在该平台上完成绑卡等操作。 由于微信、支付宝已经被大量使用用户也产生对这些平台的信任,平台支付往往是电商公司的主偠支付方式
对于由海外支付的需求,还需要提供外卡支付支持 国内不少支付渠道都能支持外卡支付,如支付宝全球购等直接对接Paypal,也是目前用的最多的外卡支付渠道 关于外卡支付,以后会有专文介绍
对于有包月小额类型的支付,手机话费也是一個不错的选择目前也有一些平台可以支持话费支付,比如虹软、联动优势等
不少公司会有自己的虚拟币,比如京豆、Q币等這些虚币也可以作为一种支付方式。
也成为余额支付、零钱支付等 指为用户建立本地账户, 支持充值之后可以使用这个账户來完成支付。
如京东的白条蚂蚁花呗等,指使用信用账户进行透支类似信用卡支付。
和代扣相反代付是平台将钱打给鼡户。
每一种支付方式的详细功能将在后续的各个章节中介绍 这里先简要介绍支付产品模块的通用功能。
支出产品根据其支付能力对外提供不同的功能。整体上来说一般支付产品需要提供如下接口:
在快捷支付、代扣等产品中,用户在使用前需偠先完成签约。签约可以在渠道侧进行一般第三方支付采用这种方式,当电商需要接入时让第三方给授权。 银行和银联的签约一般是茬电商侧进行 电商侧负责收集用户的信息,调用银行和银联的接口进行签约签约后,后续的支付行为就使用签约号来进行无需再输叺个人信息。 和签约相对应解约则是取消签约关系。
支付是少不了的操作 不同产品中支付行为不一样。快捷支付是在电商服务器仩发起请求渠道进行支付;网银支付则是跳转到银行支付网关上进行; 而账户支付、虚币支付,则是在本地进行的
有些渠道區分撤销和退款,比如银联、农行等撤销指取消当天在渠道侧未结算的交易; 而退款仅针对已经结算的交易。有些渠道则不作区分
对于需要签约的交易,可以通过这个接口来查询签约状态
通过这个接口来查询支付清单状态以及退款的订单状態。
预授权交易用于受理方向持卡人的发卡方确认交易许可受理方将预估的消费金额作为预授权金额,发送给持卡人的发卡方
对已成功的预授权交易,在结算前使用预授权撤销交易通知发卡方取消付款承诺。预授权撤销交易必须是对原始预授权交易戓追加预授权交易最终承兑金额的全额撤销
对已批准的预授权交易,用预授权完成做支付结算
预授权唍成撤销交易必须是对原始预授权完成交易的全额撤销。预授权完成撤销后的预授权仍然有效
通过FTP或者HTTP方式提供对账文件供商户侧對账。
查询商户的交易账户的余额避免由于余额不足导致交易失败。 注意不是客户的余额。 当然不是所有的银行或者第三方支付都提供这个接口。
上述操作除了对账、查单外,每个操作实现的主流程一般会包括参数校验,支付路由生成订单,風险评估调用渠道服务,更新订单和发送消息这7步对于一些比较复杂的服务,还会涉及到异步同通知处理的步骤
所有嘚支付操作,都需要对输入执行参数校验避免接口受到攻击。
验证输入参数中各字段的有效性验证比如用户ID,商户ID,价格,返回地址等参數
验证账户状态。交易主体、交易对手等账户的状态是处于可交易的状态
验证订单:如果涉及到预单,还需要验证订单号的有效性訂单状态是未支付。为了避免用户缓存某个URL地址还需要校验下单时间和支付时间是否超过预定的间隔。
验证签名签名也是为了防止支付接口被伪造。 一般签名是使用分发给商户的key来对输入参数拼接成的字符串做MD5 Hash或者RSA加密然后作为一个参数随其他参数一起提交到服务器端。如支付网关设计所介绍签名验证也可以在网关中统一完成。
根據用户选择的支付方式确定用来完成该操作的合适的支付渠道用户指定的支付方式不一定是最终的执行支付的渠道。比如用户选择通过笁行信用卡来执行支付但是我们没有实现和工行的对接,而是可以通过第三方支付比如支付宝、微信支付、易宝支付,或者银联来完荿那如何选择合适的支付渠道,就通过支付路由来实现支付路由会综合考虑收费、渠道的可用性等因素来选择最优方案。
检查本次交易是否有风险风控接口返回三种结果:阻断交易、增强验证和放行交易。
1) 阻断交易说明该交易是高风险的,需要终止鈈执行第5个步骤;
2) 增强验证,说明该交易有一定的风险需要确认下是不是用户本人在操作。这可以通过发送短信验证码或者其他可以验證用户身份的方式来做校验验证通过后,可以继续执行该交易
3) 放行交易,即本次交易是安全的可以继续往下走。
将订單信息持久化到数据库中当访问压力大的时候,数据库写入会成为一个瓶颈
所有的支付服务都需要第三方通道来完成执行。一般银行渠道的调用比较简单可以直接返回结果。一些第三方支付支付宝,微信支付等会通过异步接口来告知支付结果。
对于同步返回的结果需要在主线程中更新订单的状态,标记是支付成功还是失败对于异步返囙的渠道,需要在异步程序中处理
通过消息来通知相关系统关于订单的变更。风控信用BI等,都需要依赖这数据做准实时计算
如上述流程,其中涉及到调用远程接口其延迟不可控。如果调用方一直阻塞等待很容易超时。引入异步通知机制可以让調用方在主线程中尽快返回,通过异步线程来得到支付结果对于通过异步来获取支付结果的渠道接口,也需要对应的在异步通知中将结果返回给调用方 异步通知需要调用方提供一个回调地址,一般以http或者https的方式这就有技术风险,如果调用失败还需要重试。而重试不能过于频繁需要逐步拉大每一次重试的时间间隔。 在异步处理程序中订单根据处理结果变更状态后,也要发消息通知相关系统
每个公司根据其业务和公司发展的不同阶段,所设计的支付系统也会有所不同我们先看看互联网公司的一些典型的支付系统架构。
我們先看看业内最强的支付宝系统架构图如下:
这个整体架构上并没有与众不同之处。在模块划分上这个图显示的是最顶层的划分,也無法告知更多细节 但支付宝架构文档有两个搞支付平台设计的人必须仔细揣摩的要点。 一个是账务处理在记账方面,涉及到内外两个孓系统外部子系统是单边账,满足线上性能需求;内部子系统走复式记账满足财务需求。在清结算这个章节中也是基于这个模型来详細介绍如何记账、对账和平账
另一个亮点是柔性事务处理,利用消息机制来实现跨系统的事务处理避免数据库锁导致的性能问题。
来自京东支付平台总体架构设计 如下图:
京东金融是在网银在线的基础上发展起来的。 网银在线的原班技术人员有不少来自易宝公司在京东收购之后,又引入了支付宝的人才
因而从架构上受这两个公司的影响很大。
这是来自去哪儿公司分享的支付产品架構请看下图:
来自美团的支付平台规划架构 。这是2015年的文档 2016年美团才拿到支付牌照。 从这个架构大家也能知道為什么美团必须拿到支付牌照。
这些架构文档全部来自互联网公开资料 对于架构是否真实反映实际系统情况,需要大家自行判断 我们鉯这些文档为基础,分析支付系统的应有的软件架构
一般来说,支付系统典型架构会包含如下模块:
支付系统从架构上来说汾为三层;
支撑系统是一个公司提供给支付系统运行的基础设施。 主要包括如下子系统:
支付核心系统指用户执行支付的核心流程,包括:
用户从支付应用启动支付流程
支付应用根据应用和用户选择的支付工具来调用对应的支付产品来执行支付。
支付路由根据支付工具、渠道费率、接口稳定性等因素选择合适的支付渠道来落地支付
支付渠道调用银行、第三方支付等渠道提供的接口来执行支付操作,最终落地资金轉移
支持支付核心系统所提供的功能。服务系统又分为基础服务系统、资金系统、风控和信用系统
客户信息管理:包括对用户、商户的实名身份、基本信息、协议的管理;
卡券管理: 对优惠券、代金券、折扣券的制作、发放、使用流程的管理;
支付通道管理: 通道接口、配置参數、费用、限额以及QOS的管理;
账户和账务系统: 管理账户信息以及交易流水、记账凭证等。这里的账务一般指对接线上系统的账务采用單边账的记账方式。 内部账记录在会计核算系统中
订单系统: 一般订单系统可以独立于业务系统来实现的。这里的订单主要指支付订單。
会计核算: 提供会计科目、内部账务、试算平衡、日切、流水登记、核算和归档的功能。
资金管理: 管理公司在各个支付渠道的头寸在余额不足时进行打款。 对第三方支付公司还需要对备付金进行管理。
清算分润: 对于有分润需求的业务还需要提供清汾清算、对账处理和计费分润功能。
风控系统是支付系统必备的基础功能所有的支付行为必须做风险评估并采取对应的措施;信用系统昰在风控基础上发展的高级功能,京东的白条蚂蚁花呗等,都是成功的案例
支撑系统、核心系统和服务系统,在每个互联网公司的架构上都是大同小异的都是必不可少的模块。而支付应用是每个公司根据自己的业务来构建的各不相同。
总体来说可以按照使用对象分为针对最终用户的应用、针对商户的应用、针对运营人员的运营管理、BI和风控后台。