20170612-东南亚的移动支付

Posted by PaymentGroup on June 9, 2017

一、主题分享–东南亚当前移动支付的发展情况

1.1 分享内容

大家好,有幸能加入这个群,这段时间对支付系统这块有了更新的了解,今天我简单给大家介绍一下东南亚移动支付的现状吧,这次主要就侧重与泰国的情况。

1.整体概述

东南亚支付这块,基本主要侧重在三个国家,泰国,印尼,越南。

2013年,泰国3G牌照发牌,移动网络条件得到了巨大的提升,国内的智能机加上高端智能机大量的涌入,这些都给移动支付的发展提供了沃土。

东南亚的支付现状有一个明显的特点。信用卡少,现金支付占主流。泰国8000W人口,只有400W张左右的信用卡。这个在一段时间内给第三方支付网关提供了一个巨大的发展机会。一段时间内,运营商的短信,点卡等支付模式,在东南亚遍地开花。游戏CP是主要的使用者。

2.泰国发卡现状

在泰国,目前有4000W张左右的储蓄卡,其中有30-40%的储蓄卡都只是VISIA和MASTER。

支持信用卡的收单模式,意味着有可能做线上的快捷支付。这个给第三方支付的发展提供了一个可能。

3.泰国移动支付银行现状

目前泰国有大概10几家银行,其中最大的有5家,BBL,SCB,TMB,KBANK,TBANK。其中有四家截至17年已经支持了ODD和线上的绑卡流程。从技术层面上看,已经很接近国内了。

从技术层面看,发展很块,但也存在明显的缺陷。就是现在用户在银行端都是没有绑定手机的,泰国银行之间也没有银联这种组织。很多银行之间要相互转账都是一家一家的连。

4.当前支付方式

从支付方式上,按顺序看,就是现金,网银,信用卡,ATM,类快捷支付。现在很多地方还存在用机器存现金到钱包APP里面。对于移动支付来看,存在着很大的发展机会。

5.泰国央行

泰国央行其实一直是在和国内的支付宝和一些支付公司学习。所以,他们从去年开始在推动建立prompt pay。prompt pay, 核心本质就三点,建立用户唯一ID和银行的绑定,银行之间甚至EWALLET之间打通,相互充值以及转账。还有各个银行都必须遵循一个央行的公有协议,可以实现随时随地的转账和充值,想的很OK。但实施过程中,阻力很大。但这个如果能大面积推广,那基本就是国内的网联。泰国的支付整体提高一个档次。

6.泰国清算组织

泰国没有国有的清算组织。他有一个国内所有银行共同持股的一个民间组织,ITMX,来对所有银行的交易进行清算。这个组织原来是给银行卖设备的,现在成了正式的泰国银行清算组织。

7.泰国收单市场情况

泰国从16年开始,收单这块的业务就成直线上升状态。中国人在泰国的消费从去年的大十几亿美金,到今年基本是要突破100亿美金的空间。支付宝,微信支付,都在抢占这块市场。很多国内的收单设备商和代理都在冲进来。

8.泰国支付场景

泰国的支付还没起来,这个和场景有很大的关联。泰国目前还没有出现类似淘宝这样的一个场景。类似滴滴和类似美团的应用也有,但可惜因为支付和物流的问题都还是很早期的状态。这块应该也是有巨大的机会存在。

今天,我就简单分享到这把,如果有想了解更多细节的,可以加我微信。谢谢大家

1.2 Q&A

Q:请问你们和跨境电商有合作吗?一般跨境支付会和跨境电商合作

A:我们提供本地的收单能力。目前还没有和跨境电商合作。

Q:那是替本地商户收单吗?

A:我们可以给国内的支付公司收单,类似支付宝,微信支付等.

Q:请问,你清楚Freelancer在泰国本地的接受情况么,freelancer.com?

A:不太清楚

Q:你们资金如何清算呢?

A:收单的话,就是国内支付公司和我们结算,我们和本地商户结算。

Q:泰国的支付牌照好申请吗?

A:现在难度比较大了,但和国内比,还是有机会的.国内感觉没戏了.

Q:国内支付公司跟你们用什么币种结算呢?如果是人民币,由谁负责换汇呢?

A:离岸美金结算吧

Q:商户这端呢?应该是泰铢吧?

A:我们和商户是泰铢结算

Q:现预付卡占比大么,以前接过几个银行的,盗刷的特别厉害.

A: 无

Q:你们使用的通道是国内通道还是国外的呀?你们的通道都是接国内的第三方支付公司?不接泰国的银行,或者泰国的银行根本没有支付清算系统?

A1:我们直接对接泰国银行,泰国有个民间的清算组织.

A2:银联15年在泰国建设一套转接清算系统,16年应该已经在运行了

A3:对哦,银联是跨境支付的先驱

A4:是帮泰建设的老挝好像也有;支付宝的汇率相对银行要便宜.

A5:银联最近在泰国推二维码支付标准啊

A6:嗯,目前的二维码标准是和visa master 对标的;国际可以用。

A7:前段时间好像看到visa在泰国推扫码支付的新闻

A8:不是很清楚,泰国央行现在主推prompt pay

Q:你们现在是只接入银行卡或者银行的电子钱包么

A:直接接入银行卡

Q:中国游客在泰国用支付宝付人民币买单,结汇的时候算CNY还是CNH?

A:CNH

A:所以换汇的步骤是CNH-》美元-》泰铢 还是CNH-》泰铢

Q:换汇时怎么规避因汇率波动带来的损失呢?

A:这个比较复杂,又好多种解决方案.

Q:做这种东南亚支付的公司的技术人员是否会经常出差在国外,或者需要长期驻点在国外?

A:不需要

网友补充分享:

  1. 这个企业是做东南亚支付的
  2. 泰国的系统,银联的标准和解局

二、自由讨论

2.1 看图说话

20170612_091500

Q1:虚线什么意思?

A1:嗯,这样看的明白些了;用户c,账户c

A2:虚线代表协议授权,也就是依赖关系

Q2:这个是用例图吧

A1:这个是对像建模OM,你可以理解为class

A2: 一般产品功能设计的时候,我会话UML用例图,看着类似,不管是继承还是依赖,还有边界

A3: 我这个还没到产品层面上,你可以理解为领域建模层面

Q3:你这个是不是银行的虚拟伞型子账户?

A1:我没接触过解银行的伞形账户,如果同一业务需要分级核算,树形结构是比较好的方案,扁平化的结构不好管理。 我一直认为树形结构在计算机模型中是比较好的模型。

Q4:伞形和树形分别是什么样的?

A1:感觉就是同一个东西;只不过表述角度不同.HOMES大概就是这样吧,因为我说这个是模型,是一种抽像,屏蔽了各个产品间的差异.

2.2 聚合支付对账方式

Q1:做聚合支付的话,向第三方渠道下单如支付宝,微信订单号是用平台自己的还是商户系统传过来的?

A1:商户跟谁对账?

A2:跟聚合平台

A3:跟聚合平台对账,聚合平台可以自己生成,如果聚合平台不参与对账,必须由商户自己生成了。

A4:我们现在做法是每个商户自己生成自己的订单号,现在问题是平台用商户的还是自己内部生成一个自己的订单号去下单.

A5:自己要有自己的编号 直觉

A6:这个用哪个都无所谓,关键是防重复;自己生成就有一个麻烦,需要自己做映射.

A7:补充下,各支付渠道的订单号规则不一,完全由商户自行传订单号也有问题;如果聚合平台仅作信息二清,聚合平台不用商户的订单号创建支付订单,那商户就无法自行下载支付渠道的对账文件进行对账.

A8:对,用商户的就怕重复,用自己的就得映射;

A9:可能多个商家用同一个软件商提供的系统呢 不依赖商家编号但需要记录关系.

A10:我现在偏向是用自己的,我觉得既然做聚合那平台就应该提供对账能力;

A11:如果你们有第三方支付牌照且确认是你们给商户对账单的话,就自己生成吧,规则比较统一

A12:这个跟支付牌照有关系?

A13:对,有牌照就可以用大商户模式;有牌照就可以做二清,商户是自己的子商户。毕竟商户属于外部因素,不好控制,自己还好弄.

A14:曾经也计划通过聚合平台,为商户提供对账服务,解决数据碎片化的痛点,但是支付渠道对聚合平台的开放能力是有限的,纯粹的技术服务路线很难走

A16:一个比较平衡点的方案是技术人员辛苦点,做成可配项的,可以在商户上做配置,选用是否启用平台订单号.

A17:这个没得选,你不提供对账服务,就不能代替商户生成订单号,否则商户就无法对账了.

A18:或者设计一个规则 商家的编号+商家的订单编号 简单点

A19:不知道ping++,付钱啦是怎么做的?

A20:聚合支付平台提供这样的能力更好,毕竟聚合支付的平台有交易的信息流,是能够有基础去实现的,对于商家来说他接触的是你,也找你对账更合适

A21:聚合支付,支付公司结算给聚合的商户;提供对账给聚合商户.聚合公司提供对账给商户,一半聚合的商户都属于小商户,也不需要对账.

A22:是啊,我们以前就有这样的商户,不跟我们对账;不跟我们对账,这类商户我们都用商户的订单号;我们的系统属于混搭的.

A23:账证、账账、账实核对,尤其是最后的账实核对,所以不做二清,很难提供完整的对账服务.

A24:聚合支付,结算都不走平台,对账意义也就不大了

A25:要做二清,就需要牌照资质.问题又回到起点。

A26:也不一定啊,如果有内部商户,也是可以不用牌照的,比如集团子公司;我们的聚合支付平台,是在第三方支付平台上扩展的,做了些配置项。

A27:每个渠道单号长度限制都不一样的。有的银行才12位 直接用商户的不行的.

A28:还有要求纯数字的.

A29:我们的聚合平台向第三方下单是用自己的订单号;

A30:你们给商户提供对账吗?

A31:信息对账,不敢二清;托管给银行做结算.

A32: 银行二清,然后银行对你们开放对账功能,你们再输出至商户?

A33:恩,支付宝的代分润模式,就完全不需要平台参与,直接跟子商务清算.

A34:银行账户体系比较复杂。介质与账户分离,介质可以与主账户关联,也可以与子账户关联。子账户下还可以开虚拟账户。账户和账户之间还可以通过协议之间组合,例如集团账户,活期和定期组合,活期和贷款组合,还可以产生资金池。

Q2:支付宝,微信是直接结算给商户还是给聚合平台?

2.3 风控与公检法的合作内容讨论

Q1:第三方支付与公安部门合作打击犯罪,除反洗钱和欺诈等方面,还可以在哪些方面合作? 然后风控部门如何对接协助公安部门? 各位大神有什么好想法,多多提出,交流下

A1:类似同盾的还有哪些公司

A2:百融金服、有盾、宜信致诚 不少

A3:GEO也不错

A4:风控盾这些只是在内部防控,无法在真发生重大事件的时候,与公安部等顺畅协同处理案件吧。

A5:这些你得先明白公安部有什么要求吧?没有目标怎么做啊

2.4 小贷行业代扣模式讨论

Q1:群里有对小贷行业还款代扣比较熟的么?比如现金贷或者3C,分期还款时间到了,一般会怎么催收,扣款有哪些坑

A1:具体什么呢?我们有这个产品;可能有提前扣款啊,逾期补扣啊,银行卡余额不足补扣啊.

A2:小贷产品一般都会提前通过短信形式通知,扣款最好的方法就是让用户绑工资卡

A3:因为代扣涉及授权、成本,成功率,一般行业都会有一套代扣的解决方案吧

A4:代扣通道不好签,有的是用快捷包装的.所以,最终都是走协议扣款,协议扣款风险比较大,对商户资质要求高.

A5:应该还有一些策略,比如满额扣不成功,还可以逐步减金额扣款

2.5 退款是否更新原订单信息讨论

Q1:想请教各位大神一个问题:关于给商户提供的对账单里面,涉及到退款和原交易,你们是展示一条记录(原交易里面显示退款信息)还是两条记录(退款一条交流,原交易一条记录)?如果展示一条记录(原交易里面显示退款信息),是不是必须要更新原订单信息,这样会有什么风险吗?

A1:本来就是两条;原订单肯定是要更新的,否则怎么控制可退金额?

A2:这个显示两条

A3:支付和退款,应该是两天记录,两条.

A4:原订单更新交易状态和订单金额?这样的话不是修改了历史记录了吗?

A5:可退金额;订单金额不变.

A6:可以参考支付宝、微信支付的对账单,都是两条

A7:可是 这样 商户对账好像不太方便。

A8:这个不用参考,业务上就应该是两条.有啥不方便的?一个交易,多次退款,退N次就是N+1条.

A9:退款的依据就是依据原订单,我需要翻两条记录才能对完这一笔账,可退金额是在账务系统里面显示的吗?原订单里面也有可退金额吗?

A10:账务系统里也有,交易对账走的是流水勾兑,不关心上下文.

A11:如果 我想展示一条记录,这样是不是必须更新原交易订单才能实现?

A12:你这是两条流水,商户那也是两条流水.如果一笔订单,退1000次,你怎么展示成一条?

A13: 支付宝的对账单

A14:我知道支付宝是两笔,收钱吧现在是一笔,我想知道收钱吧怎么做到的?不过,收钱吧限制只允许发起一次退款.

A15:你发个收钱吧的对账单,我看一下

A16:那是在支付记录里展示了 退款总金额,只允许退一次可以的~ 还会展示个退款订单号吧

A17:20170612_163027

A18:这个其实不能算账单的。或者另一个意思的。 和提供给商户日账单 2回事。

A19:这个是收钱吧APP的交易流水截图吧

A20:对

A21:这个是个原始订单截图

A22:那收钱吧这种只展示一条,有修改原始订单记录吗?

A23:这个只是前台展示吧,他给商家的对账文件也是这样吗

A24:两条

A25:所以只是前台展示的时候聚合了,实际文件还是两条是吗

A26:对,所以,通常做法还是不更新历史订单的,对吧?.

A27:我们会更新原始订单,标识退款和退款金额

A28:这样如果更新原始订单,会对以后对账有影响吗?会存在数据凌乱的风险吗?

A29:基础原始数据都变了,怎么完成后续对账,怎么保证对账准确性.

A30:你的建议还是 保留原始记录,生成新的退款流水,不更新原订单记录?

A31:不论生不生成退款流水,原始订单都要更新的,原始订单是退款的依据,退款订单不能独立存在

A32:状态应该改一下吧

A33:对账是对流水,不会对业务订单

本文档来自“支付产品架构交流群” 的聊天记录整理,由志愿者整理并发布到本网站。如需要及时收到来自“支付产品架构交流群”的最新消息,请扫码关注“凤凰牌老熊”的微信公众号。目前支付产品架构群还有不少空位。 本群面向支付行业的有经验(2年以上)的产品经理、软件工程师、架构师等,提供交流平台。如想加入本群,请在本文评论中留言(不公开),说明所在的公司、负责的工作、入群分享的主题和时间。