狠狠色丁香婷婷综合尤物/久久精品综合一区二区三区/中国有色金属学报/国产日韩欧美在线观看 - 国产一区二区三区四区五区tv

前言

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

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

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

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

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

1、丟單；

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

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

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

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

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

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

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

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

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

蘋果對(duì)應(yīng)的充值商品 id 需要進(jìn)行申請(qǐng)，命名規(guī)則沒(méi)有強(qiáng)制性的要求，需要根據(jù)自己的商品類型來(lái)進(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)部的商品都對(duì)應(yīng)一個(gè)蘋果 iap 的商品id;

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

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

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

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

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

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

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

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

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

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í)信息，生成對(duì)應(yīng)的訂單，同時(shí)給用戶增加道具；

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

1、訂單提前生成

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

缺點(diǎn)：

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

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

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

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

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

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

不過(guò)也根據(jù)第一種方式做了細(xì)微的調(diào)整，因?yàn)樘O果充值存在充值成功但是回調(diào)是失敗的情況，接收到失敗的訂單回調(diào)，本地記錄的訂單號(hào)就會(huì)被清理了，這時(shí)候有成功的回調(diào)過(guò)來(lái)，本地就沒(méi)有對(duì)應(yīng)的訂單號(hào)了，同時(shí)對(duì)于訂閱商品，下一個(gè)扣款日重新發(fā)我續(xù)訂，app 接收到回調(diào)通知，本地也是沒(méi)有存儲(chǔ)對(duì)應(yīng)的訂單號(hào)。沒(méi)有訂單號(hào)，也就意味著蘋果的充值回執(zhí)信息，和用戶關(guān)聯(lián)不上了。這種情況，我們的處理方式就是，app 接收到成功的回調(diào)，本地沒(méi)有訂單號(hà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)接口請(qǐng)求不通的情況，這時(shí)候就需要執(zhí)行回調(diào)回執(zhí)的重試。

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

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

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

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

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

2、消息隊(duì)列的重試機(jī)制：一般消息隊(duì)列都有對(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í)查詢?cè)撚唵蔚臓顟B(tài)，如果訂單返回成功，更新用戶的賬戶信息；

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

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

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

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

1、丟單

丟單是蘋果充值經(jīng)常遇到的問(wèn)題，因?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、用戶頻繁切換賬戶：充值成功了，用戶在充值過(guò)程中發(fā)生了賬號(hào)的切換，因?yàn)槭褂玫奶O果賬號(hào)是同一個(gè)，但是登陸 app 的賬號(hào)可以是多個(gè)，切換賬號(hào)的過(guò)程中，充值到其中一個(gè)賬號(hào)中了，但是給到用戶的體驗(yàn)就是當(dāng)前賬號(hào)沒(méi)到賬，就認(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)就是該訂單丟單了；

下面來(lái)分析下上面的幾種情況：

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

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

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

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

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

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

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

3、處理退款

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

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

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

退款流程：

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

2、用戶申請(qǐng)退款；

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

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

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

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

最后來(lái)看下普通充值的訂單的具體信息

{
	"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", // 交易號(hào)
				"original_transaction_id": "381201227775036", // 原始交易號(hào)
				"purchase_date": "2024-01-07 04:33:29 Etc/GMT", // 最新的購(gòu)買時(shí)間
				"purchase_date_ms": "1704602009000", // 最新的購(gòu)買時(shí)間毫秒
				"purchase_date_pst": "2024-01-06 20:33:29 America/Los_Angeles", // 最新的購(gòu)買時(shí)間，太平洋時(shí)間
				"original_purchase_date": "2024-01-07 04:33:29 Etc/GMT", // 最初的購(gòu)買時(shí)間
				"original_purchase_date_ms": "1704602009000", // 最初的購(gòu)買時(shí)間，毫秒
				"original_purchase_date_pst": "2024-01-06 20:33:29 America/Los_Angeles", // 最初的購(gòu)買時(shí)間太平洋時(shí)間
				"is_trial_period": "false", // 是否是試用期
				"in_app_ownership_type": "PURCHASED"
			}
		]
	},
	"latest_receipt": "xxxxx", // 憑證信息
	"status": 0 //}

蘋果訂閱

上面簡(jiǎn)單聊了下蘋果中普通商品的充值流程，下面來(lái)聊一下訂閱商品的充值。

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

先來(lái)看下訂閱的充值流程，訂閱的首次充值流程和普通的商品的首次充值流程一樣，充值成功之后，后面會(huì)涉及訂閱的下次扣費(fèi)，所以后面多了原始交易號(hào)和回執(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)作思可選的，不過(guò)建議開啟。開啟之后就能及時(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事件通過(guò)AppleCare支持取消訂閱并退還購(gòu)買款項(xiàng)時(shí)觸發(fā)。

DID_CHANGE_RENEWAL_PREF：表示客戶對(duì)其訂閱計(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ù)訂。

通過(guò)判斷 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)問(wèn)題而無(wú)法續(xù)訂的訂閱，栗如，用戶當(dāng)前卡上沒(méi)錢了；

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

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

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

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

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

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

REFUND：表示 App Store 已成功對(duì)消耗性應(yīng)用內(nèi)購(gòu)買、非消耗性應(yīng)用內(nèi)購(gòu)買或非續(xù)訂訂閱的交易進(jìn)行退款，不同于取消（CANCEL）通知類型，取消通知類型針對(duì)的是自動(dòng)續(xù)期訂閱類型商品，用戶通過(guò) AppleCare 支持取消訂閱并退還購(gòu)買款項(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)前訂閱的道具有沒(méi)有下發(fā)，沒(méi)有下發(fā)，修改本次訂閱的狀態(tài)，下發(fā)對(duì)應(yīng)的充值道具給到當(dāng)前的用戶，并記錄本次訂閱已經(jīng)完成。

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

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

StoreKit 1 對(duì)比 2

StoreKit 1 存在的問(wèn)題：

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

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

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

4、研發(fā)過(guò)程中，無(wú)法直接關(guān)聯(lián)蘋果交易號(hào) transactionId 與 業(yè)務(wù)訂單號(hào) orderID 之間聯(lián)系，、在開發(fā)過(guò)程中，無(wú)法直接關(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 庫(kù)，該庫(kù)采用了完全新的 API 來(lái)解決應(yīng)用內(nèi)購(gòu)買問(wèn)題。 StoreKit 2 主要的更新有這幾個(gè)：

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

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

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

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

新的 api

1、新的商品接口

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

方便利用的字段：

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

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

2、新的購(gòu)買接口

提供了新的購(gòu)買商品接口。其中購(gòu)買商品時(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 里的用戶賬號(hào)；使用 UUID 格式；永久存儲(chǔ)在 Transaction 信息里。這里的存儲(chǔ)的信息，不會(huì)像 v1 版本，存在數(shù)據(jù)丟失的情況。

這里的 appAccountToken 字段蘋果的意思是用來(lái)存儲(chǔ)用戶賬號(hào)信息的，但是應(yīng)該也可以用來(lái)存儲(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：全部的購(gòu)買交易訂單，在 transaction 里面獲取；

2、Latest transactions：最新的購(gòu)買交易訂單；

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

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

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

5、管理訂閱頁(yè)面

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

6、退款api

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

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

對(duì)于后端來(lái)說(shuō)，Apple Server API V1 和 Apple Server API V2 都能夠運(yùn)用，與客戶端是否升級(jí)到 StoreKit 2 無(wú)關(guān)。

總結(jié)

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

1、蘋果支付對(duì)比微信和支付寶的最大的不同就是，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ì)生成唯一的訂單號(hào)。用戶和回執(zhí)信息的綁定，也就是，訂單號(hào)和用戶回執(zhí)信息的綁定，因?yàn)橛唵螌?duì)應(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)接口請(qǐng)求不通的情況，這時(shí)候就需要執(zhí)行回調(diào)回執(zhí)的重試；

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

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

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

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

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

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

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

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

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

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

• 1、配置服務(wù)端回調(diào)通知：配置服務(wù)端通知的動(dòng)作思可選的，不過(guò)建議開啟。開啟之后就能及時(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)前訂閱的道具有沒(méi)有下發(fā)，沒(méi)有下發(fā)，修改本次訂閱的狀態(tài)，下發(fā)對(duì)應(yīng)的充值道具給到當(dāng)前的用戶，并記錄本次訂閱已經(jīng)完成。

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

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

參考

【AppStore內(nèi)購(gòu)】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