详解“预授权”交易及支付

职场   2024-09-09 18:49   天津  
预授权是商家在进行收款时,先冻结用户一定资金作为押金,后续按实际消费金额从用户冻结资金中扣除给商家剩余金额解冻返还用户的一种支付产品
本文主要包括预授权交易相关的定义、应用场景、支付逻等,其中还会夹带一些“私货”,比如单双信息等等。
相信大家可以一口气毫不费劲就看完并能全面理解。

一.关于预授权相关

关于预授权,大家只要住过酒店,如果稍微留意一下的话,应该都会有所听闻。以酒店场景来说,就是在办理入住的时候,酒店前台通常会预先让支付一笔预估消费金额的押金,然后在退房的时候,再根据实际入驻期间的消费从押金中进行扣款,而剩余押金也相应地退还到原先的银行卡中。

这一场景对应背后的支付交易走的通常就是预授权,即酒店先发起一笔预授权交易来冻结指定银行卡里的预估消费金额当作押金,然后在离店的时候再根据实际情况发起一笔预授权完成进行扣款,然后剩余的冻结资金银行会自动返回卡中。

从以上的描述当中,大家可以看到预授权相关的几个交易:

预授权、预授权完成、预授权撤销。实际上可能还有一个预授权完成撤销交易
我们下面再简单一一介绍下各个交易的大概逻辑:

1.1预授权交易

就是商户发起冻结客户银行卡预估金额的交易,该交易发起成功后,如果不发起预授权撤销,一般可以冻结30天(不同场景可能设置不同,但从卡组的规范中一般是最长30天),第31天银行会自动撤销该预授权交易,相应冻结的金额就会释放。

 该交易只是发生了信息流,并不会产生实际的资金结算。

1.2预授权完成交易

针对预授权冻结的金额对应发起的扣款交易,商户可以在30天内根据实际消费情况,发起不超过冻结金额的115%相应金额的预授权完成交易,有些卡组可以发起多笔预授权完成交易,但是不管是单笔还是累计的预授权完成金额都不能超出冻结金额的115%。

该交易会直接产生实际的资金结算,即日终,卡组将会给收单机构和发卡出具清算报表,并完成与各方的资金结算。
另外,关于预授权完成交易,其实还可以再细分为预授权完成(请求)和预授权完成(通知)交易,英文分别称为:Pre-authorization completion(request)和Pre-authorization completion(advice)。
两者的不同点如下:
1)预授权完成(请求)
这个就是我们常见的场景使用的预授权完成交易,一般只支持在线,如果商户发起预授权完成交易请求后发现扣款金额有误,可以再发起预授权完成撤销
2)预授权完成(通知)
这个既支持在线发起也支持离线,但是一旦发起就不能再发起预授权完成撤销了,所以一般卡组的规范要求,针对预授权完成(通知)交易,一旦接收到后,发卡行不能拒绝如果确实要撤销,一般支持通过发起退货交易实现。
1.3预授权撤销

即针对预授权交易的反向交易,商户可以在冻结期30天内任何时间发起预授权撤销交易来撤销原预授权交易。预授权撤销不支持部分撤销

同原预授权交易,预授权撤销也不涉及资金的清算流程。

一旦预授权撤销成功发起,不能再撤销预授权撤销,但是可以发起冲正交易。

1.4预授权完成撤销

即针对预授权完成的撤销交易,只能在预授权完成当天当批次发起,不能跨日发起。

涉及资金的清算流程,类似于消费交易中的当天退货交易。

二.应用场景

一般信用卡和借记卡都支持预授权交易,不过信用卡用得相对多一些。

除上面的酒店场景外,常见的应用场景还包括租车、游轮、医院等,这类传统场景一般可以认为是用预授权的方式实现“押金”的功能。
另外,预授权也常常被一些用来做卡有效性的验证,比如iTunes,在真正支付购买服务前,通常会先发一笔一元的预授权交易来验证对应银行卡的有效性,预授权成功了才能继续支付,在成功后通常iTunes就会发起预授权撤销,解冻该笔预授权交易冻结的一元钱,还有PayPal也是,在绑卡前也会先发一元预授权进行卡有效性验证,预授权交易成功了之后才会继续完成绑卡的后续动作。

既然已经有消费交易,为什么还需要预授权类交易呢?

我们可以从商家和持卡人角度来看。

1)对于商家来说
通常预授权冻结的金额就是押金,可以防止跑路等风险,导致人财两空,而且预先使用了预授权,可以类似于预下单,通常会提高持卡人购买的转化率。
2)而对于持卡人来说
发生预授权时,并没有实际发生扣款,只是冻结了相应的额度,并且只需要一次操作,后续预授权完成或者预授权撤销等交易都无需再去做任何操作,相对简单了许多,而假设酒店场景使用的是消费交易,有可能出现后续一开始支付的款未覆盖或者超出实际消费的情况,还需要持卡人继续进行二次支付或者参与退款等操作,会比较麻烦。

三.支付逻辑

3.1单双信息

在分享预授权相关交易的支付逻辑前,我们先来介绍下两个名词:
单信息(Single Message)和双信息(Dual Message),以及相应的交易流程。

1)单信息

就是一条交易信息搞定全部的信息流和资金流,或者说搞定授权交易和清算(清分和结算),受理方(商户/收单机构)只需要发起一次交易请求,就可以完成授权交易,并在T+1日完成清算流程,收到应收的货款

大家可以看如下的交互图。绿色字体部分是授权交易,红色字体部分为清算流程,无需商户/收单再次发起任何的流程,一次请求就搞定了。

2)双信息

支付层面来看就是一笔交易的完成需要将信息流和资金流分成两次请求完成,即第一次授权交易请求,第二次通过请款文件请求清算获得资金
同样,大家可以看下面的交互图,绿色字体部分都是一样的,都是授权交易,与单信息区别的地方在于清算文件的出具部分(清分),也就是“2.1请款文件”这一步(蓝色字体),需要受理方在授权成功后向卡组提交请款文件,才能触发卡组的清分流程
下面我们将通过基于卡组“四方模式”的系统交互流程图来聊聊预授权相关交易的支付逻辑

3.2 预授权

流程说明:预授权相关交易中,预授权交易是唯一需要持卡人参与的交易,如果是POS交易,需要刷卡或者扫码(一般是被扫)完成验证,而如果是线上交易,一般就直接类似消费一样需要完成安全验证。如果是银联卡,还会收到交易成功短信通知,如下截图:
另外,有时候可能由于种种原因,商户有可能会在做预授权的时候,预估金额不足),导致最终持卡人消费金额超出了预授权冻结金额(甚至超出了115%),此时怎么办呢?

商户可以发起追加预授权交易,什么是追加预授权交易呢?

我们直接上一段银联在规范中的定义:

“追加预授权交易指在一笔已获得批准的预授权交易后发起的一笔相关联的预授权交易,以便向持卡人追加交易金额。”

比较好理解,我们可以结合下面的流程图来说明:
流程补充说明:
  1. 发起追加预授权交易,商户/收单需提交第一笔预授权交易的主键信息,用于关联第一笔预授权交易,银联的原交易(包括消费交易等)主键信息都放在90域(原始数据元),该域包含原始的报文类型、系统跟踪号、系统日期时间、受理机构标识码(一般为收单机构号)和发送机构标识码(如为银联交易,一般是全渠道编码等)等主键信息;

  2. 同第一笔预授权交易一样,追加预授权交易同样不会发生清算;

  3. 支持在合法合规的情况下发送多笔追加预授权交易

3.3预授权完成

前面也提到了,预授权完成其实可以分为预授权完成(请求)和预授权完成(通知),我们直接上图,一起看看区别在哪里?

1)预授权完成(请求)
2)预授权完成(通知)

大家有没有看出其中两者的不同?
在联机交易中,预授权完成(请求)是在发卡应答后,卡组才会将交易结果同步给商户/收单,而预授权完成(通知)是直接卡组校验成功就给商户/收单发送交易结果了,并没有等待发卡的应答,如果是双信息交易这个时候卡组就直接出具了清算文件,也就是进行清分了,这个前面也提到了,“一旦接收到后,发卡行不能拒绝”;
那为什么还需要发卡应答呢?
这里面主要是要确保发卡确实收到了卡组的请求,就相当于我喊你一声,如果你屁都不放一个,我肯定没法知道你听到我喊你了,比如网络通信中断的情况。
而针对一直收不到发卡行应答的预授权完成(通知)交易,这个时候卡组一般会存储交易,待网络恢复后再重新转发,直至成功收到发卡应答为止。
另外,针对上文提到的,如果是发生了追加预授权交易的预授权完成,是怎样的?

我们再在前面流程图的基础上给大家来个流程图:

流程补充说明:
针对追加预授权交易的预授权完成交易,受理侧(商户/收单)需要发预授权完成(通知)交易,并且在请求报文中需要带上和第一笔预授权一样的授权号,该授权号在第一笔预授权成功后,卡组织会在应答中返回给受理侧;
预授权完成交易是对前面所有包括第一笔和后续所有追加预授权的完成交易,所以收到该笔交易请求后,发卡需解冻所有相关的预授权冻结持卡人金额;

3.4预授权撤销

流程补充说明:
  1.  预授权撤销前面定义介绍得比较清楚了,大家看下流程即可,只要记住预授权成功后30天内可以主动发起该交易,而第31天银行会自动撤销;

  2. 如果针对追加预授权交易的预授权撤销,是对相关所有预授权的撤销并且撤销之后不允许再发起针对该笔预授权的追加预授权交易;

3.5预授权完成撤销

预授权完成撤销前面也介绍了,需要当天大批次发起,特别需要注意的是,预授权完成撤销只针对预授权完成(请求)交易,预授权完成(通知)交易是不允许发起该交易的。

那如果要取消预授权完成(通知)交易怎么办呢
 如果针对单信息交易,可以直接发起退货流程,实现撤销;
如果针对双信息交易,则收单机构可以在发送请款文件的时候,去掉该笔交易即可;

四.写在最后

本文为了减少篇幅,上面预授权相关内容主要基于卡组“四方模式”里最简单的流程来介绍,且基于单信息模式,也没有从跨境交易或者清算流程去展开
而市场上,其他的预授权服务提供方,除了卡组外,还有各种第三方支付机构,比如支付宝,相同点很简单,用户体验基本都一样,都能满足商户的“押金”需求,不同点以支付宝和卡组来对比,简单来说主要有以下两点:
1)冻结额度的对象不一样
支付宝产品比较丰富相对灵活,其背后既可以自己作为发卡行也可以作为三方支付的角色:作为发卡行的时候,客户冻结的是其支付宝余额和花呗等额度,作为三方支付的时候,就跟卡组一样了,需要支付宝转接调发卡冻结银行卡的额度;
2)支付的流程有差别
虽然都是叫预授权,支付宝并不是传统的预授权交易,而是第一笔预授权交易后的的流程,将预授权交易和消费相关交易进行了结合,没有严格的和有类似卡组的预授权完成等流程,另外,如果芝麻信用分比较高的,还可以无需冻结相应的预授权额度,也就是“免押金”;
关于卡组和支付宝的相关预授权介绍,大家可以点击下面的链接具体研究
银联预授权接口地址
https://open.unionpay.com/tjweb/acproduct/APIList?acpAPIId=759&apiservId=448&version=V2.2&bussType=0
支付宝预授权产品介绍地址
https://opendocs.alipay.com/open/00nawd?ref=api

推荐阅读

“学跨境支付”,25个子专栏,11套原型

万字:清结算体系,全局方案深度解析

3.5万字:一文搞懂“支付系统”

支付全集-珍藏版V8.0

陈天宇宙
支付系统那些事儿
 最新文章