全球支付研习社 | 企业出海,聊聊支付成功率优化的那些事儿

企业出海支付,Adyen全球支付研习社带您从头认识支付成功率,以及支付的成功率应怎么整体把控。实际操作如何分解支付成功率的优化,应该怎么做能看到数据的提升。

内容分为【基础篇】和【实操篇】讲解企业出海所面临的支付成功率

【基础篇】:梳理支付的成功率应怎么整体把控,带领大家从头认识支付成功率。

【实操篇】:如何分解支付成功率的优化,应该怎么做能看到数据的提升。

基础篇 支付成功率整体把控

从头认识支付成功率

大家都很关心自己成功率的表现,开始之前可以思考:

  • 支付成功率为什么这么重要?
  • 到底它的重要性在哪里?
  • 为什么我们有很多商户会把它作为一个重要指标呢?

举例

假设现在商户收到了一笔30美金的订单,但是这个订单支付失败了,那这个时候对于商户来说,成本是什么呢?

在这个case里面,我们的损失应该是有30美金的损失,还有支付的网关费的成本。

但是除此之外,其实还有一些其他隐性成本。对于商户来说我们收到支付订单请求之前,用户已经经历了漫长的一段旅程。

首先是市场营销。我们从用户拉新开始,到用户浏览产品,到用户添加加购物车,选择付款方式;其实以上每一个流程里面都会存在跳转和流失。等到用户真正开始提交支付订单的时候,我们就来到了用户转化漏斗的最后一个环节。这一步会深刻影响支付的成功率。如果说用户过程中支付不流畅或者交易失败,会对于用户体验的影响还是非常大的。很有可能拉新的用户,无法继续留存下去。


支付是我们用户转换漏斗的最后一个环节,是非常重要的最后一公里。

Adyen支付学院

举例来说,假设一个用户的拉新成本是30美金。那前面提到这一笔30美金的订单支付失败,成本损失除了刚才Lana提到的30美金订单收入,还有网关费和背后潜在的这30美金的用户拉新成本。所以这也是我们会经常强调支付成功率的重要性。

如果说这个最后的环节失败的话,很可能新的用户就流失了。反过来说,如果商户能够提供一个非常流畅的支付体验提高支付的成功率,是可以帮助商户整个的运营发展,提高用户的复购率的。这也是为什么我们今天会去这么想要跟大家去分享支付成功率的这个话题。

怎样从头认识支付成功率?

支付成功率具体应该怎么看呢?

我们来看一个实际案例。作为商户,我现在收到了100笔的订单请求。但是我发出给Adyen或者给其他的PSP,之后我收回来的支付成功的订单假设只有55笔,那对于我来说,订单维度的成功率其实就是55%,这是非常一个直观的数字。但是会发现,当我们需要优化成功率55%的数字,提高到60%或70%,需要对数据做拆解,了解从100笔到55笔的订单到底流失在了哪里?

我们给大家展示订单的完整线路:

第一步,用户在商户的收银台页面点击了支付的按钮。这一步可能会引发种种支付中断的情况;

  • 用户填了卡号,但是发现有件商品漏买了,需要返回去更改,那这个支付请求就取消了;
  • 支付的环节,用户发现找不到想要的支付方式,暂时没有信用卡或者其他电子支付方式支付。
  • 网页卡顿,支付平台没有办法成功的抓取支付页面信息。
  • 用户忘记卡号,但是卡片暂时不在手边

以上这些原因都有可能导致用户在商户的收银台的页面支付订单的提交率的流失。以刚才提到的100笔订单为例,可能有30笔都会在收银台前端流失。

用户把所有的信息都提交成功了,商户也把支付请求传达到收单行和网关,下一步就来到了风控检查环节,风控对支付来说是一个非常重要的节点。

商户会搭建一套自己的风控逻辑。也有很多商户应用Ayden的风控产品—Revenue Protect;在订单生成后,会运用风控产品的逻辑去进行风控的检查。以便更好了解哪些订单从风控就被拦截。

假设在70笔订单里,有90%的订单通过了风控检查。风控检查结束后,下一步就是这段时间非常火热的3DS验证的环节。

3DS验证指的是:用户需要证明自己的身份,如银行卡为本人持有的,而不是欺诈的用户。用户需要在前端通过动态验证码,指纹或者其他方式来进行身份校验。

在验证的环节出现两种转化率的流失。

第一种:

在3Ds验证过程中因为跳转导致用户流失;比如说:如果商户使用的是3Ds1.0版本,用户收不到银行验证码,或者无法成功跳转到银行的验证页面,用户就会放弃交易并关闭页面;

另一种:

即使用户完成了3Ds验证流程,也有可能出现3Ds验证没有通过的情况。这个时候adyen会带着这个3Ds验证的结果,把交易请求发给银行进行后续授权认证。由此我们可以看到只要涉及到跳转,都可能会引起转化率的流失,这就是我们经常会说的drop off “掉单”。

假设说按照80%通过率来看,刚才的订单只剩下50笔,对比最开始的100笔订单,目前我们只剩下一半的订单。

刚刚有提到风控也提到3Ds验证,这都是风控检查的一个部分,那么订单需要先经过风控还是先经过3Ds验证呢?

这是个常见问题。而真实答案是都可以。主要需要看商户偏好。

类型一 如果是对成功率很敏感的商户,可以先经过风控的拦截,然后再做3Ds验证,这样商户就可以减少一定量3Ds验证的比例。
类型二 如果是订单价格很高或者对拒付非常敏感的商户,会希望能先完成3Ds验证,如果订单没有通过3DS验证也没有拿到银行的责任转移,那商户可以采用后置风控的判断逻辑来看这些订单是否要继续处理。

一言概之:商户可以看根据自己的偏好设置,对于Adyen来说两种模式都是可以支持的。但是系统里面默认设置是前置风控,通过Adyen RevenueProtect 的交易才可以继续后面的3Ds验证流程。同时,商户也可以设置一些后置风控的规则,来查漏补缺。

完成3Ds验证流程后,就到了交易授权的步骤。

其实只有在这一步,交易才真正开始通过Adyen传给银行卡卡组,然后到用户的发卡银行。这一步是银行会根据自己的风控系统来判断这笔交易到底要不要通过中间卡组,他们会像Adyen的风控系统一样有自己检查逻辑;那如果银行的授权通过了,可以查看到订单状态会从received变成authorized授权成功;但是银行也会出于不同的原因拒绝这一笔授权,订单会变成refused拒绝。除了这个状态,同时卡组也会回传给我们。

交易成功只有一种状态,但是拒绝的原因千千万。

具体订单被拒绝的原因,稍后会在后面跟大家详细的解释。那我们假设刚才的50笔订单,银行的授权通过率是90%,那接下来我们将只剩下45笔订单。

最后一步是后置风控。

部分商户仍然想要加一道后置风控,根据自己的偏好来查漏补缺也是可以的。大部分情况下后置风控的拒绝率不会像前置风控一样高,比如刚刚的45笔订单,99%的订单会通过,只拦截一笔我们认为有风险的交易,最终我们剩下是44笔订单。

以上就是我们经历的每一步组成了完整的订单链路。这条链路非常艰难,每一个订单能够支付成功都需要经历重重的阻碍。

统计订单成功率的时候注意以下两点:

第一,要确保我们的统计维度是要一致的。

比如说作为商户,和Adyen官方数据进行比对,我们需要清楚到底这个数据使哪个环节的数据。

第二,优化是需要把总数去做拆解的。这个就是我们怎样通过订单的链路去看成功率的数字。

总结一下,订单能够支付成功,真的很不容易。一般来说我们会看到订单支付没有成功,会有四个很重要的要素。

  • 第一:用户不能放弃
  • 第二:风控不拦截
  • 第三:跳转不流失
  • 第四:银行不拒绝

订单的最后一公里,支付成功率Auth Rate

银行是否拒绝、是否通过,就是我们平时会跟大家讲的授权成功率,也叫做auth rate。

Q: 请问一下有没有什么地方可以让商户快速看到授权成功率的表现?

在我们理解授权成功率的逻辑之后,其实有两种方式;

第一种:可以进到Adyen customer area的后台有一个report (transaction report),在报表里面,我们可以看得到指定时间段的授权成功率的表现情况,包括数据的总览,百分比,授权的金额等。同时,也可以看到和过去一段时间的同期对比,这个是可以很快给大家一个清晰的概念看到Adyen处理这些交易表现情况如何。

Q:那除了整体的成功率表现外,如果我想知道某一具体交易的情况应该怎么查看?

这也是大家经常会提到的问题,比如说我现在看到一笔订单, 会问为什么这笔支付失败了?在银行回传给我们的一个字段叫做Raw Acquirer Response,意思就是说银行处理的结果,通过会正常显示状态,拒绝的话银行也会告知订单被拒绝的原因。比如在Adyen后台的Payment页面,我们看到这一笔订单,它上面写的原因就是Acquirer Response 这里写的就是Not-enough-balance。就是余额不足,这笔扣款就不会成功了。

所以,对于每一笔订单来说,无论成功或者接受,他们都会给返回这个 Raw Acquirer Response, 商户可以直接在Adyen后台的订单的页面去查看具体的原因。

Q:影响授权成功率会有哪些因素呢?

影响授权成功率的因素挺多的,通常当商户来问客户经理“现在这个授权成功率表现怎么样?”我们首要会考虑的是:商户是不是有在做本地收单。我们通常建议商户增加本地收单去代替跨境收单。

Q:可以再帮大家复习一下本地收单跟跨境收单的定义吗?

本地收单: 就是用本地的收单机构去收单,对商户会有一些要求;比如说需要商户有当地的实体和实际运营的团队,这是卡组的规定。

跨境收单:如果商户用非本地收单机构收单的交易就是跨境交易即跨境收单。

Q:为什么本地收单有更高的成功率?

第一:在跨境的交易中,发卡行对于非本地的收单机构不熟悉,授权请求中可能包含一些银行没有办法识别的信息。

第二:发卡行对跨境交易的风险评估更严格

第三:有发卡行完全不能接受跨境交易

在这些情况下,商户都是可能直接被银行拒绝的。比较常见的这个因为跨境收单而被拒绝的拒绝原因:Do not honor 、Transaction not permitted 和Invalid Transaction;大家看到这些返回码的时候,很有可能就是因为银行不喜欢跨境交易或者不能接受跨境的交易。以上这些情况,若用本地收单去代替的话,以上的这些情况就会得较大的改善。

我们有很多商户接受到这个建议后,搜反馈在成功率上面有很明显的提升。

通过本地收单,我们的银行拒绝率下降了21%

德国商户FlixBus, 支付团队负责人Dennis Friemerding

Q:除了跨境收单或是本地收单的影响,是否有其他因素对商户支付成功率有影响?

就像我们刚提到的风控拒绝、用户流失或者是本地收单还是跨境收单,这些影响因素对于商户会有比较直观的感知。但是当商户把支付请求提交给收单行,从收单行到卡组到发卡行这中间的变数对商户来说很难感知。讲到问题就我们就是作为Adyen的客户经理就要给Adyen站台一下,Adyen有个成功率优化的产品叫RevenueAccelerate, 它的理念是在支付的每一个节点商户看不见的环节帮助商户优化成功率。

简单来说它分成了4个节点。

第一个节点是3Ds验证,也就是“用户该不该做验证?做什么验证?怎么做验证?”我们有Authentication engine(智能验证引擎)会帮助商户决定是否需要验证,做3Ds1.0还是2.0的验证可以获得最高的成功率

第二个节点:支付背后的路由选择。Adyen拿到了商户的请求信息,思考“交易应该往哪里发?应该选择什么上送路径?”

关于第三第四个节点,交易请求优化和交易重试,这些我们之后再和大家慢慢分享。

实操篇如何分解支付成功率优化

支付背后的路由选择

首先:合适的支付路由可以提升授权的成功率;相反,路由的选择失败可能会导致这笔交易的失败。

关于路由的官方解释是:某一个分组从源头到目的地,决定端到端的网络路径。同时,不同的网络路径也代表着不同的处理的程序。从这个图上来看,路由从a到b怎么过去,放在支付角度来说,a端是我们的支付请求,b端是我们的发卡行,那么从a端到b端其实我们有非常多的路径或通道的选择。

Q:能不能具体说说,支付请求上送到底有哪些路径和通道?

那我想通过一个比较简单的思考题来帮助大家更好的理解路由是什么?大家可以查看下方图片有一张中国银行的白金卡,大家可能会经常碰到切身的一个场景:当客人用这张中国银行的双标卡做一笔支付时,背后是哪个卡组(UnionPay or Visa)处理这笔支付请求呢?

在一些市场,他们会有当地的法规决定所有的双标卡是客人前端自己去选择的,

但一些没有这种规定的市场里的商户也可以进行指定,或者商户自己不能判定在通过哪个卡组成功率更高,他可能让收单行去做这样的决策。

Q:海外的用户也会有像银联这样双标卡吗?

海外很多国家都会有本地的银行卡卡组,或者小的银行间网络,会出现双标卡,甚至多标卡。比如法国的蓝卡(Carte Bancaire)比利时的BCMC这些都是当地的卡组,还有美国有本地的借记卡网络,Star、Pulse、Nyce、Accel都是当地银行间的借记卡网络,美国有一个杜宾法案要求每张借记卡都应该除了Visa/MasterCard外都有另外的支付网络,并且要求发卡行允许商户和收单行进行交易路由,所以美国的借记卡绝大多数都是双标卡(多标卡)。

Q:那是不是说商户首先得支持这些本地卡组的交易,才可能有路由的机会?

对,就如刚刚那个思考题,这个问题存在的前提是,商户开通了银联这个本地卡组,如果没有开通,那么这里只有visa一个通道可走,就不存在路由了。

所以划重点!针对一些市场商户可以增加一些本地卡支付网络去丰富支付的路由选择。

Q:那Adyen具体会怎么选呢?

只要把选择增加好了,选择题可以放心的交给adyen。简单来说,Adyen有丰富的平台数据,对各市场发卡行偏好的了解,同时我们会对商户的数据模型进行机器学习,以实现在每笔交易进来的时候,我们能按照卡bin的纬度,判断出成功率最高的路由路径。刚刚介绍比较抽象,这里以法国蓝卡举个例子。

蓝卡Cartes Bancaires, 是法国的本地卡组,市场占有率较高,超过97%的18岁以上的法国人拥有蓝卡,在法国是最广泛使用的支付方式。同时这其中有99%的蓝卡都是双标卡,这意味着大部分的蓝卡都可以进行路由。

当一笔蓝卡和MasterCard双标卡交易进到Adyen时,Adyen会自动查看此双标卡BIN在平台的走两个卡组分别的成功率,例如这里看到蓝卡通道的成功率是85%,mc的成功率是50%,那我们就会选择蓝卡的通道进行支付请求的上送。



Are you looking for test card numbers?

Would you like to contact support?