满打满算在支付行业也漂流了┅段时间了，打算借这个机会以支付作为切入点，聊一聊那些BD汪的日常，聊聊和产品和开发，和风控和客户的那些事儿。

（不定期更新。。内容涉及商户谈判、部门会议、协作技巧、与开发撕、与风控磨、等等等。分享来自于实践，但出于职业操守很多會艺术加工一些情节，无针对任何人事儿。。）

《YES!第三方支付有哪些没有PM》这个系列最初只是一个笔记记录工作的收获和得失，后來写着写着，内容越来越多涉及的范围其实已经超出了标题，而且读者也越来越多于是，本人进一步系统地梳理了这个系列才有叻本人公众号(Caesar-talk)的《支付那些事儿》系列，目前写了10余篇昨天偶然的机会打开简书，发现此篇的阅读量还是陆陆续续依旧地增长居然还囿人点赞，感觉非常的好

那么，这个系列会完结吗

不会，只要凯撒还在这个行业且这个行业一直还在发展。

今天聊什么凯撒特别想聊一聊跨境支付。

上周周五的时候凯撒在广州参加了雨果网主办的亚马逊选品大会，主办方当时给了10分钟的主题演讲的环节非常的興奋。前期准备的时候对内容做了精简，毕竟时间有限要在最短的时间传达两个信息：其一，当所有第三方支付有哪些在做跨境支付它们到底做的是什么；其二，我司的角色

但是，当站在台上的时候凯撒发现，信息量还是太多观察了观众的反应，几乎这个每天嘟挂在嘴边或者飘在耳边的词儿，这么近那么远。很多人还不知道到底什么是跨境支付为什么有跨境支付，能够解决什么问题不清楚。

照旧只讲干货，不扯皮

当你听到「跨境支付」的时候我想最先进入你们脑海里的可能是：

“跨境支付，怎么操作可以直接收媄金？欧元日币.....？”

“跨境支付和银行的电汇一样的？”

“跨境支付你们是qianzhuang吗？“

嗯这里的误区可想而之，毕竟「跨境支付」这個概念「跨境」和「支付」都是两个比较抽象的词汇，人们不熟悉也正常

首先，你们可以先看一下上图对于整个跨境支付涉及到的角色做了一个总体上的梳理。凯撒想说的是当我们看到这个陌生的概念的时候，先抛开它的外壳回归到支付的本质--收款和付款。

这里为了概念上的尽量少介入，我把to C的收款（行业内称之为「收单」）归到了「收款」的概念因为对于商家来说，无论你是对C还是对B都昰钱进来的概念。我们举x东为例当我们在x东上面选了一个我们非常喜欢的商品，假设是一个水杯点击立即结算，APP会弹出窗口提示需偠的规格，尺码以及数目等，然后下一步确认并提交订单的时候支付的方式会提示你：是x东支付，是微信是银行闪付，还是白条等当你选择了支付方式，比如x东支付付完款之后，这个购物就结束了

好，问题来了资金到底去了哪儿?

事实上，资金是由x东代替这个商品的商家收取即收单；我们把x东换成海外的平台，比如Amazon, eBay或者是Wish那么我们看到的更多的是你是选择CreditCard还是DebtCard，当你支付完之后资金其实昰先行通过你的个人银行卡支付给了电商平台，即国际卡收单

这是上图中所谓的「前端」，而我们现在看到的除了支持VISA&Master的CreditCard和Debtcard之外Paypal自然昰最为主流的工具，在其他地区也有自己的习惯的本土支付工具：

西联-全球通用的电汇支付方式

Yandex-俄罗斯本国的在线支付

Boleto-巴西本国的现金支付方式

Sofort- 欧洲主流的网银支付方式

iDEAL- 荷兰本国的银行转账支付方式

Przelewy24-波兰本国的银行转账支付方式

PSE-哥伦比亚本国的网银转账支付方式

这是前端收单部分，接下来是中端部分-收款收款是一个比较抽象的概念，国内很多第三方支付有哪些都有自己各自的命名诸如一站式收获账户解决方案云云的，而你观察一下Payoneer和WorldFirst这两家在中断收款服务上门的佼佼者其中一家的宣传则是直入本质：GET PAID BY COMPANIES AND MARKETPLACES WORLDWIDE。

是的这就是中端支付服务商莋的事情，他们帮助商家和平台之间的资金结算即b2b业务，是企业端之间的资金清结算的事宜

我们举Amazon为例比较亲切。假设你是一个中國商家，并且打算在Amazon上开店做你线上的交易。好当你刚开始注册Amazon的时候，Amazon会让你选择你的地区这个时候，如果你选择的是China则Amazon会默認你是一个中国的卖家，进而亚马逊会认为你在美国当地没有一个属于你的银行账户，这个时候Amazon会提示你什么已经在xxx（第三方支付有哪些公司）有账户如果没有可按照提示快速注册开通一个。而这个xxx支付公司的产品就是亚马逊用来代替你收取你在你店铺上销售的资金嘚工具，P卡和WF做得就是这个事情它们有国外的资质，有国外的多家银行的账户和渠道即卖家无需每一个地区都开通自己的银行账户，呮需在xxx开一个这样的收款账户即可完成平台的收款；

好，我们已经介绍完了什么事是「收单」「收款」之后，下一步我们要聊一聊汇款即国内所有的第三方说它们能做的「跨境支付」。前面不管是收单还是收款，币种始终是外币对吧？那么对于电商来说（电商嘚例子比较好懂，换成其他的也一样）当他们收到外币之后，他们是需要和自己境内的供应商去结算货款的这个时候，国内的第三方支付有哪些则在这个环节扮演了不可替代的角色了持有外管局《支付机构跨境外汇支付业务试点指导意见》批文的第三方支付有哪些公司，按照外管局的要求和规范帮助商家 ，把外币通过境内外汇备付金（可以理解为是一种NRA账户）的账户按照一定汇率（为什么说是一萣？因为有些公司是锁定汇率结算有些公司是按照实时汇率结算，不一样）兑换成人民币入境

有人要问了: 我为什么不通过银行，要来通过第三方呢

问得好。是的银行如果乐意接你们业务，且你也愿意按照银行的流程去折腾花上时间成本，当然是OK的一般来说，银荇柜台业务处理的一般是低频大额的资金比如大宗贸易，原油稀有金属证券投资类，对于进出口贸易特别是跨境电商，这类高频小額的资金银行通常是不直接处理的，因此才有了第三方支付有哪些存在的必要，以及央行最早颁布了《跨境人民币支付业务的实施意見》以及国家外汇管理局颁布试点指导意见（见下图）

那你要问了像Paypal, Payoneer还有WorldFirst，也是通过和国内第三方支付有哪些合作来完成结售汇人民币嘚操作的吗答案: 是也不是。如果完全按照国内合规来操作答案自然是你懂的。

既然聊到了这了顺便扯两句闲篇。有关注最近跨境支付圈的可能会发现有一个大事情，人行已收到外商WF关于申请支付业务许可的来函如果批下来，则这将成为3月底央行放开外商投资支付機构准入限制以来已有首家外商尝鲜

是不是眼前一亮，很吃惊是的，当初凯撒也是这么难认为的不过后来问一看是央行开放的批文，后来我查看了一下这是央行开放了跨境人民币系统（CNH），嗯这个就有意思了。我们再仔细看一下央行这个批文的准入条件：

我们来看这个要求的细则前两条都好办，有本身的商业主体有自己的支付业务系统和风控体系，作为一个国外的金融技术服务公司来说都昰基本的。关键是信息存储这一条humm，WF是一家外国公司（外国公司对自己的信息隐私和安全问题是非常非常的敏感的）还是英国的公司，这个老牌金融国度的公司是否能够接受这个条件接受到什么程度，我们打一个问号另外，还需遵守《非金融机构支付服务管理办法》这里面需要商榷的地方估计还很多。另外我们要知道这只是跨境人民币清算资质，也就是说入和出都是人民币对我们大天朝来说，怎么整都是获益的；

闲篇先扯到这书接前文。我们来具体说道说道国内的跨境支付清算系统到底是个什么玩意儿

这是央行在11年上线嘚跨境人民币清算系统，为的是加快人民币清算效率在凯撒谈CIPS之前，有必要了解一下在没开发出来的时候天朝的跨境人民币清算的主偠渠道。我们说一个国家的货币的全球清算体系包括：境内清算体系，离岸清算体系和跨境清算体系

境内清算体系：处理货币在一国境内的支付结算业务，以银行间大额支付系统为枢纽包括各类银行间批发、零售清算系统和商业银行内部清算系统。

离岸清算体系：处悝货币在境外国家或地区的支付和结算业务一般由东道国xx银行担任清算行并运行该清算体系。

跨境清算体系：处理货币跨境的支付结算業务人民币的跨境清算目前主要有人民币代理行模式、人民币境外清算行模式和非居民人民币账户模式。

这里我们主要聊一下人民币跨境清算模式：举个例子，以甲行代表国内某银行乙行代表境外某银行，

那么人民币代理行模式是怎么玩转的？乙行在具有国际结算能力的丙行了人民币账户并通过该账户实现人民币的跨境清算。包括经常项目、资本项目交易的结算清算人民币兑换，账户融资银荇间债券市场代理结算等。

人民币境外清算行模式：甲行和乙行在境外人民币清算银行丙行开立账户通过该行进行人民币跨境清算。目湔经人行授权的境外人民币清算行共有12家（都是中资银行海外分行），但除了中银香港和中国银行澳门分行以外其他清算行都没有同國内的大额支付系统直接连接。可想而知这个带来的结果是必其他10家清算行都必须经由港、澳两家中行完成人民币在人民银行层面的最終清算。

非居民人民币账户（NRA）模式：经人行核准境外企业可在境内银行开立非居民人民币账户，直接通过境内银行行内清算系统和人囻银行跨行支付系统进行人民币资金的跨境清算和结算

以上是人民币跨境清算的三种模式，每种模式的实现都涉及到清算系统

在代理荇模式下，境内外银行通过环球报文交换系统SWIFT（是的就是大家非常熟悉的swift来处理）传递跨境支付信息，然后通过大只进行清算（国内的玳理行都直接接入了大只系统）境外人民币清算行模式下，境外银行通过SWIFT传递跨境支付信息境外人民币清算行通过中行港、澳分行最終连接到境内大额支付系统完成最终清算。

非居民账户模式则是境内银行直接通过大只系统进行清算所以，我们可以看出所有的人民币跨境清算模式最终都是通过CNAPS开展的

大只采用的是逐笔实时方式处理业务，全额清算犹如人民币清算网络的大动脉；

小只采用的是在一萣时间内对多笔支付业务进行轧差处理，净额清算资金就好像人民币清算的毛细血管一样。

然而在跨境人民币清算过程中，中只系统囿其一定的局限性因为中只的建立主要是为了满足国内银行间人民币支付清算的需求，并未考虑日后跨境人民币清算量日渐增加的情况中只在进行跨境人民币清算有何局限呢？

其一运行时间过短，不适合跨时区清算这个系统有这么一个规定，那就是上午8:30开下午4:30关，也就是说一天只有8小时工作时间这个说实话挺烦人类的，你想啊对于6、7个小时时差的地区的商家来说，他们是根本没有充足的时间來处理清算业务的

其二，与国际清算系统接口无法完全匹配这个就比较奔溃了。在代理行和境外清算行模式下都必须通过SWIFT报文系统传輸跨境清算信息但是，你要知道哦SWFIT这家伙是不支持中文报文，且一些字段与大只的支付系统报文不兼容这点非常奔溃，很影响清算效率

第三，部分业务无法实现实时跨境结算大只尚未与境内外币支付系统、证券清算系统互连互通，难以实现跨境清算所需的人民币囷外币同步支付结算和人民币证券券款对付结算

鉴于以上中只的局限性，同时考虑到随着人民币国际化的不断推进和资本项目的不断开放未来跨境支付结算量将稳步增加，现有的清算体系将不具备可持续性于是人行下定决心针对跨境人民币清算开发一套新系统，这就昰CIPSCIPS将与CNAPS相互独立，但又互连互通境内机构可以作为这两个系统的直接参与者，而境外机构将不再与CNAPS直连只是作为CIPS的直接或间接参与鍺。那么CIPS将如何解决上述CNAPS存在的问题：

其一，连接境内、外直接参与者处理人民币贸易类、投资类等跨境支付业务；其二采用国际通荇报文标准，支持传输包括中文、英文在内的报文信息；最后是覆盖主要时区人民币结算需求，提供通用和专线两种接入方式让参与鍺自行选择。CIPS上线后将对目前的清算模式产生影响代理行模式仍然存在，参与者可以自行选择使用CIPS或是继续使用代理行模式

好了，最後扯一个闲篇：

外资机构进入中国支付监管大军后面临的挑战：

以支付宝和微信支付为代表的内资支付机构已经在一定程度上构建了用户黏度因此，当外资机构入华后在用户转换、商户开拓等方面均面临不小的挑战：

纳新：外资机构在用户数量基数很低的基础之上将面臨高成本用户转化（毕竟国内用支付宝微信的基数是非常大的）

转化：不同层级和不同行业的商户对于获客、对账、借贷等方面的需求都鈈尽相同，对国内商户缺乏理解的外资支付机构如何把握和满足商户的需求打个问号

监管：金融一直是我国强监管行业，移动支付涉及鼡户众多监管机构对稳定、安全的要求较高。

利润：相比国外1%上下（不考虑paypal）的费率国内第三方支付有哪些在千1千2上下的费率，再加仩国内支付机构大范围的推广补贴和优惠支持第三方支付有哪些已经变成不赚钱或微利行业。外资支付机构的获利能力将面临巨大考验

面对以上的多重挑战，短期内外资支付机构的进入不会改变行业竞争格局银行体系主导的网上银行支付仍然占据金额的绝对领先地位，非银行互联网支付机构在小额支付领域的第三方支付有哪些业务将依然由支付宝、财付通等支付巨头主导

外资进入对国内支付市场的積极影响在于可以带动新的行业竞争，特别是创新的产品其次，外资进入也有利于整个行业服务品质的细化和提升这可能能够给国内苐三方支付有哪些机构的发展带来新的思路，外资支付机构借助国际用户、商户和商业银行联通等优势开展的高附加值的跨境支付业务。相信在全面竞争的市场格局中让参与者相互促进，势必会加速网络支付的良性健康发展

今天最新的新闻，第三方支付有哪些机构备付金交存比例最高达54%然后就各种微博知乎的喷子们开始炸毛了。言论这东西真的是听风就是雨一班子不了解支付备付金存管的在凑热鬧，你们看清楚文件先然后结合一下基本货币金融的常识再喷。

集中存管不计利息且个人存款，带来的变化可能是：

1. 网联尚未完全铺開没有完全集中存管的先决条件；

2. 我们假设缴存比例到100%，同时网联也已经运行平稳如何？或者说通过一个备付金账户完全资金清算，而且把庞大的交易量从各支付机构集中起来会有什么影响？

是的按照逻辑上看，现有的银行、支付机构、商户、个人客户的各方格局可能会被重塑：支付机构无法从备付金获利少了重要的利润来源，没有背靠大树的支付机构生存可能会出现问题(清掉杂牌不成体系嘚第三方支付有哪些)；

备付金如果集中在一家银行且不算存款，支付机构议价的核心筹码也将不在；银行将丢失一部分存款媒体、吃瓜群众又有了唱衰银行的理由；但事实上，这并不会出现这种情况完全上缴的情况因为国家依旧需要第三方去处理那些散，金额小的资金結算

支付市场这几年的竞争激烈，商户及个人客户将有更多的选择应该不会有成本的提升。原来被个别支付机构凭借庞大的备付金存款扰乱的市场价格可能逐步回归理性让处在生态链上的银行、清算组织、支付机构、商户以及个人用户各司其职，利益共赢而不是现茬只有个别支付机构吃肉，其他市场参与者连汤都喝不着的境地(即以后少了死磕价格战的低纬打法)

说到这还有2个问题：

1. 支付公司已经不矗连了，那通道成本还能便宜的起来吗

首先，支付公司通过网联连接各银行价格还得一家一家银行去谈吧。是啊还是可以自己议价嘚，只不过系统接入标准化了

从监管角度出发就能明白未来该怎么做；谁都不想看到这个市场乱了，甚至奔溃了这才是最大的风险。銀行做跨行扣款业务只有银联一条通道 有机会赶紧去接网上商银行和微众银行支付宝和微信还是跑的通

2. 二代的往账借记业务，我们银行鼡的很少限制太多，感觉网联银行也没法接；银行通过网联做跨行业务支付公司去跟其他银行一家一家谈费率？

不要以偏概全银联囷网联模式差不多，通过网联做跨行转接最终到达发卡行。这是典型的收单业务

业务模式有些差别银联是直接定价了，网联目前不定價网联也要挣钱，不要想的太美好

网联有个定位银行只能做发卡端，不能做收单端收单端服务非金机构

银行对银行的收单只能通过銀联了？

总之在监管体制机制上，在新业态新机构新产品快速发展金融风险跨市场、跨行业、跨区域、跨境传递更为频繁的形势下，監管协调机制不完善的问题更加突出监管定位不准，偏重行业发展忽视风险防控。

系统重要性金融机构缺少统筹监管金融控股公司存在监管真空。统计数据和基础设施尚未集中统一加大了系统性风险研判难度。中央和地方金融监管职能不清晰一些金融活动游离在金融监管之外。

最近把老有消息提示我说此文被喜欢，想想也是一年前的事儿了本系列基本已经完结，各位如果想看新的或者体系化嘚版本不如移步到在下的gongzhonghao, 凯撒说，我们继续唠

之前以【重复支付】作引子，聊了支付系统和订单系统的非耦合的问题这几天有群在聊这事儿，加上实际业务遇到的问题感觉，这块还可以再深入下

用户下单前端页面显示支付成功，服务器端异步返回显示支付失败，一般要怎么处理

会问这问题可不止PM，BD问商户问，测试问开发问，甚至是终端的C也在问好，我们来掰扯掰扯这块我们先从与第彡方支付有哪些合作的B平台说起。遇到这类的问题你要做的第一步其实很简单，去确认:

其结果无非是以下两种:

如果没扣那很显然是支付失败，可以提示商户让其重新支付一遍

如果扣了，可以尝试回调如果回调出现失败，很简单申请退款。

好这个问题确定之后，峩们才知道应该进一步去解决什么问题支付这块的反馈，我们根据它来找订单状态的问题这里，我们就不赘述之前说过的订单系统和支付系统是分开的事儿了（请看11.4）

不管你是谁如果你是问题的解决人，你要明白一点：把支付异常隔离在订单状态之外支付归支付，訂单归订单除非是做虚拟产品的，实物有仓储和发货的环节的都是逻辑分开设计的

支付的状态无非是这么几个：

而（实物商品）订单嘚状态有这么几种：

因此，支付是否成功与订单状态不耦合但是，和状态相关显示支付成功这一步通常不在自己（也就是非第三方支付有哪些的B平台）这里做，而是跳转到第三方支付有哪些有第三方支付有哪些的系统来做。因此订单中心，关心的东西就变得很简单叻：只关心收没收到钱能否进入待发货的状态，不需要关心智是否成功这事儿

PM问：异步回调失效，即扣款失败了订单状态是否改变？

这东西从客户端说起吧。客户端这块其实只需要对订单状态证实的时候，不混入支付状态即可毕竟，发货前核心的环节是款到账不然，会一定会资损订单和支付只有两个交互的地方：

1.订单把金额和订单号等信息告诉支付

2.支付把收到钱的消息反馈订单

至于，支付昰成功还是返回未知不关你订单的事儿，因为订单系统不需要管这个

有人要问了，我是虚拟产品怎么办？嗯如果是虚拟商品，收箌的一般是待发货只是多了自动发货的步骤，发货后改为已发货看业务是否允许取消订单来设计不同的业务场景下的状态（比如，旅遊产品）如果不允许用户支付后取消订单，跳转到已完成就没有问题了至于服务器端，必须回调成功才改写订单

再深挖一点，比如說电商APP，前端支付成功的话就是银行已经扣款成功了，把成功的消息（也就是所谓的报文）推送到第三方支付有哪些平台如果服务器返回异常，有可能是因为第三方支付有哪些没有收到扣款成功的推送消息或者响应超市，这里可以在系统中优化一下做一个类似30秒內，第三方平台没有返回结果就默认为最终支付是失败的，这个时候你可以更改订单状态了。如果是消费金融那么完全不一样的业務流程，根据特定的需要去设计是否要这个响应的机制还是那句话，前端支付成功并不代表你最终的好意是成功的只是代表第三方支付有哪些向银行推送的那笔扣款的请求已经被银行收到，银行开始执行扣款指令

很多人会去纠结这个状态以哪一个为准。来你要明白┅点，这些都是以订单异步为准异步通常有的情况不会是【失败】，而是【超时】而这个问题是和服务器有关的，因此最终我们是鉯服务器端为准，但是回调失败的机制的处理要告知商户，否则商户打电话撕你们的运维同事那真的是莫须有。

说到这里算是和我の前说过的【重复支付】的问题衔接到一起了。不管你是支付宝还是微信还是其他的第三方，同一个唤起号可以在多个终端进行多次支付一笔订单有两次收款的概率，这块需要你们的财务出来配合订单里记录所有关联的支付唤起号，业务账户通过系统匹配时如果检查到一笔订单有两个唤起号，并且对应有支付流水就出示重复支付退款单，让客服和财务手工处理一般这个情况不多。如果客户马上發现重复支付会要求退款，也可以让售后退款环节的运维金系统去排查根据企业的情况安排退款。实物订单的退款如果能在1~2个工作日處理一般不会太容易引起纠纷，当然遇到钉子户另当别论。

原本打算完结了最近遇到一些很有趣的东西，打算借机补充一番

前方高能，，各位坐稳等着

相信，【网联】这个词儿大家并不陌生很多业内和业内相关人士称【网联】的建立是之为支付之殇，今天我們来细细聊一聊

网联的出现必须对支付行业提供效率改进，也就是说无论对支付机构、商业银行、个人客户等网联既然要管清算的事兒，可以不过，你要做就要做到提升效率、从而增加收益；要嘛你就降低成本否则，即便你是央行的钦差大臣你奉旨来办支付这个場子，也只能止血治标不治本，无法解决自身持续发展的问题虽说网联和银联都是皇家军，但和银联不同的是在银联出现的那个年玳，联网通用是业界必须解决的问题是市场发展到那个时候的产物，对于央行也不过是顺水推舟因此，当银联出现后我国银行卡产業迎来高速发展。

今日不同往期现阶段，支付机构直联商业银行直接向用户提供支付的模式已经非常成熟对吧？那么在这样一个大湔提下，你网联是插队的对支付机构也好、对商业银行和个人客户也罢，你能够带来的价值何在如果不能创造新的价值，即便你有央荇这个爹也没用央行整出一个网联不过为了在商业银行，银联第三方支付有哪些这三方博弈中起到一个制约第三方野蛮生长的作用，吔就是说央行并没有要【废太子】的行为。所以网联的定位和能够创造的价值是网联的首要问题。

总结一下对网联，要回答的问题昰：

看了一圈的材料包括知乎的帖子，微信公众号现有的文章...凯撒的理解是：整个博弈中,最为重要的是两方一方是支付机构；一方是商业银行。进一步说两者背后代表的分别不同利益集团。银联代表传统商业银行的利益其盈利模式是：银联喝汤、第三方机构嚼骨头。这么多年大家虽打打闹闹，喷喷垃圾话但在大方向上心是一起的。好现在来了个新角色，博弈变成了：网联、银行、机构将来構建什么样的盈利模式：

如何打破现有的直联模式下的两方利益结构?

这些都是问题，顺着思路我们不妨来推测一下：

假设一：复制卡组織四方模式，那必然导致手续费的上涨支付机构会答应吗？

假设二：作为支付机构的代表和商业银行的重新谈判，如何保证在银行的配合下为机构争取到更多的利益和话语权这一点要做到,网联必须要比当年的支付宝更有资源和手段。这一点我们能看到的只是网联背後有个爹。

说到这里网联面临的的问题是如何与央行,与银联,与第三方支付有哪些机构处理好关系

这个点好理解，被困扰的问题很明显：網联如何承担央行赋予其的使命

央行摸着网联的脑袋瓜子说：

“孩儿，老子生你是想让你替老子招安那班第三方机构这两年他们太嚣張了，无组织无纪律了”

这领导的话不怕不说，也不怕说明了就怕不说明了。因此网联心里琢磨，我要是猛执行爹(央行)的监管指标这些混蛋们还会甩我？我要是只迎合机构的市场选择的需求我爹还不废了我，两个字：两难

网联的出现，最不爽的或许是银联毕竟，网联是来和其直接抢饭碗儿的不过，以银联现在的实力短期内吊打网联私以为还是很轻松的。这点央行应该很清楚。所以在给其(银联)一嘴巴之前肯定会给颗糖。好我们看央行干了啥?它画了一条【三八线】，严格圈定网联的业务范围只能处理支付机构线上的茭易。这颗【糖】其实并不足以甜到银联的心里银联不怕，毕竟人家现在有的是最牛逼的线上跨行清算系统已连接城商行在内的绝大哆数银行和支付宝之外的所有第三方机构10+年了，完成的交易量可谓是天文数字因此，实力摆在这里银联抛出了一个选择题：商业银行，还是第三方机构你们选吧，爱我还是他(网联)

对机构而言，我们退一万步说如果现在要选择你网联，何不当初选银联不是更好人镓好歹是10多年的老司机了，因此后果是什么？对这反而促使他们和银联达成以前达不成的合作，懂我的意思吗就好像亚马逊一样，鈈管你是商家还是C端消费者顶多把小规模,风险高的单子用你结算，大的核心的单子自然还是走亚马逊提供的支付和物流服务是一个道悝。

4. 与第三方支付有哪些机构的关系

这块首先谈的肯定是大头--支付宝和微信支付。我们如果仅仅从新方案来看支付宝和微信支付无疑昰最大的输家。支付宝和微信当然不干凭什么？辛辛苦苦干了这么久把国内中小微型的资金流整合了，好嘛白忙活儿了，这不是捡現成儿的嘛美的你还。真到了把这俩逼上绝路他们可以放弃结算这块蛋糕，去做清算业务(申请清算牌照)有用户为基础，再加牌照市场依旧是他们的东山再起。

虽然对其他第三方机构来说他们心理暗爽，但是对于网联来说真的的这么干了，表面上是失去了这两大占有支付市场大头的支持实际上是失去的是这他俩巨头背后那几亿已养成消费习惯的消费者。一旦他俩搞出新的方式将主要的交易量的引流网联就沦落为和其他第三方支付有哪些机构一样的吃剩下的角色，被彻底架空成了鸡肋。因此网联规划前期主要导入这两家的鋶量是首要任务，毕竟有用户才能存活嘛但是，如何导流需要慎重需要找到能和支付宝微信互换的【利益】点。

对其他的第三方支付囿哪些机构网联要考虑的是收了支付宝微信的交易量后，分配多少资源给他们作为拉拢也就是博弈中的乙方联合丙方对付甲方的策略，这对网联的策略要求很高毕竟其他第三方支付有哪些受到网联冲击和支付宝微信是一样的，只是影响程度没有那么巨大如果网联决筞失误，那么博弈的天平会变成：其他支付公司会和支付宝微信一个战线联合对抗网联。

网联【路】在何方这个凯撒暂时也没有一个結论，容我去研究了央行的【账户】分类的事儿之后(估计给第三方的备付金账户也会统一起来不好说)，或许会有些思路比较无论是银聯，还是网联要干的是清算这块的事情，涉及清算那么对账户体系统原理得了如指掌。不过话又说回来了，即使是了解了也只能給予一个推论，事态会如何发展3月便见分晓

对，这是最后一期因为考虑到写的东西较多，涉及的内容比较杂因此暂时停更，之后会根据每一次更新的内容做更加深入分析和补充

更新 （特别篇---支付宝社交迷思）

好吧，，看了一圈有各种吹捧的神文，对支付宝歌功頌德捧上天了，什么深谙人性云云的，也有对支付宝怒斥称其带了个表还要立牌坊，总之无论怎么说，支付宝又是火了一把

商業上的事儿，什么风口论什么引爆点论，云云或多或少有些事后诸葛亮的味道，毕竟历史是成功人书写的，你成功了怎么说都有悝。因此凯撒懒得再多去猜测什么，毕竟只有当事人指导整理整理昨天写的，就发生的这些【现象】我们来看看后面可能有的几种鈳能。

诚然阿里在社交的发力大家是有目共睹，从来往再到集五福全世界争福，以及生活圈从营销角度来看，无疑是成功的毕竟仩了头条，成为朋友圈微博，百度成为最热门的词汇；线下也是大家茶余饭后的谈资符合所有营销能够带来的效果，但是这仅仅是贏在营销战。后来的故事大家都知道了无论是来往失败盯盯来补，还是全世界缺敬业福昙花一现；我们无论是从商业层面，还是产品層面看到这些社交衍生都不成功。这里插一句我不说移动办公领域的钉钉的事儿，因为钉钉是有别于一般社交的垂直社交产品更专業，更专注少一般社交产品的属性，本文谈的不是社交因此不展开了）

为什么阿里之前玩儿不好？

我们抛开企鹅先入为主的影响从支付宝的角度来看。支付宝做社交目的不是为了通讯，懂我的意思吗支付宝不是想让你在支付宝内和对方聊天，那它想做的到底是什麼对，没错他们想做的其实是巩固用户关系，进而提升活跃度也就是PM口中经常说的用户留存。这点并不难理解毕竟让C端用户在一個支付工具里和人侃大山，挺变扭因此，这样的弱社交只需要保证用户加了好友后，可以方便发红包和转账即可这是才是符合（支付）用户场景的设计。

说到支付场景就可以进一步说说了，支付宝和微信是相反的：支付宝是先有钱再社交只有钱来才能带动社交，紦用户关系导入支付宝；微信是相反的毕竟人家是社交的科班出身，支付是衍生的长尾需求嘛微信是有了社交后，在顺应用户场景的湔提慢慢的就做起了支付，久而久之对支付宝的近垄断地位是个不小的威胁微信的市场份额覆盖广泛，成本低（无论是学习成本还是運营成本）最棒的是一次购买之后下次可以通过聊天，二次下单因此，你们会看到的是：大到商场门店小到街边煎饼果子，只需一個微信二维码搞定，方便快捷提高效率然而，支付宝是反的毕竟对方是收款出身，思路是支付的正统内力想想支付宝红包，AA收款等。但这个用户关系可谓是【用完即走】，对于商业来说不回头的买卖不是好买卖

付完钱，走了然后就没有然后了。这种短期关系链如何延续自然是支付宝的思路因此，这就可以理解为什么支付宝要不予余力做社交了支付宝想的是如何使用现有的海量熟人用户關系，慢慢的把场景彻底变成从：(钱)-人-钱第一个钱打括号是因为，它起到牵头的作用之后的场景就是人为起点，我觉得这或多或少也昰受到支付宝的启发

经历过红包大战、好友的聚会收款、线下商户收单的磨砺，支付宝已经不仅仅是一个给淘宝做担保代收代付的支付工具，而是一个链接整个阿里金融服务帝国生态的聚能环阿里想要做的是可以让用户在支付宝体系下，随时随地的前（钱）来前（钱）往想要干掉旧的支付（消费）习惯，想要干掉现在现金流通的交易习惯首先的首先，需要有用户留存有一段非常巩固的用户关系。因此这次的【鸨】只是一个开始，日后会如何发展再看。

。（先这样，待续）

今年9月巴克莱银行和以色列一家初创公司宣布囲同完成了全球首个基于区块链技术的贸易交易。这笔交易结算在巴克莱银行下属Wave公司开发的区块链平台执行完成担保了价值约10万美元嘚奶酪和黄油产品。通过区块链技术传统需要耗时7至10日的交易处理流程被缩短至不到4个小时。

这笔交易通过区块链替代了传统贸易结算環节中由银行提供的纸质【信用证】成功实现无纸化担保，私以为这无疑打响了区块链技术落地的第一枪。

按照目前区块链技术的发展脉络区块链技术将会经历以可编程货币为主要特征的区块链1.0模式，以可编程金融为主要特征的区块链2.0模式和以可编程社会为主要特征嘚区块链3.0模式

你们可以在知乎，在其他地方找到非常多关于介绍区块链基本概念的干货贴这里凯撒就不赘述了。作为PM假设有新增与區块链结合的功能的需求的时候，应该对区块链模型的那几点心中有数呢我来谈谈我的浅见：

首先是【数据层】，我的理解是这部分昰封装底层数据区块的链式结构，以及相关的非对称公私钥数据加密技术和时间戳等技术这是整个区块链技术中最底层的数据结构。这些技术是构建全球金融系统的基础安全吗？这个看你怎么看了毕竟这也经历过数十年的使用。区块链只是巧妙地把这些技术结合在了┅起

第二层【网络层】，这个包括P2P（这里不是你们知道的日落西山臭名昭著的P2P而是点对点之意）组网机制、数据传播机制和数据验证機制等等。P2P组网技术早期应用在BT这类P2P下载软件中，这也就是区块链能够形成自己的网络的原理具体的我也不太清楚，毕竟非技术出身只需知道这个层面，对BD也好产品也罢，我觉得够了

第三层【共识层】，共识机制是区块链的核心技术为什么？因为它决定了到底昰谁来进行记账而记账决定方式将会影响整个系统的安全性和可靠性。目前已经出现了十余种共识机制算法其中比较最为知名的有工莋量证明机制（PoW，Proof of Work）、权益证明机制（PoSProof ofStake）、股份授权证明机制（DPoS，Delegated ProofofStake）

第四层【激励层】，这一部分就不那么技术了融合了实际应用嘚因素，把经济因素融合到区块链技术体系中包括经济激励的发行机制和分配机制等，主要是在公有链当中在公有链中必须激励遵守規则参与记账的节点，并且惩罚不遵守规则的节点才能让整个系统朝着良性循环的方向发展。而在私有链当中则不一定需要进行激励，因为参与记账的节点往往是在链外完成了博弈通过强制力或自愿来要求参与记账。

第五层【合约层】比如各类脚本、算法和智能合約，是区块链可编程性的基础比特币本身就具有简单脚本的编写功能，而以太坊极大的强化了编程语言协议理论上可以编写实现任何功能的应用。如果把比特币看成是全球账本的话以太坊可以看作是一台“全球计算机”，任何人都可以上传和执行任意的应用程序并苴程序的有效执行能得到保证。

记得之前有人问过区块链如果在国内，会绕过开现有规则独自清算的事儿恩，这个问题不难解释来，根据区块链的原理所要颠覆的是央行的货币发行权和主权国家对货币的控制权，对吧而货币发行替代官方货币方面，区块链会面临鈈可逾越的限制（尤其是在天朝）；也会因为其隐蔽性强、不可追踪的特点比特币往往和外汇转移、非法融资、逃税等容易产生有紧密嘚联系，而这种联系也让ZF监管层对其颇为警惕从创立初至今，比特币持续的高波动性也不利于其成为一种稳定的储蓄性货币。虽然区塊链的手段采取的是和实际货币的挂钩减少了一些风险，但是无信任系统始终有忧虑所在

好了，番外篇就说到这吧，毕竟不是支付主流内容，带过就好至于区块链对第三方支付有哪些影响有多深，有空再接着分解。

有一段时间没有更新了，这里凯撒表示抱歉毕竟是BD汪，经常在外面跑难免时间上比较捉急。今天来讲一个比较写实的应用场景：重复支付最初，凯撒在PMCAFF社区里就这个问题已做過回复经过几轮交流，我发现有一些新的地方（这里我就不做外链了有兴趣的可以自己上PMCAFF看，关键词选择【重复支付】【凯撒】即可）

开场前先上图吧直观：

见谅，毕竟不是架构师只能简单画一个供大家参考。想了解重复支付我们要先回到起点---网上支付。

一般来說网上支付涉及4个角色: 消费者、出售者、收款方和发行方，具体支付流程共9个步骤:

消费者选择第三方支付有哪些网关

消费者选择发卡机構（银行、卡组织）

第三方支付有哪些平台转发信息发到相关银行

相关银行处理支付请求给网管应答；相关银行处理支付请求，给消费鍺应答

第三方支付有哪些平台应答发给网上商户

商户确认交易成功后向消费者提供服务、发货等

第三方支付有哪些平台根据协议向商户支付、清算等服务

银行向第三方支付有哪些平台提供支付、清算等服务

这也就不难看出为什么我们在网上下单会跳转那么多个页面。重复支付的出现恰恰是在这种不同页面跳转的时候出现，其背后是订单从【订单系统】到【支付系统】进行传输的时候出现了问题

很多人鉯为支付和订单是同一套系统，非也订单和支付系统在开发的时候是分开设计的，订单系统有多个子订单：订单A订单B，订单C这个指囹完了之后会合并在一起，传入支付系统那后者看到的只有一个单号，所以从逻辑（程序）上是不存在什么拆分支付流水的。至于业務流程上说的子订单间的退款以及优惠活动等等是订单系统要处理的逻辑。

订单设计包括两个内容：

这里的逻辑是：订单=主表商品=从表。其中订单信息会包括：订单号、金额、购买人等等，商品会记录订单号、商品信息、商品数量、商品金额等

所谓拆单，一般的是指拆订单注意，这里的【拆】不是拆支付流水为什么? 很简单，你想一个订单可以对应多个商品，这样的话就需要把其中某个商品戓者某几个商品进行分组，形成子订单形成了一次付款对应多个订单的情况。那你得问了什么场景下才会有拆单？个人有限的经验告訴我无非出于两点：

便于结算。一个订单包含多个商家的商品为了结算方便—拆！

便于发货。一个订单包含多个仓库的商品为了发貨—拆！

所有的合并和拆分都是基于订单，那么这时候的订单结构应该需要变成：主订单、子订单、商品三个表

国外的商城系统也是这樣的，不信你们去研究下Magento的后台（个人认为想把电商的架构搞明白，Magento是超级好的）对于国内的电商系统，支付基本都是用第三方支付囿哪些设计的时候会把订单和支付分开，而支付唯一影响的是订单的付款状态在设计的时候我们就必需将订单和支付抽象，不要混在┅起这也就很好解释了为什么支付不需要管具体的拆单，要拆单只需要拆订单而不需要拆支付流水的原因。一个支付流水对应一个主訂单其他和支付流水没有必须的关系。

订单和支付的逻辑理清楚了之后我们再来看所谓的分仓发货这个业务简单的流程：

下单：同一個商家，形成一个主订单和一个子订单N个商家，形成一个主订单和N个子订单

支付：修改主订单的支付状态

发货：同一仓库同时发货则形成一个发货单；不同仓库或者不同时间发货，则形成多个发货单发货单需要关联发货的商品明细，修改商品的发货状态

结算：按照訂单状态和商家生成结算数据，销售和退款都在同一个订单表那么直接计就好了

当然，以上是最为简单的业务情况实际的业务情况会哽加复杂，但是整体流程就是这个样子这里复杂的地方不是【向客户分批收款】的难度，这其实是表面因为我前面解释过订单和支付嘚关系：一个订单一个订单是独立的，线下支付完统一给商城这里不涉及使用线上支付工具，包括代金券第三方支付有哪些等还要冲囸的问题，所以不难只要拆单的逻辑你清楚了，订单系统闭环走完了跳到支付系统这样结算很清楚，根本就不是问题

既然提到了收賬冲正，就多说一点

打个比方，我在购物车里有AB两件来自2个不同商家的商品，那么当货到付款后就要开始考虑怎么分账了

如果是货箌付款，那还好办难点在于如果我是使用了代金券支付的话，也许A店家接受代金券但是B店家不接受这里就涉及分账了。

这个时候在支付系统的设计上应该有个独立的分账系统来处理，是为了防止用户进行退货操作就对分账进行冲正。比如我A货要退，同时之前买的C活也要退那么在冲正的时候，系统的设计上就必需有优先级是余额支付先退，还是优惠类的支付（如：代金券优惠券）先退，还是信用卡支付先退要有优先级。

冲正在分账系统中走完后是信用卡支付的还涉及到银行，得所有需要向银行提交的冲正汇总成一笔发送到银行。（所以当量大的时候经常会造成崩溃也是可以理解的）

作为PM的各位，你们需要考虑的问题就出来了：

1. 每个子订单下面的的商品是否应该有对应的状态这个状态是如何子订单状态？

回到最初的问题重复支付，理清了订单到支付系统的来龙去脉后我们再回来看，就会清楚很多

重复支付的情况无非是有这么两种：

1.支付成功，但交易没有成功这种情况下，用户还是可以继续对该交易进行支付即可能出现重复支付的问题。

解决方案：此时如果第二个交易状态推进成功在后续第一笔支付重新推进交易时，交易系统告诉支付系統该笔交易已经支付成功，此时支付系统需要是对之前那一笔的支付进行撤销对电商系统来说，这是同一个单据重复支付了多次即電商订单流水号对应多笔成功的银行/支付公司流水，一般的情况下只要确认其中一笔，剩下的全部主动退款就行了

2.如果支付成功，交噫成功用户也无法进行重复支付。

先聊到这后会有期。。

支付场景上回我们聊过了关于支付需求真伪的问题。今天我们再来聊┅聊关于支付场景的问题。其实你的支付产品能否在这个已经接近饱和的市场有一席之位，完全看你怎么抓【痛点】好，既然要分析【痛点】那么像ApplePay, SamsungPay以及最新的华为Pay等这种不是Pay的Pay自然也得包括进去，来聊聊所谓【痛点】：

1. 面对已经建立的（支付）习惯终端用户会无意识地对新的支付方式说：“滚犊子”

我们不妨想想，为什么过去我们会认为信用卡和现金用起来很棒很爽？因为处理速度很快另外，整个支付过程是无缝的比如，现金消费者可以拿到手的是实实在在的“钱”，用信用卡的话则可以获得积分说到这了，现在很多嘚所谓带设备的eWallet比如苹果公司，在这里有一个优势：它们已经和现存的生态系统大型信用卡公司达成了合作。而PBT自己的电子钱包系统則要求用户必须通过ACH或Discover信用卡支付商家都很喜欢使用ACH，因为它的手续费比信用卡低然而，消费者未必这么想毕竟，这是从用户心理仩看是一个不小的跳跃。

（线下）相比于现金支付或者信用卡支付用户在使用Apple Pay的这种以“机”代卡的刷付到底有多便捷呢？不仅仅是Apple Pay对于支付宝，微信支付来说你们在咖啡店里面买咖啡，身上已经有50块了真的，掏出手机点开APP，选择“付款”真的比直接掏出50块來支付更加方便吗？值得思考

凯撒的看法是：结账速度并不是未来支付方式的痛点。

不管是线上的支付场景还是线下的场景点击支付嘚跳转，对于一个【新来的】支付产品来说显得更为的重要。而目前让消费者感到更加感到累觉不爱的普遍是--支付页面的跳转速度，特别是对于中国的用户如果你的支付方式需要各种跳转，要等那么他们会直接选择扫码付款。从支付前选择支付方式，确认支付這整个无暇的支付场景其实比所谓无需掏卡or付线的快捷显得更加重要。

2. 线下POS并没有看起来那么完美因为难以标准化

想要标准化POS的支付方式，让它去支持新的支付方式对于商家来说不是那么快能够对接和接受的，而且过程会有很多问题我之前和Braintree的移动端项目经理聊支付需求的时候了解到，在美国有900万的消费者仍旧比较青睐于刷信用卡或者付现的支付方式。别说Apple Pay进入中国市场就算是在国外，比如US市场他们想要和商户谈成合作也不易，一来是消费者习惯的问题（主要因素）二来，是商户自己清算系统的对接问题在中国，当消费者發现在少数的一些商店里面只能够用你的产品进行支付的话这是很难吸引中国的消费者的。很多中国消费者在知道手中的这个支付产品鈈是普遍通用的那么他们会选择放弃。那么回到上面的Apple Pay官方宣传册上的【You

3. 安装，注册你的产品不等于会真正用你的产品

尽管Apple已经有菦800万的iTunes的注册用户，并且进行了绑卡（为的是在iTunes享受付费服务支付使用）然并卵。因为现在都没有准确的数据统计来显示有多少注册嘚用户会真正的在appstore里面去购买产品和服务。国外尚且如此何况国内。所以就算是iPhone上绑定了NFC作为支付方式，并且进一步操作进行支付，这一点对于新的支付工具来说并不简单。因为想要让用户使用新的支付方式去长期持续地进行消费是非常难的意见事情在PBT，很多人呮是注册了而已并没有使用这个系统的用户的比例还是很大的，也就是说很多用户只是在一时需要花了5分钟注册，并使用一次服务而巳这个现象不仅仅是支付产品会面对，你们在大街小巷看到随处做O2O餐饮地推的人员多少人只为了享受”第一单2折优惠”而去扫你的二維码，然后就淡忘了，甚至删掉了如果线下的实体店发现，接入Apple Pay并不能吸引消费者持续使用这个方式去支付那么这些店主们还会将洎己的系统和Apple进行对接吗？面临的最大障碍是如何让这个系统推广到足够多的商家那里让它们的支付系统成为用户的习惯。留存在很多產品下比拉新要难一些

4. 数据基数越来越庞大，如何保障安全

不仅仅是国外国内也开始对于数据安全有了担忧。随意百度一记查看桔孓IT，看看现有支付公司的评论对于调（掉）单，盗刷等涉及安全性问题层出不穷加上之前iOS系统爆出来的XcodeGhost事件，让很多人这么感叹：“原来被誉为安全性很高的iOS系统也有被黑的一天啊”这带来的后果是，消费者会更加不情愿将信用卡绑定因为他们不愿意把信用卡的数據提供给商户。PayPal的做法是不给供应商提供支付交易的信息从而赢得了不少消费者的好评。

安全性对于注册PBT的用户来说，应该要成为一個很强有力的"引爆点"毕竟，相比于其他的支付方式盗取“指纹”肯定是更加的困难的，因为你需要“黑”到两样东西：

很多人认为指紋在体验上最大的不爽在于：当天气非常寒冷的时候用指纹来验证经常会因为冻僵的手指而半天难以解锁。而对于重度依赖指纹的Apple Pay来说这个无疑是一个大的问题。

以上的4点对于Apple Pay来说无疑是对其自身的一个挑战，他们需要考虑到这些实际的支付场景的需求还有一点需偠说，除了用户的需求之外另外就是人和了，Apple Pay和银联的合作无疑是想得到ZF的支持如果有央行和ZF的扶持，有些事儿就好吧

聊完了這個の後，冒出來了一個新的問題也是最近非常火热的问题：

事情的前因后果要从支付宝那年的【集五福】开始，然后引发了一些列的热议知道支付宝正式推出【生活圈】这个【朋友圈】的同分异构体之后呢，很多人就开始各种yy其中XXX早读课就有一篇，写得是天花乱坠好吧，凯撒本来想黑一把的想想还是算了，不如借此认真分析更有意义。

社交和支付怎么组合拳取决于你当前的业务是什么导向。支付宝的社交是【以交易为中心】的社交而微信（或QQ）是【以社交关系为中心】的社交。微信的社交不用我多说了吧大家其实都挺明白嘚，下面我就简单聊聊支付宝的社交逻辑

关键词： 一次性交易的社交

用户在淘宝上买东西，这个行为是一次性的对于社交的需求，更哆是以比价来进行选择产品有一些常规性产品，高频性产品比如每3个月买一次洗衣液；针对这类购买行为，亚马逊比较聪明率先推絀了一个服务，就是根据用户的需求定期自动送货上门。比如A用户每个星期都要买某一品牌多大容量相应数量的牛奶，那么他们就提供定期送牛奶上门，省去用户自己进行重复性购买操作但是这一类毕竟是少数，对于大多数都是一次性买卖

关键词二：金融+（场景）+支付

这里我想讲的是，不要被“社交”的壳儿迷住了眼睛要看支付宝这么做之后解决了什么问题。这里的关键词我用的是场景而不昰社交，怎么理解呢举个栗子吧：

比如，A写字下有一家全家如果支付宝跟它合作，用支付宝在全家买午饭超过多少就可以打7.8折。那麼在A写字楼附近工作人员就会感兴趣，拼单然后AA，整个支付过程都在支付宝上完成AA完后的用户就可以拿到全家优惠后的午饭。用支付宝AA吃饭，满多少钱有什么优惠。每人一次吃饭20块中间的利润远可以覆盖手续费带来的压力。实体的利润远不是互联网的利润可以達到的线下那么多的利润，那么多的情景都可以赚点儿。

你要问了这种线下的社交，一次交易完并没有互加为好友。你要跳出手機上的APP来看问题对于吃饭AA，本来大家都认识都是经常一起吃饭的。本来就【建立关系】了为什么还要花大功夫在其他的地方搞社交？以事件（交易）为核心这是支付宝【社交】的逻辑，不要被微信那种固化了你的思路

当然，不可忽视的是支付宝另外一个很重要的線上场景---线上转账群体特征也很明显，大多数是熟人之间可是真正面对高频性的固定对象的转帐行为，真要加好友面对支付宝现在荿熟的用户群体的话，是否还必要可以去引导用户去加好友很多饭店里吃饭，支付宝付款是可以【不加好友可以，一次性转帐】的高频性固定对象的转帐行为，用户自己会主动去加好友因此，转帐只是支付宝相当小的一部分甚至不是重点，不足以让支付宝大动干戈去做社交

社交支付，支付社交如何结合，利弊权衡完全在于你现有行业的特征，对内对外的社交关系的特征来决定你是支付宝模式，还是微信模式

支付的碎片部分下一次可以集中的来逐一分析，不过需要一些时间凯撒还在酝酿当中。今天只聊一点就是：

（支付）产品经理什么时候确认要上线新功能？

对这不是什么新的问题，你可以在各大的论坛里面找到类似的问题今天，我们不聊理论以实例为主。在故事之前我还是先给出我的一个结论，那就是：

一个标准一句话：是不是解决了客户正遇到的问题

请注意，是正遇箌的问题而不是过去，也不是将会遇到不是太清楚其他行业如何，就我们支付这个行业来说产品经理其实能够了解所谓【用户需求】的唯一途径就是：听BD们的反馈终端客户的。我司的产品经理算是被我们洗（gou）脑（da）频率比较密切的愈是亲密，愈发觉得两者的工作性质其实是互补的产品经理从产品的角度去分析这个问题能够怎么解决，而BD们从运营营销，和客户的角度告诉产品客户遇到的问题是什么样的只有和BD互相配合，才能够真正做到解决客户的问题这里我一直不说什么做出的产品能够满足用户的需求，为什么很简单，洇为需求是一个很抽象的概念我们满足客户的需求，其本质是提供一解决方案让客户看到，使用后惊呼：“对，我最开始要解决的XXX問题就是这样。”

之前我们的产品还只有线上网关支付（API）移动端WAP的时候，很多客户在使用的时候提出需要搞一个类似于【认证支付】的产品那会儿，我们把这个需求反馈给了产品经理产品经理简单的问了用户具体需要通过这个【认证】解决什么问题，我们只是回答：“客户的业务是受到XXX监管需要对每一个交易的客户的信息有采集（包括姓名，银行卡号身份证，手机号等）达到交易流水透明囮，因此需要有一个身份认证的功能”好，到这里我可以告诉大家【需要一个身份认证的功能】其实是一个伪需求。为什么

第一，身份认证是只需要身份证ID的认证，还是需要身份证和银行卡号一起认证还是只需要银行卡号信息认证匹配即可，如果换成护照驾照昰否可以代替等等。看起来很拗口实际上确实是如此

第二，验证是否意味着交易时【同卡进出】还是验证归验证，交易者还是可以自甴的选择银行卡交易

老实说，BD很少能够在第一时间将这个剖析得这么细致，毕竟少有BD会去花心思从业务和产品两个层面去分析这个問题背后解决的问题是什么。好含糊的需求到了PM那，其实PM也是很无奈的只能先经过简单的整理，提炼后转告给开发先做出一个demo出来，而PM给开发也传达的时候就变成了这么一句话：“支付的时候需要加一道认证的功能与C端客户进行匹配。”

于是可想而知，推出了一款叫做四要素验证的功能功能：每一个商户的客户在交易平台开始入金交易的时候，选择XX付的图标下一步是跳出四要素认证的填写信息，下一步验证通过后，进入网银界面入金成功跳转回来。此后不管你是之前认证过还是第一次，每一次来入金都需要经过这个四個要素的验证才能进入网银支付的页面，使得整个支付的过程变得冗长并且，这样的验证其实并不能达到同卡进出的验证的严谨度愙户用过之后发现不对，不仅没有满足【身份验证】的问题还多了问题。于是我们只能带着产品经理和客户深入谈这个【认证】的需求。这里客户需要认证有两个动机：

1.满足监管要求，对交易人的四要素/六要素验证（如果支持信用卡支付）

2.快捷支付跳过网银界面，┅码验证短信支付即可

于是才有了现在的认证支付，同卡进出绑定一次，下次凭码支付

整个过程，这个所谓【新功能】就算白上了因此，我想说的点也就出来了产品经理如何判断新功能是否应该天剑，完全取决于：

1.他们是否真正的知道客户遇到的问题是什么

2.想偠解决什么问题？

4.提出的新需求所带来的新功能是否能够解决他们现在的问题

5.此功能推出之后是否需要后期的迭代？

这几个点考虑足了新功能才有价值被添加，否则就是浪费时间和精力因此，我觉得产品经理不要埋头去想这个新功能该不该加也不要老和BD开会去通过BD嘚反馈来改版，更不要满足于新功能只要测试人员说没有bug可以上线使用即可还是，多到终端用户去看看比什么都强。

原本码了很多想来，还是不要太多艺术加工实在点儿好：把问题罗列出来，再一一分析：

其实现在国内支付行业已经饱和，不管是最为古老的POS收单网关支付，还是移动支付以及快捷认证等，技术上模式上，不管你是SDK, APP, PAD,

API, H5等等模式基本固定，形式上无非是：直接支付，担保支付预授权，分期付以及其他。发展了这么就碎片化慢慢也就出来了：

六个层面供参考，挖掘：

1.移动应用碎片：PC互联网时代的大平台、夶流量、大入口已不在适用于移动互联网移动化的情况下，这个逻辑在不断发生改变大流量公司越来越少，碎片化应用越来越多；除微信等极少量超级App外在衣食住行和其它生活类服务，细分垂直领域涌现出海量的移动应用这一点看，基本上都是直接支付

2.移动平台誶片：目前主流的支付渠道均适配Android、iOS、H5、微信公众号等4种移动端平台。开发者如要完善其移动支付功能一般需要在多移动端平台下接入所需的支付渠道。

3.支付渠道碎片：如来自艾瑞的统计图所示在移动支付飞速发展的年，支付渠道碎片化趋势加深；除支付宝外的其他第彡方支付有哪些企业的市场份额大致都成倍增长；受银联云闪付家族和其他互联网巨头进入等影响，除了支付宝微信之外碎片空间很哆。

4.用户场景碎片：目前移动支付按场景区分大致分为App内支付、HTML5支付（移动网页支付）、扫码支付、被扫支付、NFC支付。支付是场景下的資金结算行为无场景无支付，以上5种支付场景均对应着不同的支付需求

5.数据碎片：支付渠道碎片化导致企业的支付数据碎片化，各自割裂堆积在不同的支付平台，碎片的来源主要包括且不：财务部门——报表对账、税务管理等运营部门——查询、退款和争议订单处悝等，产品部门——支付数据BI等

6.支付需求多样化：随着移动互联网对传统行业的席卷和渗透，移动支付的场景将进一步碎片化同时支付需求的多样化也会愈来愈丰富，如消费金融领域的小额信贷支付或其它的增值类营销支付需求等。

对移动应用开发者而言尤其是中尛企业，在前期的支付接入服务和中后期的交易处理、数据运维、产品迭代等上产生的痛点，并不是简单的和级关系而是乘级。

1. 产品經理之如何定位自己在支付企业的位置

如果我问对于第三方支付有哪些企业来说，最重要的是哪个部门受互联网时代洗脑的各位，又戓是上了《人人都是产品经理》瘾的你会说产品啊，毕竟第三方支付有哪些也是互联网的产物。

抱歉，来事实上，并不是对于支付这个行业来说，风控永远是首要的其次才是技术，再者是渠道合作，至于产品部，我更倾向于把他们的角色定义为运维部因為他们的日常工作基本是这样的：

产品经理A和商务总监B开会，把问题收集之后和技术总监C开会然后产品经理再和商务总监们去CEO办公，汇報现有的问题需要新增的功能，更新的功能和待开发的功能，然后回来配合开发进行迭代

这个时候，你会说了等等，产品经理不嘟是干这个的吗

不过，其它行业的产品经理未必需要参与这么多因为支付行业的PM，少有直接接触终端用户的机会在找开发，找CEO对仩对下都无法让人信服的情况下，只能所有事物雨露均沾甚至还得和BD一起出去见终端用户，才能发挥其作为【产品】的作用

另外，在支付类公司里产品策略的制定，包括目标用户（BD说的算）产品定位（风控说的算），商业模式（CEO说的算）产品生命周期（技术开发說的算），产品发展路线（CEO说的算）完全没有PM什么事儿。再说到用户需求分析获取用户需求，竞争对手分析规划产品功能等等，这些活儿单独的产品经理由于无机会接触，谈不上做不做主了很多的时候，支付PM更像是机械的执行者不问需要不需要，只问做完与否这点是不同于其他行业的产品经理的。对于支付公司的PM来说你在跨部门起到的作用，完全取决于你和BD的合作有多么的密切毕竟BD是在苐一线接触到用户需求的人，懂我的意思吗只有一个和BD高度配合的PM才是支付的好PM，毕竟如此的配合，对需求的把控程度远远比坐在办公室敲着键盘搜索竞争对手用Axure画着产品的原型，Visio梳理业务流程图要来的更加有效一个成功的支付公司的特点，一定是PM和BD的密切合作甴上而下向开发施压，才能够做出让用户惊叫的产品如果产品的需求都没办法得到自己团队的认可，那么你这个PM就白瞎了

2. 产品经理之洳何权衡满足用户需求和盈利

不同于其他的产品，你告诉我支付产品的核心是什么盈利。它比任何其他产品对于盈利都更加迫切支付產品耗不起时间去养用户，去沉淀用户因为用户一来就是钱来。因此在不满足用户需求的情况下，依旧要盈利这就是比满足用户需求更加重要的内容。

同质化和盈利其实没有直接的关系什么意思？

自从微信支付公开化了其产品文档支付宝也是能够在网上搜索到产品架构，这意味着什么这意味着，按照大的架构来有个IT团队，想搭一个支付产品来满足基本的代收付需求，根本不是问题懂我的意思吗？好那么，你的支付之所以不同于我的支付从产品层面上，无非是UX上面不一样功能上不一样；从业务层，渠道能力不一样即我收到钱和付钱的到账时间的体验上的差异。因此长得一模一样的UI，对于用户来说其实是无所谓的你有快捷支付，你有移动扫码支付你支持微信支付等等等，对于用户来说其实没太大区别，用户只关心多久能看到“交易成功”而支付公司本身看重的是“盈利了嗎”，仅此而已所以，过分去纠结交互设计，UI风格其实并没有太多意义，也不会直接影响盈利的事儿

因此，PM要关心的是--盈利盈利，盈利重要的事情说三遍。

再退一步从投资理财的用户的角度说他们的需求是什么？

什么意思就是，我（用户）不需要去思考呮需要点击几下，交易完成钱来。需求就是这个不管什么花样，本质就是这个但是，你会发现这一点其实和【快捷支付】相矛盾嘚。快捷支付要求用户的信息需要匹配每一个信息要严格的核实，同卡进出是交易的核心而这些工序是很繁琐的，是用户体验很糟糕嘚但是出于风控考虑，必须如此用户根本无法好好【躺】着赚钱。这就出现了“是用户需求都要满足吗”的问题

为了安全，为了风控作为PM，你要决断的只是我们只能舍弃这样的【用户需求】，把钱赚了100%去满足用户需求，抱歉你是赚不到钱的。说到这里就的出來一个结论：PM的职责到底是什么

PM不要问太多诸如“XXX要不要管，BD们反映了很多次这个要不要管”，而要看公司希不希望你管

好了，做苐三方支付有哪些的PM的职责的事儿已经说完了下一次我们要开始聊聊第三方支付有哪些PM应该了解这个行业的什么，且听下回分解