关于Android开发的一切
支付宝和微信移动支付的个人总结
今天在看了移动支付的文档，对整个流程都有了自己的理解，在这里记录下来自己的总结，把里面的逻辑都整理一遍
一、支付宝支付
先去看官方的支付文档，链接如下
1、先说前期准备，关键就是要生成一对公钥和私钥，这个看官方文档，现在官方有个自动生成工具，其实挺方便的。注意的是如果是java开发，生成的私钥要转成pkcs8格式。
（1）pkcs8的私钥自己保存，填到自己支付宝开发项目 里面的public static final String RSA_PRIVATE 这个字段里
（2）下面的蓝色2个选项，其实都是公钥。前个是自己上传的公钥，后一个是对应的支付宝公钥，这个支付宝公钥才是我们开发中需要的，这个切记。
（3）点红色方框，把自己生成的公钥上传给支付宝。
（4）点蓝色方框，得到支付宝的公钥，填到public static final String RSA_PUBLIC 这个字段里
2、准备完成了，接下来就是看请求参数的文档，这里告诉我们究竟要如何上传参数给支付宝后台，文档链接如下。
其实，支付宝接入的核心就是要组成下面图片所示的字符串，把这个字符串当参数传递调用支付宝Api即可。
我们来分析这个字符串。红色边框里面是签名内容sign和加密名称sign_type。（sign是根据我们上传参数生成的，也就是说所有我们上传的参数都需要一起签名；sign_type是签名方法，这里是固定值RSA）。而红色边框之外的是我们自己根据需要拼接的参数数据。接下来就是2个疑问
（1）红色边框之外的内容如何生成？
（2）红色边框里面的签名又是如何生成？
我们一个个来，先说红色边框之外的内容，把所有 值以key= “value”进行组合，之后用“&”字符连接起来，支持无序。
根据demo，我们使用一个String orderInfo = getOrderInfo("测试的商品", "该测试商品的详细描述", "0.01")方法得到这个字符串，而这个orderInfo就是红色边框之外的内容。
这个方法需要传递3个参数，第1个是商品的名字或者订单编号等，第2个是描述信息，第3个是支付的总金额。那么这个getOrderInfo的方法是怎么实现的，看下面代码。
private String getOrderInfo(String subject, String body, String price) {
// 签约合作者身份ID
String orderInfo = "partner=" + "\"" + PARTNER + "\"";
// 签约卖家支付宝账号
orderInfo += "&seller_id=" + "\"" + SELLER + "\"";
// 商户网站唯一订单号
orderInfo += "&out_trade_no=" + "\"" + getOutTradeNo() + "\"";
// 商品名称
orderInfo += "&subject=" + "\"" + subject + "\"";
// 商品详情
orderInfo += "&body=" + "\"" + body + "\"";
// 商品金额
orderInfo += "&total_fee=" + "\"" + price + "\"";
// 服务器异步通知页面路径
orderInfo += "?ify_url=" + "\"" + "http://notify.msp.hk/notify.htm" + "\"";
// 服务接口名称， 固定值
orderInfo += "&service=\"mobile.securitypay.pay\"";
// 支付类型， 固定值
orderInfo += "&payment_type=\"1\"";
// 参数编码， 固定值
orderInfo += "&_input_charset=\"utf-8\"";
// 设置未付款交易的超时时间
// 默认30分钟，一旦超时，该笔交易就会自动被关闭。
// 取值范围：1m～15d。
// m-分钟，h-小时，d-天，1c-当天（无论交易何时创建，都在0点关闭）。
// 该参数数值不接受小数点，如1.5h，可转换为90m。
orderInfo += "&it_b_pay=\"30m\"";
// extern_token为经过快登授权获取到的alipay_open_id,带上此参数用户将使用授权的账户进行支付
// orderInfo += "&extern_token=" + "\"" + extern_token + "\"";
// 支付宝处理完请求后，当前页面跳转到商户指定页面的路径，可空
orderInfo += "&return_url=\"m.alipay.com\"";
// 调用银行卡支付，需配置此参数，参与签名， 固定值 （需要签约《无线银行卡快捷支付》才能使用）
// orderInfo += "&paymethod=\"expressGateway\"";
return orderI
}可以看到，上面的这个方法就是根据请求参数说明，拼接字符串而已。
接下来就是生成红色边框里面的内容，这里就是对上传的参数进行签名，注意这里的签名要放在我们自己的后台服务端上进行，不能放在app端，demo里面用了一个String sign = sign(orderInfo);方法得到签名的内容。最后对这个签名的内容进行URL的转义，千万不要忘记了，文档说明有说明注意看下图的黑色标记，demo用了这个方法sign = URLEncoder.encode(sign, "UTF-8");得到转义后的签名
通过上面的2个步骤，我们得到了一个orderInfo 字符串，是上传的参数信息。 还有一个sign，就是签名，而且这个签名做了转义处理。但是这2个字符串不符合我们上传的格式啊，因为这2个字符串还没有拼接起来，所以最后要把这2个字符串拼接得到一个PayInfo字符串
String payInfo = orderInfo + "&sign=\"" + sign + "\"&" + getSignType();
这个getSignType()方法也很简单，就是加上“RSA”即可，如下
private String getSignType() {
return "sign_type=\"RSA\"";
可以看到，走到这里，这个payInfo就符合格式了，也就是最后调用支付宝Api的参数，如下代码。
Runnable payRunnable = new Runnable() {
public void run() {
// 构造PayTask 对象
PayTask alipay = new PayTask(PayDemoActivity.this);
// 调用支付接口，获取支付结果
String result = alipay.pay(payInfo, true);//payInfo就是我们通过上面2个步骤得到的字符串，这里当成参数传入
Message msg = new Message();
msg.what = SDK_PAY_FLAG;
mHandler.sendMessage(msg);
// 必须异步调用
Thread payThread = new Thread(payRunnable);
payThread.start();以上就是移动支付，关于支付代码的一些个人总结，大家可以结合官方代码看看
，可以结合代码看看，整体思路和逻辑就更清楚了。
二、微信移动支付
首先当然去看官方文档了，链接如下
接入的前期准备也不说，这里只说逻辑思路，微信支付需要注意的事项
1、提交和返回数据都为XML格式，根节点名为xml。
2、采用POST方法提交
3、签名的参数,将集合M内非空参数值的参数按照参数名ASCII码从小到大排序(字典序)
4、交易金额默认为人民币交易，接口中参数支付金额单位为【分】，参数值不能带小数。对账单中的交易金额单位为【元】
5、我们可以使用传统的httpClient发送post请求，
byte[] buf = Util.httpPost(url, entity);
//url就是请求的网络接口地址，entity就是根据需求封装的xml格式的字符串
String content = new String(buf);
//服务端返回字节数组，我们再转成字符串，这个字符串就是我们得到的响应数据
说清楚了注意事项，接下来理清一下支付的流程逻辑，其实很简单，步骤如下
1、统一下单，商户系统先调用该接口在微信支付服务后台生成预支付交易单，
2、返回正确的预支付订单号，在APP里面调起支付接口。
那么一个个来吧，先看统一下单，生成预支付订单的文档，我们需要分析需要上传哪些参数，
https://pay.weixin.qq.com/wiki/doc/api/app/app.php?chapter=9_1
从上图得知，最后的sign字段里面的数据就是微信支付接入的核心。那么问题就是，这个签名是怎么来的？
文档里面也说得非常清楚，其实就是2个步骤
第一步，设所有发送或者接收到的数据为集合M，将集合M内非空参数值的参数按照参数名ASCII码从小到大排序（字典序），使用URL键值对的格式（即key1=value1&key2=value2…）拼接成字符串stringA。
特别注意以下重要规则：
◆ 参数名ASCII码从小到大排序（字典序）；
◆ 如果参数的值为空不参与签名；
◆ 参数名区分大小写；
◆ 验证调用返回或微信主动通知签名时，传送的sign参数不参与签名，将生成的签名与该sign值作校验。
◆ 微信接口可能增加字段，验证签名时必须支持增加的扩展字段
第二步，在stringA最后拼接上key得到stringSignTemp字符串，并对stringSignTemp进行MD5运算，再将得到的字符串所有字符转换为大写，得到sign值signValue。
我们看看上面的2个步骤是怎么通过代码来实现的，demo里首先走了这一句 ，
String entity = genProductArgs();
//这个方法的结果也就是说上面图片所示的全部内容，包括了签名。我们看看这个方法是怎么实现的
List&NameValuePair& packageParams = new LinkedList&NameValuePair&();
packageParams.add(new BasicNameValuePair("appid", Constants.APP_ID));
packageParams.add(new BasicNameValuePair("body", "APP pay test"));
packageParams.add(new BasicNameValuePair("mch_id", Constants.MCH_ID));
packageParams.add(new BasicNameValuePair("nonce_str", nonceStr));
packageParams.add(new BasicNameValuePair("notify_url", "http://121.40.35.3/test"));
packageParams.add(new BasicNameValuePair("out_trade_no",genOutTradNo()));
packageParams.add(new BasicNameValuePair("spbill_create_ip","127.0.0.1"));
packageParams.add(new BasicNameValuePair("total_fee", "1"));
packageParams.add(new BasicNameValuePair("trade_type", "APP"));
上面的代码，就是把红色方框里面的我们需要的上传参数放到一个List集合packageParams 里面，这个集合的所有参数也就是生成预支付订单号所需要的参数（注意，这个集合里面add 的BaseNameValuePair的参数顺序不能乱写，需要按参数名ASCII码从小到大排序，比如appid参数需要放第1位，body就需要跟在第2位添加进去，mcn_id就是第3位添加，为什么要这么做，因为这个集合里的内容是需要签名的，而签名的其中一个要求就是参数名ASCII码从小到大排序，这个很关键），那么这个集合有什么用，当然就是用来签名，这个思路跟支付宝设计其实是一样的，所有上传参数封装好，接下来还有蓝色方框里面的内容需要生成，代码走了这句
String sign = genPackageSign(packageParams); //这一句就是把所有数据进行签名
我们看看这个 genPackageSign（）签名方法是如何实现的
private String genPackageSign(List&NameValuePair& params) {
StringBuilder sb = new StringBuilder();
for (int i = 0; i & params.size(); i++) {
sb.append(params.get(i).getName());
sb.append('=');
sb.append(params.get(i).getValue());
//对参数按照key=value的格式组合 所以里面的参数排序一定要先排好，顺利不能乱
sb.append('&');
sb.append("key=");
sb.append(Constants.API_KEY);
String packageSign = MD5.getMessageDigest(sb.toString().getBytes()).toUpperCase();
return packageS //在stringA最后拼接上key得到stringSignTemp字符串，并对stringSignTemp进行MD5运算，再将得到的字符串所有字符转换为大写
}可以看到，这个方法就是签名算法的具体实现，逻辑上并不难。最后得到的这个结果是个字符串，也就是sing字段里面的值，所以我们需要把它添加到上传的集合里面，所以程序继续走下面一句
packageParams.add(new BasicNameValuePair("sign", sign));
到这里，这个packageParams 就是我们所有要上传的数据里，但是它不是xml格式，接下来就要走这个方法
String xmlstring =toXml(packageParams);这个方法就是把集合里面的数据封装成xml的格式，我们来看看这个方法如何实现
private String toXml(List&NameValuePair& params) {
StringBuilder sb = new StringBuilder();
sb.append("&xml&");
for (int i = 0; i & params.size(); i++) {
sb.append("&"+params.get(i).getName()+"&");
sb.append(params.get(i).getValue());
sb.append("&/"+params.get(i).getName()+"&");
sb.append("&/xml&");
return sb.toString();
}其实很简单，循环遍历整个集合，分别把name 和value组合即可。最后得到的xmlstring
字符串就要上传的字符串，也就是entity的值，接下来直接走
byte[] buf = Util.httpPost(url, entity) ;
//这个entity就是上传的xml字符串，里面包含了所有参数和签名字段
String content = new String(buf);
//这个content 就是得到了微信后台服务器返回的所有参数
接下来我们看程序走这一句
Map&String,String& xml=decodeXml(content); 就是把数据通过android的xml解析，封装到一个map里面
最后把这个map再赋值给resultunifiedorde，这个resultunifiedorder也是一个map。问题来了，这个resultunifiedorde有什么用？里面有个字段prepay_id就是支付订单号，调微信支付的接口，其中的一个字段的值就是它了，总结：前面的这么多步骤，其实核心就是一个 ，得到预支付订单号。
拿到了预支付订单号，接下来就是走支付接口，需要的参数如下
我们看到，这里调用接口，最后的一个参数要又是sign,好吧，其实又封装sign字段之前的所有字段来生成签名，代码如下
private void genPayReq() {
req.appId = Constants.APP_ID;
req.partnerId = Constants.MCH_ID;
req.prepayId = resultunifiedorder.get("prepay_id");
//req.packageValue = "prepay_id="+resultunifiedorder.get("prepay_id");
* 这里的package参数值必须是Sign=WXPay,否则IOS端调不起微信支付，
* (参数值是"prepay_id="+resultunifiedorder.get("prepay_id")的时候Android可以，IOS不可以)
req.packageValue = "Sign=WXPay";
req.nonceStr = genNonceStr();
req.timeStamp = String.valueOf(genTimeStamp())
List&NameValuePair& signParams = new LinkedList&NameValuePair&();
signParams.add(new BasicNameValuePair("appid", req.appId));
signParams.add(new BasicNameValuePair("noncestr", req.nonceStr));
signParams.add(new BasicNameValuePair("package", req.packageValue));
signParams.add(new BasicNameValuePair("partnerid", req.partnerId));
signParams.add(new BasicNameValuePair("prepayid", req.prepayId));
signParams.add(new BasicNameValuePair("timestamp", req.timeStamp));
req.sign = genAppSign(signParams)//这里就是把之前的参数又封装和签名
也就是说demo里面的 genAppSign 和genPackageSign 这2个方法其实都是一样，不信可以去demo里看看 }
我们实际调用支付接口的参数
生成预支付订单号的参数
是不同的。但是生成签名的过程都是一样的！！！！
（1）前者生成预支付订单号封装好所有的参数，需要组成xml格式字符串，使用HttpCliet去发送数据。
（2）而实际支付接口，我们需要封装成一个PayReq 对象reg，这个reg对象里面变量就是要上传的参数，然后使用微信支付类即可，
IWXAPI msgApi = WXAPIFactory.createWXAPI(this, null);
msgApi.registerApp(Constants.APP_ID);
msgApi.sendReq(req);不用再使用HttpClient
走到这里，支付基本完成了，最后程序会执行我们自己项目里面的wxapi包的WXEntryActivity.java 里面的内容
以上的就是微信支付流程，需要大家去结合代码熟悉一下
最后最后的总结
1、支付宝和微信都需要对上传参数做签名，都是以key value排列，用&号连接多个参数，
具体上传参数到各自的文档里看即可。
2、参加签名的参数，支付宝是无序，而微信有序。
3、支付宝只做了一次签名，而微信其实做了2次签名（第一次接口调用，使用了xml格式和HttpClient请求，第2次调用了msApi去发起实际支付）。
没有更多推荐了，
加入CSDN，享受更精准的内容推荐，与500万程序员共同成长！支付宝和微信付款方式已经遍布全世界，为何外国人依旧不用？
支付宝、微信堪称现代社会的两大巨头，不仅在我们国内非常受欢迎，即使到了国外我们依然随处可见支付二维码，也就是说，以后出国旅游也都不用在担心货币兑换了，用手机扫二维码就可自动转换货币进行付款，相当的简单！
按照蚂蚁金服官方公布的数据，今年国庆期间国人使用支付宝在境外消费的总数是去年同期的 8 倍多。人均消费金额也大幅提升了近 50％。境外消费的主力军是 90 后，用户数占比高达 44％，人均消费金额达到了 1301 元。
一场由中国公司发起支付革命正在海外进行——爆买的中国游客更愿意使用移动支付而不是刷卡。这引起日本金融机构的警惕，他们也准备推出自己的移动支付产品。
支付宝这么好用，外国人感受到了吗？
支付宝全球化，一方面是提升中国游客出境游的体验，当然还有另一方面：为境外用户提供便利的移动支付服务。
在过去的两年，支付宝母公司蚂蚁金服不仅把支付技术输出到境外，还在香港、印度、马来西亚等多个国家和地区拿到了支付牌照，并推出当地版「支付宝」。
可是，被支付宝便捷服务圈粉的境外用户并不算多。截至今年 8 月，支付宝海外版的用户达到 4000 万。相比之下，截至今年 6 月，支付宝在国内的活跃用户已经达到 5.2 亿。
在香港、新加坡等地，当地居民日常使用支付方式的仍然是交通一卡通，而不是手机。交通一卡通支付在多个国家和地区已经足够成熟，用户习惯短时间难以改变。加上支付牌照、本地化运营的问题，中国的移动支付产品成为境外居民支付的首选并不太容易。最近，还有香港媒体争论，八达通卡已经够方便了，有没必要使用支付宝。
PayPal、Apple Pay 是支付宝全球化中比较大的竞争对手。但即使在 PayPal、Apple Pay 占绝对优势的美国市场，移动支付的规模远不及中国——2017 年 9 月道琼斯通讯社数据显示，中国移动支付规模是美国的 90 倍。
境外用户在自己的居住地对移动支付并没有太大感觉。如果来中国游玩，感觉也会和中国人非常不一样。
为了了解境外游客在国内支付现状，我去了趟外国游客扎堆的北京秀水街。无论是咖啡奶茶店还是服装店，都在醒目位置贴有微信、支付宝的付款二维码，一些店铺有 VISA 标识。
我在一家奶茶店旁观察了半个小时，这家店的收银台上放了一个大大的二维码，支持微信、支付宝、京东、百度钱包支付，可外国人并不能注册这些支付账户。前来购买奶茶的外国人基本都用现金。
在另一家支持刷 VISA 卡的服装店，老板告诉我说，绝大部分来店里购物的外国游客都是用现金支付，只有很少一部分刷卡。
秀水市场也考虑到了外国人支付的现实情况，在咨询台提供外币兑换人民币服务。
秀水市场店铺。
看着国人方便地使用移动支付，而自己慢吞吞地数现金，这些境外游客只能望洋兴叹了——在移动支付海外化中，他们是非常重要的突破点。
在服务这些用户上，支付宝还没有特别的行动。反倒是不声不响的百度钱包打起了主意。
今年 7 月，百度钱包与 PayPal 达成战略合作。根据合作协议，目前双方的合作主要是向国内的百度钱包用户提供跨境消费服务。
不过，百度钱包相关负责人告诉 PingWest 品玩，双方的合作也会有方便外国人到中国消费的考虑。
「针对境外用户，我们后续会为境内商户提供 PAYPAL 和 VISA、MASTER 卡等外币支付能力，同时为境内商户进行人民币结算。同时针对入境游场景，PAYPAL 收购了国外最大的聚合支付平台 Braintree，UBER、Airbnb、Booking 等公司均是 Braintree 的合作伙伴，我们也希望依托于这些场景，将百度的商户（包括糯米、外卖）提供给到国内游玩的用户。」
统计显示，2016 年入境旅游人数达到 1.38 亿人次。如果能服务好这部分用户，百度钱包将找到自己的生存空间。
相比之下，支付宝在境外用户推广，重要的形式还是电商。在俄罗斯、巴西等热衷于从淘宝海淘的国家，支付宝与当地的支付方式合作落地。
去年双 11 的数据显示，支付宝国际线上交易笔数同比增长了 60%，全球共有 224 个国家和地区的消费者用支付宝在线参与买买买。其中，俄罗斯人血拼战绩最佳，交易笔数占到总量的 48％。
今年的双 11，支付宝把购物狂欢节推广至更多地区。比如，菲律宾版支付宝 GCash 与菲律宾第二大零售集团 Ayala 旗下的 Glorietta Mall 推出 GCash 专享优惠的线下购物狂欢节；在香港，「支付宝 HK」APP 新用户在双 11 期间通过 7-ELEVEN 及 Cirkle K 便利店和渣打银行为「支付宝 HK」账户充值时，将可以获得天猫的通用红包，红包可用于双 11 的线上购物。
在用电商带动境外用户使用支付宝的同时，支付宝在当地同时推出打车支付、领取优惠券等服务。
但对支付宝来说，一切才刚刚开始。
支付宝接了30多个国家和地区，但想要服务外国人还差一步
在国内习惯了移动支付之后，出境一点都不会别扭，因为「支付宝」的标识时不时就会冒出来。
在境外，你能想到的消费场景，支付宝都帮你想到了。目前，在欧美、日韩、东南亚、港澳台等30多个国家和地区，支付宝接入的海外线下商户门店范围涵盖餐饮、超市、百货、便利店、免税店、主题乐园、海外机场等几乎所有吃喝玩乐消费场景。
甚至，在芬兰航空所有往返中国内地及香港航线上，空中购物可以使用支付宝结账；在全球最大的两家邮轮公司——挪威邮轮和嘉年华邮轮上，你也可以使用支付宝扫码付款。
为了满足国人不同目的地的消费需求，支付宝已支持美元、港元、英磅、欧元、日元、加拿大元、澳大利亚元、新加坡元等27种外币结算。而且，支付宝的铂金会员还可以享受更划算的汇率。
一位新加坡的商家说，接入支付宝之后更给游客多一种选择，而且目前接入是免费的。接入之后，中国游客更愿意用扫码付款，而不是现金。
有意思的是，支付宝在境外众多大型商户接入之后，很多街边小店也自愿提供二维码扫码付款，他们使用个人账户收款，和国内的街边小店一样。我在香港见到了很多这样的小店。
一家鱼蛋粉店的老板说，一些大陆游客经常问起可不可以扫码付款，索性找大陆的亲戚帮忙开设了支付宝和微信账户，方便大陆游客使用。
无论是微信还是支付宝，在境外推广的难度似乎并不在商户端而是在用户端——中国游客的强大消费能力让凡是有中国游客的地方，商户都愿意接入支付宝，但大多数当地居住的居民依然在「冷眼旁观」。
除了信用卡和现金的用户惯性之外，最大的门槛是实名认证，根据 2016 年 7 月公布的《非银行支付机构网络支付业务管理办法》规定，所有支付类帐户都必须进行实名认证，并对帐号的实名等级做出了定义：
I 类账户主要适用于小额支付，比如大家最常用的手机红包，但这类账户余额支付累计限额1000元；II 类账户可以日常消费、转账、购物、缴水电气费等，但一年不能超过10万元；III 类账户可以进行大额的理财，账户余额支付年累计限额20万元。
也就是说，想要使用一个网络钱包进行「消费」至少要是 II 类帐户才行。而 II 类帐户要求三种可信信息交叉验证，可信信息包括身份信息认证、银行卡信息认证、电信认证、学历认证等。
而大多数的外国人只能提供身份信息认证，即其所属国家的护照信息，而无法提供中国发卡行发行的银行卡、中国电信运营商提供的实名手机，因此也几乎不可能完成 II 类帐户的实名认证。
而支付宝和微信要想对境外用户提供服务，除了要满足中国的上述规定之外，还要满足服务所在国对支付的相关监管。而一旦两国的监管政策相互矛盾，则更无法提供服务。
这其实并非是中国支付出海的困境，也是其他所有跨国支付企业的难点。即便是老牌的 PayPal 也是通过一些复杂的分公司结构来实现跨境结算的合规操作。
不过，商户已经解决了，中国游客也自带了「推广」效果。中国支付真出海的一天可能并不远了吧。
【涨知识】
轻快PDF阅读器是一款基于手机用户所使用的手机端PDF文件查看器，轻松移动查看文件，可支持手机编辑PDF文件！
小编有话说：
支付宝、微信支付已经开始蔓延全球各大城市，将来整个全世界都在使用手机支付的时候是不是就不再使用现金了！
责任编辑：
声明：该文观点仅代表作者本人，搜狐号系信息发布平台，搜狐仅提供信息存储空间服务。
迅捷PDF编辑器官方网站
轻快PDF阅读器官方网站
今日搜狐热点我看所谓的微信和支付宝大战 究竟谁胜谁败？
微信支付与支付宝的春节红包大战刚告一段落，伴随着近日微信支付团队发布公告称自3月1日起，开始对零钱提现收取手续费，一石激起千层浪，围绕着微信支付与其它移动支付，尤其是支付宝的论争又一次引爆舆论。关于微信支付与支付宝的移动支付大战，我几年前就写过相关文章，现在重新发出来。
这两天在美交流，很多人问我如何看待微信支付和支付宝大战的事情，恰巧，最近跟几个领导一起合写了一本《支付革命》，我提几点不成熟的看法。
第一、非正面竞争
微信支付确切的说，跟支付宝不是一致竞争。支付宝是支付工具，而微信支付，只是以微信为基础，为支付提供应用场景的生态体系，微信是个底层架构，是个生态系统。支付是微信基础上衍生出来的一个服务，微信可以搭载更多的支付工具，包括了支付宝，也可以在微信上实现有效应用，所以说，微信支付跟支付宝确切的说不是一个层面上的竞争。
从结果来看，微信通过这种方式，让支付宝感受到了压力是必然的，因为很多支付工具，都可以依赖微信所形成的应用场景，来实现支付，从而就不需要再充值到支付宝里去，通过支付宝来实现支付了，从而对支付宝形成了挤压，这里的核心，其实并不是微信支付跟支付宝打，他只是支持了很多支付机构来跟支付宝打。包括了银行支付，都可以搭载微信基础。
我自己觉得支付这个行业，最终比拼的其实不是技术，而是应用场景，更多应用场景，才能有更多的支付可能，脱离了支付使用场景，支付很难生存，支付宝走到了第一，是因为有了淘宝，财付通走到第二是因为腾讯，如果单纯比拼支付，支付宝肯定远胜财付通，那是因为商品特性更产生支付基础，而社交的支付场景过少，两者不可比。但是微信横空出世之后，已经把腾讯也从原先的社交属性里给延展出来，现在的微信其实已经远不止社交的概念，一个适用人群覆盖六亿的客户端，理论上可以把人类的各类行为都涵盖在内，从而诞生出更多的想象空间了，就支付而言，就已经远远大于淘宝的支付场景，这个时候，微信支付的可怕之处就显现出来了，可以实现真正的无处不支付。
这里其实还有个所谓线下线上之争的观点，事实上，在当前的技术条件下，从逻辑上推论，互联网的总体流量也好，需求也好，都是有限的，可以直接推算为总人口乘以总时间这个是极限值，总体流量有限的情况下，诞生两个逻辑，第一个是线上线下平衡逻辑，人在线上和线下分配自己的时间，也就是分配流量，目前从电商情况来看，虽然电商发展速度很快，但是总占比还只是占到大概不到8%左右的份额，这里面其实虽然还有很大想象空间，但是现实也看到很多线下目前的确也遇到无法线上化的问题，线上入口目前白热化的竞争背后，其实反映的是线上的流量目前大幅度增长的可能性在降低，技术条件约束了很多线下东西无法线上化，虽然可以看到珠宝、汽车都在线销售，但是全体性的铺开线上化，难度还是很大。为什么O2O大行其道，反过来其实也说明的是未来线下的流量之争可能比线上更关键。
基于线上流量的增长乏力的情况下，目前互联网里的竞争业态，就反映为在各个业态之间分配时间的不同所呈现的流量此消彼长的情况，微博没落，不是因为微信比微博好，因为两者不可比，但是微信挤占了更多人类的时间，自然就会对微博构成了挤压，互联网之间的竞争，就是如此，我喜欢吃肉了，就不太会多吃素菜，因为我吃的东西总是有限的。流量之争的背后其实表现为人类更喜欢在什么地方上花更多的时间，从而把那些不愿意花时间的东西给打败了，跟这两个东西好坏不关键。
所以微信支付的逻辑其实就我愿意在微信上停留更多的时间，我自然也就会在微信上把支付的事情给干了，当然前提是微信支付要提供足够方便的支付场景，而前面说了，几乎人人在用微信，这个应用场景其实就很容易形成，支付宝的钱包，很难做到人人都用。支付场景要超越微信的难度很大，毕竟一个是开放体系，一个是单一体系。
这里面谈所谓的财付通的事情，我坚持我在北京电视台BAT大战里说过一个观点，没有微信的财付通，一无是处，而有了微信，财付通天下无敌，但是这里有个前提其实是微信要带着财付通玩，因为理论上，前面说了，微信只是个基础平台，应该是开放式的，不应该只是财付通的应用场所，否则对微信的伤害也很大，从这个角度来看，一旦微信抛弃了财付通，我看财付通会好，但是很难很好。
第二、谁胜谁败?
微信支付不犯错误的情况下，感觉失败的可能性不大，理由两个，第一个是支付宝跟其他支付是正面竞争和对抗，不但包括跟第三方支付公司竞争对抗，还跟银行进行对抗，他的核心逻辑是，支付宝自建账户体系，要从银行里拿钱充值到自己的钱包里去，虽然最终托管在银行，但是一方面必然是降低了银行利差收益，挖走了银行很大的存量低息资金，另外一方面，其实是绕开了银行的清算，形成体系内的虚拟清算，无论哪个，都是树敌过多的行为，从人家口袋里抢钱的事情，不好干。加上阿里一直很强势的作风，我感觉规模越大，阻力越大。
而微信支付前面说了，不跟任何一家支付机构形成对抗，确切的说，他是提供支付和服务的机构，更开放的模式，比相对封闭的模式，更容易起规模，也更容易铺开，所以微信支付5月份上线，我估计到年底做到五六千万的用户群，应该不是难事，这个是必然的，甚至他都会考虑放开第三方支付公司，阻力会更小，微信支付确切的说，更符合互联网的开放特性和去中介化特性。
第三，安全性。
这个问题，很难回答，从逻辑上推论，两个都必然是金融级安全技术，否则无法支撑支付这个行业，但是由于各自流程不同，在流程上的漏洞是非技术层面出现的，支付宝的快捷支付目前出现的安全漏洞报道较多，一方面是因为捆绑手机的非卡非密方式，主要是大量快捷支付的应用，可以通过拦截手机来实现破解，这个破解其实已经跟技术本身可能已经是关系不大，而是因为流程上存在漏洞，要填补这样的漏洞就要考虑更改流程，而更改流程，会带来支付体验的不佳。安全性和便捷性永远是个博弈难题，只能寻求平衡点。
另外，支付宝采取的是自建账户体系的方式，相当于你额外弄了个零钱包，而且还支持零钱包之间的相互转账功能，也在不断的扩大支付场景，零钱包可以直接使用，可以绕开银行卡进行交易，这样就使得你就要花更多的心思去保管这个零钱包，而且现在零钱包里的零钱越来越多之后，攻击力度都会极大的增加，也一定程度上抬高了安全成本。
而微信支付不是这个概念，微信支付只是帮助你从你的银行卡到别的银行卡，直接跟银行卡捆绑，他本身不是资金沉淀和账户体系的概念，资金还是沉淀在银行卡里，所以，更多安全性还其实是回归到银行卡身上去，在流程上，也比较简单，直接还是通过银行卡进行划款，流程相对更简单，应该也更安全。
当然这个只是逻辑推演，这个命题现实中还真很难说明白，我自己个人感觉，目前能解答的说法只能是谁也无法说谁比谁更安全，但是考虑到两者都是全赔策略，其实，意义也不大。反正微信支付和支付宝都是全赔的情况下，打安全牌意义也不是特别大。
第四、支付宝加上来往呢?
来往对抗微信的事情，从常理上推论，其实胜算是很小的，互联网的竞争，一致竞争的可能性，先发优势和基础性优势，是很难撼动的，我们看到过很多公司后发制人，譬如携程干掉艺龙等，但是这种概率还是很低，更何况腾讯一直以即时通讯起家，如果会被来往给干掉，我看马化腾也干脆回家种地去得了，这里的基本逻辑是，马化腾不要犯太大的错误，在微信上败给来往的可能性基本上没有。而且现在的微信承载了大量的其他功能，使得微信越来越不可能被颠覆，因为替换成本太大。
来往能做成第二个旺旺，但是做不成第二个微信，这个是我的基本判断，干趴微信的必然是另外一种更让用户群在上面停留花费更多时间的东西，在即时通讯领域，大部分人其实是不会去做第二个选择了，真没必要，用什么都一样的东西，干掉微信的是那些我们现在想不到的生活习惯或者生活方式的东西，而不是来往这样，跟微信连外表都一样的东西。
所以加上了来往的支付宝，也很难打得过微信支付，更何况，我感觉支付宝走的就是独立账户体系的模式，承载开放性的可能性基本上是没有的，即使来往做起来了，做来往支付，其实是革支付宝的命，这个对支付宝来说，可能性几乎为零。所以即使加上了来往的支付宝，也本质上行跟微信支付是不一样的东西。
最近，微信也说推出余额宝，由于微信支付是通道模式，这个模式，不会形成资金的沉淀，有账户体系，但是不以账户体系为核心，他只是给微信提供方便的资金服务应用，但是由于没有资金沉淀，也就没余额管理的概念，个人感觉微信的余额宝金额是超越余额宝是不可能的事情，余额宝的基础性优势是账户体系模式，所以这个基础不打掉，没人能超越余额宝，唯一能打败余额宝的，其实是银行的活期直接转货币基金，但是这个显然银行短期是不会去做的事情，这里面，由于微信的便捷性，估计会打掉一些纯粹以存款替代为目的的投资人放弃支付宝的钱包，而使用微信的余额宝，存在一定的分流可能性，实际的意义比较有限。
责任编辑：
声明：该文观点仅代表作者本人，搜狐号系信息发布平台，搜狐仅提供信息存储空间服务。
今日搜狐热点