第三方支付流程
一.支付寶和銀聯的支付流程
常用的支付方式有：
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支付，采用第三方支付平台進行支付的方式。