第三方支付流程

第三方支付流程

一.支付宝和银联的支付流程

常用的支付方式有：

1、支付宝支付

https://openhome.alipay.com/doc/docIndex.htm?url=https://openhome.alipay.com/doc/viewKbDoc.htm?key=236714&type=cat

支付流程：

（1）先与支付宝签约，获取商户id（partner）和账号id（seller）

（2）下载相应的公私钥文件（加密签名使用），在客户端我们可能只需要私钥

（3）下载支付宝sdk

（4）生成订单信息，可以直接客户端或者自己服务端生存都可以，但是大多是服务端生存的。

（5）调用支付宝客户端，有支付宝客户端跟支付宝打交道

（6）支付完毕之后返回结果给客户端和服务端。

2、微信支付

https://open.weixin.qq.com/cgi-bin/showdocument?action=dir_list&t=resource/res_list&verify=1&id=1417694084&token=cd674b2fe840f8e60d09126cc5c7e2cd1317ffe6&lang=zh_CN

支付流程：

(1)注册微信开放平台，创建应用获取appid，appSecret，申请支付功能，申请成功之后会返回一些参数详情见图

(2)下载微信支付sdk

(3)客户端请求订单，后台与微信后台交互，返回给客户端支付参数；

(4)调用微信客户端，由微信客户端和微信服务器打交道；

(5)客户端和服务端都会收到支付结果；（前台消息不可靠，我们需要去后台验证，如果后台没有收到支付通知，后台去微信服务器验证然后将结果返回给客户端）

注意事项：

1）如果APP里面已经使用了ShareSDK，就有一些地方要注意。不要再重复导入微信的SDK，因为shareSDK里面的extend已经包括了微信的SDK。

2）微信本身是鼓励客户APP把签名算法放到服务器上面，这样信息就不容易被破解。但是如果客户APP本身没有服务器端，或者认为不需要放到服务器端，也可以直接把签名（加密）的部分直接放在APP端。Sample代码的注释有点乱，多次提到服务器云云，但是其实可以不这么做。

3、银联

支付流程：

（1）注册申请就不是前端的事了，直接介入sdk

（2）从自己的服务端获取流水号

（3）然后调用银联sdk，不用跳转，银联sdk直接是内嵌的

（4）支付完成之后会回调代理方法

4、内购

•请求有效的产品代号集合

•购买指定产品

•验证购买

•恢复购买

http://www.tairan.com/archives/2215/

5、Ping++

https://pingxx.com/guidance/products/apple-pay

Ping++同时支持微信支付、公众账号支付、支付宝钱包、百度钱包、银联手机支付、扫码支付 开发者不再需要编写冗长的代码，简单几步就可以使你的应用获得支付功能。

支付流程：

(1) Client发送支付要素给Server

(2) Server发送支付请求并将返回的支付凭据传给Client

(3) Client调起支付控件完成支付

(4)渠道同步返回支付结果给Client

(5).Server收到Ping++发送的交易结果的异步通知

6、BeeCloud

https://beecloud.cn/doc/?from=timeline&isappinstalled=1#sec_pay?index=1

目前已经包含微信APP、支付宝APP、银联在线APP、PayPal、百度钱包APP支付功能，以及支付订单和退款订单的查询功能。还包含了线下收款功能(包括微信扫码、微信刷卡、支付宝扫码、支付宝条形码)，以及订单状态的查询与订单撤销

支付流程：

  (1)app向发送支付要素  做完这一步之后就会跳到相应的支付页面（如微信app中），让用户继续后续的支付步骤

（2）SDK向BeeCloud服务器发送预支付请求

（3）BeeCloud服务器返回预支付数据

  (4)SDK发起支付请求

（5）同步返回支付结果给app

付款完成或取消之后，会回到客户app中，需要做相应界面展示的更新（比如弹出框告诉用户"支付成功"或"支付失败")。非常不推荐用同步回调的结果来作为最终的支付结果，因为同步回调可能（虽然可能性不大）出现结果不准确的情况，最终支付结果应以下面的异步回调为准。

（6）异步返回支付结果 给BeeCloud服务器

   (7)(在客户服务端）处理异步回调结果（Webhook）

付款完成之后，根据客户在BeeCloud后台的设置，BeeCloud会向客户服务端发送一个Webhook请求，里面包括了数字签名，订单号，订单金额等一系列信息。客户需要在服务端依据规则要验证数字签名是否正确，购买的产品与订单金额是否匹配，这两个验证缺一不可。验证结束后即可开始走支付完成后的逻辑。

7.支付功能-需要返回哪些参数

公共返回参数

result_code返回码0为正常

result_msg返回信息，OK为正常

err_detail具体错误信息

id成功发起支付后返回支付表记录

不同的支付方式的返回参数有些不同，可以到官方文档去看。

支付宝返回参数说明

1、支付宝的返回有两种：return的客户端返回，notify的服务器通知返回。

支付完成后立刻返回到外部网站的客户端上，是可见的，返回机制：以GET的方式返回

返回信息包括提交给支付宝的订单信息，可根据这个返回信息做相应的操作显示给客户看。

notify_url：服务器的返回

服务器的通知返回是由支付宝的服务器发起，以POST的方式返回到合作伙伴的网站上。返回信息包括提交给支付宝的订单信息，在返回的文件中，需要输出success做为支付宝通知返回信息成功，若没有这个success的输出，那么支付宝的服务器会24小时内返回同样的返回消息，返回的时间频率会逐渐减弱，（1分钟、3分钟、5分钟、10分钟、15。。。。。。。。。。）

notify_url页面中只能做对数据库的业务操作

建议：return_url和notify_url可以都设置，前者做数据显示，后者做更新数据库

2、 注意的地方，每种返回都是有一个sign和mysign的验证，作用，验证参数是否有效和是否是支付宝发出的消息。还有一个交易状态的判断：trade_status是判断交易状态是否成功，例如：

返回状态：

trade_status = "WAIT_BUYER_PAY"等待买家付款

trade_status = "WAIT_SELLER_SEND_GOODS"买家付款，等待买家发货

trade_status = "WAIT_BUYER_CONFIRM_GOODS"卖家付款，等待买家确认

rade_status = "TRADE_FINISHED"交易完成

基本上会有以上几种重要的交易状体需要判断，还有一些详细：请以支付宝接口文档为主，当然不是每种接口都有这些交易状态，虚拟的即时到帐接口是不存在买卖双方确认的环节的。

service      =   "create_direct_pay_by_user"即时到帐接口的服务名称

service      =   "trade_create_by_buyer"标准实务双接口服务名称

HAS_NO_PRIVILEGE出现这个样的错误，请注意您说开通的接口权限是否是以上两种，或者在您集成的接口中是否有用您与支付宝签约后的ID和key

4.支付的安全处理；

（1）请求基于https

（2）可多次进行数据加密

关于支付方面安全的处理不用我们去管，具体的安全问题是由支付宝、微信等支付三方的自己内部去做的。

二、有没有做过支付？需要注意哪些问题？

有:

1、产品的支付验证服务器选择

当创建好产品后，客户端进行IAP服务监听后，由于IAP在支付后成功后，会收到苹果服务器的支付凭证，客户端在获取到支付凭证后，需要将支付凭证反馈给server服务器进行支付验证确认。此时，不管是采用客户端APP的server验证方式还是客户端APP验证方式，都需要根据当前APP的支付环境选择正确的验证地址，在苹果服务器中，沙盒测试环境的IAP验证地址为：https://sandbox.itunes.apple.com/verifyReceipt，正常线上交易的验证地址为：https://buy.itunes.apple.com/verifyReceipt，为保证审核的通过，需要在客户端或server进行双重验证，即，先以线上交易验证地址进行验证，如果苹果正式验证服务器的返回验证码code为21007，则再一次连接沙盒测试服务器进行验证即可。

在应用提审时，苹果IAP提审验证时是在沙盒环境的进行的，即：苹果在审核App时，只会在sandbox环境购买，其产生的购买凭证，也只能连接苹果的测试验证服务器，如果没有做双验证，需要特别注意此问题，否则会被拒；

2、产品线上支付过程中的不同环境处理

IAP沙盒环境及线上环境在处理过程中有些问题，需进行特殊处理；

在沙盒环境下，进行支付时，无银行支付验证过程，此时应用一直处于IAP支付过程中，直至支付完成；

而在线环境下，由于IOS6添加了支付确认过程，导致在银行密码确认过程中确认完毕后，应用未能及时返回APP,且此时会收到server下推的SKPaymentTransactionStateFailed事件，当返回到应用后，如果此时已经注册了IAP支付消息处理，当刚才的支付成功后，苹果服务器会反馈SKPaymentTransactionStatePurchased或SKPaymentTransactionStateRestored事件，此时客户端在此事件中获取凭证并进行支付确认；

由于部分类型具有购买恢复操作Restore，所以当删除APP后，又重新安装APP，此时需要恢复之前的购买时，在IAP处理中仍需进行SKPaymentTransactionStateRestored事件的处理，如果通过server方式进行支付凭证验证的，需要判断当前的Restore事件是恢复支付还是购买支付，以保证servver的统计正确；此时可由server根据验证凭证中的有效信息（如有效期信息）进行判断是为新的购买还是以往支付的恢复；

3、IAP事件注册时机

对于IAP支付，当支付成功时但由于网络等引起的支付凭证验证失败或未进行验证时，在IAP事件注册后，苹果服务器会通过SKPaymentTransactionStatePurchased或SKPaymentTransactionStateRestored事件进行返回支付凭证，客户端需对此支付凭证进行验证，以保证支付完整性；为此，在app启动时，应直接进行IAP事件注册；即：[SKPaymentQueuedefaultQueue]addTransactionObserver操作；

4、越狱手机的IAP问题

由于越狱手机可能安装了黑客的恶意程序，监听网络数据，支付凭证中并不包含任何用户的apple id信息，所以我们的app和服务器无法知道这个凭证是谁买的，如果恶意程序截获苹果服务器的有效支付凭证，但恶意程序将假的支付凭证发给后台server导致原支付的账号验证失败，而此时恶意程序将截获的有效支付凭证对应到另外的支付账号上，就会导致该恶意程序设置的账号通过正确的支付凭证而获取server的认证。

所以，对于越狱的手机可禁用IAP支付，采用第三方支付平台进行支付的方式。