Q1:內購和Apple Pay的區別?
- A1:內購是內購,Apple Pay是Apple Pay。我不知道有多少人第一次接觸時,會把這倆概念混淆掉,這裏你可以簡單這麼理解,虛擬的物品就是用內購,實際的物品就是用Apple Pay。Apple Pay是一種支付方式,你可以類比爲支付寶,微信那種。但人家只支持實際物品,如果你東西是虛擬的話,你卻集成Apple Pay上架是要被拒絕的哦~當然反過來,實際物品你卻集成內購上架,也是一樣被拒。對於大部分的國內開發者而言,你很少會遇到需要集成Apple Pay的App的。能用支付寶/微信的場景還要求支持Apple Pay的產品畢竟是少數。
Q2:內購項目的類型區別?
-
A2:首先內購項目分爲以下4種,消耗型項目,非消耗型項目,自動續期訂閱,非續期訂閱。我們來一個個介紹。
消耗型項目:只可使用一次的產品,使用之後即失效,必須再次購買。就是大家最廣爲所知的虛擬幣,比如直播平臺鬥魚的魚翅,熊貓的竹子,嗶哩嗶哩的B幣等,這個概念大家應該很好理解,不過多解釋了。 -
非消耗型項目:只需購買一次,不會過期或隨着使用而減少的產品。這個一般是遊戲那裏用的多,一般是付費解鎖關卡的場景,用戶買過一次,卸載重裝或者同一個Apple id但換App賬號時,也要能保證用戶重新獲得該內購商品。所以App內部需要額外去實現恢復購買的邏輯。
-
自動續期訂閱:允許用戶在固定時間段內購買動態內容的產品。除非用戶選擇取消,否則此類訂閱會自動續期。iTunces上給的示例是:每月訂閱提供流媒體服務的 App。對比我們熟悉的,網易雲音樂的內購商品-連續包月黑膠VIP,就是此類型。一般來說,沒啥必要不要選這一種,如果是VIP的那種場景推薦下面非續期訂閱類型去做。自動續期訂閱的坑非常多,比另外幾種內購類型都要複製。
-
非續期訂閱:一般來說VIP可以用這種方法來做訂閱,我們公司項目的VIP購買就是這種方式。他的實現方式你可以完全照搬消耗性項目,不用做什麼額外處理,也不用去管返回的訂閱日期什麼的東西,就是以服務器那邊爲準。服務器的日期開始,服務器的日期結束。既簡單又保險,不需要額外的做什麼處理。
Q3:VIP一定要用內購做嗎?
- A3:其實判斷你們公司的App到底需不需要用內購,很簡單,就是看跟實際物品有沒有關係。如果你的VIP功能是類似餓了麼這種,點外賣可以打折/多領紅包 那麼就不需要用內購,上架的時候說清楚就行了。如果你的VIP功能是虛擬的,比如頭像更炫酷,尊貴的VIP身份標示,獨特的入場動畫等等虛擬相關的,比如QQ會員,就必須要用內購去做。需要說明的是,那種是VIP才能和某某用戶聊天的場景,是VIP才能得到App裏某某用戶的服務【語音,視頻】時,這一類的場景蘋果一樣認爲是虛擬的,一樣要用內購去做。
Q4:VIP內購一定是非續期/自動續期訂閱嗎?我可不可以用虛擬幣購買VIP呢?
- A4:這個問題我自己經歷過。我的答案是你也可以用虛擬幣購買VIP的這種方式,但如果被拒絕,你只能老老實實的按前種方式去做。如果你們的App既有虛擬幣又有VIP,產品希望你VIP是直接用虛擬幣去購買,這樣整個流程都很方便。那麼你一定要記住。千萬不要在1.0版本這麼做,這是血淚教訓。1.0版本會抓的很嚴很嚴,同時虛擬幣+VIP功能,百分百蘋果會要求你VIP要用續期訂閱去實現。最保險的做法呢,1.0版本不要做任何內購,迭代幾個小版本後,加入虛擬幣內購,在迭代幾個小版本,加入VIP直接用虛擬幣購買的功能,這是最最保險的做法。記住:1.0的審覈力度是真的很嚴,能先不做內購就不要做內購,老闆或許不懂,1.0版本什麼都想要,但往往因爲內購,會讓你們的產品反覆被拒。這一塊如果大家感興趣,可以看看,我的1.0版本就是加了內購,反覆被拒5次。血淚教訓
Q5:我們老闆心疼那百分之30的手續費,我能不能不用內購啊,有沒辦法繞過內購?
- A5:辦法是有的。但是有風險。我16年做過繞開內購的方法。思路很簡單,就是App裏集成支付寶/微信/內購這種功能,後臺做控制開關,審覈時,開關打開,給審覈人員看內購功能,審覈通過後,開關關閉,給正常用戶是用支付寶/微信功能。這個方法,我17年的時候聽到很多羣友說不行了,你在上架審覈時,蘋果會掃描你的包,檢測到第三方支付sdk時,會拒絕掉。後來又有羣友說可以用H5的方式實現支付功能。另外可能會有別的繞開蘋果審覈的實現方式,如果有哪位朋友知道,不妨留言告知。但不管是哪種方式,都是有風險的,蘋果對內購一直抓的很嚴,如果讓它知道你們在錢的方面上欺騙過他,後果還是很嚴重的。iOS上的用戶付費率還是很不錯的,付費意願基本上可以是安卓用戶的十幾倍。所以如果你們的產品真的有前景,並且想長久做下去,還是奉勸不要做欺騙蘋果的事情了。
Q6:網上有好多講丟單的博客,看的是一臉懵逼,有的看懂後,在看下一篇又不懂了,感覺都好複雜。
-
A6:我在剛接觸內購的時候也是這樣,我覺得有些博客講的真有點過了,它爲了考慮一些用戶的極端操作,多出來很多邏輯處理,導致博客異常的複雜,我記得有博客講必須要把receipt_data等信息存到keychain裏,因爲用戶有可能卸載App,如果你只存到NSUserDefaults裏,那樣就丟單了。 …那麼有沒有這種情況呢?我覺得是肯定有的。但我們來算算機率,首先他內購成功,在向服務器調接口的時候,他手機突然沒電了/斷網了/程序崩潰了/網絡差等的久他自己殺死進程了 巴拉巴拉。 然後他在下一次手機恢復正常的時候,果斷卸載掉App,重新去App Store上下載安裝,進入App後,發現內購沒到賬。
867088104DC1554FE5CDF4E962061E43.jpg -
網上博客還愛用那種切換賬號的場景舉例,A內購成功了,但用戶各種騷操作後,自己換到B賬號,然後服務器那邊把商品發到B賬號上了,等等。
-
這些情況都是存在的,因爲蘋果的內購機制問題,你是不能百分百保證不丟單的,不要把丟單情況看的那麼嚴重,邏輯寫的那麼複雜。你看看所有大廠的App上都會寫充值遇到問題,點我聯繫客服 巴拉巴拉。關於丟單,我的做法是這樣的,在蘋果內購成功的回調裏,NSUserDefaults存每一筆支付成功的訂單,如果服務器校驗成功,就把本地存的這筆訂單刪除。如果沒收到服務器的響應,就一直保留。然後每次App啓動就會去把本地存的丟單信息扔向服務器校驗,校驗成功刪除,校驗失敗不管。這裏還是看開發時間,當時我寫內購功能的時候,預算時間就兩天不到,所以寫的飛快,就簡單的用這個辦法去防止丟單,目前來看,沒有發現過一筆真正用戶充錢但商品沒到賬的例子。如果大家開發時間充足,可以慢慢去彌補極端操作漏洞。