【不定期更新】【连载】《YES！第三方支付行业没有PM》
满打满算，在支付行业也漂流了一段时间了，打算借这个机会，以支付作为切入点，聊一聊，那些BD汪的日常，聊聊和产品，和开发，和风控，和客户的那些事儿。
（不定期更新。。。。内容涉及商户谈判、部门会议、协作技巧、与开发撕、与风控磨、等等等。。。分享来自于实践，但出于职业操守，很多会艺术加工一些情节，无针对任何人，事儿。。。）
2018.05.11 更新，关于跨境支付
《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-波兰本国的银行转账支付方式
Sberbank-俄罗斯最主流的银行
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是一家外国公司（外国公司对自己的信息隐私和安全问题是非常非常的敏感的），还是英国的公司，这个老牌金融国度的公司是否能够接受这个条件，接受到什么程度，我们打一个问号。另外，还需遵守《非金融机构支付服务管理办法》，这里面需要商榷的地方估计还很多。另外，我们要知道这只是跨境人民币清算资质，也就是说入和出都是人民币，对我们大天朝来说，怎么整都是获益的；
闲篇先扯到这，书接前文。我们来具体说道说道国内的跨境支付清算系统到底是个什么玩意儿。
这话题有得说，我们从最为简单的事先从CIPS开始了解。CIPS, Cross-border Interbank Payment System, 这是央行在11年上线的跨境人民币清算系统，为的是加快人民币清算效率。在凯撒谈CIPS之前，有必要了解一下在没开发出来的时候，天朝的跨境人民币清算的主要渠道。我们说，一个国家的货币的全球清算体系包括：境内清算体系，离岸清算体系和跨境清算体系。
境内清算体系：处理货币在一国境内的支付结算业务，以银行间大额支付系统为枢纽，包括各类银行间批发、零售清算系统和商业银行内部清算系统。
离岸清算体系：处理货币在境外国家或地区的支付和结算业务，一般由东道国xx银行担任清算行并运行该清算体系。
跨境清算体系：处理货币跨境的支付结算业务，人民币的跨境清算目前主要有人民币代理行模式、人民币境外清算行模式和非居民人民币账户模式。
这里，我们主要聊一下人民币跨境清算模式：举个例子，以甲行代表国内某银行，乙行代表境外某银行，
那么，人民币代理行模式是怎么玩转的？乙行在具有国际结算能力的丙行了人民币账户，并通过该账户实现人民币的跨境清算。包括经常项目、资本项目交易的结算清算，人民币兑换，账户融资，银行间债券市场代理结算等。
人民币境外清算行模式：甲行和乙行在境外人民币清算银行丙行开立账户，通过该行进行人民币跨境清算。目前，经人行授权的境外人民币清算行共有12家（都是中资银行海外分行），但除了中银香港和中国银行澳门分行以外，其他清算行都没有同国内的大额支付系统直接连接。可想而知，这个带来的结果是必其他10家清算行都必须经由港、澳两家中行完成人民币在人民银行层面的最终清算。
非居民人民币账户（NRA）模式：经人行核准，境外企业可在境内银行开立非居民人民币账户，直接通过境内银行行内清算系统和人民银行跨行支付系统进行人民币资金的跨境清算和结算。
以上是人民币跨境清算的三种模式，每种模式的实现都涉及到清算系统。
（CNAPS, China National Automatic Payment System, 是指中国现代化支付系统，由大额支付系统HVPS和小额批量支付系统BEPS（Bulk Electronic Payment System）组成。这里太多名词，太拗口，我们来个缩写吧，HVPS简称大只，BEPS简称为小只，CNAPS为中只；HVPS, High Value Payment System）
在代理行模式下，境内外银行通过环球报文交换系统SWIFT（是的，就是大家非常熟悉的swift来处理）传递跨境支付信息，然后通过大只进行清算（国内的代理行都直接接入了大只系统）。境外人民币清算行模式下，境外银行通过SWIFT传递跨境支付信息，境外人民币清算行通过中行港、澳分行最终连接到境内大额支付系统完成最终清算。
非居民账户模式则是境内银行直接通过大只系统进行清算。所以，我们可以看出所有的人民币跨境清算模式最终都是通过CNAPS开展的。
大只采用的是逐笔实时方式处理业务，全额清算，犹如人民币清算网络的大动脉；
小只采用的是在一定时间内对多笔支付业务进行轧差处理，净额清算资金，就好像人民币清算的毛细血管一样。
然而，在跨境人民币清算过程中，中只系统有其一定的局限性。因为中只的建立主要是为了满足国内银行间人民币支付清算的需求，并未考虑日后跨境人民币清算量日渐增加的情况。中只在进行跨境人民币清算有何局限呢？
其一，运行时间过短，不适合跨时区清算。这个系统有这么一个规定，那就是上午8:30开，下午4:30关，也就是说一天只有8小时工作时间。这个说实话挺烦人类的，你想啊，对于6、7个小时时差的地区的商家来说，他们是根本没有充足的时间来处理清算业务的。
其二，与国际清算系统接口无法完全匹配。这个就比较奔溃了。在代理行和境外清算行模式下都必须通过SWIFT报文系统传输跨境清算信息。但是，你要知道哦，SWFIT这家伙是不支持中文报文，且一些字段与大只的支付系统报文不兼容，这点非常奔溃，很影响清算效率。
第三，部分业务无法实现实时跨境结算。大只尚未与境内外币支付系统、证券清算系统互连互通，难以实现跨境清算所需的人民币和外币同步支付结算和人民币证券券款对付结算。
鉴于以上中只的局限性，同时考虑到随着人民币国际化的不断推进和资本项目的不断开放，未来跨境支付结算量将稳步增加，现有的清算体系将不具备可持续性。于是人行下定决心针对跨境人民币清算开发一套新系统，这就是CIPS。CIPS将与CNAPS相互独立，但又互连互通。境内机构可以作为这两个系统的直接参与者，而境外机构将不再与CNAPS直连，只是作为CIPS的直接或间接参与者。那么，CIPS将如何解决上述CNAPS存在的问题：
其一，连接境内、外直接参与者，处理人民币贸易类、投资类等跨境支付业务；其二采用国际通行报文标准，支持传输包括中文、英文在内的报文信息；最后是，覆盖主要时区人民币结算需求，提供通用和专线两种接入方式，让参与者自行选择。CIPS上线后将对目前的清算模式产生影响。代理行模式仍然存在，参与者可以自行选择使用CIPS或是继续使用代理行模式。
好了，最后扯一个闲篇：
外资机构进入中国支付监管大军后面临的挑战：
以支付宝和微信支付为代表的内资支付机构已经在一定程度上构建了用户黏度，因此，当外资机构入华后在用户转换、商户开拓等方面均面临不小的挑战：
纳新：外资机构在用户数量基数很低的基础之上，将面临高成本用户转化（毕竟国内用支付宝微信的基数是非常大的）
转化：不同层级和不同行业的商户对于获客、对账、借贷等方面的需求都不尽相同，对国内商户缺乏理解的外资支付机构如何把握和满足商户的需求，打个问号
监管：金融一直是我国强监管行业，移动支付涉及用户众多，监管机构对稳定、安全的要求较高。
利润：相比国外1%上下（不考虑paypal）的费率，国内第三方支付在千1千2上下的费率，再加上国内支付机构大范围的推广补贴和优惠支持，第三方支付已经变成不赚钱或微利行业。外资支付机构的获利能力将面临巨大考验。
面对以上的多重挑战，短期内外资支付机构的进入不会改变行业竞争格局。银行体系主导的网上银行支付仍然占据金额的绝对领先地位，非银行互联网支付机构在小额支付领域的第三方支付业务将依然由支付宝、财付通等支付巨头主导。
外资进入对国内支付市场的积极影响在于可以带动新的行业竞争，特别是创新的产品，其次，外资进入也有利于整个行业服务品质的细化和提升，这可能能够给国内第三方支付机构的发展带来新的思路，外资支付机构借助国际用户、商户和商业银行联通等优势，开展的高附加值的跨境支付业务。相信在全面竞争的市场格局中，让参与者相互促进，势必会加速网络支付的良性健康发展。
以上
（未完待续）
2017.12.29 更新，关于备付金存管
今天最新的新闻，第三方支付机构备付金交存比例最高达54%，然后就各种微博知乎的喷子们开始炸毛了。言论这东西真的是听风就是雨，一班子不了解支付备付金存管的在凑热闹，你们看清楚文件先，然后结合一下基本货币金融的常识再喷。
集中存管，不计利息且个人存款，带来的变化可能是：
1. 网联尚未完全铺开，没有完全集中存管的先决条件；
2. 我们假设缴存比例到100%，同时网联也已经运行平稳，如何？或者说，通过一个备付金账户完全资金清算，而且把庞大的交易量从各支付机构集中起来，会有什么影响？
是的，按照逻辑上看，现有的银行、支付机构、商户、个人客户的各方格局可能会被重塑：支付机构无法从备付金获利，少了重要的利润来源，没有背靠大树的支付机构生存可能会出现问题(清掉杂牌，不成体系的第三方支付)；
有什么问题吗？有
备付金如果集中在一家银行且不算存款，支付机构议价的核心筹码也将不在；银行将丢失一部分存款，媒体、吃瓜群众又有了唱衰银行的理由；但事实上，这并不会出现这种情况完全上缴的情况，因为国家依旧需要第三方去处理那些散，金额小的资金结算。
支付市场这几年的竞争激烈，商户及个人客户将有更多的选择，应该不会有成本的提升。原来被个别支付机构凭借庞大的备付金存款扰乱的市场价格可能逐步回归理性，让处在生态链上的银行、清算组织、支付机构、商户以及个人用户各司其职，利益共赢，而不是现在只有个别支付机构吃肉，其他市场参与者连汤都喝不着的境地(即以后少了死磕价格战的低纬打法)
说到这，还有2个问题：
1. 支付公司已经不直连了，那通道成本还能便宜的起来吗？
首先，支付公司通过网联连接各银行，价格还得一家一家银行去谈吧。是啊，还是可以自己议价的，只不过系统接入标准化了
从监管角度出发，就能明白未来该怎么做；谁都不想看到这个市场乱了，甚至奔溃了，这才是最大的风险。银行做跨行扣款业务只有银联一条通道 有机会赶紧去接网上商银行和微众银行，支付宝和微信还是跑的通
2. 二代的往账借记业务，我们银行用的很少，限制太多，感觉网联银行也没法接；银行通过网联做跨行业务，支付公司去跟其他银行一家一家谈费率？
不要以偏概全。银联和网联模式差不多，通过网联做跨行转接，最终到达发卡行。这是典型的收单业务
业务模式有些差别，银联是直接定价了，网联目前不定价。网联也要挣钱，不要想的太美好
网联有个定位，银行只能做发卡端，不能做收单端，收单端服务非金机构
银行对银行的收单只能通过银联了？
总之，在监管体制机制上，在新业态新机构新产品快速发展，金融风险跨市场、跨行业、跨区域、跨境传递更为频繁的形势下，监管协调机制不完善的问题更加突出。监管定位不准，偏重行业发展，忽视风险防控。
系统重要性金融机构缺少统筹监管，金融控股公司存在监管真空。统计数据和基础设施尚未集中统一，加大了系统性风险研判难度。中央和地方金融监管职能不清晰，一些金融活动游离在金融监管之外。
动车上码的，先这样
2017.07.10
最近把老有消息提示我说，此文被喜欢，想想也是一年前的事儿了。本系列基本已经完结，各位如果想看新的或者体系化的版本，不如移步到在下的gongzhonghao, 凯撒说，我们继续唠
2016.01.21 续说订单与支付
之前，以【重复支付】作引子，聊了支付系统和订单系统的非耦合的问题。这几天有群在聊这事儿，加上实际业务遇到的问题，感觉，这块还可以再深入下。
一个问题：
用户下单前端页面显示支付成功，服务器端异步返回，显示支付失败，一般要怎么处理？
会问这问题可不止PM，BD问，商户问，测试问，开发问，甚至是终端的C也在问。好，我们来掰扯掰扯这块。我们先从与第三方支付合作的B平台说起。遇到这类的问题，你要做的第一步其实很简单，去确认:
找谁？第三方支付
确认什么？款是否已扣
其结果无非是以下两种:
如果没扣，那很显然是支付失败，可以提示商户让其重新支付一遍。
如果扣了，可以尝试回调，如果回调出现失败，很简单，申请退款。
好，这个问题确定之后，我们才知道应该进一步去解决什么问题。支付这块的反馈，我们根据它来找订单状态的问题。这里，我们就不赘述之前说过的订单系统和支付系统是分开的事儿了（请看11.4）
不管你是谁，如果你是问题的解决人，你要明白一点：把支付异常隔离在订单状态之外，支付归支付，订单归订单，除非是做虚拟产品的，实物有仓储和发货的环节的都是逻辑分开设计的。
支付的状态无非是这么几个：
待支付未唤起
待支付已唤起
支付成功
支付失败
而（实物商品）订单的状态有这么几种：
待支付
待发货
已发货
因此，支付是否成功与订单状态不耦合，但是，和状态相关。显示支付成功这一步通常不在自己（也就是非第三方支付的B平台）这里做，而是跳转到第三方支付，有第三方支付的系统来做。因此，订单中心，关心的东西就变得很简单了：只关心收没收到钱，能否进入待发货的状态，不需要关心智是否成功这事儿。
PM问：异步回调失效，即扣款失败了，订单状态是否改变？
这东西，从客户端说起吧。客户端这块，其实只需要对订单状态证实的时候，不混入支付状态即可，毕竟，发货前核心的环节是款到账，不然，会一定会资损。订单和支付只有两个交互的地方：
1.订单把金额和订单号等信息告诉支付
2.支付把收到钱的消息反馈订单
至于，支付是成功还是返回未知，不关你订单的事儿，因为订单系统不需要管这个。
有人要问了，我是虚拟产品，怎么办？嗯，如果是虚拟商品，收到的一般是待发货，只是多了自动发货的步骤，发货后改为已发货，看业务是否允许取消订单来设计不同的业务场景下的状态（比如，旅游产品）。如果不允许用户支付后取消订单，跳转到已完成就没有问题了。至于服务器端，必须回调成功才改写订单。
再深挖一点，比如说，电商APP，前端支付成功的话，就是银行已经扣款成功了，把成功的消息（也就是所谓的报文）推送到第三方支付平台。如果服务器返回异常，有可能是因为第三方支付没有收到扣款成功的推送消息，或者响应超市，这里可以在系统中优化一下，做一个类似30秒内，第三方平台没有返回结果，就默认为最终支付是失败的，这个时候，你可以更改订单状态了。如果是消费金融，那么完全不一样的业务流程，根据特定的需要去设计是否要这个响应的机制。还是那句话，前端支付成功并不代表你最终的好意是成功的，只是代表第三方支付向银行推送的那笔扣款的请求已经被银行收到，银行开始执行扣款指令。
很多人会去纠结这个状态以哪一个为准。来，你要明白一点，这些都是以订单异步为准，异步通常有的情况不会是【失败】，而是【超时】。而这个问题是和服务器有关的，因此，最终我们是以服务器端为准，但是，回调失败的机制的处理要告知商户，否则商户打电话撕你们的运维同事，那真的是莫须有。
说到这里，算是和我之前说过的【重复支付】的问题衔接到一起了。不管你是支付宝还是微信，还是其他的第三方，同一个唤起号可以在多个终端进行多次支付，一笔订单有两次收款的概率，这块需要你们的财务出来配合。订单里记录所有关联的支付唤起号，业务账户通过系统匹配时，如果检查到一笔订单有两个唤起号，并且对应有支付流水，就出示重复支付退款单，让客服和财务手工处理，一般这个情况不多。如果客户马上发现重复支付，会要求退款，也可以让售后退款环节的运维金系统去排查，根据企业的情况安排退款。实物订单的退款如果能在1~2个工作日处理，一般不会太容易引起纠纷，当然，遇到钉子户另当别论。
今儿到这。
2016.12.09 完结？不
原本打算完结了，最近遇到一些很有趣的东西，打算借机补充一番。
前方高能，，，各位坐稳，等着
2016.12.03 完结
相信，【网联】这个词儿大家并不陌生，很多业内和业内相关人士称【网联】的建立是之为支付之殇，今天我们来细细聊一聊。
敢问【网联】路在何方
网联的出现必须对支付行业提供效率改进，也就是说无论对支付机构、商业银行、个人客户等，网联既然要管清算的事儿，可以，不过，你要做就要做到提升效率、从而增加收益；要嘛你就降低成本。否则，即便你是央行的钦差大臣，你奉旨来办支付这个场子，也只能止血，治标不治本，无法解决自身持续发展的问题。虽说网联和银联都是皇家军，但和银联不同的是，在银联出现的那个年代，联网通用是业界必须解决的问题，是市场发展到那个时候的产物，对于央行也不过是顺水推舟。因此，当银联出现后，我国银行卡产业迎来高速发展。
今日不同往期，现阶段，支付机构直联商业银行直接向用户提供支付的模式已经非常成熟，对吧？那么，在这样一个大前提下，你网联是插队的，对支付机构也好、对商业银行和个人客户也罢，你能够带来的价值何在？如果不能创造新的价值，即便你有央行这个爹也没用。央行整出一个网联不过为了在商业银行，银联，第三方支付这三方博弈中起到一个制约第三方野蛮生长的作用，也就是说，央行并没有要【废太子】的行为。所以，网联的定位和能够创造的价值是网联的首要问题。
总结一下，对网联，要回答的问题是：
我是谁？
为了谁？
代表谁？
看了一圈的材料，包括知乎的帖子，微信公众号现有的文章...凯撒的理解是：整个博弈中,最为重要的是两方，一方是支付机构；一方是商业银行。进一步说，两者背后代表的分别不同利益集团。银联代表传统商业银行的利益，其盈利模式是：银联喝汤、第三方机构嚼骨头。这么多年，大家虽打打闹闹，喷喷垃圾话，但在大方向上心是一起的。好，现在来了个新角色，博弈变成了：网联、银行、机构，将来构建什么样的盈利模式：
谁喝汤？
谁吃肉？
谁啃骨头？
如何打破现有的直联模式下的两方利益结构?
这些都是问题，顺着思路，我们不妨来推测一下：
假设一：复制卡组织四方模式，那必然导致手续费的上涨，支付机构会答应吗？
假设二：作为支付机构的代表，和商业银行的重新谈判，如何保证在银行的配合下为机构争取到更多的利益和话语权？这一点要做到,网联必须要比当年的支付宝更有资源和手段。这一点，我们能看到的只是网联背后有个爹。
说到这里，网联面临的的问题是如何与央行,与银联,与第三方支付机构处理好关系
2. 与央行的关系
这个点好理解，被困扰的问题很明显：网联如何承担央行赋予其的使命？
央行摸着网联的脑袋瓜子说：
“孩儿，老子生你是想让你替老子招安那班第三方机构，这两年他们太嚣张了，无组织无纪律了。”
这领导的话不怕不说，也不怕说明了，就怕不说明了。因此，网联心里琢磨，我要是猛执行爹(央行)的监管指标，这些混蛋们还会甩我？我要是只迎合机构的市场选择的需求，我爹还不废了我，两个字：两难。
3. 与银联的关系
网联的出现，最不爽的或许是银联，毕竟，网联是来和其直接抢饭碗儿的。不过，以银联现在的实力，短期内吊打网联私以为还是很轻松的。这点，央行应该很清楚。所以在给其(银联)一嘴巴之前，肯定会给颗糖。好，我们看央行干了啥?它画了一条【三八线】，严格圈定网联的业务范围，只能处理支付机构线上的交易。这颗【糖】其实并不足以甜到银联的心里。银联不怕，毕竟人家现在有的是最牛逼的线上跨行清算系统，已连接城商行在内的绝大多数银行和支付宝之外的所有第三方机构10+年了，完成的交易量可谓是天文数字。因此，实力摆在这里，银联抛出了一个选择题：商业银行，还是第三方机构，你们选吧，爱我还是他(网联)？
对机构而言，我们退一万步说，如果现在要选择你网联，何不当初选银联不是更好？人家好歹是10多年的老司机了，因此，后果是什么？对，这反而促使他们和银联达成以前达不成的合作，懂我的意思吗？就好像亚马逊一样，不管你是商家还是C端消费者，顶多把小规模,风险高的单子用你结算，大的，核心的单子自然还是走亚马逊提供的支付和物流服务是一个道理。
4. 与第三方支付机构的关系
这块，首先谈的肯定是大头--支付宝和微信支付。我们如果仅仅从新方案来看，支付宝和微信支付无疑是最大的输家。支付宝和微信当然不干，凭什么？辛辛苦苦干了这么久，把国内中小微型的资金流整合了，好嘛，白忙活儿了，这不是捡现成儿的嘛，美的你还。真到了把这俩逼上绝路，他们可以放弃结算这块蛋糕，去做清算业务(申请清算牌照)，有用户为基础，再加牌照，市场依旧是他们的东山再起。
虽然对其他第三方机构来说，他们心理暗爽，但是对于网联来说，真的的这么干了，表面上是失去了这两大占有支付市场大头的支持，实际上是失去的是这他俩巨头背后那几亿已养成消费习惯的消费者。一旦他俩搞出新的方式将主要的交易量的引流，网联就沦落为和其他第三方支付机构一样的吃剩下的角色，被彻底架空，成了鸡肋。因此，网联规划前期主要导入这两家的流量是首要任务，毕竟有用户才能存活嘛，但是，如何导流需要慎重，需要找到能和支付宝微信互换的【利益】点。
对其他的第三方支付机构，网联要考虑的是收了支付宝微信的交易量后，分配多少资源给他们作为拉拢，也就是博弈中的乙方联合丙方对付甲方的策略，这对网联的策略要求很高，毕竟其他第三方支付受到网联冲击和支付宝微信是一样的，只是影响程度没有那么巨大。如果网联决策失误，那么博弈的天平会变成：其他支付公司会和支付宝微信一个战线，联合对抗网联。
网联【路】在何方，这个凯撒暂时也没有一个结论，容我去研究了央行的【账户】分类的事儿之后(估计给第三方的备付金账户也会统一起来，不好说)，或许会有些思路，比较无论是银联，还是网联，要干的是清算这块的事情，涉及清算，那么对账户体系统原理得了如指掌。不过，话又说回来了，即使是了解了，也只能给予一个推论，事态会如何发展，3月便见分晓
对，这是最后一期，因为考虑到写的东西较多，涉及的内容比较杂，因此暂时停更，之后会根据每一次更新的内容做更加深入分析和补充。
多谢各位读者的关注
2016.11.29 更新 （特别篇---支付宝社交迷思）
好吧，，，看了一圈，有各种吹捧的神文，对支付宝歌功颂德，捧上天了，什么深谙人性云云的，，也有对支付宝怒斥，称其带了个表还要立牌坊，总之，无论怎么说，支付宝又是火了一把。
商业上的事儿，什么风口论，什么引爆点论，云云，或多或少有些事后诸葛亮的味道，毕竟，历史是成功人书写的，你成功了，怎么说都有理。因此，凯撒懒得再多去猜测什么，毕竟只有当事人指导，整理整理昨天写的，就发生的这些【现象】，我们来看看后面可能有的几种可能。
诚然，阿里在社交的发力大家是有目共睹，从来往，再到集五福全世界争福，以及生活圈。从营销角度来看，无疑是成功的，毕竟上了头条，成为朋友圈，微博，百度成为最热门的词汇；线下也是大家茶余饭后的谈资，符合所有营销能够带来的效果，但是，这仅仅是赢在营销战。后来的故事大家都知道了，无论是来往失败盯盯来补，还是全世界缺敬业福，昙花一现；我们无论是从商业层面，还是产品层面看到，这些社交衍生都不成功。这里插一句，我不说移动办公领域的钉钉的事儿，因为钉钉是有别于一般社交的垂直社交产品，更专业，更专注，少一般社交产品的属性，本文谈的不是社交，因此不展开了）
为什么阿里之前玩儿不好？
我们抛开企鹅先入为主的影响，从支付宝的角度来看。支付宝做社交，目的不是为了通讯，懂我的意思吗？支付宝不是想让你在支付宝内和对方聊天，那它想做的到底是什么？对，没错，他们想做的其实是巩固用户关系，进而提升活跃度，也就是PM口中经常说的用户留存。这点并不难理解，毕竟让C端用户在一个支付工具里和人侃大山，挺变扭。因此，这样的弱社交，只需要保证用户加了好友后，可以方便发红包和转账即可，这是才是符合（支付）用户场景的设计。
说到支付场景，就可以进一步说说了，支付宝和微信是相反的：支付宝是先有钱再社交，只有钱来才能带动社交，把用户关系导入支付宝；微信是相反的，毕竟人家是社交的科班出身，支付是衍生的长尾需求嘛。微信是有了社交后，在顺应用户场景的前提，慢慢的就做起了支付，久而久之对支付宝的近垄断地位是个不小的威胁。微信的市场份额覆盖广泛，成本低（无论是学习成本还是运营成本），最棒的是一次购买之后下次可以通过聊天，二次下单，因此，你们会看到的是：大到商场门店，小到街边煎饼果子，只需一个微信二维码，搞定，方便快捷提高效率。然而，支付宝是反的。毕竟对方是收款出身，思路是支付的正统内力，想想支付宝红包，AA收款等。。。但这个用户关系可谓是【用完即走】，对于商业来说不回头的买卖不是好买卖。
付完钱，走了，然后就没有然后了。这种短期关系链如何延续自然是支付宝的思路，因此，这就可以理解为什么支付宝要不予余力做社交了。支付宝想的是如何使用现有的海量熟人用户关系，慢慢的把场景彻底变成从：(钱)-人-钱。第一个钱打括号是因为，它起到牵头的作用，之后的场景就是人为起点，我觉得这或多或少也是受到支付宝的启发。
经历过红包大战、好友的聚会收款、线下商户收单的磨砺，支付宝已经不仅仅是一个给淘宝做担保，代收代付的支付工具，而是一个链接整个阿里金融服务帝国生态的聚能环，阿里想要做的是可以让用户在支付宝体系下，随时随地的前（钱）来前（钱）往，想要干掉旧的支付（消费）习惯，想要干掉现在现金流通的交易习惯，首先的首先，需要有用户留存，有一段非常巩固的用户关系。因此，这次的【鸨】只是一个开始，日后会如何发展，再看。
。。。（先这样，待续）
2016.11.18 更新（番外篇）
先说点儿背景：
今年9月，巴克莱银行和以色列一家初创公司宣布共同完成了全球首个基于区块链技术的贸易交易。这笔交易结算在巴克莱银行下属Wave公司开发的区块链平台执行完成，担保了价值约10万美元的奶酪和黄油产品。通过区块链技术，传统需要耗时7至10日的交易处理流程被缩短至不到4个小时。
这笔交易通过区块链替代了传统贸易结算环节中由银行提供的纸质【信用证】，成功实现无纸化担保，私以为，这无疑打响了区块链技术落地的第一枪。
按照目前区块链技术的发展脉络，区块链技术将会经历以可编程货币为主要特征的区块链1.0模式，以可编程金融为主要特征的区块链2.0模式和以可编程社会为主要特征的区块链3.0模式。
你们可以在知乎，在其他地方找到非常多关于介绍区块链基本概念的干货贴，这里凯撒就不赘述了。作为PM，假设有新增与区块链结合的功能的需求的时候，应该对区块链模型的那几点心中有数呢？我来谈谈我的浅见：
首先是【数据层】，我的理解是，这部分是封装底层数据区块的链式结构，以及相关的非对称公私钥数据加密技术和时间戳等技术，这是整个区块链技术中最底层的数据结构。这些技术是构建全球金融系统的基础。安全吗？这个看你怎么看了，毕竟这也经历过数十年的使用。区块链只是巧妙地把这些技术结合在了一起。
第二层【网络层】，这个包括P2P（这里不是你们知道的日落西山臭名昭著的P2P，而是点对点之意）组网机制、数据传播机制和数据验证机制等等。。P2P组网技术早期应用在BT这类P2P下载软件中，这也就是区块链能够形成自己的网络的原理。具体的我也不太清楚，毕竟非技术出身，只需知道这个层面，对BD也好，产品也罢，我觉得够了。
第三层【共识层】，共识机制是区块链的核心技术，为什么？因为它决定了到底是谁来进行记账，而记账决定方式将会影响整个系统的安全性和可靠性。目前已经出现了十余种共识机制算法，其中比较最为知名的有工作量证明机制（PoW，Proof of Work）、权益证明机制（PoS，Proof ofStake）、股份授权证明机制（DPoS，Delegated ProofofStake）。
第四层【激励层】，这一部分就不那么技术了，融合了实际应用的因素，把经济因素融合到区块链技术体系中，包括经济激励的发行机制和分配机制等，主要是在公有链当中。在公有链中必须激励遵守规则参与记账的节点，并且惩罚不遵守规则的节点，才能让整个系统朝着良性循环的方向发展。而在私有链当中，则不一定需要进行激励，因为参与记账的节点往往是在链外完成了博弈，通过强制力或自愿来要求参与记账。
第五层【合约层】，比如各类脚本、算法和智能合约，是区块链可编程性的基础。比特币本身就具有简单脚本的编写功能，而以太坊极大的强化了编程语言协议，理论上可以编写实现任何功能的应用。如果把比特币看成是全球账本的话，以太坊可以看作是一台“全球计算机”，任何人都可以上传和执行任意的应用程序，并且程序的有效执行能得到保证。
记得之前有人问过，区块链如果在国内，会绕过开现有规则独自清算的事儿。恩，这个问题不难解释。来，根据区块链的原理，所要颠覆的是央行的货币发行权和主权国家对货币的控制权，对吧？而货币发行替代官方货币方面，区块链会面临不可逾越的限制（尤其是在天朝）；也会因为其隐蔽性强、不可追踪的特点，比特币往往和外汇转移、非法融资、逃税等容易产生有紧密的联系，而这种联系也让ZF监管层对其颇为警惕。从创立初至今，比特币持续的高波动性，也不利于其成为一种稳定的储蓄性货币。虽然区块链的手段采取的是和实际货币的挂钩，减少了一些风险，但是无信任系统始终有忧虑所在。
好了，番外篇就说到这吧，，，毕竟不是支付主流内容，带过就好。至于区块链对第三方支付影响有多深，有空再接着分解。。。
2016.11.4 更新
有一段时间没有更新了，这里凯撒表示抱歉，毕竟是BD汪，经常在外面跑，难免时间上比较捉急。今天来讲一个比较写实的应用场景：重复支付。最初，凯撒在PMCAFF社区里就这个问题已做过回复，经过几轮交流，我发现有一些新的地方（这里我就不做外链了，有兴趣的可以自己上PMCAFF看，关键词选择【重复支付】【凯撒】即可）
开场前先上图吧，直观：
系统层
见谅，毕竟不是架构师，只能简单画一个供大家参考。想了解重复支付，我们要先回到起点---网上支付。
一般来说，网上支付涉及4个角色: 消费者、出售者、收款方和发行方，具体支付流程共9个步骤:
消费者下单
消费者选择第三方支付网关
消费者选择发卡机构（银行、卡组织）
第三方支付平台转发信息发到相关银行
相关银行处理支付请求，给网管应答；相关银行处理支付请求，给消费者应答
第三方支付平台应答发给网上商户
商户确认交易成功后向消费者提供服务、发货等
第三方支付平台根据协议向商户支付、清算等服务
银行向第三方支付平台提供支付、清算等服务
这也就不难看出，为什么我们在网上下单会跳转那么多个页面。重复支付的出现，恰恰是在这种不同页面跳转的时候出现，其背后是订单从【订单系统】到【支付系统】进行传输的时候出现了问题。
很多人以为支付和订单是同一套系统，非也。订单和支付系统在开发的时候是分开设计的，订单系统有多个子订单：订单A，订单B，订单C，这个指令完了之后会合并在一起，传入支付系统，那后者看到的只有一个单号，所以，从逻辑（程序）上是不存在什么拆分支付流水的。至于业务流程上说的子订单间的退款以及优惠活动等等，是订单系统要处理的逻辑。
1、订单设计
订单设计包括两个内容：
订单信息
商品信息
这里的逻辑是：订单=主表，商品=从表。其中，订单信息会包括：订单号、金额、购买人等等，商品会记录订单号、商品信息、商品数量、商品金额等。
2、拆单
所谓拆单，一般的是指拆订单，注意，这里的【拆】不是拆支付流水。为什么? 很简单，你想，一个订单可以对应多个商品，这样的话，就需要把其中某个商品或者某几个商品进行分组，形成子订单，形成了一次付款对应多个订单的情况。那你得问了，什么场景下才会有拆单？个人有限的经验告诉我，无非出于两点：
便于结算。一个订单包含多个商家的商品，为了结算方便—拆！
便于发货。一个订单包含多个仓库的商品，为了发货—拆！
所有的合并和拆分都是基于订单，那么这时候的订单结构应该需要变成：主订单、子订单、商品三个表。
3、支付流水
国外的商城系统也是这样的，不信你们去研究下Magento的后台（个人认为，想把电商的架构搞明白，Magento是超级好的），对于国内的电商系统，支付基本都是用第三方支付，设计的时候会把订单和支付分开，而支付唯一影响的是订单的付款状态，在设计的时候我们就必需将订单和支付抽象，不要混在一起，这也就很好解释了为什么支付不需要管具体的拆单，要拆单只需要拆订单，而不需要拆支付流水的原因。一个支付流水对应一个主订单，其他和支付流水没有必须的关系。
订单和支付的逻辑理清楚了之后，我们再来看所谓的分仓发货这个业务简单的流程：
下单：同一个商家，形成一个主订单和一个子订单，N个商家，形成一个主订单和N个子订单
支付：修改主订单的支付状态
发货：同一仓库同时发货，则形成一个发货单；不同仓库或者不同时间发货，则形成多个发货单。发货单需要关联发货的商品明细，修改商品的发货状态。
结算：按照订单状态和商家生成结算数据，销售和退款都在同一个订单表，那么直接计就好了
当然，以上是最为简单的业务情况，实际的业务情况会更加复杂，但是整体流程就是这个样子。这里复杂的地方不是【向客户分批收款】的难度，这其实是表面，因为我前面解释过订单和支付的关系：一个订单一个订单是独立的，线下支付完统一给商城，这里不涉及使用线上支付工具，包括代金券，第三方支付等还要冲正的问题，所以不难。只要拆单的逻辑你清楚了，订单系统闭环走完了跳到支付系统，这样结算很清楚，根本就不是问题。
既然提到了收账冲正，就多说一点。
打个比方，我在购物车里有A，B两件来自2个不同商家的商品，那么当货到付款后就要开始考虑怎么分账了。
如果是货到付款，那还好办。难点在于如果我是使用了代金券支付的话，也许A店家接受代金券但是B店家不接受，这里就涉及分账了。
这个时候，在支付系统的设计上应该有个独立的分账系统来处理，是为了防止用户进行退货操作，就对分账进行冲正。比如，我A货要退，同时之前买的C活也要退，那么在冲正的时候，系统的设计上就必需有优先级，是余额支付先退，还是优惠类的支付（如：代金券，优惠券）先退，还是信用卡支付先退，要有优先级。
冲正在分账系统中走完后，是信用卡支付的还涉及到银行，得所有需要向银行提交的冲正汇总成一笔，发送到银行。（所以当量大的时候经常会造成崩溃也是可以理解的）。
作为PM的各位，你们需要考虑的问题就出来了：
1. 每个子订单下面的的商品是否应该有对应的状态，这个状态是如何子订单状态？
2. 退款优先级设计
3. 如何做流量切割
回到最初的问题，重复支付，理清了订单到支付系统的来龙去脉后，我们再回来看，就会清楚很多。
重复支付的情况无非是有这么两种：
1.支付成功，但交易没有成功，这种情况下，用户还是可以继续对该交易进行支付，即可能出现重复支付的问题。
解决方案：此时如果第二个交易状态推进成功，在后续第一笔支付重新推进交易时，交易系统告诉支付系统，该笔交易已经支付成功，此时支付系统需要是对之前那一笔的支付进行撤销，对电商系统来说，这是同一个单据重复支付了多次，即电商订单流水号对应多笔成功的银行/支付公司流水，一般的情况下，只要确认其中一笔，剩下的全部主动退款就行了。
2.如果支付成功，交易成功，用户也无法进行重复支付。
先聊到这，后会有期。。。
2016.9.1 更新
支付场景。上回我们聊过了关于支付需求真伪的问题。今天，我们再来聊一聊关于支付场景的问题。其实，你的支付产品能否在这个已经接近饱和的市场有一席之位，完全看你怎么抓【痛点】，好，既然要分析【痛点】，那么像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 don't need your wallet】(你不再需要你的钱包) 就会完全被人抛在脑后。
3. 安装，注册，你的产品不等于会真正用你的产品
尽管Apple已经有近800万的iTunes的注册用户，并且进行了绑卡（为的是在iTunes享受付费服务支付使用），然并卵。因为，现在都没有准确的数据统计来显示有多少注册的用户会真正的在appstore里面去购买产品和服务。国外尚且如此，何况国内。所以，就算是iPhone上绑定了NFC作为支付方式，并且进一步操作，进行支付，这一点对于新的支付工具来说，并不简单。因为想要让用户使用新的支付方式去长期持续地进行消费是非常难的意见事情。在PBT，很多人只是注册了而已，并没有使用这个系统的用户的比例还是很大的，也就是说，很多用户只是在一时需要花了5分钟注册，并使用一次服务而已。这个现象不仅仅是支付产品会面对，你们在大街小巷看到随处做O2O餐饮地推的人员，多少人只为了享受”第一单2折优惠”而去扫你的二维码，然后，就淡忘了，甚至删掉了。如果线下的实体店发现，接入Apple Pay并不能吸引消费者持续使用这个方式去支付，那么这些店主们还会将自己的系统和Apple进行对接吗？面临的最大障碍是如何让这个系统推广到足够多的商家那里，让它们的支付系统成为用户的习惯。留存在很多产品下比拉新要难一些。
4. 数据基数越来越庞大，如何保障安全
不仅仅是国外，国内也开始对于数据安全有了担忧。随意百度一记，查看桔子IT，看看现有支付公司的评论，对于调（掉）单，盗刷等涉及安全性问题层出不穷。加上之前iOS系统爆出来的XcodeGhost事件，让很多人这么感叹：“原来被誉为安全性很高的iOS系统也有被黑的一天啊”。这带来的后果是，消费者会更加不情愿将信用卡绑定，因为他们不愿意把信用卡的数据提供给商户。PayPal的做法是不给供应商提供支付交易的信息，从而赢得了不少消费者的好评。
安全性，对于注册PBT的用户来说，应该要成为一个很强有力的"引爆点"，毕竟，相比于其他的支付方式，盗取“指纹”肯定是更加的困难的，因为你需要“黑”到两样东西：
1.手机
2.手指
很多人认为指纹在体验上最大的不爽在于：当天气非常寒冷的时候，用指纹来验证经常会因为冻僵的手指而半天难以解锁。而对于重度依赖指纹的Apple Pay来说，这个无疑是一个大的问题。
以上的4点，对于Apple Pay来说无疑是对其自身的一个挑战，他们需要考虑到这些实际的支付场景的需求。还有一点需要说，除了用户的需求之外，另外就是人和了，Apple Pay和银联的合作无疑是想得到ZF的支持，如果有央行和ZF的扶持，有些事儿就好吧。
聊完了這個之後，冒出來了一個新的問題，也是最近非常火热的问题：
支付要不要做社交
事情的前因后果要从支付宝那年的【集五福】开始，然后引发了一些列的热议，知道支付宝正式推出【生活圈】这个【朋友圈】的同分异构体之后呢，很多人就开始各种yy，其中XXX早读课就有一篇，写得是天花乱坠。好吧，凯撒本来想黑一把的，想想还是算了，不如借此认真分析，更有意义。
社交和支付怎么组合拳，取决于你当前的业务是什么导向。支付宝的社交是【以交易为中心】的社交，而微信（或QQ）是【以社交关系为中心】的社交。微信的社交不用我多说了吧，大家其实都挺明白的，下面我就简单聊聊支付宝的社交逻辑。
关键词： 一次性交易的社交
用户在淘宝上买东西，这个行为是一次性的，对于社交的需求，更多是以比价来进行选择产品，有一些常规性产品，高频性产品，比如每3个月买一次洗衣液；针对这类购买行为，亚马逊比较聪明，率先推出了一个服务，就是根据用户的需求，定期自动送货上门。比如，A用户每个星期都要买某一品牌多大容量相应数量的牛奶，那么，他们就提供定期送牛奶上门，省去用户自己进行重复性购买操作。但是这一类毕竟是少数，对于大多数都是一次性买卖。
关键词二：金融+（场景）+支付
这里我想讲的是，不要被“社交”的壳儿迷住了眼睛，要看支付宝这么做之后解决了什么问题。这里的关键词我用的是场景，而不是社交，怎么理解呢？举个栗子吧：
比如，A写字下有一家全家，如果支付宝跟它合作，用支付宝在全家买午饭超过多少，就可以打7.8折。那么，在A写字楼附近工作人员就会感兴趣，拼单，然后AA，整个支付过程都在支付宝上完成。AA完后的用户就可以拿到全家优惠后的午饭。用支付宝AA，吃饭，满多少钱，有什么优惠。每人一次吃饭20块，中间的利润远可以覆盖手续费带来的压力。实体的利润远不是互联网的利润可以达到的。线下那么多的利润，那么多的情景，都可以赚点儿。
你要问了，这种线下的社交，一次交易完，并没有互加为好友。你要跳出手机上的APP来看问题，对于吃饭AA，本来大家都认识，都是经常一起吃饭的。本来就【建立关系】了，为什么还要花大功夫在其他的地方搞社交？以事件（交易）为核心，这是支付宝【社交】的逻辑，不要被微信那种固化了你的思路。
当然，不可忽视的是支付宝另外一个很重要的线上场景---线上转账，群体特征也很明显，大多数是熟人之间，可是真正面对高频性的固定对象的转帐行为，真要加好友，面对支付宝现在成熟的用户群体的话，是否还必要可以去引导用户去加好友？很多饭店里吃饭，支付宝付款，是可以【不加好友可以，一次性转帐】的，高频性固定对象的转帐行为，用户自己会主动去加好友，因此，转帐只是支付宝相当小的一部分，甚至不是重点，不足以让支付宝大动干戈去做社交。
綜上
社交支付，支付社交，如何结合，利弊权衡，完全在于你现有行业的特征，对内对外的社交关系的特征来决定，你是支付宝模式，还是微信模式
（未完待续。。。）
2016.8.24更新
支付的碎片部分，下一次可以集中的来逐一分析，不过需要一些时间，凯撒还在酝酿当中。今天只聊一点，就是：
（支付）产品经理什么时候确认要上线新功能？
对，这不是什么新的问题，你可以在各大的论坛里面找到类似的问题。今天，我们不聊理论，以实例为主。在故事之前，我还是先给出我的一个结论，那就是：
一个标准，一句话：是不是解决了客户正遇到的问题
请注意，是正遇到的问题，而不是过去，也不是将会遇到。不是太清楚其他行业如何，就我们支付这个行业来说，产品经理其实能够了解所谓【用户需求】的唯一途径就是：听BD们的反馈终端客户的。我司的产品经理算是被我们洗（gou）脑（da）频率比较密切的，愈是亲密，愈发觉得两者的工作性质其实是互补的。产品经理从产品的角度去分析这个问题能够怎么解决，而BD们从运营，营销，和客户的角度告诉产品客户遇到的问题是什么样的。只有和BD互相配合，才能够真正做到解决客户的问题。这里我一直不说什么做出的产品能够满足用户的需求，为什么？很简单，因为需求是一个很抽象的概念，我们满足客户的需求，其本质是提供一解决方案，让客户看到，使用后，惊呼：“对，我最开始要解决的XXX问题，就是这样。”
懂我的意思吗？
来，上例子：
之前我们的产品还只有线上网关支付（API），移动端WAP的时候，很多客户在使用的时候提出需要搞一个类似于【认证支付】的产品。那会儿，我们把这个需求反馈给了产品经理，产品经理简单的问了用户具体需要通过这个【认证】解决什么问题，我们只是回答：“客户的业务是受到XXX监管，需要对每一个交易的客户的信息有采集（包括姓名，银行卡号，身份证，手机号等），达到交易流水透明化，因此需要有一个身份认证的功能。”好，到这里，我可以告诉大家【需要一个身份认证的功能】其实是一个伪需求。为什么？
第一，身份认证？是只需要身份证ID的认证，还是需要身份证和银行卡号一起认证，还是只需要银行卡号信息认证匹配即可，如果换成护照，驾照是否可以代替等等。看起来很拗口，实际上确实是如此
第二，验证是否意味着交易时【同卡进出】？还是验证归验证，交易者还是可以自由的选择银行卡交易。
老实说，BD很少能够在第一时间，将这个剖析得这么细致，毕竟，少有BD会去花心思从业务和产品两个层面去分析这个问题背后解决的问题是什么。好，含糊的需求到了PM那，其实PM也是很无奈的，只能先经过简单的整理，提炼后，转告给开发先做出一个demo出来，而PM给开发也传达的时候就变成了这么一句话：“支付的时候需要加一道认证的功能，与C端客户进行匹配。”
于是，可想而知，推出了一款叫做四要素验证的功能，功能：每一个商户的客户在交易平台开始入金交易的时候，选择XX付的图标，下一步是跳出四要素认证的填写信息，下一步，验证通过后，进入网银界面，入金成功跳转回来。此后，不管你是之前认证过还是第一次，每一次来入金都需要经过这个四个要素的验证，才能进入网银支付的页面，使得整个支付的过程变得冗长，并且，这样的验证其实并不能达到同卡进出的验证的严谨度。客户用过之后发现不对，不仅没有满足【身份验证】的问题，还多了问题。于是，我们只能带着产品经理和客户深入谈这个【认证】的需求。这里，客户需要认证有两个动机：
1.满足监管要求，对交易人的四要素/六要素验证（如果支持信用卡支付）
2.快捷支付，跳过网银界面，一码验证，短信支付即可
于是才有了现在的认证支付，同卡进出，绑定一次，下次凭码支付。
整个过程，这个所谓【新功能】就算白上了。因此，我想说的点也就出来了，产品经理如何判断新功能是否应该天剑，完全取决于：
1.他们是否真正的知道客户遇到的问题是什么？
2.想要解决什么问题？
3.达到什么效果？
4.提出的新需求所带来的新功能是否能够解决他们现在的问题？
5.此功能推出之后是否需要后期的迭代？
这几个点考虑足了，新功能才有价值被添加，否则就是浪费时间和精力。因此，我觉得产品经理不要埋头去想这个新功能该不该加，也不要老和BD开会去通过BD的反馈来改版，更不要满足于新功能只要测试人员说没有bug可以上线使用即可，还是，多到终端用户去看看，比什么都强。
2016.8.21更新
原本码了很多，想来，还是不要太多艺术加工，实在点儿好：把问题罗列出来，再一一分析：
其实，现在国内支付行业已经饱和，不管是最为古老的POS收单，网关支付，还是移动支付，以及快捷认证等，技术上，模式上，不管你是SDK, APP, PAD,
API, H5等等，模式基本固定，形式上，无非是：直接支付，担保支付，预授权，分期付，以及其他。发展了这么就，碎片化慢慢也就出来了：
六个层面供参考，挖掘：
1.移动应用碎片：PC互联网时代的大平台、大流量、大入口已不在适用于移动互联网，移动化的情况下，这个逻辑在不断发生改变，大流量公司越来越少，碎片化应用越来越多；除微信等极少量超级App外，在衣食住行和其它生活类服务，细分垂直领域涌现出海量的移动应用。这一点看，基本上都是直接支付。
2.移动平台碎片：目前主流的支付渠道均适配Android、iOS、H5、微信公众号等4种移动端平台。开发者如要完善其移动支付功能，一般需要在多移动端平台下接入所需的支付渠道。
3.支付渠道碎片：如来自艾瑞的统计图所示，在移动支付飞速发展的2014-2015年，支付渠道碎片化趋势加深；除支付宝外的其他第三方支付企业的市场份额，大致都成倍增长；受银联云闪付家族和其他互联网巨头进入等影响，除了支付宝微信之外，碎片空间很多。
4.用户场景碎片：目前移动支付按场景区分，大致分为App内支付、HTML5支付（移动网页支付）、扫码支付、被扫支付、NFC支付。支付是场景下的资金结算行为，无场景无支付，以上5种支付场景均对应着不同的支付需求。
5.数据碎片：支付渠道碎片化导致企业的支付数据碎片化，各自割裂，堆积在不同的支付平台，碎片的来源主要包括且不：财务部门——报表对账、税务管理等，运营部门——查询、退款和争议订单处理等，产品部门——支付数据BI等。
6.支付需求多样化：随着移动互联网对传统行业的席卷和渗透，移动支付的场景将进一步碎片化，同时支付需求的多样化也会愈来愈丰富，如消费金融领域的小额信贷支付，或其它的增值类营销支付需求等。
对移动应用开发者而言，尤其是中小企业，在前期的支付接入服务和中后期的交易处理、数据运维、产品迭代等上，产生的痛点，并不是简单的和级关系，而是乘级。
2016.8.15
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应该了解这个行业的什么，且听下回分解。
（未完待续。。。。）
