**沙箱限制：**在開發沙箱中消耗開發人員管理的消耗性產品時，僅支援 XSTS 權杖驗證。在沙箱環境中，User Store ID 或 Microsoft Entra ID 驗證不適用於開發人員管理之消耗性產品的消耗呼叫。請據此規劃您的測試。如需詳細資訊，請參閱 Consume API 的必要條件一節。
使用 Microsoft.StoreServices .NET 程式庫和範例
為協助示範本文所概述的原則和流程，請檢閱 Microsoft.StoreServices 範例，其中提供：- 使用 Microsoft.StoreServices 程式庫管理驗證，並呼叫 Microsoft Store 服務。
- 管理消耗性產品、追蹤擱置中的消耗要求、調節已退款的購買、更新已過期的 User Store ID 等的範例邏輯。
- 設定指南，其中包含本文中關於如何針對此驗證方法設定您的 Microsoft Entra ID 的步驟。
- Microsoft.StoreServices (GitHub)
- Microsoft.StoreServices 範例 (GitHub)
管理消耗性產品
消耗性產品管理服務的建議大綱
使用單一伺服器流程來驗證擁有權、履行使用並調節退款。下列大綱可讓這些職責清楚明確且可安全重試。在您的服務上管理使用者餘額與在 Microsoft Store 上管理
Store 管理的消耗性產品可以透過從 Microsoft Store 消耗任何非零餘額，完全在您的遊戲服務上管理。或者，也可以透過 Microsoft Store 管理使用者的消耗性產品餘額，只在用於遊戲內項目時才消耗數量。不過，開發人員管理的消耗性產品需要在遊戲服務上管理。如需開發人員管理與 Microsoft Store 管理之消耗性產品的詳細資訊，請參閱選擇適當的產品類型。 最常見的方法是在您的服務上追蹤使用者的有效貨幣餘額。在此設計中，您的服務會查詢非零的消耗性產品餘額、加以消耗，然後將等值的遊戲內貨幣存入使用者的帳戶。此流程可減少履行後重複呼叫 Store API、簡化跨平台餘額處理，並為支援團隊提供調整餘額的中央系統。 典型設定：將每個貨幣層級設定為個別的 Store 管理消耗性產品，每次購買授予數量1，然後將每個產品對應至其遊戲內價值。範例：「500 金幣」消耗性產品會將 Store 數量增加為 1；消耗之後，Store 數量會回到 0，而您的服務會存入 500 金幣。
Store 管理的消耗性產品可以在購買時直接將完整價值授予 Store 數量 (例如，每次購買 500)。在該模型中，Store 會追蹤餘額成長，而您的服務會在使用者於遊戲中花費貨幣時扣除數量。不過，將所有層級都設為單一產品識別碼下的 SKU，會限制特定層級促銷定價和 5x5 兌換權杖等功能。請參閱提供遊戲內貨幣的最佳做法。
使用 TrackingId 作為消耗驗證的備援系統
在每個消耗要求中包含TrackingId。如果回應遺失，請使用相同的 TrackingId、使用者、productId 和數量重試，以確認原始消耗是否成功。此重試要求可防止重複授予，同時仍允許安全重試。
下列流程顯示可安全重試的消耗模式。
產品 A (500 遊戲內金幣) 是一個設定為在 Store 內授予數量 1 的消耗性產品。
- 使用者購買產品 A，現在呼叫查詢服務時，該產品的數量為
1。 - 遊戲的服務在 Microsoft Store 查詢 API 中查詢使用者的消耗性產品餘額，看到使用者的餘額為
1。 - 遊戲服務產生 TrackingID，建立消耗一個產品數量的消耗要求，並將要求資訊新增至擱置中交易清單。
- 遊戲服務將要求傳送至 Microsoft Store 消耗 API。
- 遊戲服務無法取得消耗 API 回應 (網路封包遺失、服務中斷、斷電等)。此時，服務無法確認交易是否已完成。如果使用者在中斷期間再次購買，僅查詢存貨可能會造成混淆。請使用擱置中交易清單，並以相同的要求值重試。
- 遊戲服務決定何時應重試消耗要求。
- 遊戲服務使用相同的使用者、ProductId、TrackingId 和數量重新建立消耗要求。
- 遊戲服務將要求傳送至 Microsoft Store 消耗 API。
- 遊戲服務收到回應，指出要求成功且使用者的新餘額為 ‘0’。
- 遊戲服務將 500 金幣加入伺服器上追蹤的使用者貨幣餘額。
- 由於項目已被消耗、驗證，且使用者已在服務上獲得正確的遊戲內貨幣，遊戲服務會從擱置中交易清單移除該消耗要求。
驗證先前交易要求時 Microsoft Store Consume API 的行為
如果要求帶有不同的值，API 會將其視為新的消耗要求。 如果 API 偵測到使用相同TrackingId、使用者、數量和 productId 的重試，就不會再次消耗。而是會傳回包含目前剩餘餘額的成功回應。由於此行為，只要要求值完全相同，重新傳送逾時的要求就是安全的。
如果您對消耗 API 使用 X-Token 驗證，只要新的 X-Token 與先前要求屬於同一個 XBOX 使用者，您就可以更新並取得新的 X-Token。
使用 Clawback 事件服務減少消耗性產品的退貨和退款詐騙
為協助防止消耗性產品遭到濫用及詐騙性退貨或退款，您的服務應使用 Clawback 事件服務。Clawback 可讓您的服務在消耗性產品遭到退貨或退款時收到事件。您的服務應從使用者的帳戶中移除該消耗性產品所增加的價值。 若要針對 Clawback 事件採取動作，請確保您在傳送至 collections.mp.microsoft.com/v8.0/collections/consume 的消耗要求中使用"includeOrderIds": TRUE 選項。您的服務應使用下列變數儲存 API 回應中的消耗交易資料：
請及早設定此追蹤資料庫，最好在加入 Clawback 佇列之前完成。及早取得的資料可為您提供歷史交易以供日後調節，並提供乾淨的基準來衡量 Clawback 處理的影響。
如需詳細資訊，請參閱從您的服務管理退款與退單。