柚子快報邀請碼778899分享：iOS

http://yzkb.51969.com/

iOS蘋果內(nèi)購詳細步驟

iOS開發(fā)支付的兩種方式1 Apple Pay + 調(diào)取外部支付，例如支付寶、微信、銀聯(lián)等2 蘋果內(nèi)購IAP（In-App Purchase）

1 IAP規(guī)則詳解1.1 適用范圍1.2 IAP類型1.2.1 Consumable products （消耗型商品）1.2.2 Non-consumable products（非消耗型商品）1.2.3 Non-renewable subscriptions（非續(xù)期訂閱）1.2.4 Auto-renewable subscriptions（自動續(xù)期訂閱）1.2.4.1 Free subscriptions（免費訂閱）

1.3 定價1.4 分成1.5 結(jié)算

2 IAP設(shè)計開發(fā)要點2.1 創(chuàng)建和提交IAP項目2.1.1 盡量不要刪除已創(chuàng)建的IAP2.1.2 注意區(qū)分reference name和display name2.1.3 當App審核被拒時

2.2 IAP支付流程2.3 不能忽視的坑2.3.1 延遲返回支付結(jié)果2.3.2 服務(wù)端校驗延遲2.3.3 非官方渠道包支付失敗問題2.3.4 貨幣校驗2.3.5 未綁定App Store支付方式的用戶支付流程

3 更多IAP實踐經(jīng)驗總結(jié)3.1 匿名購買3.2 跨平臺同步3.3 虛擬幣3.4 退款問題3.5 支付成功率3.6 作弊行為

4 代碼集成4.1 引入頭文件4.2 遵循兩個代理4.3 開啟內(nèi)購檢測4.4 設(shè)置內(nèi)購點擊事件4.5 請求商品，獲取商品信息，以及代理4.6 沙盒測試環(huán)境驗證以及正式環(huán)境

5 IAP QA測試幫助6 App Store協(xié)議、稅務(wù)和銀行業(yè)務(wù)6.1 登錄iTunes Connect6.2 選擇申請合同類型6.3 申請iOS Paid Application合同6.4 添加銀行賬戶6.5 報稅（跟咱沒啥關(guān)系，但還是要填）6.5.1 填寫稅務(wù)信息6.5.2 填寫聯(lián)系信息，如果是個人開發(fā)者就全寫自己

6.6 等待審核

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

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

什么是Apple Pay？

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

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

2 蘋果內(nèi)購IAP（In-App Purchase）

什么是內(nèi)購？

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

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

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

可以簡單理解成，帶有內(nèi)購功能的項目以后的成本會比安卓、PC端高出30%成本。 內(nèi)購使用場景：愛奇藝APP購買會員，QQ斗地主里面的充值QB等。 支付彈窗圖標、價格、詳情等都需要到https://developer.apple.com里面去設(shè)置。具體下面會講到。

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

1 IAP規(guī)則詳解

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

1.1 適用范圍

在App內(nèi)需要付費使用的產(chǎn)品功能或虛擬商品/服務(wù)，如游戲道具、電子書、音樂、視頻、訂閱會員、App的高級功能等。App內(nèi)購買實體商品（如淘寶買衣服）不適用IAP，不在App內(nèi)使用的虛擬商品（如充話費）或服務(wù)（如滴滴叫車）也不適用IAP。 那么問題來了，假如在App內(nèi)購買一個音樂專輯，既能在App里面聽數(shù)字專輯，同時也能獲得實體商品cd，適不適用IAP呢？ 答案是適用的。因為App內(nèi)的數(shù)字專輯和實體商品cd在使用上是可以分離的，數(shù)字專輯符合IAP的適用范圍，購買就要用IAP。否則各種游戲里面賣648的道具，都聲稱商品不僅包含游戲道具，購買后還能獲得一個5毛錢的實體紀念品（舉例），就直接繞過IAP，蘋果豈不完蛋？ 蘋果規(guī)定，適用范圍內(nèi)的虛擬商品或服務(wù)，必須使用IAP購買支付，不允許使用支付寶、微信支付等其它支付方式（包括Apple Pay），也不允許以任何方式（包括跳出App、提示文案等）引導(dǎo)用戶通過應(yīng)用外部渠道購買。原則上蘋果也不允許通過外部兌換碼等方式在應(yīng)用內(nèi)解鎖虛擬商品或服務(wù)，但實際上兌換碼的限制是有些模糊的，因為有些App可以在應(yīng)用內(nèi)獲得兌換碼（比如活動發(fā)放優(yōu)惠券或簽到獎勵），很難嚴格界定是一個外部兌換碼還是內(nèi)容兌換碼。因此，在IAP購買中使用優(yōu)惠券抵扣一般情況下是允許的，但如果很明顯地引導(dǎo)用戶在App外購買兌換碼，再在App內(nèi)兌換成虛擬商品或服務(wù)，是會被蘋果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內(nèi)購買一個功能，而這個功能需要和一個實體商品結(jié)合起來使用，這種情況下，允許使用IAP之外的方式來解鎖功能，但前提是仍然需要提供IAP購買的選項。比如用戶在一個健康管理App內(nèi)購買一個高級計步器功能，但這個計步器功能需要跟手環(huán)配合使用，要和手環(huán)打包購買。這個情況下，App可以在IAP購買的選項基礎(chǔ)上，再提供其它的購買方式。但現(xiàn)實中好像并見過沒有這樣的案例。因為App完全可以把計步器變成免費功能，只是沒有手環(huán)不起實際作用，然后把手環(huán)當成是一個在App外使用的實體商品，這樣跟IAP就沒有半毛錢關(guān)系了。誰沒事找事還把這個東西做成IAP還要給蘋果分成啊~另外還有一些跨平臺同步的復(fù)雜案例，在本文的第三部分再進一步介紹。

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（非消耗型商品）

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

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

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

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

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

1.2.4.1 Free subscriptions（免費訂閱）

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

其中需要特別注意的是：

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

1.3 定價

在創(chuàng)建IAP項目的時候，需要設(shè)定價格，這個價格只能從蘋果預(yù)設(shè)的價格等級中選擇，比如等級1對應(yīng)1美元、6元人民幣，等級2對應(yīng)2美元、12元人民幣……最高等級87對應(yīng)999.99美元、6498元人民幣。另外可能是為了照顧某些貨幣區(qū)的開發(fā)者和用戶，還有一些特殊的等級，比如備用等級A對應(yīng)1美元、1元人民幣，備用等級B對應(yīng)1美元、3元人民幣這樣。除此之外，IAP項目不能定一個9.9元人民幣這樣不符合任何等級的價格。詳細價格等級表可以看蘋果的官方文檔 蘋果的價格等級表通常是不會調(diào)整的，但也不排除在某些貨幣匯率發(fā)生巨大變化的情況下，對該貨幣的定價進行調(diào)整，調(diào)整前蘋果會發(fā)郵件通知開發(fā)者。 另外，價格等級表中不同貨幣的匯率關(guān)系與實際匯率存在差異，淘寶上有部分低價的iOS游戲內(nèi)購代充就是利用了某些貨幣的匯率差來做生意。 對于開發(fā)者來說，如果App在中國區(qū)以外發(fā)布，可能需要注意一下匯率的問題。某些地區(qū)的內(nèi)購結(jié)算成人民幣后收入會低于相應(yīng)價格等級的人民幣收入，所以在一些需要嚴格計算實際收入的情況下（比如財務(wù)統(tǒng)計營收，或內(nèi)購收入需要進一步與平臺CP方進行分成），可能需要根據(jù)內(nèi)購的實際支付貨幣及金額和還有相應(yīng)匯率來計算收入，或者也可以用一些辦法來限制某些地區(qū)的內(nèi)購（在本文2.2部分會講）。 補充說明一下，IAP項目的價格在商品發(fā)布以后是可以在itunes connect后臺修改的，也可以設(shè)置限時優(yōu)惠價。但是大部分聯(lián)網(wǎng)App的內(nèi)購項目價格是從自己的服務(wù)端獲取的，如果要修改價格或設(shè)置限時優(yōu)惠，需要兩邊一起處理，還是挺麻煩的。

1.4 分成

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

1.5 結(jié)算

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

2 IAP設(shè)計開發(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內(nèi)的購買項目，如果命名規(guī)則下有某個product id永久失效，可能會導(dǎo)致整個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支付流程

這部分內(nèi)容屬于功能實現(xiàn)的邏輯，同樣在《In-App Purchase Programming Guide》中有詳細說明： 具體來說，IAP的支付模式分為 客戶端校驗 和 服務(wù)端校驗 2種模式，客戶端校驗?zāi)Ｊ揭驗槿菀讉卧熘Ц稇{據(jù)，安全性比較低，一般只有非常簡單的單機App才會使用，大部分App都會采用 服務(wù)端校驗 模式。

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

步驟說明：

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

以上簡要步驟總結(jié)：

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

2.3 不能忽視的坑

2.3.1 延遲返回支付結(jié)果

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

2.3.2 服務(wù)端校驗延遲

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

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

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

在上述流程步驟1中，如果用戶安裝的App不是App Store官方渠道包（從PP助手、同步推等第三方應(yīng)用商店下載），蘋果API會直接返回product id不存在并結(jié)束支付流程，在交互層面上表現(xiàn)為用戶點擊購買后直接提示支付失敗。 類似的，越獄設(shè)備在安裝某些內(nèi)購破解插件后，也會導(dǎo)致無法進行內(nèi)購（返回product id不存在）。不過現(xiàn)在iOS設(shè)備的越獄比例已經(jīng)非常低了，基本可以忽略。 因此，針對這個問題的解決辦法是：當返回product id不存在時，提示用戶安裝的可能是非官方渠道包，引導(dǎo)用戶到App Store下載官方渠道包。

2.3.4 貨幣校驗

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

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

這是一個巨大的坑！

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

3 更多IAP實踐經(jīng)驗總結(jié)

3.1 匿名購買

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

3.2 跨平臺同步

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

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

3.3 虛擬幣

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

3.4 退款問題

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

3.5 支付成功率

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

3.6 作弊行為

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

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

4 代碼集成

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

4.1 引入頭文件

import StoreKit

4.2 遵循兩個代理

SKProductsRequestDelegate, SKPaymentTransactionObserver

4.3 開啟內(nèi)購檢測

func add(_ observer: SKPaymentTransactionObserver)

let paymentQueue: PaymentQueue = SKPaymentQueue.default()

paymentQueue.add(self)

4.4 設(shè)置內(nèi)購點擊事件

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,

callback: @escaping RequestCallback

) {

self.callback = callback

request = SKProductsRequest(productIdentifiers: productIds)

super.init()

request.delegate = self

}

class func startQuery(

_ productIds: Set,

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(response.products)

let invalidProductIDs = Set(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(),

invalidProductIDs: Set(),

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é)議、稅務(wù)和銀行業(yè)務(wù)

6.1 登錄iTunes Connect

登錄iTunes Connect 進入?yún)f(xié)議、稅務(wù)和銀行業(yè)務(wù)頁面

6.2 選擇申請合同類型

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

頁面內(nèi)容分為兩塊：

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

合同類型分為3種：

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

6.3 申請iOS Paid Application合同

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

6.4 添加銀行賬戶

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

6.5 報稅（跟咱沒啥關(guān)系，但還是要填）

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

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

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

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

6.5.1 填寫稅務(wù)信息

包括以下幾點：

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，大約半天就通過了。

柚子快報邀請碼778899分享：iOS

http://yzkb.51969.com/

好文閱讀