在集成和調試訂閱型商品時，我們會依賴沙盒環境來進行模擬實際場景。 訂閱型商品的購買流程和一次性商品的購買流程類似，但訂閱還有其他細節場景，比如續訂成功或失敗，續訂周期時長等。沙盒環境下的訂閱續訂時間會比正常情況更快，引入“時光機”概念幫助您快速測試您應用的訂閱場景。比如訂閱周期為1周，商品在3分鐘後 ...
在集成和調試訂閱型商品時，我們會依賴沙盒環境來進行模擬實際場景。
訂閱型商品的購買流程和一次性商品的購買流程類似，但訂閱還有其他細節場景，比如續訂成功或失敗，續訂周期時長等。沙盒環境下的訂閱續訂時間會比正常情況更快，引入“時光機”概念幫助您快速測試您應用的訂閱場景。比如訂閱周期為1周，商品在3分鐘後發生續期，此時訂閱型商品有效期延長了3分鐘。
下麵對沙盒環境和現網環境訂閱通知事件進行簡單對比，針對兩種環境下收到的notificationType事件進行對照。
a) 撤銷訂閱
測試一：購買商品後，在自動續費前撤銷訂閱：
測試二：購買商品後，商品到期併發生自動續期後再撤銷原訂閱：
總結：沙盒環境、現網環境對於撤銷訂閱後，訂閱商品都立即消失，同時這筆訂閱費都用會立刻發起返還，後續不再自動續期。訂閱通知事件上，由於沙盒環境採用了時光機概念，短期內會多次收到續期成功的訂閱事件通知。
b) 設置暫停計劃
** 場景分析**
正式環境下:
7月28號14：27首次購買周卡，返回訂閱關鍵事件0。0表示首次購買。
7月28號14：28取消訂閱，返回訂閱關鍵事件5。5表示訂閱停止。
7月28號14：29恢復訂閱，返回訂閱關鍵事件6，恢復訂閱。
7月28號14：29設置暫停計劃一周，返回訂閱關鍵事件11，11表示設置了暫停續期計劃(包括暫停計劃的創建、修改以及在暫停計劃生效前的計劃終止)。
8月5號13：27進入暫停期，原訂閱是7月28號購買的周卡，到期時間是8月4號，8月5號進入暫停期，收到通知10。
8月8號09：17恢復續訂，此時商品已到期，收到關鍵事件通知3、6。3表示恢復一個已過期的訂閱，6表示續期恢復正常。
沙盒環境下：
9月20號10：17首次購買半年卡，返回訂閱關鍵事件0。0表示首次購買，與正式環境一致。
9月20號10：18取消訂閱，返回訂閱關鍵事件5。與正式環境一致。
9月20號10：19恢復訂閱，返回訂閱通知6和7，與正式環境多返回通知7，這個沙盒設置如此，正式環境不受影響。
9月20號10：19設置暫停25分鐘，返回訂閱通知11（表示創建、暫停計劃生效前終止）。商品11：17分到期後進入暫停期25分鐘。
沙盒下進入暫停期沒有收到關鍵事件通知10。是因為暫停和過期事件是通過事後檢查發現的，目前是通過每日檢查發現訂閱進入暫停期或是過期。由於沙盒周期短，在次日檢查時周期已經結束，所以沒有10的事件通知，正式環境下正常。
9月20號11：25在暫停期內，手動恢復續訂，返回訂閱通知3和6，與正式環境一致。
之後每隔半小時自動續訂一次。
瞭解更多詳情>>
訪問華為開發者聯盟官網
獲取開髮指導文檔
華為移動服務開源倉庫地址：GitHub、Gitee
關註我們，第一時間瞭解 HMS Core 最新技術資訊~
