iOS開發(fā)支付的兩種方式

1 Apple Pay + 調取外部支付，例如支付寶、微信、銀聯(lián)等

什么是Apple Pay？

簡單說是一種“支付工具”。對于國外流行信用卡，Apple Pay很符合美國的國情。但對于中國，微信支付、支付寶支付更加便利符合中國的人的行為習慣。
說到這你可能就理解了，Apple Pay，就是類比支付寶類似的線上線下支付工具。
Apple Pay和 支付寶、微信一樣主要針對現(xiàn)實現(xiàn)金交易。當然也存在平臺支持虛擬產品支付。例如淘寶平臺出售虛擬物品，電話費、游戲卡等等。但這不屬于蘋果內購范疇。

當然對于我們的自己的App,我們可以接入多種支付方式。

2 蘋果內購IAP（In-App Purchase）

什么是內購？

如果你購買的商品，是在本app中使用和消耗的，就一定要用內購，否則會被拒絕上線，例如：游戲幣，在線書籍，app中使用的道具等虛擬產品。如果購買的就是普通的商品，例如淘寶買東西等，就不需要用內購。內購的話，蘋果公司需要抽取30%左右傭金。

蘋果內購價格表中的實際收入是動態(tài)變化的，會根據(jù)稅收變化而發(fā)生改變，一般蘋果會收取30%左右的金額。但是表格里邊的價格和等級一般是不變的。

當然，打賞功能被納入內購項目中。所以例如微信打賞功能、直播項目打賞主播都必須采用內購。

• 可以簡單理解成，帶有內購功能的項目以后的成本會比安卓、PC端高出30%成本。

• 內購使用場景：愛奇藝APP購買會員，QQ斗地主里面的充值QB等。

• 支付彈窗圖標、價格、詳情等都需要到https://developer.apple.com里面去設置。具體下面會講到。

項目積分購買課程需使用內購方式，因此本文將按照政策規(guī)則、代碼集成+丟包處理、稅務填寫銀行賬號信息等方面詳細介紹IAP

1 IAP規(guī)則詳解

• 本文所述IAP（In-App Purchase），特指蘋果App Store的應用內購買，是蘋果為App內購買虛擬商品或服務提供的一套交易系統(tǒng)。
  首先來討論一下IAP的基本規(guī)則以及其中的一些要點：

1.1 適用范圍

• 在App內需要付費使用的產品功能或虛擬商品/服務，如游戲道具、電子書、音樂、視頻、訂閱會員、App的高級功能等。
• App內購買實體商品（如淘寶買衣服）不適用IAP，不在App內使用的虛擬商品（如充話費）或服務（如滴滴叫車）也不適用IAP。
  那么問題來了，假如在App內購買一個音樂專輯，既能在App里面聽數(shù)字專輯，同時也能獲得實體商品cd，適不適用IAP呢？
  答案是適用的。因為App內的數(shù)字專輯和實體商品cd在使用上是可以分離的，數(shù)字專輯符合IAP的適用范圍，購買就要用IAP。否則各種游戲里面賣648的道具，都聲稱商品不僅包含游戲道具，購買后還能獲得一個5毛錢的實體紀念品（舉例），就直接繞過IAP，蘋果豈不完蛋？
  蘋果規(guī)定，適用范圍內的虛擬商品或服務，必須使用IAP購買支付，不允許使用支付寶、微信支付等其它支付方式（包括Apple Pay），也不允許以任何方式（包括跳出App、提示文案等）引導用戶通過應用外部渠道購買。
• 原則上蘋果也不允許通過外部兌換碼等方式在應用內解鎖虛擬商品或服務，但實際上兌換碼的限制是有些模糊的，因為有些App可以在應用內獲得兌換碼（比如活動發(fā)放優(yōu)惠券或簽到獎勵），很難嚴格界定是一個外部兌換碼還是內容兌換碼。因此，在IAP購買中使用優(yōu)惠券抵扣一般情況下是允許的，但如果很明顯地引導用戶在App外購買兌換碼，再在App內兌換成虛擬商品或服務，是會被蘋果Reject的。
• 另外在App Store Review Guidelines 3.1.4 里面還有這樣一條特殊規(guī)則：

“App features that work in combination with an approved physical product (such as a toy) on an optional basis may unlock functionality without using IAP, provided that an IAP option is available as well.”

• 意思就是說，用戶在App內購買一個功能，而這個功能需要和一個實體商品結合起來使用，這種情況下，允許使用IAP之外的方式來解鎖功能，但前提是仍然需要提供IAP購買的選項。
• 比如用戶在一個健康管理App內購買一個高級計步器功能，但這個計步器功能需要跟手環(huán)配合使用，要和手環(huán)打包購買。這個情況下，App可以在IAP購買的選項基礎上，再提供其它的購買方式。
• 但現(xiàn)實中好像并見過沒有這樣的案例。因為App完全可以把計步器變成免費功能，只是沒有手環(huán)不起實際作用，然后把手環(huán)當成是一個在App外使用的實體商品，這樣跟IAP就沒有半毛錢關系了。誰沒事找事還把這個東西做成IAP還要給蘋果分成啊~
• 另外還有一些跨平臺同步的復雜案例，在本文的第三部分再進一步介紹。

1.2 IAP類型

• 如前面說的，IAP是一套商品交易系統(tǒng)，而非簡單的支付系統(tǒng)。每一個購買項目都需要在App的itunes connect后臺創(chuàng)建一個商品，提交給蘋果審核，審核通過后，購買項目才會生效。
• 在創(chuàng)建IAP商品時，主要有4種類型可供選擇：

1.2.1 Consumable products （消耗型商品）

• 該類型適用于可多次購買的消耗型項目，如游戲道具、虛擬幣等。

1.2.2 Non-consumable products（非消耗型商品）

• 該類型適用于一次購買永久有效的項目，如電子書、游戲關卡等。
• 該類型項目支持跨設備同步和本地restore，比如說，用戶在某個App中購買了一本書，可在所有相同Apple ID設備的App中免費獲取這本書，而不要需要借助App本身的帳號體系，即使在App中刪除了這本書，也可免費重新獲取。

1.2.3 Non-renewable subscriptions（非續(xù)期訂閱）

• 該類型適用于固定有效期的非自動續(xù)費項目，如云音樂的會員和一些視頻App的會員。沒有跨設備同步和本地restore機制，用戶可以多次購買。

1.2.4 Auto-renewable subscriptions（自動續(xù)期訂閱）

• 該類型適用于自動續(xù)費的訂閱項目，如Apple Music的按月訂閱，用戶購買后會每月自動續(xù)費，直到用戶手動取消或者開發(fā)者下架IAP項目。
• 類似Non-consumable products，該類型也支持跨設備同步和本地restore機制。
• 之前這種類型只支持newsstand類別（報刊雜志）的App，從2016年6月開始支持所有類型的App，但除了newsstand類別之外，國內的App很少使用這種類型的內購。

1.2.4.1 Free subscriptions（免費訂閱）

• 該類型是Auto-renewable subscriptions的一個特例，適用于免費的訂閱項目，僅支持newsstand類別的App，同樣支持跨設備同步和本地restore機制。
  《In-App Purchase Programming Guide》詳細說明了各種類型的適用范圍和特性。

其中需要特別注意的是：

• 1 針對Non-consumable products類型的IAP項目，蘋果會要求App提供一個“恢復購買”的功能，以支持跨設備同步和本地restore。同時，如果App本身有用戶帳號系統(tǒng)，那么用戶只要付費一次，就可以通過restore機制將IAP項目無限復制到多個用戶帳號下。
  因此，對于類似電子書之類的一次購買永久有效的項目，如果希望使用App本身的用戶帳號系統(tǒng)，避開跨設備同步和本地restore機制，可以考慮選擇Non-renewable subscriptions類型。同時，考慮到Non-renewable subscriptions一般是有固定有效期的，可以加一個無限長的有效期（比如9999天），以應對蘋果審核。
• 2 Consumable products和Non-renewable subscriptions都是可以重復購買的IAP項目，前者更偏向消耗品，后者更偏向訂閱品。另外還有一個區(qū)別是，針對Non-renewable subscriptions的IAP項目，用戶如果之前已經買過一次，過期后再次購買或者切換App帳號后購買，支付流程中會出現(xiàn)一個系統(tǒng)彈窗提示用戶之前已經購買過該項目，是否要再次購買，如果用戶不小心點了取消，支付流程就會終止。
  蘋果設計這個彈窗的本意更多是根據(jù)Apple ID識別用戶身份，避免用戶重復購買相同項目。但對于有用戶帳號體系的App，這個提示是有點多余的，雖然影響不大。因此，如果一個IAP項目既適用于Consumable products也適用于Non-renewable subscriptions，比較建議選擇Consumable products。

1.3 定價

• 在創(chuàng)建IAP項目的時候，需要設定價格，這個價格只能從蘋果預設的價格等級中選擇，比如等級1對應1美元、6元人民幣，等級2對應2美元、12元人民幣……最高等級87對應999.99美元、6498元人民幣。另外可能是為了照顧某些貨幣區(qū)的開發(fā)者和用戶，還有一些特殊的等級，比如備用等級A對應1美元、1元人民幣，備用等級B對應1美元、3元人民幣這樣。除此之外，IAP項目不能定一個9.9元人民幣這樣不符合任何等級的價格。詳細價格等級表可以看蘋果的官方文檔

• 蘋果的價格等級表通常是不會調整的，但也不排除在某些貨幣匯率發(fā)生巨大變化的情況下，對該貨幣的定價進行調整，調整前蘋果會發(fā)郵件通知開發(fā)者。

• 另外，價格等級表中不同貨幣的匯率關系與實際匯率存在差異，淘寶上有部分低價的iOS游戲內購代充就是利用了某些貨幣的匯率差來做生意。

• 對于開發(fā)者來說，如果App在中國區(qū)以外發(fā)布，可能需要注意一下匯率的問題。某些地區(qū)的內購結算成人民幣后收入會低于相應價格等級的人民幣收入，所以在一些需要嚴格計算實際收入的情況下（比如財務統(tǒng)計營收，或內購收入需要進一步與平臺CP方進行分成），可能需要根據(jù)內購的實際支付貨幣及金額和還有相應匯率來計算收入，或者也可以用一些辦法來限制某些地區(qū)的內購（在本文2.2部分會講）。

• 補充說明一下，IAP項目的價格在商品發(fā)布以后是可以在itunes connect后臺修改的，也可以設置限時優(yōu)惠價。但是大部分聯(lián)網App的內購項目價格是從自己的服務端獲取的，如果要修改價格或設置限時優(yōu)惠，需要兩邊一起處理，還是挺麻煩的。

1.4 分成

• 很多人都知道，App Store上的付費App和App內購，蘋果與開發(fā)者默認是3/7分成。
• 但實際上，在某些地區(qū)蘋果與開發(fā)者分成之前需要先扣除交易稅，開發(fā)者的實際分成不一定是70%。從2015年10月開始，蘋果對中國地區(qū)的App Store購買扣除了2%的交易稅，對于中國區(qū)帳號購買的IAP，開發(fā)者的實際分成在68%~69%之間。而且中國以外不同地區(qū)的交易稅標準也存在差異，如1.3中所述，如果需要嚴格計算實際收入，可能需要把這個部分也考慮進來。
• 針對不同地區(qū)的內購，內購價格和對應的開發(fā)者實際收入在蘋果的價格等級表（1.3中的鏈接）中有詳細列舉。
• 另外，根據(jù)蘋果在2016年6月的新規(guī)則，針對Auto-Renewable Subscription類型的IAP，如果用戶購買的訂閱時間超過1年，那么從第二年開始，開發(fā)者可以獲得85%的分成。詳情可查看：
  https://developer.apple.com/app-store/subscriptions/

1.5 結算

• 針對IAP的交易收入，蘋果一般以5周(每年1/4/7/10月)或4周(其余月份)作為一個結算周期，并在每個結算周期結束后第33天向開發(fā)者付賬。

2 IAP設計開發(fā)要點

2.1 創(chuàng)建和提交IAP項目

• 開發(fā)IAP之前需要先在itunes connect后臺創(chuàng)建IAP商品，并按規(guī)范填寫product id、商品名稱、價格、截圖等信息。
• 如果App當前版本支持新增的IAP項目，可不用發(fā)版直接提交IAP審核。如果需要App新功能配合，則需要和App版本一起提交。
  《In-App Purchase Configuration Guide for iTunes Connect》詳細介紹了IAP的創(chuàng)建和提交流程：

其中需要特別注意的是：

2.1.1 盡量不要刪除已創(chuàng)建的IAP

• 已創(chuàng)建的IAP除了product id之外的所有信息都可以修改，如果刪除了一個IAP，將無法再創(chuàng)建一個相同product id的IAP，也意味著該product id永久失效。而product id一般有特定的命名規(guī)則，用來標示App內的購買項目，如果命名規(guī)則下有某個product id永久失效，可能會導致整個product id命名規(guī)則都要修改，掉進坑里~

2.1.2 注意區(qū)分reference name和display name

• reference name是給開發(fā)者自己看的，display name會在IAP支付流程的確認購買系統(tǒng)彈窗中展示給用戶，而且不能隨意修改（修改需要重新提交IAP審核），所以命名的時候要弄清楚。

2.1.3 當App審核被拒時

• 如果IAP隨App版本一起提交審核，有問題時所有新提交的IAP項目和App版本會同時被拒，再次提交App審核時，一定要記得重新提交所有IAP項目（每個IAP還得要手動編輯一下才能重新提交真麻煩），否則蘋果是無法繼續(xù)審核的。

2.2 IAP支付流程

• 這部分內容屬于功能實現(xiàn)的邏輯，同樣在《In-App Purchase Programming Guide》中有詳細說明：

• 具體來說，IAP的支付模式分為 客戶端校驗 和 服務端校驗 2種模式，客戶端校驗模式因為容易偽造支付憑據(jù)，安全性比較低，一般只有非常簡單的單機App才會使用，大部分App都會采用 服務端校驗 模式。

另外不同類型的IAP支付流程也會有一些小差異（主要是restore機制），下面就以最常用的Consumable products和Non-renewable subscriptions類型為例，來說明一下IAP的支付流程：

步驟說明：

1. 程序向服務器發(fā)送請求，獲得一份產品列表。
2. 服務器返回包含產品標識符的列表。
3. 程序向App Store發(fā)送請求，得到產品的信息。
4. App Store返回產品信息。
5. 程序把返回的產品信息顯示給用戶（App的store界面）
6. 用戶選擇某個產品
7. 程序向App Store發(fā)送支付請求
8. App Store處理支付請求并返回交易完成信息。
9. 程序從信息中獲得數(shù)據(jù)，并發(fā)送至服務器。
10. 服務器紀錄數(shù)據(jù)，并進行審(我們的)查。
11. 服務器將數(shù)據(jù)發(fā)給App Store來驗證該交易的有效性。
12. App Store對收到的數(shù)據(jù)進行解析，返回該數(shù)據(jù)和說明其是否有效的標識。
13. 服務器讀取返回的數(shù)據(jù)，確定用戶購買的內容。
14. 服務器將購買的內容傳遞給程序。

以上簡要步驟總結：

• 用戶進入購買虛擬物品頁面，App從后臺服務器獲取產品列表然后顯示給用戶
• 用戶點擊購買購買某一個虛擬物品，APP就發(fā)送該虛擬物品的productionIdentifier到Apple服務器
• Apple服務器根據(jù)APP發(fā)送過來的productionIdentifier返回相應的物品的信息（描述，價格等）
• 用戶點擊確認鍵購買該物品，購買請求發(fā)送到Apple服務器
• Apple服務器完成購買后，返回用戶一個完成購買的憑證
• APP發(fā)送這個憑證到后臺服務器驗證
• 后臺服務器把這個憑證發(fā)送到Apple驗證，Apple返回一個字段給后臺服務器表明該憑證是否有效
• 后臺服務器把驗證結果在發(fā)送到APP，APP根據(jù)驗證結果做相應的處理

2.3 不能忽視的坑

2.3.1 延遲返回支付結果

• 在上述流程的步驟6，由于網絡問題等種種原因，即使用戶已經付款成功，客戶端也可能一時半會收不到蘋果API的支付成功通知，也無法主動向蘋果API請求查詢支付狀態(tài)，只能被動等待通知。
• 因此有些情況下，客戶端會延遲收到支付成功的通知（可能是過了幾分鐘，也有可能是下次打開App的時候），針對這種情況，需要做好兩件事：
• 1 客戶端本地保存所有支付結果未確認的交易信息，并設置一個監(jiān)聽進程，在收到支付成功的信息后，繼續(xù)處理這筆交易的后續(xù)流程。極端情況下，用戶在交易結果未確認的情況下刪除App，保存在App本地數(shù)據(jù)庫中的交易信息也會丟失，因此，更好的方案是 把交易信息存到iOS系統(tǒng)的keychain里面
• 2 當本地存在支付結果未確認的交易信息時，在交互上提示用戶可能需要等待支付結果，避免用戶重復付款

2.3.2 服務端校驗延遲

在上述流程6~8的支付憑據(jù)校驗過程中，因為網絡問題等各種原因，客戶端可能無法及時收到服務端的校驗成功通知，類似的，這種情況需要：

• 1 客戶端本地保存支付憑據(jù)，并持續(xù)向服務端輪詢校驗結果，直到返回明確的校驗成功或校驗無效的結果。支付憑據(jù)最好也保存在 keychain 里面
• 2 在客戶端向服務端輪詢結果時，為了避免用戶在支付結果頁面等待過久，交互層面上可以先結束支付流程（經過一定時間超時），同時提示用戶需要等待支付結果，避免用戶重復付款

2.3.3 非官方渠道包支付失敗問題

• 在上述流程步驟1中，如果用戶安裝的App不是App Store官方渠道包（從PP助手、同步推等第三方應用商店下載），蘋果API會直接返回product id不存在并結束支付流程，在交互層面上表現(xiàn)為用戶點擊購買后直接提示支付失敗。

• 類似的，越獄設備在安裝某些內購破解插件后，也會導致無法進行內購（返回product id不存在）。不過現(xiàn)在iOS設備的越獄比例已經非常低了，基本可以忽略。

• 因此，針對這個問題的解決辦法是：當返回product id不存在時，提示用戶安裝的可能是非官方渠道包，引導用戶到App Store下載官方渠道包。

2.3.4 貨幣校驗

• 如本文1.3部分所述，如果App在中國區(qū)以外發(fā)布，但由于某些原因又希望限制某些地區(qū)帳號的內購，可以在上述流程的步驟4校驗用戶支付的貨幣單位，并禁止某些貨幣的購買。同時在交互上也要給用戶相應的提示，類似不支持特殊地區(qū)帳號購買的彈窗說明。

2.3.5 未綁定App Store支付方式的用戶支付流程

這是一個巨大的坑！

• 如果用戶在內購前未綁定App Store的支付方式，在上述流程的步驟5，點擊系統(tǒng)彈窗(第1次)的確認購買后，會自動跳轉到App Store的綁定支付方式界面。接著如果順利完成支付方式的綁定，會再自動跳轉跳回App，再次出現(xiàn)系統(tǒng)彈窗(第2次)讓用戶確認購買。
• 但是，當用戶點擊系統(tǒng)彈窗(第1次)的確認購買后，蘋果API會立即向客戶端返回支付失敗…支付失敗…失敗…一般情況下，客戶端收到支付失敗的返回，理所應當認為支付已經取消了，而丟棄本地的交易信息。但萬萬沒想到后面用戶綁定支付方式完成后會繼續(xù)確認購買，這簡直就是蘋果IAP系統(tǒng)設計的一個大bug！
• 如果知道了這個坑，解決方案也很簡單，就是在蘋果API返回支付失敗時，用類似2.3.1的方式處理，保留待確認的交易信息并持續(xù)監(jiān)聽支付結果返回。

3 更多IAP實踐經驗總結

3.1 匿名購買

• 很多App在第一次提交IAP時都會因為不支持匿名購買被拒，原因是App Store Review Guidelines要求App在非必要的情況下，不允許強制用戶注冊/登錄后才能使用某些功能。
• 一般情況下，對于沒有IAP的App，強制用戶注冊/登錄才能使用是不會被拒的（除非遇到很苛刻的審核人員），但是對于IAP，一般都會要求支持匿名購買。當然你也可以嘗試編一堆原因說明為什么強制用戶注冊/登錄是必要的（比如提供的商品或服務需要獲取用戶手機號或郵箱之類的理由），但也不能保證說服審核人員。
• 支持匿名購買，通常需要在用戶未登錄App帳號的情況下，臨時保存用戶的購買記錄，并在用戶登錄后合并到App帳號數(shù)據(jù)。

3.2 跨平臺同步

雖然在原則上，蘋果不允許通過外部渠道解鎖App內需要付費才能使用的功能或虛擬商品，比如在web端購買一個課程，在App內觀看，但實際在某些條件下是可以做跨平臺同步用戶購買的內容：

• 1 在iOS App內也提供相應商品IAP購買的前提下，通過App帳號同步用戶在不同平臺上購買的內容。這條規(guī)則適用到大部分游戲上可能會比較苛刻，但是一般的內容類App都是行的通的。
• 2 針對電子書、音樂、視頻等項目，App只提供單純的內容閱讀/觀看功能，而不提供任何發(fā)現(xiàn)和訂閱內容的功能（比如Kindle iOS版），可支持用戶在外部渠道購買內容后在App中使用（具體可參考App Store Review Guidelines 3.1.3）。但實際上是否允許可能也要取決于審核人員的判斷，比如云課堂曾經提交過一個版本，不能購買付費課程，但是允許用戶在web端購買付費課程后在iOS端觀看，就被拒了，理由是付費課程不屬于上述條件的內容范疇。

3.3 虛擬幣

• 由于IAP的價格等級機制，無法支持靈活的商品定價（如9.9元人民幣）和營銷功能（如優(yōu)惠券抵扣等），很多App會引入虛擬幣，先通過IAP內購充值特定價格的虛擬幣（如6、12、18、648等），再使用虛擬幣購買具體的商品。
• 類似IAP跨平臺同步問題，iOS平臺充值的虛擬幣不允許和其他平臺（Android、web）流通，外部平臺充值的虛擬幣不能在iOS平臺使用，同時iOS平臺充值的虛擬幣也不能在外部平臺使用。
• 但實際中，我們會發(fā)現(xiàn)有些App，比如喜馬拉雅和得到，支持用戶在微信公眾號中充值虛擬幣（雖然微信充值也區(qū)分了iOS平臺和其他平臺），再在App內使用，并且在App內的充值界面，隱晦的提示用戶如果充值遇到問題，可以關注微信公眾號獲取客服幫助（實際上就是引導用戶用微信充值）。這種做法嚴格意義上是不合規(guī)的，但如果蘋果審核不嚴也能通過，算是打擦邊球，估計這招效果還不錯~

3.4 退款問題

• 根據(jù)蘋果政策，用戶在購買IAP后90天內，能以各種原因申請退款（扣款后購買失敗、買錯了、不喜歡等等），但實際能不能退成功蘋果說了算。
• 如果一個用戶申請退款成功，蘋果會在與開發(fā)者結算時記一筆退款訂單（當然原來購買成功的訂單也在），錢就不給了，而且蘋果也不會告訴你是哪個用戶退款的，而且用戶購買的東西還在，簡直就是霸王條件~
• 訂單數(shù)據(jù)可以在itunes connect后臺的“付款和財務報告”中查看，但沒有詳細時間信息和用戶信息，很難定位到相應的平臺訂單。
• 對于游戲或者一些自營平臺來說，可能就是少點收入。而對于需要與平臺CP方一一分成的產品來說，可能就要虧錢。為了解決這個問題，可設計一套退款訂單分配規(guī)則，根據(jù)IAP訂單的時間周期、金額，結合平臺訂單的一些信息，將IAP退款訂單分配到平臺訂單，由平臺和CP方共同承擔退款。
• 從歷史數(shù)據(jù)來看，一般不遇到大量惡意退款的情況下，IAP的退款率可能在1~3%之間（取決于App內容質量、用戶心情，還有蘋果的心情）。對于IAP營收額很大的App，可能需要考慮一下退款的問題。

3.5 支付成功率

• 云課堂曾經對比過iPhone端使用支付寶/微信支付（注意：繞過IAP使用第三方支付屬于違規(guī)行為，可能導致應用下架或開發(fā)者被封號，切勿模仿！）和IAP的支付數(shù)據(jù)，發(fā)現(xiàn)第三方支付的用戶支付成功率大概是IAP的2~3倍，反映在營收上也差了2倍多。
  不難理解，國內App Store的用戶支付習慣肯定不如第三方支付成熟。而經過進一步的用戶問卷調研，發(fā)現(xiàn)影響IAP支付成功率的因素有很多方面：
• 1 用戶安裝的App來自第三方應用商店或使用越獄設備，無法使用IAP支付（約5%用戶）
• 2 用戶未綁定App Store支付方式（約75%用戶，數(shù)據(jù)很驚人）
• 3 用戶在IAP支付過程綁定支付方式遇到問題，放棄了（約50%用戶）
• 以上數(shù)據(jù)僅代表云課堂iPhone端的用戶群，某種意義上也說明云課堂的用戶比較小白（產品本身的目標用戶很大一部分就是小白），沒接觸過IAP這種支付方式。不同產品的目標用戶群的App Store內購使用習慣肯定也存在差異。
• 不過，隨著App Store內購的普及（一方面是游戲內購帶動，另一方面也得益于蘋果的推廣，比如經常搞一些App一元購活動，還有從2016年11月開始支持綁定支付寶），用戶的內購習慣也在持續(xù)養(yǎng)成，從數(shù)據(jù)上也能看出IAP支付成功率的上升趨勢，對于接入IAP的產品是友好的。

3.6 作弊行為

考慮到IAP的分成、退款以及支付成功率等一系列問題，雖然我們有很多種辦法可以偷偷繞過IAP使用第三方支付，比如：

• 1 通過后臺開關控制在某些時間開啟第三方支付
• 2 根據(jù)用戶信息和行為識別出明顯不是蘋果審核人員的用戶（特別是其中一些高客單價用戶），開放第三方支付
  等等……
  但是根據(jù)公司企業(yè)發(fā)展部、市場部、法務部的要求，切勿在IAP的問題上搞事情！好好遵守蘋果規(guī)則，做好產品，爭取App Store推薦。

4 代碼集成

內購所需要寫的代碼是非常少的，只有幾百行。

4.1 引入頭文件

import StoreKit

4.2 遵循兩個代理

SKProductsRequestDelegate, SKPaymentTransactionObserver

4.3 開啟內購檢測

func add(_ observer: SKPaymentTransactionObserver)

let paymentQueue: PaymentQueue = SKPaymentQueue.default()
paymentQueue.add(self)

4.4 設置內購點擊事件

private func purchase(
    product: SKProduct, 
    quantity: Int,
    atomically: Bool,      
    applicationUsername: String = "", 
    completion: @escaping (PurchaseResult) -> Void
) {
    guard SwiftyStoreKit.canMakePayments else {
        let error = NSError(
          domain: SKErrorDomain, 
          code: SKError.paymentNotAllowed.rawValue,
          userInfo: nil
        )
        completion(.error(error: SKError(_nsError: error)))
        return
    }

    paymentQueueController.startPayment(
      Payment(
        product: product, 
        quantity: quantity, 
        atomically: atomically, 
        applicationUsername: applicationUsername
      ) { result in
        completion(self.processPurchaseResult(result))
    })
}

4.5 請求商品，獲取商品信息，以及代理

private let request: SKProductsRequest
deinit {
    request.delegate = nil
}
private init(
  productIds: Set<String>,
  callback: @escaping RequestCallback
) {
    self.callback = callback
    request = SKProductsRequest(productIdentifiers: productIds)
    super.init()
    request.delegate = self
}

class func startQuery(
  _ productIds: Set<String>, 
  callback: @escaping RequestCallback
) -> InAppProductQueryRequest {
    let request = InAppProductQueryRequest(productIds: productIds, callback: callback)
    request.start()
    return request
}

func start() {
    request.start()
}
func cancel() {
    request.cancel()
}

// MARK: SKProductsRequestDelegate
func productsRequest(
  _ request: SKProductsRequest,
  didReceive response: SKProductsResponse
) {
    let retrievedProducts = Set<SKProduct>(response.products)
    let invalidProductIDs = Set<String>(response.invalidProductIdentifiers)
    performCallback(RetrieveResults(retrievedProducts: retrievedProducts,
        invalidProductIDs: invalidProductIDs, error: nil))
}

func requestDidFinish(_ request: SKRequest) {

}

func request(
  _ request: SKRequest, 
  didFailWithError error: Error
) {
    performCallback(
      RetrieveResults(
        retrievedProducts: Set<SKProduct>(), 
        invalidProductIDs: Set<String>(), 
        error: error
      )
    )
}

private func performCallback(_ results: RetrieveResults) {
    DispatchQueue.main.async {
        self.callback(results)
    }
}

4.6 沙盒測試環(huán)境驗證以及正式環(huán)境

public enum VerifyReceiptURLType: String {
    // 正式環(huán)境驗證
		case production = "https://buy.itunes.apple.com/verifyReceipt"
    // 沙盒測試環(huán)境驗證
		case sandbox = "https://sandbox.itunes.apple.com/verifyReceipt"
}

public init(service: VerifyReceiptURLType = .production) {
    self.service = service
}

private let service: VerifyReceiptURLType

public func validate(
  receipt: String,
  password autoRenewPassword: String? = nil,
  completion: @escaping (VerifyReceiptResult) -> Void) {

  let storeURL = URL(string: service.rawValue)! // safe (until no more)
  let storeRequest = NSMutableURLRequest(url: storeURL)
  storeRequest.httpMethod = "POST"

  let requestContents: NSMutableDictionary = [ "receipt-data": receipt ]
  // password if defined
      if let password = autoRenewPassword, !password.isEmpty {
    requestContents.setValue(password, forKey: "password")
  }

  // Encore request body
  do {
    storeRequest.httpBody = try JSONSerialization.data(withJSONObject: requestContents, options: JSONSerialization.WritingOptions.prettyPrinted)
  } catch let e {
    completion(.error(error: .requestBodyEncodeError(error: e)))
    return
  }

  // Remote task
  let task = URLSession.shared.dataTask(with: storeRequest as URLRequest) { data, _, error -> Void in

    // there is an error
    if let networkError = error {
      completion(.error(error: .networkError(error: networkError)))
      return
    }

    // there is no data
    guard let safeData = data else {
      completion(.error(error: .noRemoteData))
      return
    }

    // cannot decode data
    guard let receiptInfo = try? JSONSerialization.jsonObject(with: data!, options: .mutableLeaves) as? ReceiptInfo ?? [:] else {
      let jsonStr = String(data: safeData, encoding: String.Encoding.utf8)
      completion(.error(error: .jsonDecodeError(string: jsonStr)))
      return
    }

    // get status from info
    if let status = receiptInfo["status"] as? Int {
      let receiptStatus = ReceiptStatus(rawValue: status) ?? ReceiptStatus.unknown
      if case .testReceipt = receiptStatus {
        let sandboxValidator = AppleReceiptValidator(service: .sandbox)
        sandboxValidator.validate(receipt: receipt, password: autoRenewPassword, completion: completion)
      } else {
        if receiptStatus.isValid {
          completion(.success(receipt: receiptInfo))
        } else {
          completion(.error(error: .receiptInvalid(receipt: receiptInfo, status: receiptStatus)))
        }
      }
    } else {
      completion(.error(error: .receiptInvalid(receipt: receiptInfo, status: ReceiptStatus.none)))
    }
  }
  task.resume()
}

5 IAP QA測試幫助

IAP沙盒測試賬號使用

6 App Store協(xié)議、稅務和銀行業(yè)務

6.1 登錄iTunes Connect

1. 登錄iTunes Connect

2. 進入協(xié)議、稅務和銀行業(yè)務頁面

   

6.2 選擇申請合同類型

進入協(xié)議、稅務和銀行業(yè)務頁面后，會有3種合同類型，如果你之前沒有主動申請過去合同，那么一般你現(xiàn)在激活的合同只有iOS Free Application一種。

頁面內容分為兩塊：

• Request Contracts(申請合同)
• Contracts In Effect(已生效合同)。

合同類型分為3種：

• iOS Free Application(免費應用合同)
• iOS Paid Application(付費應用合同)
• iAd App NetNetwork(廣告合同)

6.3 申請iOS Paid Application合同

• 當我們點擊申請iOS Paid Application合同后，該合同的狀態(tài)會變成如下的樣子，我們可以看到其中Status為Pending Tax, Bank, Contact。意思是聯(lián)系方式、銀行和稅務信息沒有填寫。
  

6.4 添加銀行賬戶

• 填寫銀行CNAPS Code(ABA匯款路線號碼)

6.5 報稅（跟咱沒啥關系，但還是要填）

默認美國打勾，其他有的話打勾，一般都沒

選擇美國U.S Tax Forms，選擇后會問你兩個問題

• 第一個問題如下：詢問你是否是美國居民，有沒有美國伙伴關系或者美國公司，如果沒有直接選擇No。

• 第二個問題如下：詢問你有沒有在美國的商業(yè)性活動，沒有也直接選No。

6.5.1 填寫稅務信息

包括以下幾點：

• Individual or Organization Name：個人或者組織名稱
• Country of incorporation： 所在國家
• Type of Beneficial Owner：受益方式，獨立開發(fā)者選個人
• Permanent Residence：居住地址
• Mailing address：郵寄地址
• Name of Person Making this Declaration：聲明人
• Title：頭銜

填寫完這些信息后就可以提交了

6.5.2 填寫聯(lián)系信息，如果是個人開發(fā)者就全寫自己

6.6 等待審核

當你填寫完所有資料后，合同狀態(tài)就會變成Processing，大約半天就通過了。

文章來源地址http://www.zghlxwxcb.cn/news/detail-407859.html

到了這里，關于iOS_蘋果內購詳細步驟的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！