最近接了不少支付相关的sdk，自己看下来发现这个业务其实蛮固定的套路。这里做下总结
介绍
其实市面上是有各种不同的支付平台的，像国内有aliy, wechat, 国外是paypal。 这还是比较主流的平台，如果考虑到其他的渠道，毛估可能会有上百个。
上面这个截图是从payssion平台截图下来的。对于开发者来说要全部接入一遍明显不现实的，并且也受限于法律法规有些平台不是你想接就能接入的。
流程
其实如果自己大概能接2-3个以后就会发现其实这些支付业务是差不多的“套路”的，或者也叫做流程。
1. 去对应平台生成应用，最主要的是拿到appId, appKey, appSecret这三样东西。
1. appId一般是是用来识别你应用的（非必须）
2. appKey一般是用于签名（可以认为是公钥），可暴露
3. appSecret也是用于签名（可以认为是私钥），不可暴露
2. 客户端像业务服务器拉起订单请求，主要是获取订单号orderId和金额amount
3. 客户端带着前面的获取的信息，继续请求业务服务器拉起支付请求。
4. 支付请求需要进心签名，各个平台签名方案不一样。但基本上是将一些必须参数同appKey和appSecret混合起来进行签名，获得一个sig。
1. 常见的一种签名方式（服务器端）：将业务参数按照字母顺序排列（除掉appKey），然后用appkey进心md5之类签名获得sig。当然这中间会涉及一些特殊字符和大小写处理。
2. 渠道一般会用私钥去解，看能不能获得相同的sig来判断签名是否正确。
5. 支付请求还需要带着两个额外的参数： returnUrl和notifyUrl。 这两个参数也可以通过渠道网站后台设置。
1. returnUrl可以认为是支付完成后跳转位置
2. notifyUrl实际上是一个异步状态同步通知位置
6. 一般来说，通过sdk完成步骤5后，返回结果会有一个和orderId匹配的transactionId。这个东西就是平台的流水号，而orderId是业务的流水号。两者需要建立一个映射关系，比如能够互相查找之类。像国内的基本会返回一个二维码支持移动支付。
7. 基本用户完成支付后，业务网站就是等待渠道调用notifyUrl就好了。为了避免丢失请求或者网络问题，渠道会要求notifyUrl返回特定字符，比如'success'。如果没有收到，它会通过轮询的方式去继续请求这个notifyUrl。最后的结果是要么获取到了特定字符，要么尝试上限达到而失败。
8. 收到NotifyUrl请求，首先也要验证平台过来sig的有效性，然后业务逻辑需要进行一个去重或者“等幂”操作。主要是更新订单状态state和进行商品发放的逻辑。
9. 在notifyUrl也有可能失败的情况下，不少渠道是提供query的功能的。这样业务可以通过主动查找订单的状态来继续自己的业务逻辑。
其实可以看到整个流程还是比较清晰的，就算有平台的差异性，但这个“套路”是基本固定的。有了这个固定的“套路”，其实诞生了不少的“中间商”： 它们做的事情无非是帮你统一了各个平台的差异化：
1. 统一了参数名字
2. 同意了接口路由
3. 统一了签名方法
4. 统一了汇率之类其他东西
然后收取了一些“服务费”。感觉这些公司就是躺着赚钱啊，真是容易。