前言

接觸公司的充值業(yè)務(wù)很久了,在處理蘋果充值的時(shí)候也踩了很多的坑，這里就花時(shí)間來總結(jié)下。

蘋果內(nèi)購

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

為什么這里著重來介紹 IAP 呢，因?yàn)?IAP 和微信支付和支付寶支付的實(shí)現(xiàn)邏輯不太一樣，因?yàn)?IAP 支付依賴 IOS 客戶端調(diào)用異步支付回調(diào)接口，進(jìn)行用戶和訂單的綁定，會(huì)有丟單的情況產(chǎn)生，這里
假定大家對蘋果支付有一定了解了，重點(diǎn)主要是來聊下蘋果支付的技術(shù)實(shí)現(xiàn)方案。

聊下，目前 IAP 中充值我們遇到的問題點(diǎn)

1、丟單；

2、訂單充值到錯(cuò)誤的賬號；

3、在蘋果設(shè)置中直接點(diǎn)擊充值，導(dǎo)致不到賬。

蘋果支付的難點(diǎn)

關(guān)于蘋果充值的難點(diǎn)，這邊總結(jié)下來就是下面兩點(diǎn)：

1、如何處理訂單回執(zhí)和用戶賬號的綁定關(guān)系；

2、APP 中復(fù)雜的網(wǎng)絡(luò)環(huán)境，如何保證訂單能夠成功回調(diào)；

方案設(shè)計(jì)

下面來介紹下蘋果支付中需要特別關(guān)注的點(diǎn)。

1、商品設(shè)計(jì)

蘋果對應(yīng)的充值商品 id 需要進(jìn)行申請，命名規(guī)則沒有強(qiáng)制性的要求，需要根據(jù)自己的商品類型來進(jìn)行映射。通常的做法，服務(wù)端會(huì)定義自己系統(tǒng)的內(nèi)部的商品，服務(wù)端會(huì)提供一個(gè)提供一個(gè)商品列表的接口，會(huì)把自己系統(tǒng)內(nèi)部的商品信息，映射到蘋果系統(tǒng)中的商品id。

如何合理的設(shè)計(jì)蘋果 iap 的商品ID呢？一般有兩種做法？

1、每個(gè)系統(tǒng)內(nèi)部的商品都對應(yīng)一個(gè)蘋果 iap 的商品id;

這種就是需要申請的商品id比較多，同時(shí)如果商品信息發(fā)生更改，就需要重新申請，當(dāng)然，如果自己系統(tǒng)內(nèi)部的商品，比較單一，并且基本上能夠保持不變，那這種方式可以商品設(shè)計(jì)的選擇之一。

2、每種類型的商品，一個(gè)價(jià)格對應(yīng)一個(gè)蘋果 iap 的商品id；

蘋果的 iap 的商品id和價(jià)格做綁定了，如果商品信息有變化，只要價(jià)格不變，就不用重新申請對應(yīng)的 iap 商品id 了。

具體使用哪種可以根據(jù)自己系統(tǒng)中的商品特點(diǎn)來進(jìn)行選擇。

2、用戶和回執(zhí)的綁定

蘋果支付中，蘋果回調(diào)中的是沒有第三方訂單信息的，所以，蘋果訂單回執(zhí)信息和用戶的綁定需要在 APP 中完成。

蘋果充值成功，給到 IOS 客戶端充值的回調(diào)信息，然后客戶端需要把當(dāng)前的回執(zhí)信息和當(dāng)前的用戶做好綁定，上報(bào)數(shù)據(jù)到自己的服務(wù)端，進(jìn)行訂單校驗(yàn)和充值道具的下發(fā)。

處理充值的時(shí)候，每一筆訂單都會(huì)生成唯一的訂單號。用戶和回執(zhí)信息的綁定，也就是，訂單號和用戶回執(zhí)信息的綁定，因?yàn)橛唵螌?yīng)數(shù)據(jù)，里面會(huì)關(guān)聯(lián)用戶信息。

這樣用戶和回執(zhí)的綁定也就回歸到用戶訂單和蘋果回執(zhí)的綁定，那么訂單號在何時(shí)生成，如何和蘋果回執(zhí)做綁定呢？有兩種方案，下面來一一探討下。

1、生成訂單 -> 發(fā)起 iap 充值 -> 客戶端 綁定訂單id和 iap 充值的回執(zhí)信息，向服務(wù)端發(fā)起回調(diào) -> 服務(wù)端接收到回調(diào)信息，校驗(yàn)訂單回執(zhí)，給用戶增加道具；

2、發(fā)起 iap 充值 -> 接收到回調(diào)信息 -> 客戶端將商品信息，用戶信息，iap 的回執(zhí)信息，一起回調(diào)給服務(wù)端 -> 服務(wù)端接收到回調(diào)信息，校驗(yàn)回執(zhí)信息，生成對應(yīng)的訂單，同時(shí)給用戶增加道具；

這兩種最主要的差別就是訂單的生成時(shí)機(jī)不同，第一中訂單號對客戶端是可見的，第二種訂單號對客戶端是不可見的。

1、訂單提前生成

訂單提前生成，比較符合我們處理的訂單的邏輯，如果自己的充值系統(tǒng)中也同時(shí)集成了微信和支付寶的支付，那么選用這種方式，訂單的處理就相對統(tǒng)一。

缺點(diǎn)：

1、每次點(diǎn)擊充值就會(huì)有一個(gè)訂單的生成，即使用戶后面沒有實(shí)際的充值，會(huì)有無效訂單數(shù)據(jù)的產(chǎn)生；

2、因?yàn)橛唵翁柡吞O果回執(zhí)信息的綁定是需要在客戶端中進(jìn)行綁定操作的，那么這個(gè)就會(huì)存在綁定錯(cuò)亂的情況，用戶可能點(diǎn)擊充值了多個(gè)商品，這時(shí)候處理綁定的時(shí)候， A 商品的訂單號，綁定到了 B 商品的回執(zhí)信息上了。結(jié)果就是用戶訂單異常。

2、回調(diào)的時(shí)候生成訂單號

訂單是后面生成的，所以可以控制只有回執(zhí)信息驗(yàn)證通過的時(shí)候才生成訂單號，避免了無用訂單的生成。

不過這兩種處理方式個(gè)人感覺差別不大，設(shè)計(jì)的時(shí)候考慮下如果有其它的支付方式同時(shí)存在，如何做好兼容就行了。

我們用的第一種，提前生成訂單，因?yàn)槲覀兿到y(tǒng)中同時(shí)存在了，微信，支付寶和蘋果充值，所以各個(gè)充值方式的兼容也是我們考慮的一個(gè)重要的點(diǎn)。

不過也根據(jù)第一種方式做了細(xì)微的調(diào)整，因?yàn)樘O果充值存在充值成功但是回調(diào)是失敗的情況，接收到失敗的訂單回調(diào)，本地記錄的訂單號就會(huì)被清理了，這時(shí)候有成功的回調(diào)過來，本地就沒有對應(yīng)的訂單號了，同時(shí)對于訂閱商品，下一個(gè)扣款日重新發(fā)我續(xù)訂，app 接收到回調(diào)通知，本地也是沒有存儲(chǔ)對應(yīng)的訂單號。沒有訂單號，也就意味著蘋果的充值回執(zhí)信息，和用戶關(guān)聯(lián)不上了。這種情況，我們的處理方式就是，app 接收到成功的回調(diào)，本地沒有訂單號，就重新調(diào)用服務(wù)端接口重新生成一個(gè)。保證用戶和蘋果的回執(zhí)信息一定能關(guān)聯(lián)上。

3、回調(diào)的重試

因?yàn)樘O果訂單的綁定依賴于客戶端，當(dāng)網(wǎng)絡(luò)環(huán)境不好，接收到回調(diào)信息，之后向自己的服務(wù)端進(jìn)行回執(zhí)信息的驗(yàn)證，出現(xiàn)接口請求不通的情況，這時(shí)候就需要執(zhí)行回調(diào)回執(zhí)的重試。

當(dāng)然重試分成兩部分

1、客戶端回調(diào)回執(zhí)信息的重試；

2、服務(wù)端驗(yàn)證回執(zhí)信息的重試。

一般服務(wù)端在設(shè)計(jì)充值的時(shí)候，都會(huì)使用到分布式事務(wù)，消息隊(duì)列等來保證事務(wù)的最終一致性。同時(shí)對于一些第三方的請求，也會(huì)有對應(yīng)的重試機(jī)制：

1、數(shù)據(jù)標(biāo)記法：接收到請求，先落數(shù)據(jù)庫，如果驗(yàn)證成功將數(shù)據(jù)標(biāo)記成功，如果一直沒有驗(yàn)證處理成功，就定時(shí)從數(shù)據(jù)庫將此數(shù)據(jù)取出來，繼續(xù)重試驗(yàn)證的邏輯；

2、消息隊(duì)列的重試機(jī)制：一般消息隊(duì)列都有對應(yīng)的重試機(jī)制，消息驗(yàn)證成功，就將消息從隊(duì)列中移除，否則重新丟到隊(duì)列中，借助隊(duì)列的重試機(jī)制，知道本消息處理成功。

客戶端部分的重試步驟：

1、接收到蘋果的回調(diào)，拼接訂單和用戶信息，向自己的服務(wù)端發(fā)起回調(diào)；

2、如果自己服務(wù)端的回調(diào)接口，返回成功，在一定時(shí)間內(nèi)定時(shí)查詢該訂單的狀態(tài)，如果訂單返回成功，更新用戶的賬戶信息；

3、如果回調(diào)自己的服務(wù)端失敗，這時(shí)候就需要進(jìn)行重試操作，1分鐘內(nèi)重試5次，直到該回調(diào)接口返回成功的狀態(tài)；

4、如果1分鐘內(nèi)重試了5次還是失敗，記錄該回執(zhí)信息，用戶打開app，或者切換到充值頁面的時(shí)候繼續(xù)重試。

因?yàn)閷τ诨卣{(diào)的處理，服務(wù)端只要接收到請求，就會(huì)記錄該回調(diào)信息，然后接口返回成功，所以只要客戶端的網(wǎng)絡(luò)正常，這種失敗的情況是不會(huì)出現(xiàn)的，多次的重試操作一定能規(guī)避這種情況。

充值沖遇到的問題點(diǎn)

1、丟單

丟單是蘋果充值經(jīng)常遇到的問題，因?yàn)槭?app 接收到的蘋果的服務(wù)回調(diào)，相比于服務(wù)端的 sever to server 的通知，受限于客戶端的當(dāng)時(shí)的網(wǎng)絡(luò)環(huán)境，app 的打開狀況，穩(wěn)定性是偏差的。

如何處理呢？

原則上就是客戶端接收到蘋果的回調(diào)通知，盡可能的拼接用戶信息和回執(zhí)信息發(fā)送給自己的服務(wù)單進(jìn)行數(shù)據(jù)的驗(yàn)證，服務(wù)在驗(yàn)證數(shù)據(jù)的時(shí)候做好訂單的唯一性處理，避免商品超發(fā)的情況。

總結(jié)了可能有下面幾種情況：

1、接收到異常的回調(diào)：充值成功了，但是客戶端先接收到的是一個(gè)充值失敗的回調(diào)，然后草草結(jié)束掉本次訂單，導(dǎo)致后面收到了充值成功的訂單，但是訂單已經(jīng)結(jié)束就不處理了，最終結(jié)果就是丟單了；

2、網(wǎng)絡(luò)不穩(wěn)定：充值成功了，客戶端成功接收到了蘋果的回調(diào)，但是給自己服務(wù)端回調(diào)的時(shí)候，因?yàn)榫W(wǎng)絡(luò)原因?qū)е禄卣{(diào)失敗了，結(jié)果就是用戶丟單了；

3、用戶頻繁切換賬戶：充值成功了，用戶在充值過程中發(fā)生了賬號的切換，因?yàn)槭褂玫奶O果賬號是同一個(gè)，但是登陸 app 的賬號可以是多個(gè)，切換賬號的過程中，充值到其中一個(gè)賬號中了，但是給到用戶的體驗(yàn)就是當(dāng)前賬號沒到賬，就認(rèn)為是丟單了；

4、自己服務(wù)端校驗(yàn)票據(jù)異常：充值成功了，客戶端接收到了回調(diào)，但是回調(diào)回執(zhí)信息給自己服務(wù)端的時(shí)候，服務(wù)端在驗(yàn)證票據(jù)的時(shí)候出現(xiàn)了異常，導(dǎo)致該訂單驗(yàn)證失敗，用戶的體驗(yàn)就是該訂單丟單了；

下面來分析下上面的幾種情況：

對于情況場景 1 和場景 2，客戶端盡可能的做好重試，只要接收到蘋果 iap 中的回調(diào)，就拼接信息回掉給自己的服務(wù)端，如果當(dāng)前的回調(diào)接口沒有返回成功的標(biāo)識，就要繼續(xù)重試。

對于場景 3 ，可以在交互上優(yōu)化，用戶充值之后返回 app ，可以加一個(gè)充值中的 loading 頁面，避免用戶在這個(gè)過程中出現(xiàn)切換賬號的操作。

對于場景 3 ，一般服務(wù)端在設(shè)計(jì)充值這種業(yè)務(wù)的時(shí)候都會(huì)用到分布式事務(wù)，所以這種情況是能夠避免的。

2、充值成功，下發(fā)的物品不對

因?yàn)槌渲瞪唐?，訂單號?ipa 充值回執(zhí)信息的綁定是在 app 中操作的。如果用戶在充值的時(shí)候有頻繁點(diǎn)擊充值的行為，那么在綁定充值回執(zhí)的數(shù)據(jù)的時(shí)候，就有可能出現(xiàn)綁定錯(cuò)亂的情況。

原來商品的 a 的回執(zhí)信息，綁定時(shí)候，被綁定到了 商品 b 上面。

這時(shí)候服務(wù)端就需要做好數(shù)據(jù)的檢驗(yàn)，如果通過回執(zhí)信息請求蘋果的訂單接口是能拿到，充值訂單對應(yīng)的 iap 商品，通過這個(gè)商品就能判斷回到數(shù)據(jù)綁定的數(shù)據(jù)是否正確，如果不正確修改當(dāng)前訂單信息的數(shù)據(jù)即可。

3、處理退款

根據(jù)蘋果的策略，用戶在購買IAP后90天內(nèi)，能以各種原因申請退款（扣款后購買失敗、買錯(cuò)了、不喜歡等等）。

用戶成功申請退款了，系統(tǒng)中對應(yīng)的道具也要清除掉，不然就是充值漏洞了，里面的商品就會(huì)被用戶白嫖了。

蘋果在 WWDC 2020 蘋果全球開發(fā)者大會(huì)，蘋果宣布所有的內(nèi)購項(xiàng)類型，當(dāng)用戶在應(yīng)用內(nèi)退款成功時(shí)，App Store Server 會(huì)發(fā)送實(shí)時(shí)的通知給開發(fā)者服務(wù)器告知有退款，開發(fā)者可通過處理該消息來更新用戶的賬戶信息。

退款流程：

1、用戶購買內(nèi)購商品；

2、用戶申請退款；

3、蘋果發(fā)起退款；

4、Apple Store Server 發(fā)送退款通知；

5、用戶收到退款成功的通知；

6、開發(fā)者收到退款訂單通知。

最后來看下普通充值的訂單的具體信息

{
	"environment": "Production", // 當(dāng)前的環(huán)境，Production表示生產(chǎn)環(huán)境，Sandbox表示的是沙盒環(huán)境
	"receipt": {
		"receipt_type": "Production",
		"adam_id": 6666666,
		"app_item_id": 8888888,
		"bundle_id": "test.888888",
		"application_version": "4.79.0.1",
		"download_id": 999999999,
		"version_external_identifier": 862386348,
		"receipt_creation_date": "2024-01-07 04:33:30 Etc/GMT",
		"receipt_creation_date_ms": "1704602010000",
		"receipt_creation_date_pst": "2024-01-06 20:33:30 America/Los_Angeles",
		"request_date": "2024-01-10 01:39:43 Etc/GMT",
		"request_date_ms": "1704850783803",
		"request_date_pst": "2024-01-09 17:39:43 America/Los_Angeles",
		"original_purchase_date": "2023-12-30 23:42:26 Etc/GMT",
		"original_purchase_date_ms": "1703979746000",
		"original_purchase_date_pst": "2023-12-30 15:42:26 America/Los_Angeles",
		"original_application_version": "4.79.0.1",
		"in_app": [{
				"quantity": "1", // 商品的數(shù)量
				"product_id": "1111101_2_2_12.00", // iap 的商品id
				"transaction_id": "381201227775036", // 交易號
				"original_transaction_id": "381201227775036", // 原始交易號
				"purchase_date": "2024-01-07 04:33:29 Etc/GMT", // 最新的購買時(shí)間
				"purchase_date_ms": "1704602009000", // 最新的購買時(shí)間毫秒
				"purchase_date_pst": "2024-01-06 20:33:29 America/Los_Angeles", // 最新的購買時(shí)間，太平洋時(shí)間
				"original_purchase_date": "2024-01-07 04:33:29 Etc/GMT", // 最初的購買時(shí)間
				"original_purchase_date_ms": "1704602009000", // 最初的購買時(shí)間，毫秒
				"original_purchase_date_pst": "2024-01-06 20:33:29 America/Los_Angeles", // 最初的購買時(shí)間太平洋時(shí)間
				"is_trial_period": "false", // 是否是試用期
				"in_app_ownership_type": "PURCHASED"
			}
		]
	},
	"latest_receipt": "xxxxx", // 憑證信息
	"status": 0 //}

蘋果訂閱

上面簡單聊了下蘋果中普通商品的充值流程，下面來聊一下訂閱商品的充值。

自動(dòng)訂閱根據(jù)名字能看出來相對于普通的商品，自動(dòng)訂閱的商品到了扣款周期，蘋果會(huì)自動(dòng)發(fā)起重新扣款。

先來看下訂閱的充值流程，訂閱的首次充值流程和普通的商品的首次充值流程一樣，充值成功之后，后面會(huì)涉及訂閱的下次扣費(fèi)，所以后面多了原始交易號和回執(zhí)信息的記錄，方便后面自動(dòng)扣款的續(xù)訂操作。

蘋果訂閱商品在下個(gè)扣款周期扣費(fèi)的時(shí)候，扣款的動(dòng)作由蘋果自動(dòng)發(fā)起，這和支付寶和微信的訂閱扣款邏輯不同。

因?yàn)槭翘O果自動(dòng)進(jìn)行的扣款處理，所以會(huì)如果蘋果扣款的時(shí)候的通知不及時(shí)或者消息丟失，就很容易造成用戶的丟單情況。

處理思路：

1、配置服務(wù)端回調(diào)通知

配置服務(wù)端回調(diào)通知，配置服務(wù)端通知的動(dòng)作思可選的，不過建議開啟。開啟之后就能及時(shí)收到蘋果的訂單的狀態(tài)，處理用戶的訂單狀態(tài)。

App Store Server Notifications V1

服務(wù)端的通知類型，有下面幾種：

CANCEL：表示蘋果支持已經(jīng)取消了自動(dòng)續(xù)期訂閱并且用戶在cancellation_date_ms時(shí)間收到了退款信息；

觸發(fā)時(shí)機(jī)：

CANCEL事件通過AppleCare支持取消訂閱并退還購買款項(xiàng)時(shí)觸發(fā)。

DID_CHANGE_RENEWAL_PREF：表示客戶對其訂閱計(jì)劃進(jìn)行了更改，該更改會(huì)在下一次續(xù)訂時(shí)生效。當(dāng)前活動(dòng)的計(jì)劃不受影響；

觸發(fā)時(shí)機(jī)：

當(dāng)用戶在同一訂閱分組中，從一個(gè)訂閱商品切換到另一個(gè)訂閱商品時(shí)，會(huì)觸發(fā) DID_CHANGE_RENEWAL_PREF 事件；

DID_CHANGE_RENEWAL_STATUS：表示訂閱續(xù)訂狀態(tài)發(fā)生變化；

觸發(fā)時(shí)機(jī)：

用戶關(guān)閉了訂閱，或者非訂閱狀態(tài)重新續(xù)訂。

通過判斷 auto_renew_status 判斷當(dāng)前的訂閱狀態(tài)，auto_renew_status == 0 表示訂閱狀態(tài)已經(jīng)關(guān)閉， auto_renew_status == 1 表示訂閱處于開啟狀態(tài)。

DID_FAIL_TO_RENEW：表示由于計(jì)費(fèi)問題而無法續(xù)訂的訂閱，栗如，用戶當(dāng)前卡上沒錢了；

DID_RECOVER：表示成功自動(dòng)續(xù)訂一個(gè)過去續(xù)訂失敗的過期訂閱。檢查expires_date以確定下一次續(xù)費(fèi)的日期和時(shí)間；

DID_RENEW：表示用戶當(dāng)前的訂閱周期已經(jīng)重新續(xù)訂了；

INITIAL_BUY：用戶在首次發(fā)生訂閱時(shí)觸發(fā)；

INTERACTIVE_RENEWAL：表示客戶通過使用應(yīng)用程序界面或在 App Store 帳戶的訂閱設(shè)置中以交互方式續(xù)訂訂閱;

觸發(fā)時(shí)機(jī)：

用戶取消了訂閱，一段時(shí)間后用戶通過 AppStore 交互頁面重新訂閱產(chǎn)品，會(huì)觸發(fā) INTERACTIVE_RENEWAL 事件。

REFUND：表示 App Store 已成功對消耗性應(yīng)用內(nèi)購買、非消耗性應(yīng)用內(nèi)購買或非續(xù)訂訂閱的交易進(jìn)行退款，不同于取消（CANCEL）通知類型，取消通知類型針對的是自動(dòng)續(xù)期訂閱類型商品，用戶通過 AppleCare 支持取消訂閱并退還購買款項(xiàng)時(shí)觸發(fā)；

蘋果服務(wù)端的返回狀態(tài) DID_RENEW 就表示蘋果當(dāng)前的訂閱的扣款已經(jīng)成功了，接收到這個(gè)狀態(tài)的通知，處理用戶的訂單即可。

2、客戶端通知；

蘋果每次訂閱的扣款也會(huì)下發(fā)通知到客戶端，客戶端接收到的扣款成功的通知，回調(diào)該信息到自己的服務(wù)端，服務(wù)端接收到該回調(diào)通知，判斷當(dāng)前訂閱的道具有沒有下發(fā)，沒有下發(fā)，修改本次訂閱的狀態(tài)，下發(fā)對應(yīng)的充值道具給到當(dāng)前的用戶，并記錄本次訂閱已經(jīng)完成。

3、服務(wù)端定時(shí)輪詢；

服務(wù)端定時(shí)輪詢快到期的訂閱，向蘋果發(fā)起請求查詢當(dāng)前訂閱的狀態(tài)，判斷訂閱當(dāng)前的扣款狀態(tài)，如果扣款了，就修改訂閱扣款到下個(gè)周期，下發(fā)充值道具給到用戶，否則就繼續(xù)輪詢，直到用戶取消訂閱，或者用戶訂閱扣款成功。

StoreKit 1 對比 2

StoreKit 1 存在的問題：

1、蘋果后臺(tái)不能查看到退款的訂單詳情。只能蘋果處理退款后發(fā)通知給我們的服務(wù)器，告知發(fā)生了一筆退款；

2、消耗性、非消耗性、非續(xù)期訂閱、自動(dòng)續(xù)訂能不能在沙盒環(huán)境測試退款，系統(tǒng)沒提供這種測試方式；

3、不能夠?qū)⒂脩舴答伒奶O果付費(fèi)收據(jù)里的 orderID 與具體的業(yè)務(wù)訂單進(jìn)行關(guān)聯(lián)；

4、研發(fā)過程中，無法直接關(guān)聯(lián)蘋果交易號 transactionId 與 業(yè)務(wù)訂單號 orderID 之間聯(lián)系，、在開發(fā)過程中，無法直接關(guān)聯(lián) transaction 與 orderID 之間聯(lián)系，雖然有一個(gè) applicationUserName 字段，可以存儲(chǔ)一個(gè)信息。但是這個(gè)字段是不是 100%靠譜，在某些情況下會(huì)丟失存儲(chǔ)的數(shù)據(jù)；

StoreKit 2

2021 年 WWDC，在 iOS 15 系統(tǒng)上推出了一個(gè)新的 StoreKit 2 庫，該庫采用了完全新的 API 來解決應(yīng)用內(nèi)購買問題。 StoreKit 2 主要的更新有這幾個(gè)：

StoreKit 2 庫采用 Swift 5.5 版本最新特性重寫，只支持 Swift、iOS 15+，提供了一些新的 API 接口，導(dǎo)致新的支付流程會(huì)發(fā)生一些變化。

1、提供了獲取交易歷史記錄、可購買的商品列表(自動(dòng)續(xù)期訂閱以及非消耗品)信息；

2、提供了獲取訂閱狀態(tài)、管理訂閱狀態(tài)接口；

3、支持在 App 內(nèi)發(fā)起退款。

新的 api

1、新的商品接口

新增了一些商品類型，訂閱信息，這些字段信息在 StoreKit 1 里是沒有的。

方便利用的字段：

1、通過新增的 product type 我們可以輕易的知道當(dāng)前的商品是消耗品還是訂閱商品；

2、針對于自動(dòng)連續(xù)訂閱的第一次購買優(yōu)惠，我們可以直接感知到當(dāng)前的商品是不是用戶的 Apple ID 下的第一次購買；

2、新的購買接口

提供了新的購買商品接口。其中購買商品時(shí)增加了一些可選參數(shù) PurchaseOption 結(jié)構(gòu)體，該結(jié)構(gòu)體里有新增的特別重要的字段 appAccountToken， 類似 SKPayment.applicationUsername 字段，但是 appAccountToken 信息會(huì)永久保存在 Transaction 信息內(nèi)。

appAccountToken 字段是由開發(fā)者創(chuàng)建的；關(guān)聯(lián)到 App 里的用戶賬號；使用 UUID 格式；永久存儲(chǔ)在 Transaction 信息里。這里的存儲(chǔ)的信息，不會(huì)像 v1 版本，存在數(shù)據(jù)丟失的情況。

這里的 appAccountToken 字段蘋果的意思是用來存儲(chǔ)用戶賬號信息的，但是應(yīng)該也可以用來存儲(chǔ) orderID 相關(guān)的信息，需要將 orderID 轉(zhuǎn)成 UUID 格式塞到 Transaction 信息內(nèi)，方便處理補(bǔ)單、退款等操作。

處理驗(yàn)證 Transaction。系統(tǒng)會(huì)驗(yàn)證是否是一個(gè)合法的 Transaction，此時(shí)系統(tǒng)不再提供 base64 的 receip string 信息，只需要上傳 transaction.id 和 transaction.originalID，服務(wù)器端根據(jù)需要選擇合適的 ID 進(jìn)行驗(yàn)證。

3、交易歷史查詢接口

提供了三個(gè)新的交易（Transcation）相關(guān)的 API：

1、All transactions：全部的購買交易訂單，在 transaction 里面獲??；

2、Latest transactions：最新的購買交易訂單；

3、Current entitlements：所有當(dāng)前訂閱的交易，以及所有購買（且未退還）的非消耗品。

4、訂閱類型項(xiàng)目的狀態(tài)

訂閱類型項(xiàng)目的狀態(tài)，比如主動(dòng)獲取最新的交易、獲取更新訂閱的狀態(tài)，獲取更新訂閱的信息等。其中獲取更新訂閱的信息，可以獲取更新的狀態(tài)、品項(xiàng) id、如果過期的話，可以知道過期的原因。（比如用戶取消、扣費(fèi)失敗、訂閱正常過期等。）獲取的所有數(shù)據(jù)都是 JWS 格式驗(yàn)證。

5、管理訂閱頁面

可以直接喚起 App Store 里的管理訂閱頁面。

6、退款api

提供了新的發(fā)起退款 API，允許用戶在開發(fā)者的 App 中直接進(jìn)行退款申請。用戶進(jìn)行申請退款后，App 可以收到通知、另外蘋果服務(wù)器也會(huì)通知開發(fā)者服務(wù)器。

StoreKit 2 支持 iOS 15 以上的系統(tǒng)，所有如果用戶有很多這個(gè)版本之下的用戶，就需要考慮如何合理的接入新的版本了。

對于后端來說，Apple Server API V1 和 Apple Server API V2 都能夠運(yùn)用，與客戶端是否升級到 StoreKit 2 無關(guān)。

總結(jié)

上面主要總結(jié)了蘋果支付的主要邏輯。

1、蘋果支付對比微信和支付寶的最大的不同就是，IAP 支付依賴 IOS 客戶端調(diào)用異步支付回調(diào)接口，進(jìn)行用戶和訂單的綁定；

2、蘋果支付最大的難點(diǎn)就是用戶和回執(zhí)的綁定；

• 蘋果充值成功，給到 IOS 客戶端充值的回調(diào)信息，然后客戶端需要把當(dāng)前的回執(zhí)信息和當(dāng)前的用戶做好綁定，上報(bào)數(shù)據(jù)到自己的服務(wù)端，進(jìn)行訂單校驗(yàn)和充值道具的下發(fā)。

• 處理充值的時(shí)候，每一筆訂單都會(huì)生成唯一的訂單號。用戶和回執(zhí)信息的綁定，也就是，訂單號和用戶回執(zhí)信息的綁定，因?yàn)橛唵螌?yīng)數(shù)據(jù)，里面會(huì)關(guān)聯(lián)用戶信息。

3、重試，因?yàn)橐蕾囉?app 的回調(diào)，所有當(dāng)網(wǎng)絡(luò)環(huán)境不好，接收到回調(diào)信息，之后向自己的服務(wù)端進(jìn)行回執(zhí)信息的驗(yàn)證，出現(xiàn)接口請求不通的情況，這時(shí)候就需要執(zhí)行回調(diào)回執(zhí)的重試；

• 客戶端部分的重試步驟：

• 1、接收到蘋果的回調(diào)，拼接訂單和用戶信息，向自己的服務(wù)端發(fā)起回調(diào)；

• 2、如果自己服務(wù)端的回調(diào)接口，返回成功，在一定時(shí)間內(nèi)定時(shí)查詢該訂單的狀態(tài)，如果訂單返回成功，更新用戶的賬戶信息；

• 3、如果回調(diào)自己的服務(wù)端失敗，這時(shí)候就需要進(jìn)行重試操作，1分鐘內(nèi)重試5次，直到該回調(diào)接口返回成功的狀態(tài)；

• 4、如果1分鐘內(nèi)重試了5次還是失敗，記錄該回執(zhí)信息，用戶打開app，或者切換到充值頁面的時(shí)候繼續(xù)重試。

• 因?yàn)閷τ诨卣{(diào)的處理，服務(wù)端只要接收到請求，就會(huì)記錄該回調(diào)信息，然后接口返回成功，所以只要客戶端的網(wǎng)絡(luò)正常，這種失敗的情況是不會(huì)出現(xiàn)的，多次的重試操作一定能規(guī)避這種情況。

4、退款的處理，根據(jù)蘋果的策略，用戶在購買IAP后90天內(nèi)，能以各種原因申請退款（扣款后購買失敗、買錯(cuò)了、不喜歡等等）；

• 用戶成功申請退款了，系統(tǒng)中對應(yīng)的道具也要清除掉，不然就是充值漏洞了，里面的商品就會(huì)被用戶白嫖了。

• 蘋果在 WWDC 2020 蘋果全球開發(fā)者大會(huì)，蘋果宣布所有的內(nèi)購項(xiàng)類型，當(dāng)用戶在應(yīng)用內(nèi)退款成功時(shí)，App Store Server 會(huì)發(fā)送實(shí)時(shí)的通知給開發(fā)者服務(wù)器告知有退款，開發(fā)者可通過處理該消息來更新用戶的賬戶信息。

5、蘋果訂閱：因?yàn)橛嗛喪翘O果直接發(fā)起的，所以我們要合理的處理訂閱扣款之后的回調(diào)；

• 1、配置服務(wù)端回調(diào)通知：配置服務(wù)端通知的動(dòng)作思可選的，不過建議開啟。開啟之后就能及時(shí)收到蘋果的訂單的狀態(tài)，處理用戶的訂單狀態(tài)；

• 回調(diào)中的 CANCEL：表示蘋果支持已經(jīng)取消了自動(dòng)續(xù)期訂閱并且用戶在cancellation_date_ms時(shí)間收到了退款信息；

• 2、客戶端通知；

• 蘋果每次訂閱的扣款也會(huì)下發(fā)通知到客戶端，客戶端接收到的扣款成功的通知，回調(diào)該信息到自己的服務(wù)端，服務(wù)端接收到該回調(diào)通知，判斷當(dāng)前訂閱的道具有沒有下發(fā)，沒有下發(fā)，修改本次訂閱的狀態(tài)，下發(fā)對應(yīng)的充值道具給到當(dāng)前的用戶，并記錄本次訂閱已經(jīng)完成。

• 3、服務(wù)端定時(shí)輪詢；

• 服務(wù)端定時(shí)輪詢快到期的訂閱，向蘋果發(fā)起請求查詢當(dāng)前訂閱的狀態(tài)，判斷訂閱當(dāng)前的扣款狀態(tài)，如果扣款了，就修改訂閱扣款到下個(gè)周期，下發(fā)充值道具給到用戶，否則就繼續(xù)輪詢，直到用戶取消訂閱，或者用戶訂閱扣款成功。

參考

【AppStore內(nèi)購】https://liushoukai.github.io/2020/04/04/appstore-in-app-purchase/
【官方文檔】https://developer.apple.com/cn/in-app-purchase/
【iOS StoreKit 2 新特性解析】https://juejin.cn/post/7096063372159877150
【蘋果支付】https://boilingfrog.github.io/2024/01/28/蘋果iap支付/

作者：ZhanLi 轉(zhuǎn)自博客園 https://www.cnblogs.com/ricklz/p/17993800