支付
一.支付寶和銀聯(lián)的支付流程
常用的支付方式有：
1、支付寶支付
支付流程：
（1）先與支付寶簽約讶凉，獲取商戶id（partner）和賬號id（seller）
（2）下載相應的公私鑰文件（加密簽名使用）华嘹，在客戶端我們可能只需要私鑰
（3）下載支付寶sdk
（4）生成訂單信息溢吻，可以直接客戶端或者自己服務端生存都可以烘豌，但是大多是服務端生存的。
（5）調用支付寶客戶端，有支付寶客戶端跟支付寶打交道
（6）支付完畢之后返回結果給客戶端和服務端塘安。
2、微信支付
支付流程：
(1)注冊微信開放平臺援奢，創(chuàng)建應用獲取appid兼犯，appSecret，申請支付功能集漾，申請成功之后會返回一些參數(shù)詳情見圖
(2)下載微信支付sdk
(3)客戶端請求訂單切黔，后臺與微信后臺交互，返回給客戶端支付參數(shù)帆竹；
(4)調用微信客戶端绕娘，由微信客戶端和微信服務器打交道；
(5)客戶端和服務端都會收到支付結果栽连；（前臺消息不可靠险领，我們需要去后臺驗證侨舆，如果后臺沒有收到支付通知，后臺去微信服務器驗證然后將結果返回給客戶端）
注意事項：
1）如果APP里面已經(jīng)使用了ShareSDK绢陌，就有一些地方要注意挨下。不要再重復導入微信的SDK，因為shareSDK里面的extend已經(jīng)包括了微信的SDK脐湾。
2）微信本身是鼓勵客戶APP把簽名算法放到服務器上面臭笆，這樣信息就不容易被破解。但是如果客戶APP本身沒有服務器端秤掌，或者認為不需要放到服務器端愁铺，也可以直接把簽名（加密）的部分直接放在APP端。Sample代碼的注釋有點亂闻鉴，多次提到服務器云云茵乱，但是其實可以不這么做。
3孟岛、銀聯(lián)
支付流程：
（1）注冊申請就不是前端的事了瓶竭，直接介入sdk
（2）從自己的服務端獲取流水號
（3）然后調用銀聯(lián)sdk，不用跳轉渠羞，銀聯(lián)sdk直接是內嵌的
（4）支付完成之后會回調代理方法
4斤贰、內購
?請求有效的產(chǎn)品代號集合
?購買指定產(chǎn)品
?驗證購買
?恢復購買
http://www.tairan.com/archives/2215/
5、Ping++
https://pingxx.com/guidance/products/apple-pay
Ping++同時支持微信支付次询、公眾賬號支付荧恍、支付寶錢包、百度錢包屯吊、銀聯(lián)手機支付块饺、掃碼支付 開發(fā)者不再需要編寫冗長的代碼，簡單幾步就可以使你的應用獲得支付功能雌芽。
支付流程：
(1) Client發(fā)送支付要素給Server
(2) Server發(fā)送支付請求并將返回的支付憑據(jù)傳給Client
(3) Client調起支付控件完成支付
(4)渠道同步返回支付結果給Client
(5).Server收到Ping++發(fā)送的交易結果的異步通知
6、BeeCloud
https://beecloud.cn/doc/?from=timeline&isappinstalled=1#sec_pay?index=1
目前已經(jīng)包含微信APP辨嗽、支付寶APP世落、銀聯(lián)在線APP、PayPal夜焦、百度錢包APP支付功能般哼，以及支付訂單和退款訂單的查詢功能齿桃。還包含了線下收款功能(包括微信掃碼、微信刷卡武花、支付寶掃碼、支付寶條形碼)杈帐，以及訂單狀態(tài)的查詢與訂單撤銷
支付流程：
? (1)app向發(fā)送支付要素 ?做完這一步之后就會跳到相應的支付頁面（如微信app中）体箕，讓用戶繼續(xù)后續(xù)的支付步驟
（2）SDK向BeeCloud服務器發(fā)送預支付請求
（3）BeeCloud服務器返回預支付數(shù)據(jù)
? (4)SDK發(fā)起支付請求
（5）同步返回支付結果給app
付款完成或取消之后专钉，會回到客戶app中，需要做相應界面展示的更新（比如彈出框告訴用戶"支付成功"或"支付失敗")累铅。非常不推薦用同步回調的結果來作為最終的支付結果跃须，因為同步回調可能（雖然可能性不大）出現(xiàn)結果不準確的情況，最終支付結果應以下面的異步回調為準娃兽。
（6）異步返回支付結果 給BeeCloud服務器
? ?(7)(在客戶服務端）處理異步回調結果（Webhook）
付款完成之后菇民，根據(jù)客戶在BeeCloud后臺的設置，BeeCloud會向客戶服務端發(fā)送一個Webhook請求投储，里面包括了數(shù)字簽名第练，訂單號，訂單金額等一系列信息玛荞〗刻停客戶需要在服務端依據(jù)規(guī)則要驗證數(shù)字簽名是否正確，購買的產(chǎn)品與訂單金額是否匹配冲泥，這兩個驗證缺一不可驹碍。驗證結束后即可開始走支付完成后的邏輯。
7.支付功能-需要返回哪些參數(shù)
公共返回參數(shù)
result_code返回碼0為正常
result_msg返回信息凡恍，OK為正常
err_detail具體錯誤信息
id成功發(fā)起支付后返回支付表記錄
不同的支付方式的返回參數(shù)有些不同志秃，可以到官方文檔去看。
支付寶返回參數(shù)說明
1嚼酝、支付寶的返回有兩種：return的客戶端返回浮还，notify的服務器通知返回。
支付完成后立刻返回到外部網(wǎng)站的客戶端上闽巩，是可見的钧舌，返回機制：以GET的方式返回
返回信息包括提交給支付寶的訂單信息，可根據(jù)這個返回信息做相應的操作顯示給客戶看涎跨。
notify_url：服務器的返回
服務器的通知返回是由支付寶的服務器發(fā)起洼冻，以POST的方式返回到合作伙伴的網(wǎng)站上。返回信息包括提交給支付寶的訂單信息隅很，在返回的文件中撞牢，需要輸出success做為支付寶通知返回信息成功，若沒有這個success的輸出叔营，那么支付寶的服務器會24小時內返回同樣的返回消息屋彪，返回的時間頻率會逐漸減弱，（1分鐘绒尊、3分鐘畜挥、5分鐘、10分鐘婴谱、15蟹但。躯泰。。矮湘。斟冕。。缅阳。磕蛇。。十办。）
notify_url頁面中只能做對數(shù)據(jù)庫的業(yè)務操作
建議：return_url和notify_url可以都設置秀撇，前者做數(shù)據(jù)顯示，后者做更新數(shù)據(jù)庫
2向族、 注意的地方呵燕，每種返回都是有一個sign和mysign的驗證，作用件相，驗證參數(shù)是否有效和是否是支付寶發(fā)出的消息再扭。還有一個交易狀態(tài)的判斷：trade_status是判斷交易狀態(tài)是否成功，例如：
返回狀態(tài)：
trade_status = "WAIT_BUYER_PAY"等待買家付款
trade_status = "WAIT_SELLER_SEND_GOODS"買家付款夜矗，等待買家發(fā)貨
trade_status = "WAIT_BUYER_CONFIRM_GOODS"賣家付款泛范，等待買家確認
rade_status = "TRADE_FINISHED"交易完成
基本上會有以上幾種重要的交易狀體需要判斷，還有一些詳細：請以支付寶接口文檔為主紊撕，當然不是每種接口都有這些交易狀態(tài)罢荡，虛擬的即時到帳接口是不存在買賣雙方確認的環(huán)節(jié)的。
service ? ? ?= ? "create_direct_pay_by_user"即時到帳接口的服務名稱
service ? ? ?= ? "trade_create_by_buyer"標準實務雙接口服務名稱
HAS_NO_PRIVILEGE出現(xiàn)這個樣的錯誤对扶，請注意您說開通的接口權限是否是以上兩種区赵，或者在您集成的接口中是否有用您與支付寶簽約后的ID和key
4.支付的安全處理；
（1）請求基于https
（2）可多次進行數(shù)據(jù)加密
關于支付方面安全的處理不用我們去管浪南，具體的安全問題是由支付寶笼才、微信等支付三方的自己內部去做的。
二络凿、有沒有做過支付患整？需要注意哪些問題？
有:
1喷众、產(chǎn)品的支付驗證服務器選擇
當創(chuàng)建好產(chǎn)品后，客戶端進行IAP服務監(jiān)聽后紧憾，由于IAP在支付后成功后到千，會收到蘋果服務器的支付憑證，客戶端在獲取到支付憑證后赴穗，需要將支付憑證反饋給server服務器進行支付驗證確認憔四。此時膀息，不管是采用客戶端APP的server驗證方式還是客戶端APP驗證方式，都需要根據(jù)當前APP的支付環(huán)境選擇正確的驗證地址了赵，在蘋果服務器中潜支，沙盒測試環(huán)境的IAP驗證地址為：https://sandbox.itunes.apple.com/verifyReceipt，正常線上交易的驗證地址為：https://buy.itunes.apple.com/verifyReceipt柿汛，為保證審核的通過冗酿，需要在客戶端或server進行雙重驗證，即络断，先以線上交易驗證地址進行驗證裁替，如果蘋果正式驗證服務器的返回驗證碼code為21007，則再一次連接沙盒測試服務器進行驗證即可貌笨。
在應用提審時弱判，蘋果IAP提審驗證時是在沙盒環(huán)境的進行的，即：蘋果在審核App時锥惋，只會在sandbox環(huán)境購買昌腰，其產(chǎn)生的購買憑證，也只能連接蘋果的測試驗證服務器膀跌，如果沒有做雙驗證遭商，需要特別注意此問題，否則會被拒淹父；
2株婴、產(chǎn)品線上支付過程中的不同環(huán)境處理
IAP沙盒環(huán)境及線上環(huán)境在處理過程中有些問題，需進行特殊處理暑认；
在沙盒環(huán)境下困介，進行支付時，無銀行支付驗證過程蘸际，此時應用一直處于IAP支付過程中座哩，直至支付完成；
而在線環(huán)境下粮彤，由于IOS6添加了支付確認過程根穷，導致在銀行密碼確認過程中確認完畢后，應用未能及時返回APP,且此時會收到server下推的SKPaymentTransactionStateFailed事件导坟，當返回到應用后屿良，如果此時已經(jīng)注冊了IAP支付消息處理，當剛才的支付成功后惫周，蘋果服務器會反饋SKPaymentTransactionStatePurchased或SKPaymentTransactionStateRestored事件尘惧，此時客戶端在此事件中獲取憑證并進行支付確認；
由于部分類型具有購買恢復操作Restore递递，所以當刪除APP后喷橙，又重新安裝APP啥么，此時需要恢復之前的購買時，在IAP處理中仍需進行SKPaymentTransactionStateRestored事件的處理贰逾，如果通過server方式進行支付憑證驗證的悬荣，需要判斷當前的Restore事件是恢復支付還是購買支付，以保證servver的統(tǒng)計正確疙剑；此時可由server根據(jù)驗證憑證中的有效信息（如有效期信息）進行判斷是為新的購買還是以往支付的恢復氯迂；
3、IAP事件注冊時機
對于IAP支付核芽，當支付成功時但由于網(wǎng)絡等引起的支付憑證驗證失敗或未進行驗證時囚戚，在IAP事件注冊后，蘋果服務器會通過SKPaymentTransactionStatePurchased或SKPaymentTransactionStateRestored事件進行返回支付憑證轧简，客戶端需對此支付憑證進行驗證驰坊，以保證支付完整性；為此哮独，在app啟動時拳芙，應直接進行IAP事件注冊；即：[SKPaymentQueuedefaultQueue]addTransactionObserver操作皮璧；
4舟扎、越獄手機的IAP問題
由于越獄手機可能安裝了黑客的惡意程序，監(jiān)聽網(wǎng)絡數(shù)據(jù)悴务，支付憑證中并不包含任何用戶的apple id信息睹限，所以我們的app和服務器無法知道這個憑證是誰買的，如果惡意程序截獲蘋果服務器的有效支付憑證讯檐，但惡意程序將假的支付憑證發(fā)給后臺server導致原支付的賬號驗證失敗羡疗，而此時惡意程序將截獲的有效支付憑證對應到另外的支付賬號上，就會導致該惡意程序設置的賬號通過正確的支付憑證而獲取server的認證别洪。
所以叨恨，對于越獄的手機可禁用IAP支付，采用第三方支付平臺進行支付的方式挖垛。
