iOS 蘋果內(nèi)購(gòu)（In-App Purchase）

內(nèi)購(gòu)簡(jiǎn)介

IAP 全稱：In-App Purchase骗炉，是指蘋果 App Store 的應(yīng)用內(nèi)購(gòu)買，是蘋果為 App 內(nèi)購(gòu)買虛擬商品或服務(wù)提供的一套交易系統(tǒng)惠赫。

內(nèi)購(gòu)導(dǎo)圖

適用范圍

在 App 內(nèi)需要付費(fèi)使用的產(chǎn)品功能或虛擬商品/服務(wù)邑贴，如游戲道具、電子書签则、音樂、視頻铐料、訂閱會(huì)員渐裂、App的高級(jí)功能等需要使用 IAP，而在 App 內(nèi)購(gòu)買實(shí)體商品（如淘寶購(gòu)買手機(jī)）或者不在 App 內(nèi)使用的虛擬商品（如充話費(fèi)）或服務(wù)（如滴滴叫車）則不適用于 IAP钠惩。

簡(jiǎn)而言之芯义，蘋果規(guī)定：適用范圍內(nèi)的虛擬商品或服務(wù)，必須使用 IAP 進(jìn)行購(gòu)買支付妻柒，不允許使用支付寶、微信支付等其它第三方支付方式（包括Apple Pay）耘分，也不允許以任何方式（包括跳出App举塔、提示文案等）引導(dǎo)用戶通過應(yīng)用外部渠道購(gòu)買。

內(nèi)購(gòu)準(zhǔn)備

App 內(nèi)集成內(nèi)購(gòu)代碼之前需要先去開發(fā)賬號(hào)的 iTunes Connect 后臺(tái)填寫銀行賬戶信息求泰、配置內(nèi)購(gòu)商品（包括產(chǎn)品ID央渣、價(jià)格等），還需要配置沙盒賬號(hào)用于 IAP 測(cè)試渴频。

銀行賬戶信息填寫

配置內(nèi)購(gòu)商品

IAP 是一套商品交易系統(tǒng)芽丹，而非簡(jiǎn)單的支付系統(tǒng)，每一個(gè)購(gòu)買項(xiàng)目都需要在開發(fā)者后臺(tái)的 iTunes Connect 后臺(tái)為 App 創(chuàng)建一個(gè)對(duì)應(yīng)的商品卜朗，提交給蘋果審核通過后拔第，購(gòu)買項(xiàng)目才會(huì)生效咕村。

新建內(nèi)購(gòu)商品有四種選擇分別是：
  • 消耗型項(xiàng)目：只可使用一次的產(chǎn)品，使用之后即失效蚊俺，必須再次購(gòu)買懈涛，如：游戲幣、一次性虛擬道具等泳猬。
  • 非消耗型項(xiàng)目：只需購(gòu)買一次批钠，不會(huì)過期或隨著使用而減少的產(chǎn)品。如：電子書得封。
  • 自動(dòng)續(xù)期訂閱：允許用戶在固定時(shí)間段內(nèi)購(gòu)買動(dòng)態(tài)內(nèi)容的產(chǎn)品埋心。除非用戶選擇取消，否則此類訂閱會(huì)自動(dòng)續(xù)期忙上，如：Apple Music這類按月訂閱的商品拷呆。
  • 非續(xù)期訂閱：允許用戶購(gòu)買有時(shí)限性服務(wù)的產(chǎn)品，此 App 內(nèi)購(gòu)買項(xiàng)目的內(nèi)容可以是靜態(tài)的晨横。此類訂閱不會(huì)自動(dòng)續(xù)期洋腮。

一般情況下用的最多的是消耗型商品，根據(jù) App 類型也會(huì)使用到非消耗型和自動(dòng)續(xù)期訂閱手形，以消耗型商品舉例：

這里需要注意的是產(chǎn)品 ID 具有唯一性啥供，建議使用項(xiàng)目的 Bundle Identidier 作為前綴后面拼接自定義的唯一的商品名或者ID（字母、數(shù)字）库糠。

這里有個(gè)坑：一旦新建一個(gè)內(nèi)購(gòu)商品伙狐，它的產(chǎn)品ID將永遠(yuǎn)被占用，即使該商品已經(jīng)被刪除瞬欧，已創(chuàng)建的內(nèi)購(gòu)商品除了產(chǎn)品 ID 之外的所有信息都可以修改贷屎，如果刪除了一個(gè)內(nèi)購(gòu)商品，將無法再創(chuàng)建一個(gè)相同產(chǎn)品 ID 的商品艘虎，也意味著該產(chǎn)品 ID 永久失效唉侄，一般來說產(chǎn)品ID有特定的命名規(guī)則，如果命名規(guī)則下有某個(gè)產(chǎn)品 ID 永久失效野建，可能會(huì)導(dǎo)致整個(gè)產(chǎn)品ID命名規(guī)則都要修改属划，這里千萬(wàn)要注意！

另外內(nèi)購(gòu)商品的定價(jià)只能從蘋果提供的價(jià)格等級(jí)去選擇候生，這個(gè)價(jià)格等級(jí)是固定的同眯，同一價(jià)格等級(jí)會(huì)對(duì)應(yīng)各個(gè)國(guó)家的貨幣，也就是說內(nèi)購(gòu)商品的價(jià)格是根據(jù) Apple ID 所在區(qū)域的貨幣進(jìn)行結(jié)算的唯鸭，比如：一個(gè)內(nèi)購(gòu)商品你選擇等級(jí)1须蜗，那么這個(gè)商品在美區(qū)是 0.66 美元，在中區(qū)是 6 元人民幣，在香港去是 8 港幣明肮，這些價(jià)格一般是固定的菱农，除非某些貨幣出現(xiàn)大的變動(dòng)（印象中有過一次盧布大跌，蘋果調(diào)整過俄區(qū)的價(jià)格）晤愧，價(jià)格等級(jí)表可以點(diǎn)擊 所有價(jià)格和貨幣 查看大莫。

另外要注意：蘋果內(nèi)購(gòu)是需要抽取30%的分成，實(shí)際結(jié)算是分成之前需要先扣除交易稅官份，不同地區(qū)交易稅不同只厘，具體分成數(shù)額參看價(jià)格表。

iOS 11 用戶可以在 App Store 內(nèi) App 的下載頁(yè)面內(nèi)直接購(gòu)買應(yīng)用的內(nèi)購(gòu)商品舅巷，這項(xiàng)功能蘋果稱作做 Promoting In-App Purchases羔味，如果你的 App 需要在 App Store 推廣自己的內(nèi)購(gòu)商品，則需要在 App Store 推廣 里上傳推廣用的圖像钠右，另外蘋果也在 iOS11 SDK 里面新增了從 App Store 購(gòu)買內(nèi)購(gòu)項(xiàng)目跳轉(zhuǎn)到 App 的新方法赋元。

iTunes Connect 后臺(tái)選擇 用戶和職能，選擇 + 添加測(cè)試賬號(hào)飒房。

填寫沙箱測(cè)試賬號(hào)信息需要注意以下幾點(diǎn)：

  • 電子郵件不能是別人已經(jīng)注冊(cè)過 AppleID 的郵箱
  • 電子郵箱可以不是真實(shí)的郵箱搁凸，但是必須符合郵箱格式
  • App Store 地區(qū)的選擇，測(cè)試的時(shí)候彈出的提示框以及結(jié)算的價(jià)格會(huì)按照沙箱賬號(hào)選擇的地區(qū)來狠毯，建議測(cè)試的時(shí)候新建幾個(gè)不同地區(qū)的賬號(hào)進(jìn)行測(cè)試

配置好測(cè)試賬號(hào)之后护糖，看一下沙箱賬號(hào)測(cè)試的時(shí)候如何使用：

  • 首先沙箱測(cè)試賬號(hào)必須在真機(jī)環(huán)境下進(jìn)行測(cè)試，并且是 adhoc 證書或者 develop 證書簽名的安裝包嚼松，沙盒賬號(hào)不支持直接從 App Store 下載的安裝包
  • 去真機(jī)的 App Store 退出真實(shí)的 Apple ID 賬號(hào)嫡良，退出之后并不需要在App Store 里面登錄沙箱測(cè)試賬號(hào)
  • 然后去 App 里面測(cè)試購(gòu)買商品，會(huì)彈出登錄框献酗，選擇 使用現(xiàn)有的 Apple ID寝受，然后登錄沙箱測(cè)試賬號(hào)，登錄成功之后會(huì)彈出購(gòu)買提示框罕偎，點(diǎn)擊 購(gòu)買很澄，然后會(huì)彈出提示框完成購(gòu)買

稅務(wù)信息

  1. 登錄 iTunes Connect

  2. 協(xié)議、稅務(wù)和銀行業(yè)務(wù)

內(nèi)購(gòu)實(shí)現(xiàn)

寫代碼之前先來了解對(duì)比一下 IPA 和支付寶支付颜及，首先看支付寶的支付流程：

  • App 發(fā)起一筆支付交易痴怨，然后服務(wù)端根據(jù)支付寶的要求把訂單信息進(jìn)行加密簽名
  • 服務(wù)端把加密的交易信息返回給 App，App 拿到交易信息調(diào)用支付寶的 SDK器予，把支付信息給到支付寶的服務(wù)端驗(yàn)證
  • 驗(yàn)證通過后，App 跳轉(zhuǎn)到支付寶 App 或者網(wǎng)頁(yè)版支付寶捐迫，用戶使用支付寶進(jìn)行支付
  • 支付成功后從支付寶 App 跳轉(zhuǎn)回到我們自己 APP乾翔，我們?cè)?App 里處理回調(diào)結(jié)果刷新UI等
  • 同時(shí)支付寶的服務(wù)器也會(huì)回調(diào)我們自己服務(wù)器，把收據(jù)傳給服務(wù)器，支付寶服務(wù)器會(huì)一直回調(diào)我們的服務(wù)器直到我們的服務(wù)器確認(rèn)收到收據(jù)
  • 我們的服務(wù)器收到回調(diào)確認(rèn)之后反浓，確認(rèn)訂單支付成功
  • 為了以防萬(wàn)一萌丈，App 上回調(diào)返回成功之后我們還需要去自己服務(wù)器驗(yàn)證是否真的支付成功（一切以服務(wù)器為準(zhǔn)）

微信支付和支付寶支付的流程是類似的，來看看 IAP 的支付流程：

  • App 發(fā)起一筆內(nèi)購(gòu)支付雷则，然后服務(wù)端生成一個(gè)訂單號(hào)并且返回給 App
  • App 拿到交易訂單之后調(diào)用 IPA 創(chuàng)建一個(gè) IPA 交易辆雾，并且添加到支付隊(duì)列
  • 然后 IAP 會(huì)調(diào)用 Apple ID 支付頁(yè)面等待用戶確認(rèn)支付，IPA 和蘋果自己的 IPA 服務(wù)器通訊月劈，回調(diào)購(gòu)買成功度迂，并且把收據(jù)寫入 App 沙盒
  • 然后 App 去沙盒獲取收據(jù)并且上傳到自己的服務(wù)器
  • 服務(wù)器去 IAP 服務(wù)器查詢收據(jù)的有效性并且對(duì)應(yīng)到某個(gè)訂單號(hào)，如果有效就通知 App猜揪，并且發(fā)放該內(nèi)購(gòu)商品惭墓，App 調(diào)用IAP 支付隊(duì)列去結(jié)束該 IPA 交易

對(duì)比來看兩者區(qū)別好像也不大，支付寶或者微信支付而姐，一旦App 端支付成功腊凶，之后的驗(yàn)證工作就完全是我們的服務(wù)器和支付寶服務(wù)器之間的通訊了，服務(wù)端之間的通訊就保證了交易的可靠性拴念，但是看看 IAP钧萍，同樣的交易，服務(wù)端的驗(yàn)證卻需要 App 端去驅(qū)動(dòng)政鼠，由于 App 的網(wǎng)絡(luò)環(huán)境比服務(wù)端復(fù)雜风瘦、用戶操作的不確定性可能會(huì)導(dǎo)致 APP 無法正確的驅(qū)動(dòng)服務(wù)端驗(yàn)證交易，另一方面 IAP 的服務(wù)器在美國(guó)缔俄，驗(yàn)證查詢交易的延遲也很嚴(yán)重

IAP 的代碼看起來并不多流程也比較清晰弛秋，主要是下面幾步：

  • 根據(jù)內(nèi)購(gòu)商品的產(chǎn)品 ID 初始化一個(gè) SKProductsRequest 對(duì)象，調(diào)用該對(duì)象的 start() 方法進(jìn)行內(nèi)購(gòu)商品的請(qǐng)求
  • 把商品請(qǐng)求中獲取到的 SKProduct 對(duì)象生成一個(gè) SKPayment 對(duì)象俐载，并把它壓入到 SKPaymentQueue 支付隊(duì)列中
  • 然后從支付隊(duì)列的代理方法 func paymentQueue(_ queue: SKPaymentQueue, updatedTransactions transactions: [SKPaymentTransaction]) 里面獲取到交易（transaction）的狀態(tài)蟹略，交易完成后調(diào)用支付隊(duì)列的 finishTransaction()完成內(nèi)購(gòu)支付
內(nèi)購(gòu)流程形象圖
內(nèi)購(gòu)業(yè)務(wù)邏輯圖
內(nèi)購(gòu)流程

內(nèi)購(gòu)的核心流程：

①客戶端發(fā)起支付訂單

②客戶端監(jiān)聽購(gòu)買結(jié)果

③蘋果回調(diào)訂單購(gòu)買成功時(shí)，客戶端把蘋果給的receipt_data和一些訂單信息上報(bào)給服務(wù)器

④后臺(tái)服務(wù)器拿receipt_data向蘋果服務(wù)器校驗(yàn)

⑤蘋果服務(wù)器向返回status結(jié)果遏佣，含義如下挖炬，其中為0時(shí)表示成功。

21000 App Store無法讀取你提供的JSON數(shù)據(jù)
21002 收據(jù)數(shù)據(jù)不符合格式
21003 收據(jù)無法被驗(yàn)證
21004 你提供的共享密鑰和賬戶的共享密鑰不一致
21005 收據(jù)服務(wù)器當(dāng)前不可用
21006 收據(jù)是有效的状婶，但訂閱服務(wù)已經(jīng)過期意敛。當(dāng)收到這個(gè)信息時(shí)，解碼后的收據(jù)信息也包含在返回內(nèi)容中
21007 收據(jù)信息是測(cè)試用（sandbox）膛虫，但卻被發(fā)送到產(chǎn)品環(huán)境中驗(yàn)證
21008 收據(jù)信息是產(chǎn)品環(huán)境中使用草姻，但卻被發(fā)送到測(cè)試環(huán)境中驗(yàn)證

⑥服務(wù)器發(fā)現(xiàn)訂單校驗(yàn)成功后，會(huì)把這筆訂單存起來稍刀，transaction_id用MD5值映射下撩独，保存到數(shù)據(jù)庫(kù)敞曹，防止同一筆訂單，多次發(fā)放內(nèi)購(gòu)商品综膀。

避坑指南

  1. 點(diǎn)擊購(gòu)買沒有彈出輸入賬戶密碼框澳迫。

解決方法：到手機(jī)設(shè)置里面 iTunes Store 與 App Store 里面注銷你原本的賬號(hào)。

  1. 運(yùn)行程序的時(shí)候剧劝，賬戶中明明添加了商品橄登，但是無法獲得商品ID。

解決方法：Capabilities -> In-App Purchase 設(shè)置 ON讥此。

  1. 丟單處理
  • 用戶輸入完 Apple ID 密碼或者驗(yàn)證完指紋支付成功之后拢锹，網(wǎng)絡(luò)突然中斷導(dǎo)致 IAP 沒有收到支付成功的通知，App 就無法在支付隊(duì)列的代理方法中獲取支付成功的通知暂论，后續(xù)的發(fā)放內(nèi)購(gòu)商品也就不可能了
  • App 在代理方法里收到了支付成功的通知面褐，但是 App 上傳交易收據(jù)到我們服務(wù)器去查詢的時(shí)候如果查詢失敗，那么服務(wù)器就無法發(fā)放內(nèi)購(gòu)商品取胎，因?yàn)檫@個(gè)行為是 App 驅(qū)動(dòng)服務(wù)器的行為展哭，這里有個(gè)坑就是支付隊(duì)列的代理方法 func paymentQueue(_ queue: SKPaymentQueue, updatedTransactions transactions: [SKPaymentTransaction]) 需要下次 App 重新啟動(dòng)才會(huì)重新調(diào)用，這個(gè)時(shí)候我們 App 才能重新去驅(qū)動(dòng)服務(wù)器查詢交易闻蛀，由于用戶操作的不確定性匪傍，不知道什么時(shí)候用戶才會(huì)重新打開App，發(fā)放內(nèi)購(gòu)商品的周期自然也不確定
  • 之前有開發(fā)者反應(yīng)觉痛，IAP 通知代理方法交易成功役衡，但是沙盒里面取收據(jù)的時(shí)候發(fā)現(xiàn)為空，或者當(dāng)前支付成功的訂單并沒有寫入沙盒的收據(jù)薪棒，導(dǎo)致上傳到服務(wù)器的收據(jù)查詢不到結(jié)果
  • 如果用戶支付成功手蝎，收據(jù)也上傳服務(wù)器成功，但是在服務(wù)器驗(yàn)證階段用戶刪除了App俐芯，導(dǎo)致App 無法去處理這些沒有被驗(yàn)證完的訂單
  • 如何處理越獄iOS手機(jī)內(nèi)購(gòu)的問題

以上問題都可能會(huì)導(dǎo)致用戶支付成功了棵介，卻收不到我們發(fā)放的內(nèi)購(gòu)商品，統(tǒng)一起來稱為：內(nèi)購(gòu)丟單

客戶端必須要給服務(wù)器傳的三個(gè)參數(shù)：receipt_data吧史， product_id 邮辽，transaction_id

//該方法為監(jiān)聽內(nèi)購(gòu)交易結(jié)果的回調(diào)
- (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray<SKPaymentTransaction *> *)transactions
transactions 為一個(gè)數(shù)組 遍歷就可以得到 SKPaymentTransaction 對(duì)象的元素transaction。然后從transaction里可以取到以下這兩個(gè)個(gè)參數(shù)贸营，product_id吨述，transaction_id。另外從沙盒里取到票據(jù)信息receipt_data 
我們先看怎么取到以上的三個(gè)參數(shù)
//獲取receipt_data
NSData *data = [NSData dataWithContentsOfFile:[[[NSBundle mainBundle] appStoreReceiptURL] path]];
NSString * receipt_data = [data base64EncodedStringWithOptions:0];
//獲取product_id
NSString *product_id = transaction.payment.productIdentifier;
//獲取transaction_id
NSString * transaction_id = transaction.transactionIdentifier;
這是我們必須要傳給服務(wù)器的三個(gè)字段钞脂。以上三個(gè)字段需要做好空值校驗(yàn)搪柑，避免崩潰匣椰。
下面我們來解釋一下望几，為什么要給服務(wù)器傳這三個(gè)參數(shù)。
receipt_data：這個(gè)不解釋了 大家都懂 不傳的話 服務(wù)器根本沒法校驗(yàn)
product_id：這個(gè)也不用解釋 內(nèi)購(gòu)產(chǎn)品編號(hào) 你不傳的話 服務(wù)器不知道你買的哪個(gè)訂單
transaction_id：這個(gè)是交易編號(hào)肋层，是必須要傳的。因?yàn)槟阋欠乐乖姜z下內(nèi)購(gòu)被xx就必須要校驗(yàn)in_app這個(gè)參數(shù)翎迁。而這個(gè)參數(shù)的數(shù)組元素有可能為多個(gè)，你必須得找到一個(gè)唯一標(biāo)示净薛，才可以區(qū)分訂單到底是那一筆汪榔。

后臺(tái)處理

前面說到用戶支付成功之后，我們拿到沙盒的收據(jù)信息去蘋果的 IAP 服務(wù)器去驗(yàn)證肃拜，這里既可以直接在 App 端驗(yàn)證也可以讓服務(wù)器去驗(yàn)證痴腌，實(shí)際上根據(jù)我的測(cè)試，App 端直接去IAP服務(wù)器驗(yàn)證比較快燃领，畢竟中間少了很多步驟士聪，但是考慮到越獄的 iOS 設(shè)備完全可以在系統(tǒng)層面跳過或者偽造收據(jù)，早期的 iOS 開發(fā)很多公司都是采用都是這種本地驗(yàn)證猛蔽，但是現(xiàn)在基本都是通過后臺(tái)驗(yàn)證的方式剥悟，具體的后臺(tái)驗(yàn)證步驟如下：

  • App端拿到沙盒的收據(jù)（receipt-data）,進(jìn)行一次base64編碼，上傳給服務(wù)器
  • 服務(wù)器拿到收據(jù)之后發(fā)到 IAP 服務(wù)器去驗(yàn)證曼库，驗(yàn)證成功之后收據(jù)需要和自己的訂單號(hào)進(jìn)行映射并且記錄在數(shù)據(jù)庫(kù)区岗，之后每次驗(yàn)證之前都需要先判斷收據(jù)是否存在，防止 App 端重復(fù)上傳相同的收據(jù)毁枯，重復(fù)發(fā)放內(nèi)購(gòu)商品
  • 服務(wù)器發(fā)放內(nèi)購(gòu)商品慈缔，推送通知給用戶等

由于 App 上線 App Store 之前我們是使用沙盒賬號(hào)測(cè)試的，沙盒測(cè)試的收據(jù)驗(yàn)證也是要去沙盒收據(jù)的服務(wù)器驗(yàn)證种玛。

而且蘋果在上線審核的時(shí)候也是使用沙盒賬號(hào)測(cè)試的藐鹤，那如何識(shí)別App端發(fā)過來的收據(jù)是沙盒測(cè)試還是正式環(huán)境用戶的購(gòu)買呢？這里服務(wù)端就要采用雙重驗(yàn)證赂韵，即先把收據(jù)拿到正式環(huán)境的驗(yàn)證地址去驗(yàn)證娱节，如果蘋果的正式環(huán)境驗(yàn)證服務(wù)器返回的狀態(tài)碼 status 為 21007，則說明當(dāng)前收據(jù)是沙盒環(huán)境產(chǎn)生右锨，則再連接一次沙盒環(huán)境服務(wù)器進(jìn)行驗(yàn)證括堤，這樣不管是我們自己采用沙盒賬號(hào)測(cè)試還是蘋果審核人員采用沙盒賬號(hào)進(jìn)行審核、或者用戶購(gòu)買都可以保證收據(jù)正常的驗(yàn)證成功绍移。

①先判重悄窃，避免重復(fù)分發(fā)內(nèi)購(gòu)商品。收到客戶端上報(bào)的 transaction_id 后蹂窖，直接MD5后去數(shù)據(jù)庫(kù)查轧抗，能查到說明是重復(fù)訂單，返回相應(yīng)錯(cuò)誤碼給客戶端瞬测，如果查不到横媚，去蘋果那邊校驗(yàn)纠炮。

②服務(wù)器拿到蘋果的校驗(yàn)結(jié)果后，首先判斷訂單狀態(tài)是不是成功灯蝴。

③如果訂單狀態(tài)成功在判斷in_app這個(gè)字段有沒有恢口，沒有直接就返回失敗了。如果存在的話穷躁，遍歷整個(gè)數(shù)組耕肩，通過客戶端給的transaction_id 來比較，取到相同的訂單時(shí)问潭，對(duì)比一下bundle_id 猿诸，product_id 是不是正確的。

如果以上校驗(yàn)都正確就把這筆訂單充值進(jìn)去狡忙，給用戶分發(fā)內(nèi)購(gòu)商品梳虽。

注意：一定要告訴后臺(tái)，不論校驗(yàn)是否成功灾茁，只要客戶端給服務(wù)器傳了receipt_data等參數(shù)就一定要保存到數(shù)據(jù)庫(kù)里窜觉。

Tips

  • iOS端傳過來的蘋果回調(diào)收據(jù)信息需base64加密，如果有嚴(yán)重的錯(cuò)誤問題删顶，注意收據(jù)信息的特殊符號(hào)替換竖螃，eg:"%2B"。
  • 蘋果內(nèi)購(gòu)訂閱型驗(yàn)證服務(wù)器需多加共享密鑰（由iOS開發(fā)人員提供給你）驗(yàn)證逗余，如果是添加的公共秘鑰特咆，那么消耗型驗(yàn)證也需要加上秘鑰驗(yàn)證。
  • 蘋果內(nèi)購(gòu)消耗型訂單傳過來的訂單是在in_app數(shù)組里录粱，而自動(dòng)訂閱型續(xù)訂的最新數(shù)據(jù)都在latest_receipt_info數(shù)組里腻格。

自動(dòng)訂閱續(xù)費(fèi)

  • 添加server to server 通知

latest_expired_receipt_info 用于自動(dòng)續(xù)訂。過期訂閱的收據(jù)的JSON表示形式啥繁，僅當(dāng)通知類型為RENEWAL或CANCEL或訂閱過期且續(xù)訂失敗時(shí)返回菜职。項(xiàng)目集成請(qǐng)看官網(wǎng)有介紹。

  • 服務(wù)端server輪詢要過期和過期的訂單數(shù)據(jù)旗闽，主動(dòng)向蘋果服務(wù)器驗(yàn)證酬核。

GitHub Demo

MQCCoder/XYIAPKit

參考文章

App 內(nèi)購(gòu)買項(xiàng)目配置流程

iOS 內(nèi)購(gòu)（In-App Purchase）總結(jié)

iOS開發(fā)支付篇——內(nèi)購(gòu)(IAP)詳解

iOS內(nèi)購(gòu)全面實(shí)戰(zhàn)

iOS內(nèi)購(gòu)（IAP）自動(dòng)續(xù)訂訂閱類型總結(jié)

IOS 內(nèi)購(gòu)IAP 自動(dòng)訂閱收據(jù)驗(yàn)證文檔服務(wù)端翻譯

iOS內(nèi)購(gòu)（IAP）自動(dòng)續(xù)訂訂閱類型服務(wù)端總結(jié)

springboot接入蘋果內(nèi)購(gòu)

java(jfinal) 接入ios內(nèi)購(gòu)（連續(xù)包月訂閱），服務(wù)端進(jìn)行二次驗(yàn)證

iOS 內(nèi)購(gòu)（In-App Purchase）總結(jié)

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 人面猴
    序言：七十年代末适室，一起剝皮案震驚了整個(gè)濱河市嫡意，隨后出現(xiàn)的幾起案子，更是在濱河造成了極大的恐慌捣辆，老刑警劉巖蔬螟，帶你破解...
    沈念sama閱讀 221,820評(píng)論 6贊 515
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件，死亡現(xiàn)場(chǎng)離奇詭異汽畴，居然都是意外死亡旧巾，警方通過查閱死者的電腦和手機(jī)耸序，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 94,648評(píng)論 3贊 399
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進(jìn)店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來鲁猩，“玉大人坎怪，你說我怎么就攤上這事±眨” “怎么了芋忿？”我有些...
    開封第一講書人閱讀 168,324評(píng)論 0贊 360
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵，是天一觀的道長(zhǎng)疾棵。 經(jīng)常有香客問我，道長(zhǎng)痹仙，這世上最難降的妖魔是什么是尔？ 我笑而不...
    開封第一講書人閱讀 59,714評(píng)論 1贊 297
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任，我火速辦了婚禮开仰，結(jié)果婚禮上拟枚，老公的妹妹穿的比我還像新娘。我一直安慰自己众弓，他們只是感情好恩溅，可當(dāng)我...
    茶點(diǎn)故事閱讀 68,724評(píng)論 6贊 397
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布。 她就那樣靜靜地躺著谓娃，像睡著了一般脚乡。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上滨达，一...
    開封第一講書人閱讀 52,328評(píng)論 1贊 310
  • 城市分裂傳說
    那天奶稠，我揣著相機(jī)與錄音，去河邊找鬼捡遍。 笑死锌订，一個(gè)胖子當(dāng)著我的面吹牛，可吹牛的內(nèi)容都是我干的画株。 我是一名探鬼主播辆飘，決...
    沈念sama閱讀 40,897評(píng)論 3贊 421
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼，長(zhǎng)吁一口氣：“原來是場(chǎng)噩夢(mèng)啊……” “哼谓传！你這毒婦竟也來了蜈项？” 一聲冷哼從身側(cè)響起，我...
    開封第一講書人閱讀 39,804評(píng)論 0贊 276
  • 萬(wàn)榮殺人案實(shí)錄
    序言：老撾萬(wàn)榮一對(duì)情侶失蹤良拼，失蹤者是張志新（化名）和其女友劉穎战得，沒想到半個(gè)月后，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體庸推，經(jīng)...
    沈念sama閱讀 46,345評(píng)論 1贊 318
  • ?護(hù)林員之死
    正文 獨(dú)居荒郊野嶺守林人離奇死亡常侦，尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 38,431評(píng)論 3贊 340
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年浇冰，在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片聋亡。...
    茶點(diǎn)故事閱讀 40,561評(píng)論 1贊 352
  • 活死人
    序言：一個(gè)原本活蹦亂跳的男人離奇死亡肘习，死狀恐怖，靈堂內(nèi)的尸體忽然破棺而出坡倔，到底是詐尸還是另有隱情漂佩，我是刑警寧澤，帶...
    沈念sama閱讀 36,238評(píng)論 5贊 350
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布罪塔，位于F島的核電站投蝉，受9級(jí)特大地震影響，放射性物質(zhì)發(fā)生泄漏征堪。R本人自食惡果不足惜瘩缆，卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,928評(píng)論 3贊 334
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望佃蚜。 院中可真熱鬧庸娱，春花似錦、人聲如沸谐算。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,417評(píng)論 0贊 24
  • 一樁弒父案，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽(yáng)洲脂。三九已至斤儿，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間腮考，已是汗流浹背雇毫。 一陣腳步聲響...
    開封第一講書人閱讀 33,528評(píng)論 1贊 272
  • 情欲美人皮
    我被黑心中介騙來泰國(guó)打工， 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留踩蔚，地道東北人棚放。 一個(gè)月前我還...
    沈念sama閱讀 48,983評(píng)論 3贊 376
  • 代替公主和親
    正文 我出身青樓，卻偏偏與公主長(zhǎng)得像馅闽，于是被迫代替她去往敵國(guó)和親飘蚯。 傳聞我的和親對(duì)象是個(gè)殘疾皇子，可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 45,573評(píng)論 2贊 359

推薦閱讀更多精彩內(nèi)容