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