您的位置:新浦京赌场娱乐场 > 互联网技术 > 支付交易一般性准则

支付交易一般性准则

2019-05-06 08:01

收单网关是平台方支付系统和用户/商户的PC、移动APP所使用的外部网络之间的接口,为支付系统操作将外网传输的数据转换为系统内部数据,同时负责将平台业务系统的内部请求转化为支付系统的内部数据。

一旦同步处理失败,那么能以某种策略重播这个消息,直到业务系统恢复正常、处理完毕为止。

业务系统和支付系统之间通过 https 协议来进行通信,接口以 URL 的形式提供并以 post 的请求方式进行处理;文档的接口包括两种:服务接口和通知接口;服务接口由支付系统提供,供业务方调用;通知接口由业务方提供,供支付系统调用;虽然通知接口由业务方提供,但是仍由支付系统制定接口规范;服务接口包括接口说明中的所有接口信息,通知接口目前仅包括交易状态和退款状态的通知等。接口设计说明

 

构造请求信息:业务系统根据支付系统提供的接口规则构造请求信息,例如支付下单、取消订单、退款等等;发送请求信息:把构造好的信息发送到指定的地址;处理请求信息:支付系统会得到请求的数据信息,按照预定的验签,业务参数校验等一系列验证通过后,将请求的数据信息对业务(对应支付、取消、充值等等)进行处理;返回响应信息:支付系统会以同步和异步两种处理方式,返回业务数据处理结果;一般情况下,同步通知仅代表请求处理成功,业务订单处理状态会以异步通知的形式主动回调用户在下单的时候设置的异步回调地址,通知业务方时若得不到业务方的响应信息值「success」,支付系统会重复若干次(按照一定的频次配置),以防止掉单现象;若业务方户不设置,则不会通知;业务系统收到异步通知后,结合自身的业务规则改变支付单状态,进行如订单状态更新等业务处理。

四. 正常支付流程的两个要点

收单网关

 

②流程

电商业务容易出现以下问题:

业务平台充值支付平台充值例如,在用户感知层面,早期的支付宝与淘宝不分你我,支付宝像是为淘宝定制的专属钱包,但实际上用户在支付宝充值的余额与淘宝业务并无关联;而腾讯的虚拟货币 Q 币则是由业务端发起的交易,因此与业务平台具有强关联性。因此基于支付平台的两种做法,一种是基于支付平台的账户做充值,另一种是基于业务平台做充值。

  • 第三方支付平台可能同一时刻给你的 pay.5xxxxn.com 交易中心集群服务推送过来两个一模一样的支付成功通知。
  • 用户浏览器可能安装了某种插件(如早期的迅雷插件),插件本身为了探测 一个URL 是否是BT资源,会同时模拟发起一个 HTTP GET 请求。
  • 上游服务不可控,不可预知地向发起下游服务发起并发请求。

收单网关

收单网关的设计要素包含:业务方、用户、业务系统、支付系统。

下面举两个小例子:

收单网关设计要素包含:

枚举名称
枚举说明
TRADE_CLOSED
  • 在指定时间段内未支付时关闭的交易;
  • 在交易完成全额退款成功时关闭的交易。

收单网关流程

3.3. 来自于多个支付渠道的重复支付

例如,早期支付宝 PC 端的即时到账产品,用户通过 PC 网银即时到账产品付款后,单笔交易即时结算到了商户的平台账户中,由此可得:

例一:

图片 1

因为,有可能补录数据已跨日或跨月,前一日的结算清单可能已计算完毕,如果按前者的逻辑,突然又补录一条记录,结果前一日(上一个月)也不结算它,后一日(下一个月)也不结算,那这个订单就漏结算了。

图片 2

 

①担保交易:用户在业务平台中选择某商家的商品进行购买,支付完成后该笔订单资金进入平台的担保账户,等到用户确认收货后,将该笔订单的资金结算给对应商家账户;此交易类型也可以适用于一些具备结算周期等时间属性的业务当中,通过网关的担保收单接口和结算接口做到由业务方灵活控制结算账期。

3.1. 掉单的被动处理

图片 3

这个所谓退款处理结束通知,实际上仍是一个“trade_status_sync(交易状态同步)”通知,特殊性在于携带的 refund_stauts =REFUND_SUCCESS 参数,实际例子如下所示:

首先定义充值产品的产品代码;业务端充值:此类产品虚币账户体系独立于支付系统;充值和虚拟币的消费业务端完全闭环,由支付系统内部针对该充值业务开设一个统一的收款账户,结算时通过支付系统提供的入账记资金分润,适用于直播、视频等纯互联网虚拟业务;接口定义:下单支付接口;优势:开发成本低,实现起来相对简单、可快速实现业务;劣势:账务不清晰,流程不统一、有一定资金风险。支付系统充值:通过支付系统账户体系实现,所有充值资金通过钱包收银台或支付系统的充值网关接口实现;钱包收银台:充值行为发生在支付系统体系内(参考前文中讲到的支付宝逻辑)且独立于业务平台。原则上当公司业务规模扩大,不同的 App 统一接入支付系统时,独立的钱包账户余额应可同时支持不同业务的账户支付需求。例如,美团账户余额充值的资金同时适用于美团外卖、点评等,此时美团的钱包已经是拥有独立账户体系的产品,接入各业务平台仅需不同业务端识别用户的唯一标识即可;充值网关接口:针对于业务方发起的充值行为,各个业务平台自己本身具备充值业务需要支付体系的账户能力提供支持。通过网关充值且可以满足各个业务方不同账户类型的诉求,需要每个业务方在用户发起充值时,充值至用户在此业务下开设的对应虚拟账户,例如 B 站的 B 币、金瓜子等,就来源于不同的业务方开设的不同虚币账户;接口定义:充值接口(账户类型、uid、金额、支付方式等);优势:资金账户清晰、流程标准化、所有支付、账户由支付系统控制,资金安全有一定保证;劣势:开发成本高,实现起来相对复杂。出款交易

支付系统宕机,一段时间后才恢复,此时客服主动处理顾客投诉掉单的订单,从第三方支付查到已支付后,将订单置为已付款。那么,该订单的支付时间怎么记呢?

接口定义

3)网银直连的订单是关闭不了的,因为它没有跟支付宝账户绑定。

收单网关的设计要素包含:业务方、用户、业务系统、支付系统。

『顾客购买××团的商品后,第一次付款时,由于付款故障(如系统掉单),使得顾客认为付款未成功,所以,顾客换用了其他支付渠道(如选择支付宝的网银直连,或者选择网银在线)进行了第二次付款,于是××团帐号收到两笔付款,且两笔付款均付款成功。』

将支付系统的支付能力抽象出来,提供各类交易方式,例如下单、支付、修改金额、确认结算、退款、关闭交易、查询等标准接口,对外输出收单网关;基于收付款方的交易链业务路抽象交易类型、交易产品以满足不同业务方各类交易场景的需求;鉴权校验、交易结果通知;对接业务方。担保收单交易

这不是偶然现象。

支付系统:支付清结算平台。

触发条件名
触发条件默认值
退款处理结束
true(触发通知)

a.退款状态:退款订单的状态;

 

定义产品码,可以拆分为出款到卡和出款到账户等不同的产品,针对 B 端商户的提现交易记录,原则上最好单独用表单显示;按照流程图所示,提现时首选要做好余额校验动作;

 

退款成功退款失败交易服务 交易服务的作用

 

图片 4

 

收单网关的职责为支付平台化后,系统内部接口不可对外,因此所有外部系统需要通过统一的网关接口调用支付平台;由网关进行一系列格式校验、参数校验、业务调用权限检查后再向支付进行转发。

对于××团发起的到第三方支付的交易请求。我们有 jxxxe_pay_log 记录;

定义担保交易产品代码,标识此类交易订单的类型。担保交易分为下单支付和结算两个环节:

A:系统可能对关键记录做了一系列修改,甚至有程序在某个时间段内误写引入了脏数据,但郑昀提示您,我们依然要能从各种操作日志表中随时倒推回历史某一个时刻的快照,一是确保随时能安全地把数据还原回去,二是管理平台可以清晰地展示出由谁引发、怎么变化的历史,三是便于排查问题。

充值交易即用户对账户余额进行充值,一般运用于充值虚拟币、钱包余额等产品。用户对账户余额进行充值,一般运用于充值虚拟币、钱包等产品,首先需要对充值的两种做法做一个区分。

a.交易状态:交易订单的状态;

譬如,对于记录了订单信息的 order_info 表,会员如果点击使用账户余额支付了订单的应付金额,那么该订单操作日志表就会做如下记录,原订单记录的重要字段(what)在什么时候(when)从什么变为了什么(how),都会详细记录。

基本请求接口:所有请求接口都要加上基本请求参数,例如接口名称、版本、App ID、签名、签名方式、同步跳转地址等关键信息,当发起调用时,所有业务接口都会加上该接口参数,可参考支付宝和微信等第三方支付公司的接口参数定义。服务请求接口:根据支付系统本身的能力抽象出的业务接口,给到外部业务方进行调用。即时到账交易网关接口:买家在业务系统中选择购买商品下单,付款成功后金额直接入卖家账户。担保交易网关接口:买家在业务系统中选择购买商品下单,有部分金额为担保金额,买家付款成功后,担保部分进入平台方账户,未担保金额直接入卖家账户。结算网关接口:买家使用担保交易下单付款完成,在收到货物后,将担保金额结算给卖家。继续支付网关接口:买家在支付页面未成功支付,需要在业务系统中继续支付时,调用该接口。退款网关接口:买卖双方在达成退款协议后,可针对及时到账交易,订金下定等已支付交易 由业务系统发起退款请求。交易查询网关接口:因为某一方原因, 可能导致业务方在预期时间内都收不到最终支付通知, 此时业务方可以通过该接口来查询订单的详细支付状态。通知接口:根据业务方提供的通知地址,将支付结果等信息返回给业务方①交易状态变更通知:通知业务方时,接口信息里面会传递业务订单号、交易订单号、状态、金额、时间等相关信息,以便业务方能更好的做业务处理;

请提前调用 支付宝交易信息敏感词分析接口(fast_text_trade) ,在录入信息时就阻止保存。

业务系统:业务端的业务系统;

 

图片 5

注意几个要点:

收单网关的职责为支付平台化后,系统内部接口不可对外,因此所有外部系统需要通过统一的网关接口调用支付平台;由网关进行一系列格式校验、参数校验、业务调用权限检查后再向支付进行转发。

电商的支付子系统提供一个 Web Service,来接收各家第三方支付的各种异步通知。

①流程

 

②充值交易的设计要点:

  • 支付子系统是一个独立工程,独立部署,有单独的二级域名。

②出款交易的设计要点:

接收对方通知之后,你可能会遭遇各种异常,如:

③担保交易设计

 

收单网关是平台方支付系统和用户/商户的PC、移动APP所使用的外部网络之间的接口,为支付系统操作将外网传输的数据转换为系统内部数据,同时负责将平台业务系统的内部请求转化为支付系统的内部数据。

4)商户如发现交易已关闭的订单被用户支付后,那么必须进入异常支付流程(能原路退返就退,如无法退返则返还至账户余额)。

②即时到账的设计要点:

 

出款也称之为提现。用户基于自己账户余额发起提现,一般电商平台涉及到的场景为 C端用户的钱包账户余额提现和B端用户收益账户的余额提现,是将资金从平台的虚币账户转移用户外部账户的过程。具体分类可分为出款到卡及出款到账户。

这里的“直接修改”特指,没有把变更行为记录到日志表里,而是直接在原始记录上 update 甚至 delete ,这种“篡改”和“毁尸灭迹”是明文禁止的,即使留下了文件类型日志也是不允许的。

图片 6

图片 7

若支付宝不垫资,则即时到账底层包装接口的银行为 T 0 给到支付宝;若支付宝垫资,则银行资金未结算前,支付宝将备付金账户中的存量资金为商户的平台账户进行结算。即时到账交易与业务场景息息相关,在某些非担保流程中,若用户付款后需要立马进行履约的情况,则适合即时到账产品,例如各平台的会员产品购买场景。


业务方:指业务平台。可根据公司业务规模大小、业务领域或公司主体等维度,对对接的业务方进行区分,接入后这些业务方即成为支付平台的收单商户,使用平台支付产品实现其收付费功能需求;

2.1. 交易关闭通知的处理

图片 8

所以不同业务之间必须严格隔离,防止一个业务超负荷或宕机连累其他业务。

即时到账交易即用户在平台上选择商品购买并支付,付款的资金立马结算到商家的收款账户中。

第一,要修改这些记录的关键字段时,必须在相关日志表里保留变更日志,并记录操作人和发起人,一定要确保历史可回溯。

定义担保交易产品代码,标识此类交易订单的类型;和担保收单的区别,在于即时到账产品没有单独的结算环节;在下单的时候,接口参数里包含分润参数,当交易发起时就需要业务方算出该笔订单分润收款主题数、确定好用户的 UID、账户类型、金额等参数;分润原则:先收钱再分钱且收到金额 ≥ 分润总金额,即先入后出、收大于等于付。充值交易

第二,严禁对记录做物理删除,只能是软删除。

用户:业务平台 C 端用户,可根据业务方进行划分;

 

出款到账户:目前常见的场景为用户发起提现到支付宝或者微信账户,接入支付宝微信等第三方支付公司的付款产品即可满足此需求,业务端需做好用户端的第三方账号信息采集,用户发起提现的时将账户等相关信息上传至第三方等待出款结果即可;根据业务模式,针对 B 端商户提现时,优先做实名认证再发起提现,且发起提现的账户信息和实名认证信息一致为佳,再根据业务端需求判断是否有针对 C 端用户做实名认证处理的必要;出款到卡:和付款到账户的主流程没有太大区别,但一般情况下需要商户端采集用户银行卡信息,因此需要将支付系统中存储银行卡相关的数据(卡 Bin 信息、城市、省份等),并对业务 端提供绑定、查询等接口为佳,这样用户前端绑卡时无论是卡 Bin 接口验证,还是前端做选择输入银行都能拥有较好的体验。*提现到银行卡需要接入对应的银行卡出款渠道。《支付系统设计白皮书》由 PingPlusPlus支付学院出品。

掉单后,等待支付宝补发通知给你,商户可能来不及应对汹涌而来的顾客投诉。

等待买家付款付款成功交易成功交易结束交易关闭②退款状态变更通知:通知业务方时,接口信息里面会传递原始业务订单号、退款业务订单号、退款交易订单号、状态、金额、时间等相关信息,以便业务方能更好的做业务处理;

处理办法还是:按时间顺序,稍晚一些的付款被认为是重复支付,进入异常支付流程(能原路退返就退,如无法退返则返还至账户余额)。

①流程

支付宝是这么定义“交易关闭”的:

第一个环节为下单环节,交易参与双方当中付款人是用户,收款人则是平台在支付系统内部开设的一个担保账户,担保账户属于内部的一个结算过渡户,代表着这钱是要给出去的,时候时候给出去基于业务方的指令来决定。第二个环节在发起结算的时候,确认之前这笔担保交易订单需要和商户进行最终结算,此时基于业务方调用结算接口,交易参与双方当中新增两条收付款人记录,付款人为担保账户,收款人为该笔订单的商户;最终资金以内部户转账的形式将担保账户中该笔订单资金,转给实际收款的商户账户。即时到账交易

原因也很简单:

①流程

图片 9  

电商结算和对账,由于帐期定义(如日清日结,如T 2结算,如销售佣金计算,如CPS联盟结算),非常依赖于数据记录的时间。

支付宝收到这个参数后,界面会有如下展示:

 

触发条件名
触发条件描述
触发条件默认值
TRADE_CLOSED
交易关闭
false(不触发通知)

团购商户为了避免超卖,应该

1.2. 对关键资源的操作,当接口保证不了幂等性时,必须能防并发

交易关闭通知默认是不发送的,如下表格所示:

 

一是,采信第三方支付系统传递的真实支付时间。二是,记录为手动重置的当前时间。

例二:

如果你的接口不具备幂等性,那么请保证整个(分布式)系统内对一个重要事物(订单,账户的资金变动等)的有效操作线程,同一时间内有且只有一个。

Q:什么叫历史可回溯?

实例:

即时到帐交易接口中有这么一个参数:

1)如果交易已经关闭,但商户的网站上仍保留了订单的“付款”按钮,那么点击跳转到支付宝后,会看到如下警告信息:

但如果商户(也就是你的网站)向支付宝申请打开了该配置,那么请注意接收 TRADE_CLOSED 通知,它会对你的核心购买逻辑产生影响。

当然,真实支付时间也还是要记录到日志表的。

(具体细节请看支付宝的《单笔交易查询接口(single_trade_query).pdf》)

所以,郑昀提醒您,你应该主动地、积极地先把对方的(支付成功、退款处理等)通知存入一个存储介质,如消息队列;

图片 10  

 

所以,当由于以下原因补录或同步数据时,请慎重考虑数据的时间字段到底如何采信:

因为这样的话,相当于你的业务完全依赖于第三方支付下一次重试了。

本文由新浦京赌场娱乐场发布于互联网技术,转载请注明出处:支付交易一般性准则

关键词: