做內(nèi)購(gòu)這塊我前后在三個(gè)項(xiàng)目里踩過(guò)坑一次是 Apple 收據(jù)校驗(yàn)在灰度環(huán)境全掛一次是 Google Play 商品因?yàn)橥浾{(diào)確認(rèn)接口被系統(tǒng)在第三天自動(dòng)退款還有一次是訂閱續(xù)訂的通知沒(méi)接用戶續(xù)費(fèi)了但權(quán)益沒(méi)續(xù)上。這幾次事故之后我把整套鏈路重新捋了一遍用 Golang 寫(xiě)了統(tǒng)一的服務(wù)端校驗(yàn)層把Golang 內(nèi)購(gòu)接入流程和解析Google Play、Apple IAP這件事拆成可復(fù)用的模塊。這篇內(nèi)容講的就是這套東西移動(dòng)端應(yīng)用內(nèi)購(gòu)買的服務(wù)端校驗(yàn)包含 Apple IAP 的收據(jù)校驗(yàn)與 StoreKit 2 的簽名驗(yàn)證也包含 Google Play 的購(gòu)買令牌校驗(yàn)、確認(rèn)與訂閱狀態(tài)查詢。它解決的問(wèn)題很直白——客戶端傳來(lái)的我付過(guò)錢了這句話一個(gè)字都不能信必須由服務(wù)端去平臺(tái)側(cè)核對(duì)。適合已經(jīng)有 Go 后端基礎(chǔ)、正在接內(nèi)購(gòu)或者被內(nèi)購(gòu)?fù)丝顔?wèn)題折磨過(guò)的同學(xué)看也適合剛接手支付模塊、需要快速搞清楚鏈路全貌的人。下面按設(shè)計(jì)思路、核心機(jī)制、實(shí)操落地、問(wèn)題排查四塊來(lái)講代碼都可以直接拿去改。1. 內(nèi)購(gòu)鏈路的整體設(shè)計(jì)與方案選型1.1 客戶端在支付鏈路里能做的事比想象中少很多新手一開(kāi)始會(huì)把內(nèi)購(gòu)理解成客戶端調(diào)個(gè)支付彈窗成功了告訴我一聲。這個(gè)理解如果只做 Demo 沒(méi)問(wèn)題一旦上線就是災(zāi)難。平臺(tái)側(cè)的支付結(jié)果在客戶端手里只是一個(gè)憑據(jù)Apple 給的是收據(jù)receipt或 JWS 簽名串Google 給的是一個(gè) purchaseToken 字符串。它們本身沒(méi)有任何防偽能力用戶越獄或者抓包之后把這些字符串換成別人的、偽造的、重放的你的服務(wù)端如果照單全收就等于開(kāi)了個(gè)免費(fèi)領(lǐng)取的口子。所以鏈路必須這樣切客戶端只負(fù)責(zé)三件事——拉起支付、拿到憑據(jù)、把憑據(jù)扔給自家服務(wù)端。服務(wù)端負(fù)責(zé)拿憑據(jù)去平臺(tái)服務(wù)器核對(duì)核對(duì)通過(guò)之后才落單、發(fā)貨、寫(xiě)權(quán)益。這樣一來(lái)客戶端能造假的環(huán)節(jié)就只剩把別人的憑據(jù)發(fā)給我而這種重放會(huì)被訂單表的唯一索引擋住。我在第一版設(shè)計(jì)里吃過(guò)一個(gè)虧為了省一次請(qǐng)求讓客戶端在支付成功回調(diào)里直接把商品 ID 和金額帶上服務(wù)端核對(duì)收據(jù)之后用客戶端傳的金額入賬。結(jié)果測(cè)試同學(xué)隨手改了個(gè)金額參數(shù)虛擬幣到賬數(shù)直接翻倍。教訓(xùn)很直接——價(jià)格、商品 ID、幣種這些信息必須從平臺(tái)返回的報(bào)文或者你自己的商品配置表里取客戶端傳過(guò)來(lái)的只當(dāng)作參考日志。1.2 服務(wù)端校驗(yàn)架構(gòu)的兩種取舍架構(gòu)上實(shí)際只有兩種做法。第一種是即時(shí)校驗(yàn)客戶端拿到憑據(jù)立刻請(qǐng)求服務(wù)端服務(wù)端同步調(diào)平臺(tái)接口校驗(yàn)通過(guò)返回發(fā)貨結(jié)果。第二種是落庫(kù)異步校驗(yàn)服務(wù)端先收下憑據(jù)寫(xiě)進(jìn)待校驗(yàn)表立刻返回已受理后臺(tái) worker 慢慢去調(diào)平臺(tái)接口。兩種我都在生產(chǎn)用過(guò)選擇看場(chǎng)景。即時(shí)校驗(yàn)的優(yōu)點(diǎn)是用戶體驗(yàn)好支付完立刻看到權(quán)益到賬代碼鏈路也短。缺點(diǎn)是平臺(tái)接口抖一下用戶就卡在支付成功但不到賬的頁(yè)面還容易重復(fù)點(diǎn)擊造成并發(fā)。異步校驗(yàn)的優(yōu)點(diǎn)是抗抖動(dòng)平臺(tái)接口超時(shí)了可以重試客戶端也不用等。缺點(diǎn)是用戶要等而且需要一個(gè)補(bǔ)償機(jī)制告訴客戶端你的貨到了。我的做法是混合先落庫(kù)用唯一索引保證冪等然后在請(qǐng)求內(nèi)同步嘗試一次校驗(yàn)成功就直接返回成功失敗就把訂單標(biāo)記成待重試丟給后臺(tái)客戶端拿到處理中狀態(tài)開(kāi)始輪詢。這樣既保住了快路徑的體驗(yàn)又不會(huì)被平臺(tái)接口的抖動(dòng)拖死。后臺(tái) worker 用的是固定間隔加指數(shù)退避間隔從 5 秒起步最多重試 8 次累計(jì)大概覆蓋半小時(shí)超過(guò)就進(jìn)人工隊(duì)列。1.3 數(shù)據(jù)模型與狀態(tài)機(jī)怎么定表結(jié)構(gòu)這塊我建議一開(kāi)始就想清楚后面改動(dòng)成本很高。核心是兩張表訂單表和權(quán)益表。訂單表記錄每一次支付嘗試權(quán)益表記錄用戶最終擁有的東西。中間用訂單 ID 關(guān)聯(lián)不要把兩者合成一張表否則退款、訂閱續(xù)期這些場(chǎng)景會(huì)讓你非常難受。訂單表的關(guān)鍵字段我列一下直接用 SQL 表達(dá)更清楚CREATE TABLE iap_order ( id BIGSERIAL PRIMARY KEY, user_id BIGINT NOT NULL, platform SMALLINT NOT NULL, -- 1apple 2google product_id VARCHAR(128) NOT NULL, order_no VARCHAR(64) NOT NULL, -- 自家訂單號(hào) outer_txn_id VARCHAR(128) NOT NULL, -- 平臺(tái)交易號(hào) / purchaseToken 哈希 original_txn_id VARCHAR(128) DEFAULT , -- Apple 原始交易號(hào)訂閱續(xù)期用 receipt TEXT DEFAULT , -- 原始憑據(jù)留檔排查 amount BIGINT DEFAULT 0, -- 單位分 currency VARCHAR(8) DEFAULT , status SMALLINT NOT NULL DEFAULT 0, env SMALLINT NOT NULL DEFAULT 0, -- 0生產(chǎn) 1沙盒 expire_at TIMESTAMPTZ, created_at TIMESTAMPTZ NOT NULL DEFAULT now(), updated_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE UNIQUE INDEX uk_iap_order_outer ON iap_order(platform, outer_txn_id); CREATE UNIQUE INDEX uk_iap_order_no ON iap_order(order_no);那個(gè)唯一索引是整張表的命門(mén)。并發(fā)請(qǐng)求、客戶端重試、消息重復(fù)投遞全部靠它在數(shù)據(jù)庫(kù)層攔住比在代碼里加鎖可靠得多。Go 側(cè)配合INSERT ... ON CONFLICT DO NOTHING加RETURNING id插入成功就繼續(xù)走校驗(yàn)插入失敗說(shuō)明是重復(fù)請(qǐng)求直接查老訂單返回當(dāng)前狀態(tài)就行一次數(shù)據(jù)庫(kù)往返解決問(wèn)題。狀態(tài)機(jī)我定成五個(gè)狀態(tài)用整數(shù)表示0 待校驗(yàn)、1 已支付待發(fā)貨、2 已完成、3 已退款、4 校驗(yàn)失敗需人工。流轉(zhuǎn)規(guī)則很簡(jiǎn)單只允許 0→1→2 和 1→3其他跳轉(zhuǎn)一律拒絕并打告警日志。狀態(tài)機(jī)的作用不是好看是讓你在出了退款、掉單、重復(fù)回調(diào)這些事的時(shí)候能一眼看出訂單卡在哪一步。2. 兩條通道的核心機(jī)制與關(guān)鍵細(xì)節(jié)2.1 Apple 收據(jù)校驗(yàn)verifyReceipt 的老路與 StoreKit 2 的新路Apple 這邊歷史包袱比較重現(xiàn)在同時(shí)存在兩套東西。老的一套是verifyReceipt接口客戶端從SKPaymentQueue拿到一個(gè) base64 編碼的收據(jù)串服務(wù)端 POST 到https://buy.itunes.apple.com/verifyReceipt請(qǐng)求體里除了收據(jù)還要帶共享密鑰訂閱類商品必需。返回的 JSON 里status為 0 表示校驗(yàn)通過(guò)非 0 就是各類錯(cuò)誤碼。這里有個(gè)所有接入方都會(huì)遇到的坑生產(chǎn)地址返回 21007 的時(shí)候說(shuō)明你拿到的是沙盒收據(jù)必須改打https://sandbox.itunes.apple.com/verifyReceipt重新校驗(yàn)一次。反過(guò)來(lái)沙盒地址返回 21008 說(shuō)明是生產(chǎn)收據(jù)。標(biāo)準(zhǔn)做法是先生產(chǎn)后沙盒無(wú)條件打生產(chǎn)收到 21007 再降級(jí)打沙盒。我見(jiàn)過(guò)有同學(xué)反過(guò)來(lái)寫(xiě)先打沙盒再打生產(chǎn)結(jié)果沙盒接口在生產(chǎn)環(huán)境經(jīng)常超時(shí)白白多一次 RTT。新的 StoreKit 2 換了一套思路不再給整包收據(jù)而是給一個(gè) JWS 簽名的Transaction對(duì)象。這個(gè)串本身帶簽名服務(wù)端用 Apple 的公鑰鏈驗(yàn)簽就能確認(rèn)內(nèi)容沒(méi)被篡改。JWS 的 header 里有x5c字段是個(gè)證書(shū)數(shù)組第一張是簽名證書(shū)最后一張是根證書(shū) Apple Root CA - G3。驗(yàn)簽流程是拿x5c拼出證書(shū)鏈驗(yàn)證鏈上每一級(jí)的簽名關(guān)系取第一張證書(shū)的公鑰驗(yàn) JWS 的簽名最后檢查 payload 里的bundleId、environment、transactionId跟你預(yù)期的一致。這兩套要選哪個(gè)我的建議是新項(xiàng)目直接上 StoreKit 2 加服務(wù)端 JWS 驗(yàn)簽再配一套 App Store Server Notifications V2 接收續(xù)訂、退款、撤銷事件。老項(xiàng)目如果還在用SKPaymentQueue別急著大改先把降級(jí)邏輯和錯(cuò)誤碼處理好等有排期了再遷移。因?yàn)閮商椎氖論?jù)格式、有效期字段、訂閱信息結(jié)構(gòu)全不一樣混著用很容易在解析層出 bug。JWS 驗(yàn)簽的 Go 實(shí)現(xiàn)通常用github.com/go-jose/go-jose/v3把x5c里的證書(shū)逐個(gè)x509.ParseCertificate然后手動(dòng)驗(yàn)證上下級(jí)簽名最后jose.ParseSigned驗(yàn) payload。這一步我建議寫(xiě)單元測(cè)試固定住因?yàn)樽C書(shū)鏈校驗(yàn)寫(xiě)錯(cuò)往往不會(huì)報(bào)錯(cuò)只會(huì)一直返回 false。2.2 Google Play購(gòu)買令牌、服務(wù)端校驗(yàn)與確認(rèn)機(jī)制Google 這邊鏈路相對(duì)干凈但有幾個(gè)機(jī)制如果不了解會(huì)導(dǎo)致很隱蔽的資損?？蛻舳擞?Play Billing 完成支付后會(huì)拿到三樣?xùn)|西purchaseToken、productId、orderId。服務(wù)端拿這三個(gè)去調(diào) Android Publisher API一次性商品走purchases.products.get訂閱走purchases.subscriptionsv2.get。鑒權(quán)用服務(wù)賬號(hào)Service Account在 Google Cloud 控制臺(tái)創(chuàng)建下載 JSON 密鑰放到服務(wù)器上授予 Play Console 里的財(cái)務(wù)權(quán)限和訂單查詢權(quán)限。Go 側(cè)用golang.org/x/oauth2/google加google.golang.org/api/androidpublisher/v3就夠了SDK 會(huì)自動(dòng)處理 token 緩存和刷新。要注意的是權(quán)限授予有延遲剛加完服務(wù)賬號(hào)就去調(diào)接口經(jīng)常會(huì)拿到 401 或 403等五分鐘再試一般就好。真正容易出事的是確認(rèn)機(jī)制acknowledge。Google 規(guī)定一筆購(gòu)買必須在三天內(nèi)被確認(rèn)否則會(huì)被自動(dòng)退款。這個(gè)確認(rèn)不是校驗(yàn)很多同學(xué)把products.get返回purchaseState 1當(dāng)成萬(wàn)事大吉然后就沒(méi)下文了三天后用戶收到退款通知貨還在用戶手里。正確流程是校驗(yàn)通過(guò)并且發(fā)貨成功之后立刻調(diào)purchases.products.acknowledge。消耗型商品比如金幣用purchases.products.consume替代consume 本身也帶確認(rèn)效果。訂閱也有類似的東西subscriptionsv2.get返回的subscriptionState是SUBSCRIPTION_STATE_ACTIVE才算有效還有acknowledgementState字段0 表示還沒(méi)確認(rèn)。訂閱的確認(rèn)同樣是三天期限。另外訂閱還有個(gè)賬號(hào)綁定選項(xiàng)開(kāi)啟之后 purchaseToken 會(huì)跟用戶賬號(hào)綁定換賬號(hào)無(wú)法使用是否開(kāi)啟取決于你的產(chǎn)品設(shè)計(jì)我個(gè)人傾向開(kāi)啟能有效減少共享行為。還有一個(gè)容易被忽略的點(diǎn)purchaseState 2表示掛起pending通常是用戶選了現(xiàn)金支付等延遲付款方式。這種訂單在校驗(yàn)時(shí)會(huì)返回 pending你不應(yīng)該發(fā)貨也不能拒絕而是要等狀態(tài)變化。實(shí)現(xiàn)上要么靠實(shí)時(shí)開(kāi)發(fā)者通知RTDN推送要么靠客戶端下次啟動(dòng)時(shí)重查。我的做法是兩條都上RTDN 走 Pub/Sub 推到一個(gè) HTTP 端點(diǎn)收到消息后不信任消息內(nèi)容拿里面的 purchaseToken 再去查一次真實(shí)狀態(tài)這樣最穩(wěn)。2.3 冪等、補(bǔ)單與退款回收冪等這件事說(shuō)穿了就三層防護(hù)第一層是客戶端側(cè)的按鈕防抖防止用戶連點(diǎn)第二層是服務(wù)端的分布式鎖按 purchaseToken 加鎖鎖的粒度要細(xì)第三層是數(shù)據(jù)庫(kù)唯一索引這是最后一道保險(xiǎn)。三層里只有第三層是絕對(duì)可靠的前兩層都可能因?yàn)榫W(wǎng)絡(luò)分區(qū)失效。所以我寫(xiě)代碼時(shí)永遠(yuǎn)假設(shè)前兩層不存在唯一索引沖突就老老實(shí)實(shí)返回已有訂單。補(bǔ)單是個(gè)必需品而不是可選項(xiàng)。用戶支付成功但網(wǎng)絡(luò)斷了的場(chǎng)景每天都在發(fā)生客戶端本地要緩存未完成的交易下次啟動(dòng)時(shí)按順序重新上報(bào)。我建議給客戶端一個(gè)未完成訂單隊(duì)列用本地?cái)?shù)據(jù)庫(kù)存上報(bào)成功一條刪一條。Apple 的SKPaymentQueue本身會(huì)保留未完成的交易并在下次啟動(dòng)時(shí)重放Google 的queryPurchasesAsync也能拿到所有有效購(gòu)買但主動(dòng)補(bǔ)單在跨設(shè)備、重裝應(yīng)用之后仍然必要。退款回收是很多人上線后才想起來(lái)做的。Apple 的退款通過(guò) App Store Server Notifications V2 的REFUND或REVOKE通知下發(fā)Google 的通過(guò)voidedPurchases.list接口或者 RTDN 的 voided 通知下發(fā)。收到之后要做的是把對(duì)應(yīng)訂單狀態(tài)置為已退款把權(quán)益收回或者標(biāo)記成負(fù)數(shù)而不是直接刪記錄。刪記錄會(huì)導(dǎo)致對(duì)賬時(shí)對(duì)不上而且用戶申訴時(shí)你沒(méi)有依據(jù)。3. 從零跑通的實(shí)操過(guò)程3.1 賬號(hào)與憑證準(zhǔn)備Apple 側(cè)需要的東西App Store Connect 里的應(yīng)用、一個(gè)內(nèi)購(gòu)商品配置好商品 ID 和價(jià)格檔位、一個(gè)用于收據(jù)校驗(yàn)的共享密鑰在應(yīng)用信息的App 專用共享密鑰里生成。如果做訂閱還要配置訂閱群組。訂閱群組的層級(jí)設(shè)計(jì)會(huì)直接影響用戶升級(jí)降級(jí)時(shí)的行為建議先把檔位排好再上線后改很麻煩。Google 側(cè)需要Play Console 里創(chuàng)建應(yīng)用、上傳一個(gè)帶 billing 權(quán)限的簽名包到內(nèi)部測(cè)試軌道、配置商品、創(chuàng)建服務(wù)賬號(hào)并授權(quán)。注意商品必須在有有效 APK 的軌道上才能生效光在草稿狀態(tài)創(chuàng)建商品客戶端是拉不到商品列表的。這一點(diǎn)卡了我半天一直以為是代碼問(wèn)題其實(shí)是包沒(méi)傳。配置統(tǒng)一放配置文件或者密鑰管理服務(wù)里不要硬編碼。我用的是一個(gè)結(jié)構(gòu)體從環(huán)境變量加載方便在不同環(huán)境切換。共享密鑰這種敏感信息單獨(dú)存權(quán)限收緊到只有支付服務(wù)能讀。# 環(huán)境變量示例 export IAP_APPLE_SHARED_SECRETxxxxxxxx export IAP_APPLE_BUNDLE_IDcom.example.app export IAP_GOOGLE_SA_FILE/etc/iap/service-account.json export IAP_GOOGLE_PACKAGEcom.example.app3.2 Apple 校驗(yàn)服務(wù)的 Go 實(shí)現(xiàn)先看數(shù)據(jù)結(jié)構(gòu)定義。verifyReceipt的響應(yīng)體字段特別多只定義你需要的字段就夠了Go 的 json 解析會(huì)忽略多余字段。type appleVerifyRequest struct { ReceiptData string json:receipt-data Password string json:password,omitempty ExcludeOld bool json:exclude-old-transactions } type appleVerifyResponse struct { Status int json:status Env string json:environment Receipt struct { BundleID string json:bundle_id InApp []struct { ProductID string json:product_id TransactionID string json:transaction_id OriginalTxID string json:original_transaction_id PurchaseDateMs string json:purchase_date_ms ExpiresDateMs string json:expires_date_ms IsTrialPeriod string json:is_trial_period InAppOwnershipType string json:in_app_ownership_type } json:in_app } json:receipt LatestReceiptInfo []struct { ProductID string json:product_id TransactionID string json:transaction_id ExpiresDateMs string json:expires_date_ms } json:latest_receipt_info }校驗(yàn)函數(shù)的核心是生產(chǎn)降級(jí)沙盒和狀態(tài)碼分流兩件事寫(xiě)在一起const ( appleProdURL https://buy.itunes.apple.com/verifyReceipt appleSandboxURL https://sandbox.itunes.apple.com/verifyReceipt ) func verifyApple(ctx context.Context, receipt string, sharedSecret string) (*appleVerifyResponse, bool, error) { body, _ : json.Marshal(appleVerifyRequest{ ReceiptData: receipt, Password: sharedSecret, ExcludeOld: true, }) resp, err : postJSON(ctx, appleProdURL, body) if err ! nil { return nil, false, err } var out appleVerifyResponse if err : json.Unmarshal(resp, out); err ! nil { return nil, false, err } if out.Status 0 { return out, false, nil } if out.Status 21007 { // 沙盒收據(jù)打到了生產(chǎn)地址降級(jí)重試 resp2, err : postJSON(ctx, appleSandboxURL, body) if err ! nil { return nil, true, err } var out2 appleVerifyResponse if err : json.Unmarshal(resp2, out2); err ! nil { return nil, true, err } if out2.Status 0 { return out2, true, nil } return nil, true, fmt.Errorf(apple sandbox verify failed: %d, out2.Status) } return nil, false, fmt.Errorf(apple verify failed: %d, out.Status) }postJSON里我加了 15 秒超時(shí)和一次重試重試只針對(duì)網(wǎng)絡(luò)錯(cuò)誤和 5xx業(yè)務(wù)錯(cuò)誤碼不重試因?yàn)橹卦囈膊粫?huì)變。超時(shí)時(shí)間不能設(shè)太短Apple 的校驗(yàn)接口在促銷期間偶爾會(huì)到 8 秒以上設(shè) 5 秒會(huì)誤殺。拿到響應(yīng)之后要做三件事核對(duì)receipt.bundle_id是不是自己的應(yīng)用核對(duì)返回的 product_id 是不是訂單里的產(chǎn)品核對(duì)in_app里確實(shí)存在這條transaction_id。這三步都是防止串號(hào)和偽造的必要檢查。金額不要從響應(yīng)里取Apple 的收據(jù)里沒(méi)有可靠的金額字段價(jià)格得查你自己的商品配置表。3.3 Google Play 校驗(yàn)與確認(rèn)的 Go 實(shí)現(xiàn)Google 側(cè)的結(jié)構(gòu)比 Apple 干凈先初始化 servicefunc newPublisher(ctx context.Context, saFile string) (*androidpublisher.Service, error) { data, err : os.ReadFile(saFile) if err ! nil { return nil, err } creds, err : google.CredentialsFromJSON(ctx, data, androidpublisher.AndroidpublisherScope) if err ! nil { return nil, err } return androidpublisher.NewService(ctx, option.WithCredentials(creds)) }一次性商品的校驗(yàn)與確認(rèn)func verifyConsumable(ctx context.Context, svc *androidpublisher.Service, pkg, productID, token string) error { purchase, err : svc.Purchases.Products.Get(pkg, productID, token).Context(ctx).Do() if err ! nil { return fmt.Errorf(get product purchase: %w, err) } // purchaseState: 0 未指定 1 已購(gòu)買 2 掛起 if purchase.PurchaseState ! 1 { return fmt.Errorf(purchase state not completed: %d, purchase.PurchaseState) } if purchase.OrderId { return errors.New(empty order id, suspicious) } // 發(fā)貨邏輯放在這里且必須冪等 if err : grantGoods(ctx, purchase.OrderId, productID); err ! nil { return err } // 消耗型商品用 consume它同時(shí)完成確認(rèn) if err : svc.Purchases.Products.Consume(pkg, productID, token).Context(ctx).Do(); err ! nil { return fmt.Errorf(consume: %w, err) } return nil }訂閱的狀態(tài)查詢用的是 v2 接口返回結(jié)構(gòu)比 v1 清晰很多func verifySubscription(ctx context.Context, svc *androidpublisher.Service, pkg, token string) (*androidpublisher.SubscriptionPurchaseV2, error) { sub, err : svc.Purchases.Subscriptionsv2.Get(pkg, token).Context(ctx).Do() if err ! nil { return nil, err } switch sub.SubscriptionState { case SUBSCRIPTION_STATE_ACTIVE, SUBSCRIPTION_STATE_IN_GRACE_PERIOD, SUBSCRIPTION_STATE_CANCELED: // 三種狀態(tài)都要給權(quán)益寬限期和已取消未到期都要算有效 default: return nil, fmt.Errorf(subscription inactive: %s, sub.SubscriptionState) } if sub.AcknowledgementState ACKNOWLEDGEMENT_STATE_PENDING { if err : svc.Purchases.Subscriptions.Acknowledge(pkg, token, androidpublisher.SubscriptionPurchasesAcknowledgeRequest{}). Context(ctx).Do(); err ! nil { return nil, fmt.Errorf(ack: %w, err) } } return sub, nil }這里有個(gè)細(xì)節(jié)值得單獨(dú)說(shuō)SUBSCRIPTION_STATE_CANCELED狀態(tài)的訂閱用戶雖然取消了自動(dòng)續(xù)訂但在當(dāng)前付費(fèi)周期結(jié)束前仍然有權(quán)益。很多實(shí)現(xiàn)只認(rèn) ACTIVE導(dǎo)致用戶一取消就掉權(quán)益被投訴的概率極高。判斷權(quán)益是否有效應(yīng)該看lineItems[].expiryTime那個(gè)時(shí)間沒(méi)到就繼續(xù)給。3.4 聯(lián)調(diào)與沙盒驗(yàn)證Apple 的沙盒環(huán)境需要在設(shè)備上登錄沙盒測(cè)試賬號(hào)這個(gè)賬號(hào)在 App Store Connect 的用戶與訪問(wèn)里創(chuàng)建跟真實(shí) Apple ID 完全隔離。沙盒環(huán)境下訂閱周期會(huì)被大幅壓縮周訂閱 3 分鐘就走完一個(gè)周期方便測(cè)續(xù)訂邏輯。測(cè)試時(shí)建議把續(xù)訂通知的接收方指向一臺(tái)能看日志的機(jī)器觀察整個(gè)周期的事件流。Google 的測(cè)試賬號(hào)在 Play Console 的許可測(cè)試?yán)锱渲门渲弥笥眠@個(gè)賬號(hào)下單不實(shí)際扣款。這里有個(gè)限制測(cè)試購(gòu)買只能走測(cè)試軌道或者內(nèi)部測(cè)試軌道正式軌道上的包不會(huì)用測(cè)試賬號(hào)。聯(lián)調(diào)我一般跑五個(gè)用例跑通了才敢上灰度正常購(gòu)買到賬、重復(fù)上報(bào)同一筆憑據(jù)、平臺(tái)校驗(yàn)接口超時(shí)后補(bǔ)單、退款通知回收到權(quán)益、訂閱跨周期續(xù)訂后權(quán)益續(xù)期。這五個(gè)用例覆蓋了內(nèi)購(gòu) 90% 的故障場(chǎng)景。第一次接入的時(shí)候我在沙盒里反復(fù)跑這五個(gè)跑了大概兩天后來(lái)真上線的時(shí)候確實(shí)沒(méi)出大問(wèn)題。4. 高頻問(wèn)題與排查實(shí)錄4.1 錯(cuò)誤碼速查表Apple 和 Google 的錯(cuò)誤碼如果只看文檔會(huì)很難對(duì)應(yīng)到實(shí)際問(wèn)題我整理了一張按真實(shí)遇到過(guò)的場(chǎng)景歸納的表排查時(shí)對(duì)著看比翻文檔快。平臺(tái)返回常見(jiàn)原因處理方式Apple21000請(qǐng)求體不是合法的 JSON 或 HTTP 方法不對(duì)檢查 Content-Type 和 POST 方法Apple21002收據(jù)數(shù)據(jù)格式異常確認(rèn) base64 沒(méi)被二次編碼或截?cái)郃pple21003收據(jù)無(wú)法通過(guò)認(rèn)證收據(jù)被篡改或來(lái)自不明的應(yīng)用Apple21004共享密鑰不匹配檢查密鑰是否對(duì)應(yīng)當(dāng)前應(yīng)用Apple21005服務(wù)器暫不可用隔 30 秒重試別密集打Apple21006訂閱已過(guò)期正常情況不發(fā)貨即可Apple21007沙盒收據(jù)打到了生產(chǎn)地址降級(jí)到沙盒地址重試Apple21008生產(chǎn)收據(jù)打到了沙盒地址說(shuō)明環(huán)境配置錯(cuò)切回生產(chǎn)Apple21010賬號(hào)不存在或已過(guò)期檢查訂閱是否被 Apple 客服撤銷Google401服務(wù)賬號(hào) token 無(wú)效檢查密鑰 JSON 和系統(tǒng)時(shí)間Google403未授權(quán)或權(quán)限不足Play Console 里補(bǔ)授訂單查詢權(quán)限Google404商品或購(gòu)買記錄不存在productId 拼錯(cuò)或包名不對(duì)Google410purchaseToken 已作廢已被退款或已消耗不發(fā)貨Google429調(diào)用頻率超限加退避別把校驗(yàn)放在循環(huán)里GooglepurchaseState2支付掛起不發(fā)貨物等 RTDN 或客戶端重查GoogleacknowledgementState0未確認(rèn)立即調(diào) acknowledge超過(guò)三天會(huì)退款表里最后兩行是我認(rèn)為最值得單獨(dú)記住的。掛起狀態(tài)如果當(dāng)成失敗直接拒絕用戶付了錢拿不到東西會(huì)來(lái)投訴未確認(rèn)如果忘了調(diào)三天后平臺(tái)自動(dòng)退款用戶白拿資損是靜默發(fā)生的不對(duì)賬根本發(fā)現(xiàn)不了。4.2 那些只有踩過(guò)才知道的坑收據(jù)必須原樣入庫(kù)。一開(kāi)始我覺(jué)得收據(jù)太長(zhǎng)沒(méi)必要存只存交易號(hào)。結(jié)果有一次用戶申訴說(shuō)沒(méi)收到貨平臺(tái)側(cè)顯示已扣款我這邊查不到記錄因?yàn)闆](méi)有原始收據(jù)連手動(dòng)補(bǔ)驗(yàn)都沒(méi)法做?，F(xiàn)在我在訂單表里留了receipt TEXT字段壓縮后存儲(chǔ)成本很低救命的次數(shù)不少。時(shí)間一律用 UTC金額一律用整數(shù)存最小單位。這兩個(gè)規(guī)范不是潔癖是血淚。我們踩過(guò)一次時(shí)區(qū)問(wèn)題Apple 返回的expires_date_ms是毫秒時(shí)間戳轉(zhuǎn)換時(shí)用了本地時(shí)區(qū)在跨境用戶那里算出了負(fù)數(shù)剩余時(shí)間訂閱直接判為過(guò)期。金額用浮點(diǎn)數(shù)存的問(wèn)題更明顯0.1 0.2不等于0.3對(duì)賬時(shí)差幾分錢查到最后是浮點(diǎn)精度。日志要留請(qǐng)求和響應(yīng)原文但要脫敏。排查內(nèi)購(gòu)問(wèn)題 90% 的時(shí)間在比對(duì)報(bào)文沒(méi)有原始報(bào)文基本靠猜。收據(jù)和 purchaseToken 屬于憑據(jù)日志里只打前 8 位加后 4 位共享密鑰絕對(duì)不打。我習(xí)慣在日志里帶一個(gè) traceID從客戶端請(qǐng)求一路串到平臺(tái)接口調(diào)用出問(wèn)題直接 grep。不要在校驗(yàn)鏈路里做耗時(shí)操作。最開(kāi)始我把發(fā)貨邏輯寫(xiě)權(quán)益、發(fā)消息、更新用戶等級(jí)全塞在校驗(yàn)請(qǐng)求里同步做平臺(tái)接口一慢整個(gè)請(qǐng)求就超時(shí)用戶重試又觸發(fā)一次。后來(lái)拆成兩步校驗(yàn)只負(fù)責(zé)寫(xiě)訂單狀態(tài)發(fā)貨走內(nèi)部消息隊(duì)列消費(fèi)端做真正的權(quán)益變更。這樣校驗(yàn)的耗時(shí)穩(wěn)定在 200ms 以內(nèi)用戶體驗(yàn)好很多。訂閱續(xù)訂的通知要做去重。App Store Server Notifications 是至少一次投遞同一條通知可能來(lái)兩次甚至更多。我第一次接的時(shí)候沒(méi)做去重用戶續(xù)費(fèi)一次權(quán)益加了兩次續(xù)了兩個(gè)月。去重鍵用notificationUUID配合唯一索引簡(jiǎn)單有效。別忽略家庭共享和跨區(qū)差異。Apple 的家庭共享會(huì)讓一筆購(gòu)買被多個(gè)賬號(hào)使用收據(jù)里的in_app_ownership_type字段會(huì)標(biāo)成FAMILY_SHARED這時(shí)候要不要給權(quán)益得看你的產(chǎn)品規(guī)則。Google 那邊則要考慮不同國(guó)家地區(qū)的稅率和定價(jià)同一商品在不同地區(qū)的實(shí)際金額差異很大做對(duì)賬時(shí)不能用固定金額比對(duì)。灰度階段先把校驗(yàn)接口的監(jiān)控拉滿。我給校驗(yàn)接口配了四個(gè)指標(biāo)成功率、P95 耗時(shí)、各錯(cuò)誤碼計(jì)數(shù)、沙盒流量占比。沙盒流量占比這個(gè)指標(biāo)特別有用正常生產(chǎn)環(huán)境的沙盒流量應(yīng)該是 0一旦冒出來(lái)說(shuō)明有測(cè)試包泄到了正式環(huán)境或者有用戶在偽造沙盒收據(jù)——兩種情況都得立刻看。最后分享一個(gè)我在架構(gòu)上的取舍。這套東西現(xiàn)在的形態(tài)是一個(gè)獨(dú)立的支付服務(wù)對(duì)外只暴露兩個(gè) RPCVerify和Query。所有平臺(tái)差異都收斂在服務(wù)內(nèi)部業(yè)務(wù)方不需要知道是 Apple 還是 Google。商品配置也放在這個(gè)服務(wù)里一個(gè) product_id 對(duì)應(yīng)一份權(quán)益描述業(yè)務(wù)方只按 product_id 領(lǐng)取。這么做的好處是以后接第三個(gè)平臺(tái)業(yè)務(wù)側(cè)一行代碼都不用動(dòng)。代價(jià)是支付服務(wù)成了關(guān)鍵路徑所以它的可用性要求比其他服務(wù)高一個(gè)等級(jí)我給它配了獨(dú)立的數(shù)據(jù)庫(kù)實(shí)例和獨(dú)立的告警通道寧可多花點(diǎn)資源也不想再經(jīng)歷一次支付不可用導(dǎo)致的全局故障。