做了好多支付开发相关 总结总结 与开发语言无关

ghostwwl

1. 传统的 html 或者wap支付(代表: 百付宝， 老版本支付宝接口， 银联， 快钱....) 流程
        a. 本地订单数据 按照规则签名 构建form 提交到指定的url
        b. 后面的流程就是 支付接入口那边处理的
        c. 处理完后一般有后台通知 有的还有前台通知

2. 带预下单的支付(代表: 微信支付， 蚂蚁金服新版支付宝的当面付【扫码支付】)
        a. 本地订单签名 提交到 指定的接口
        b. 返回的数据交给客户端 比喻 生成二维码 给他们的客户端扫
        c. 支付成功后台会有通知

3. 关于后台通知和到账查询问题
        a. 记住所有的通知你处理完后要正确的返回 告诉他们我收到通知并且处理了 不然会不停的通知(各家不同）
        b. 一般来说提供商不出问题 都会及时通知 但是有时候没有呢
        c. 基本现在所有的 提供商都会有 单笔交易查询接口
        d. 我们可以 通过本地商户订单号 调用这个接口 查询这个订单在他们那边的情况
        e. 可以用来自动对账和作为回调的补充

4. 关于给一堆银行卡打款的问题
        a. 很多支付接口都提供 企业付款接口
        b. 构建支付订单 把银行卡和金额及开户行。。。。 提交请求 一般都直接返回他们的受理情况
        c. 他们受理后 一般T+1 最块2个小时左右就到对方账户了
        d. 同样这个也有查询接口 查询他们打款到哪一步了

5. 关于洗钱和信用卡交易
        a. 如果我没有记错 貌似 包括微信支付在内 好多支付接口 都可以在构造的时候 加入不允许用户使用信用卡支付
        b. 你懂得 这样就避免了企业到时候要协助调查信用卡套现的风险

6. 关于大量并发造成支付问题
        a. 这个问题大多数发生在 调用支付接口 接口速度慢等着返回 然后本地支付并发量大的情况下
        b. 举个例子 过年了要发微信红包
        c. 发现大量的用户来了 领取红包 后台直接。。。。
        d. 处理办法呢 哈哈哈
                1. 把调用微信给一个用户发红包的 接口弄成分布式rpc
                2. 来了调用这个rpc接口发了就ok
                3. 这个分布式rpc 后面也许在10几台 或者N个进程处理在
                4. 我们只需要发出去就ok 不管是那台机器去调用的微信发红包接口
        e. 另外的方法 实在没有过多的机器
                1. 领取红包 加入任务队列 比喻 rabbitmq
                2. 任务如果添加成功 直接给用户返回 好了等红包吧 你已经领到了 大约在 xxx 小时内会给你发送
                3. 后台搞个服务就是处理这个任务队列 一个一个发 哈哈。。。。。

7. 其它的一些呢
        a. 数据安全问题
                1. 基本见到的都是采用 ras签名 (接入放1对密钥 私钥自己发出的数据签名 公钥上传 给他们用来验证我们的签名)
                2. 然后他们也有1对密钥 私钥他们用来签名给你返回的数据 收到数据 你用他们的公钥验证签名
                3. 有的中间还有aes加密 就是你把数据aes加密后 在签名发给他们 他们受到后 验证签名 再aes解析


基本上常见的 支付接口大概都是这样一个流程呢
坑人的也不少 包括现在支付宝蚂蚁金服的文档都有的地方或者例子不对呢
这个时候咋办 看他们自己提供的api代码

支付宝新版本的sdk 很恶心 比喻说他自带的php sdk 450左右个源代码[而且还面向对象关键写的不咋地] 90%代码都雷同 如果只用扫码支付 大约46行代码可以搞定
他还有一个坑 商户同一个订单号可以重复下单 自己体验体验 这个又会造成其他的坑 当你看到支付宝服务器返回 系统错误 恭喜 你找到他们设计失误的地方了
当然这个不会造成钱的问题


关于内部会计及自动对账的一些 就不写了
没办法 现在没有好的blog用了 做个笔记先

ghostwwl

ras = rsa 打错字