type
status
date
slug
summary
tags
category
icon
password
这一天被耍的团团转。竟然在三个平台上的支付宝相关信息都没有统一，还在说什么好用，真是无语了。最终用了小一天的时间来统一和测试了支付宝的相关集成问题。这里列一下集成过程中的一些总要的点吧。
一. 文档在哪里？
在网上搜个支付宝的文档都费劲，官方的文档页压根就没有找到，网上信息似乎说明支付宝只有一个 Demo，貌似还不是很靠谱(看这里)。害得我搜了好久相关信息。发现支付宝只有一个官方的论坛，使用过程中遇到的所有问题都提交到这个论坛里面，论坛里面会有管理员给你解答。在论坛中我发现了支付宝的一些相关资料，竟然是以帖子的形式出现的。。。文档竟然在下载下来的压缩包里面！！！
PS：支付宝AlipayRsaLib.a文件至今没有支持 arm64 架构。其中的 base64.o 已知与百度地图SDK，zbar冲突。但是 AlipayRsaLib.a 并不依赖 base64.o。因此可以删除其中的 base64.o 来解决冲突。具体操作可以查看我的这篇文章
论坛说明:
今天最开始遇到的问题就是手机端支付成功无法回调服务器端 notify_url.php 的接口。由于支付宝的测试是需要真的走现金交易流程的，而且服务器端也看不出什么问题。后来发现论坛里面有不少出现这个问题的，而且会有论坛管理员回复告知你在回调过程中发生了什么错误。所以如果遇到调试困难的相关问题，可以提交到这个论坛里面，等待管理员告知你支付宝后台的相关日志信息。
二. 客户端和服务器的私钥/公钥是一致的么？
支付宝的整个交易过程实际上是一个认证的过程，我们使用的是 RSA 加密，这是一种非对称加密算法，发现阮一峰博客对这个有一个比较有趣的解释，下面给出了地址。这种加密是需要公钥和私钥的，但是支付宝的文档写的比较模糊，开始我们一直没有搞懂服务器端和客户端的公钥私钥是否应该保持一致。在这里就说一下这个认证过程吧。
甲和乙通信
- 甲生成一个私钥，然后根据私钥生成公钥。甲保留私钥(privateKey1)，把公钥(publicKey1)交给乙
- 乙生成一个私钥，然后根据私钥生成公钥。乙保留私钥(privateKey2)，把公钥(publicKey2)交给甲
- 甲向乙发送信息：甲把要发送的信息使用私钥(privateKey1)签名，然后把签名后的信息发送给乙
- 乙接收甲的信息：乙使用公钥(publicKey1)验证签名，确认这条信息是甲发来。
- 乙向甲发送信息：乙把要发送的信息使用私钥(privateKey2)签名，然后把签名后的数据发送给甲
- 甲接收乙的信息：甲适用公钥(publicKey2)验证签名，确认这条信息是乙发来的
实际上支付宝的交易流程是使用公钥私钥来签名(可以把上面的过程甲看成支付宝，乙看成我们)，所以支付宝的文档上说明用户需要自己生成一个私钥，用作签名，然后使用这个私钥再生成公钥，把这个公钥上传到支付宝后台管理上面，用作支付宝的签名验证。然后支付宝会给用户一个支付宝的公钥，用户使用这个公钥来做签名验证。
综上：
服务器端需要保存一个自己生成的私钥来对数据签名，还需要保存一个支付宝的公钥，当支付宝做接口回调的时候来验证支付宝签名。
客户端也是需要使用私钥来签名数据，使用支付宝公钥来验证支付宝签名
所以服务器与客户端的私钥和公钥都应该是一致的
三. 再谈非对称加密
公钥私钥的原则：
- 一个公钥对应一个私钥。
- 密钥对中，让大家都知道的是公钥，不告诉大家，只有自己知道的，是私钥。
- 如果用其中一个密钥加密数据，则只有对应的那个密钥才可以解密。
- 如果用其中一个密钥可以进行解密数据，则该数据必然是对应的那个密钥进行的加密。
公钥与私钥的作用是：用公钥加密的内容只能用私钥解密，用私钥加密的内容只能用公钥解密
非对称加密可以用来加密数据，也可以用来做身份认证
加密：
加密是甲方使用公钥加密数据，乙方使用私钥解密数据
认证：
甲方使用私钥签名，乙方使用公钥验证