前言：
近期耗拓，項目中用到應用內(nèi)支付，隨之在無任何參考資料的情形下奏司，獨上高樓乔询，望盡天涯路！開始應用內(nèi)支付資料收集韵洋，文檔閱讀竿刁，和源碼Demo分析等黄锤。
應用內(nèi)支付網(wǎng)上資料甚少，且特老食拜，需總體匯總后準備做一系列文章學習鸵熟，愿與各位大神切磋技術點滴。
好了负甸，廢話不多說了流强，本篇重點為對應用內(nèi)支付進行前期的理解，策略為有前人做好的技術分享呻待，能用則用煮盼，不能用則參考修改后自己總結學習。
目錄：
一.各種支付方式學習以及對應用內(nèi)支付理解
二.支付申請準備工作
三.蘋果三種賬戶設計學習
四.應用內(nèi)支付文字版流程梳理
一.各種支付方式學習以及對應用內(nèi)支付理解
1.各種支付方式有哪些
平時接觸比較多的微信支付带污，支付寶支付，銀聯(lián)支付等香到；
在iOS平臺支付主要分為二類：第三方支付和應用內(nèi)支付
第三方支付：支付寶鱼冀，微信支付，京東（包含其他App內(nèi)的支付等）悠就，銀聯(lián)支付等千绪；
應用內(nèi)支付：包含蘋果支付和IAP（內(nèi)購）。
其中第三方支付之前集成學習過微信和支付寶支付詳見下面文章：
應用內(nèi)支付中的蘋果支付和內(nèi)購支付最大的區(qū)別在于購買的物品是真實物品還是虛擬物品：
如人們平時網(wǎng)上購物的衣食電器類的為真實物品梗脾，采用蘋果支付荸型；而形如，會員炸茧，游戲幣瑞妇，訂閱網(wǎng)絡雜志等虛擬物品采用內(nèi)購支付IAP。
注意：本系列文章主要討論IAP內(nèi)購支付方式梭冠。
2.應用內(nèi)支付理解
IAP全稱為In-App Purchase,即為應用內(nèi)支付方式辕狰，蘋果設立的目的即因為人家提供平臺，我們各位技術人員用技術開發(fā)產(chǎn)品控漠，對一些虛擬產(chǎn)品（如會員）抽成30%蔓倍，不然不讓審核通過，霸道的吸血鬼吧盐捷！
蘋果對虛擬產(chǎn)品定義如上面支付分類偶翅，對虛擬產(chǎn)品本身細分為以下四類，解釋也很詳細碉渡，這里就不多說了聚谁！
二.支付申請準備工作
1.第一個參考對象如下：
該Demo主要參考到如下第一部分即藍色區(qū)間即可，因為第二部分不是最新的參考無用滞诺，第三部分可參考也可不參考垦巴，第四部分本篇之后的下篇會封裝完整Demo學習媳搪。
2.創(chuàng)建內(nèi)購項目：
進入我們的項目后，按照以下步驟依次點擊添加內(nèi)購產(chǎn)品骤宣，注意下面紅色框框在第一次還沒添加項目時實際是空的哦秦爆！
進入下面的界面，注意這里的自動續(xù)期訂閱請謹慎選擇憔披，站在用戶的角度考慮是不太合理的哦等限！
點擊創(chuàng)建后來到下圖所示頁面，依次填上藍色箭頭所指的地方芬膝，紅色箭頭往下的內(nèi)容暫時可不填望门，之后點擊存儲，即完成商品的創(chuàng)建锰霜；需要注意的是筹误，上線審核前需要和產(chǎn)品經(jīng)理溝通以下內(nèi)容如何填的問題，切記癣缅，不然蘋果可能無法過審厨剪，且不能有測試的字樣。
3.添加內(nèi)購項目測試賬號
回到我的App界面友存，如下圖所示：點擊對應的用戶和職能
進入下面的界面祷膳，按照如圖順序點擊對應的+號添加
進入下圖所示界面，之后全部填寫完畢屡立，點擊存儲即可直晨。
其中如上所示的：
電子郵件可填一個假郵件，
密碼一定要復雜些膨俐，和AppId的密碼設置一樣勇皇，含有數(shù)字，大小寫字母和下劃線焚刺，不然就會出現(xiàn)下面的問題儒士，實測挺坑的。
AppStore地區(qū)本來沒什么可說的檩坚，可是關于游戲分區(qū)問題着撩，中國區(qū)和其他地方的區(qū)就不能是同樣的沙盒測試賬號，注意匾委！
同理AppStorre Connect 用戶創(chuàng)建如下拖叙，之后點擊下一步按照提示一步步走下去即可，唯一注意的是赂乐，這里的郵箱是真實郵箱薯鳍，切必須是綁定AppId的郵箱，因為添加完成后，郵箱會收到一個驗證鏈接加入
至此挖滤，準備工作已全部完畢崩溪。
三.蘋果三種賬戶設計學習
原本在很早研究蘋果推送時第一次知道蘋果為了避免測試環(huán)境數(shù)據(jù)污染線上數(shù)據(jù)，專門設置了所謂的二種開發(fā)模式斩松，開發(fā)中的為開發(fā)模式伶唯，上線后為生產(chǎn)模式；
本次開發(fā)中惧盹，蘋果雖號稱是2種模式乳幸，實際研究中發(fā)現(xiàn)為3種模式，
3.1即上面用戶和職能說的比較詳細的沙箱技術測試員模式钧椰；
3.2即同樣為上面用戶和職能中的AppStoreConnect用戶模式粹断；
3.2為真正通過蘋果審核后的線上普通用戶模式；
這三種模式有什么注意事項呢嫡霞？3.1模式一切為假的瓶埋，如郵箱賬號為假，付款金額為假诊沪，可以自行測試學習养筒；3.2模式則賬號必須為真的，且打包通過ad Hoc模式打包娄徊，之后通過TestFlight下載使用，但所付金額依然是假的盾戴。嘿嘿寄锐，以上2種模式可以好好裝土豪了哈！
3.3模式則是面對我們真正的用戶尖啡，一步步的真金白銀付出橄仆，當然是在蘋果抽走30%后的剩余部分。
四.應用內(nèi)支付文字版流程梳理
1.支付流程
1.1.支付前
（1）.創(chuàng)建對應的商品衅斩，并告訴后臺對應的商品Id
（2）.App從后臺獲取商品列表盆顾，埋伏對應的ProductId在每個應用中
（3）.通過ProductId去蘋果服務器獲取蘋果對每個商品的的下單請求
1.2.支付中
（4）.用戶點擊購買按鈕時，調(diào)出蘋果的支付AppId輸入賬號密碼窗口畏梆，輸入密碼后
（5）.把對應已經(jīng)下單好的請求數(shù)據(jù)發(fā)送支付到AppStore
（6）.蘋果處理支付請求后返回對應的transaction信息
（7）.客戶端確認后開始驗證
1.3.支付后
（8）.首先拿到transaction信息中的productId是否存在您宪，之后獲取本地的receipt字符串去蘋果服務器驗證
（9）.驗證成功后再去我們的服務器驗證（本地服務器拿到此信息到蘋果服務器驗證），此即為雙重驗證
（10）.最后根據(jù)我們的服務器返回結果決定用戶是否購買成功奠涌，同時我們的服務端要更改對應的字段宪巨，比方變成會員或者給用戶充對應的游戲幣等
2.注意事項：
1.其實第一次研究該支付時，是在用戶點擊了購買之后才開始下單溜畅，支付捏卓，雙重認證的流程，之后經(jīng)過具體改進慈格，把下單放在用戶點擊購買按鈕之前就會減少用戶等待時間怠晴，但又有一個問題遥金，用戶假如第一次進來就點擊購買，此時還未下單成功蒜田，則還會出現(xiàn)下單失敗的問題稿械，故而，詳情見下篇解決辦法物邑。
2.雙重認證時溜哮，客戶端發(fā)蘋果服務端時返回為0說明是正常支付成功信息，但是返回21002色解，也要注意是支付成功的信息茂嗓，只是因為本次支付成功距離上次太近了，有刷單嫌疑而已科阎，故而需要把這種情況考慮進去述吸，都發(fā)給后臺，其他則按照蘋果后臺返回的碼作相關邏輯即可锣笨。
詳見以下鏈接蝌矛，直接拉到最后即可。
3.支付成功后错英，用戶有時還未來得及驗證是否成功入撒，此時網(wǎng)絡失敗該如何！
這個問題椭岩，下面2.4已經(jīng)描述了對應的解決辦法茅逮。
4.下單，支付等用delegate（block）回調(diào)好還是用通知好些
個人傾向于通知判哥，原因有二：
其一献雅，支付成功后，要更改的地方可能不止該界面塌计，有更多頁面涉及挺身，一對多當然用通知；
其二锌仅，解決2.3的問題章钾，在遇到支付問題時，下次啟動的時候只要設置Appdelegate為觀察者热芹，可以在任意頁面把比方進入的首頁或者登陸頁繼續(xù)驗證支付雙重認證問題伍玖，直到有結果，避免漏單剿吻，錯單問題窍箍。
本篇啰里啰嗦，好像沒說到什么重點，原諒好久沒寫技術文章了椰棘，適應下纺棺，下篇等待干貨支付流程和Demo吧！
