מחזור החיים של מינוי

רכישות של מינויים יכולות לעבור כמה מצבים שונים במהלך מחזור החיים שלהן, בהתאם לגורמים רבים, כולל התנהגות החידוש האוטומטי, מצבים של דחיית תשלום ופעולות ניהול של המפתחים.

ניהול מחזור החיים של מינויים שמתחדשים אוטומטית

כשמצב המינוי של משתמש משתנה, שרת הקצה העורפי מקבל הודעת SubscriptionNotification

איור 1. מצבי מחזור חיים ואירועי מעבר לרכישות של מינויים עם חידוש אוטומטי.

כדי לעדכן את המצב בקצה העורפי, צריך להפעיל את ה-API של purchases.subscriptionsv2.get עם אסימון הרכישה שכלול בהתראה. נקודת הקצה הזו מספקת את המצב העדכני של המנוי לפי טוקן הרכישה, והיא נחשבת למקור האמין לניהול המינויים.

אסימון הרכישה תקף מההרשמה למינוי ועד 60 יום לאחר התפוגה. אחרי התאריך הזה, לא ניתן יהיה להשתמש באסימון הרכישה כדי לבצע קריאה ל-Google Play Developer API.

רכישות חדשות של מינויים מתחדשים אוטומטית

כשמשתמש רוכש מינוי, נשלחת הודעה מסוג SubscriptionNotification‏ SUBSCRIPTION_PURCHASED ללקוח ה-RTND. בין שאתם מקבלים את ההתראה הזו ובין שאתם רושמים רכישה חדשה באפליקציה דרך PurchasesUpdatedListener או אחזור ידני של רכישות בשיטה onResume() של האפליקציה, עליכם לעבד את הרכישה החדשה בקצה העורפי המאובטח. לשם כך, בצע את הצעדים הבאים:

  1. שולחים שאילתה לנקודת הקצה purchases.subscriptionsv2.get כדי לקבל משאב מינוי שמכיל את מצב המינוי העדכני.
  2. מוודאים שהערך בשדה subscriptionState הוא SUBSCRIPTION_STATE_ACTIVE.
  3. מאמתים את הרכישה.
  4. נותנים למשתמש גישה לתוכן. אפשר לזהות את חשבון המשתמש שמשויך לרכישה באמצעות האובייקט ExternalAccountIdentifiers במשאב המינוי, אם מזהים הוגדרו בזמן הרכישה באמצעות setObfuscatedAccountId ו-setObfuscatedProfileId.

ב-Play Billing Library יש גם שיטה לאישור מינוי, acknowledgePurchase(), ושיטה לבדיקת סטטוס האישור, isAcknowledged(). עם זאת, מומלץ לטפל בעיבוד הרכישות בקצה העורפי כדי לשפר את האבטחה.

משאב המינוי לרכישות חדשות נראה דומה לדוגמה הבאה:

{
  "kind": "androidpublisher#subscriptionPurchaseV2",
  "startTime": "2022-04-22T18:39:58.270Z",
  "regionCode": "US",
  "subscriptionState": "SUBSCRIPTION_STATE_ACTIVE",
  "latestOrderId": "GPA.3333-4137-0319-36762",
  "acknowledgementState": "ACKNOWLEDGEMENT_STATE_PENDING", // need to acknowledge new purchases
  "lineItems": [
    {
      "productId": "sub_variant_plan01",
      "expiryTime": next_renewal_date,
      "autoRenewingPlan": {
        "autoRenewEnabled": true
      }
    }
  ],
}

חידושים של מינויים

למינוי ללא תשלומים שמתחדש באופן אוטומטי, נשלחת התראה SUBSCRIPTION_RENEWED כשהמינוי מתחדש. למינוי בתשלומים, נשלחת התראה SUBSCRIPTION_RENEWED בכל פעם שמתבצע חיוב על המינוי בתאריך החיוב שלו. מוודאים שהמשתמש עדיין זכאי למינוי, ומעדכנים את מצב המינוי באמצעות הערך החדש של expiryTime שמופיע במשאב המינוי שמוחזר מ-Google Play Developer API. משאב המינוי נראה כך:

{
  "kind": "androidpublisher#subscriptionPurchaseV2",
  "startTime": "2022-04-22T18:39:58.270Z",
  "regionCode": "US",
  "subscriptionState": "SUBSCRIPTION_STATE_ACTIVE",
  "latestOrderId": "GPA.3333-4137-0319-36762",
  "acknowledgementState": "ACKNOWLEDGEMENT_STATE_ACKNOWLEDGED",
  "lineItems": [
    {
      "productId": "sub_variant_plan01",
      "expiryTime": next_renewal_date,
      "autoRenewingPlan": {
        "autoRenewEnabled": true
      }
    }
  ]
}

אין צורך לאשר את חידוש המינויים.

תקופת חסד

אם יש בעיות בתשלום במהלך חידוש המינוי, Google תודיע למשתמש ותנסה מדי פעם לחדש את המינוי זמן מה לפני שתוקף המינוי יפוג. תקופת ההחלמה יכולה לכלול תקופת חסד ואחריה תקופת השהיית החשבון. במהלך תקופת החסד, למשתמש עדיין אמורה להיות גישה לזכויות המינוי שלו.

השיטה queryPurchasesAsync() ממשיכה להחזיר רכישות שנמצאות בתקופת החסד. אם האפליקציה שלכם מסתמכת רק על queryPurchasesAsync כדי לבדוק אם משתמש זכאי למינוי, האפליקציה אמורה לטפל באופן אוטומטי בתקופות החסד, כי המינויים האלה מוצגים כפעילים דרך ספריית החיוב ב-Play.

סנכרון מצב המינוי עם הקצה העורפי מאפשר לכם לקבל מידע נוסף על דחיות תשלומים, ומספק הקשר נוסף כשאתם מנסים לצמצם את שיעור נטישת הלקוחות הלא מרצון. כדי לקבל התראה כשהמשתמש נכנס לתקופת חסד, אפשר להאזין להודעות SubscriptionNotification מסוג SUBSCRIPTION_IN_GRACE_PERIOD. בזמן שהמשתמש נמצא בתקופת חסד, משאב המינוי מכיל את הערך autoRenewEnabled = true. מערכת Google Play מרחיבה באופן דינמי את הערך של expiryTime עד שתקופת החסד תסתיים, כי ההרשאה אמורה להימשך עד שהמשתמש יבטל אותה או עד שתקופת החסד תסתיים לאחר פרק הזמן המקסימלי שלה. הערך של השדה subscriptionState בתקופה הזו הוא SUBSCRIPTION_STATE_IN_GRACE_PERIOD. משאב המינוי נראה כך:

{
  "kind": "androidpublisher#subscriptionPurchaseV2",
  ...
  "subscriptionState": "SUBSCRIPTION_STATE_IN_GRACE_PERIOD",
  ...
  "lineItems": [
    {
      "productId": "sub_variant_plan01",
      "expiryTime": timestamp_in_future,
      "autoRenewingPlan": {
        "autoRenewEnabled": true
      }
    }
  ],
}

משתמשים שנמצאים בתקופת חסד יקבלו הודעה מ-Play על כך שהתשלום שלהם נדחה, ויידרשו לפתור את הבעיות באמצעי התשלום בחנות Play. כשמשתמש נכנס לתקופת חסד, כדאי גם לעודד אותו לתקן את אמצעי התשלום במקרה שהכשל היה לא מכוון. דרך פשוטה לעשות זאת היא להשתמש ב-In-App Messaging API. אם תפעילו את ה-API הזה כשהמשתמש יפתח את האפליקציה, תוצג לו הודעה מ-Play בסרגל ההודעות הזמני, שבה יצוין שהתשלום שלו נדחה. ההודעה הזו כוללת גם קישור עומק שמאפשר למשתמש לתקן את אמצעי התשלום ב-Google Play.

ברגע שהמשתמש יטפל באמצעי התשלום, המינוי יתחדש בתאריך החידוש המקורי, ותוכלו לטפל בחידוש כפי שמתואר בקטע חידושים.

אם המשתמש לא יתקן את אמצעי התשלום במהלך תקופת החסד, המינוי ייכנס להחזקה בחשבון והמשתמש יאבד את הזכאות.

גישה ושחזור בתקופת החסד

באיור 2 מוצג ציר זמן של מינוי שנכנס לתקופת חסד ולאחר מכן מתאושש כשהמשתמש מתקן את אמצעי התשלום שלו. בתום תקופת החסד, המשתמש אמור לאבד את ההטבות של המינוי ולהיכנס למצב של השהיה של החשבון.

איור 2. ציר זמן של מינוי שנכנס לתקופת חסד ומתאושש לפני שהיא מסתיימת.

חשוב לזכור את הנקודות הבאות:

  • במהלך תקופת החסד, המשתמש אמור לשמור על הגישה להטבות המינוי.
  • כשמינוי מתאושש במהלך תקופת החסד, תאריך החידוש לא מתאפס.
  • אם תגדילו את תקופת החסד – לדוגמה, מ-7 ימים ל-14 ימים – המשתמשים שנמצאים בתקופת החסד יקבלו גישה מורחבת להטבות המינוי.
  • אם תקצרו את תקופת החסד, ההטבות של המינויים של משתמשים שנמצאים עמוק מספיק בתקופת החסד הישנה ויחרגו מתקופת החסד החדשה יבטלו באופן מיידי. לדוגמה, אם מקצרים את תקופת החסד מ-14 יום ל-7 ימים, ההטבות של המינויים של משתמשים שנמצאים בימים 8 עד 14 של תקופת החסד הישנה יבטלו באופן מיידי.
  • המינוי יישאר במצב פעיל ולא תקבלו RTDN לתקופת החסד עד לסיום תקופת החסד השקטה

תקופת חסד שקטה

אפשר להגדיר תקופת חסד של 0 ימים, אבל Play ימתין לפחות יום אחד כדי לוודא שיש מספיק זמן לניסיונות חוזרים של תשלום. תקופת החסד השקטה הזו מספקת רשת ביטחון לעיבוד התשלומים. במהלך 24 השעות האלה, המינוי יישאר בסטטוס ACTIVE.

הדרך הטובה ביותר לשמור על סנכרון עם השינויים במצב המינוי היא להקשיב להתראות בזמן אמת למפתחים (RTDN) ולהגיב להן. כדי לקבל סטטוס מדויק יותר של המינוי, צריך להפעיל את השיטה purchases.subscriptionsv2.get() בזמן ה-RTDN במקום בזמן התפוגה.

בהתאם לסטטוס המינוי אחרי תקופת החסד השקטה של 24 שעות, אמורה להגיע אחת מההתראות הבאות:

  • SUBSCRIPTION_ON_HOLD (אם התכונה מופעלת)
  • SUBSCRIPTION_CANCELED (אם בוטל)
  • SUBSCRIPTION_EXPIRED (אם התוקף פג)
  • SUBSCRIPTION_RENEWED (אם החידוש בוצע בהצלחה)

אפשר גם להפעיל את השיטה subscriptionV2.get() בכל שלב אחרי תקופת החסד השקטה של 24 שעות כדי לקבל את הסטטוס העדכני של המינוי.

השעיית חשבון

אם יש בעיות בתשלום של חידוש המינוי, אחרי שתקופת החסד תסתיים, תתחיל תקופת השהיה של החשבון. כשמינוי נכנס להשהיה של החשבון, צריך לחסום את הגישה להרשאה למינוי.

במהלך ההשהיה של החשבון, עליכם להמשיך לטפל בביטולים, בשחזור או ברכישה מחדש של המינויים לפי הצורך, כי המשתמש יכול לבצע את השינויים האלה בזמן שהמינוי בהשהיה.

הודעות RTDN מאפשרות לכם לדעת מתי המשתמש נכנס לתקופת ההשהיה של החשבון, כדי שתוכלו להודיע לו בהקדם האפשרי למה הגישה שלו למינוי הושעתה. דרך פשוטה לעשות זאת היא להשתמש ב-In-App Messaging API. קריאה ל-API הזה כשהמשתמש פותח את האפליקציה תציג לו הודעה בסרגל ההודעות הזמני על כך שהתשלום שלו נדחה. ההודעה הזו כוללת גם קישור עומק שמאפשר למשתמש לתקן את אמצעי התשלום ב-Google Play.

אם המשתמשים יכולים לגשת לתוכן המנויים מחוץ לאפליקציה, יכול להיות שהם יגלו שהם איבדו את הגישה בפלטפורמות שונות. מומלץ לשלוח התראה או אימייל למשתמש כדי להודיע לו שהמינוי שלו לא פעיל יותר בגלל דחיית התשלום.

המינוי לא מוחזר באמצעות השיטה queryPurchasesAsync() במהלך השהיית החשבון, לכן אם האפליקציה שלכם מסתמכת על השיטה הזו כדי להציג רכישות קיימות, עליכם לתמוך בהשהיית החשבון כברירת מחדל.

כשמשתמשים בהתראות בזמן אמת למפתחים, מקבלים הודעת SubscriptionNotification מסוג SUBSCRIPTION_ON_HOLD כשמינויים נכנסים להחזקה בחשבון. קוראים לשיטה purchases.subscriptionsv2.get משרת הקצה העורפי המאובטח כדי לאחזר את פרטי המינוי החדשים. במהלך השהיית החשבון, השדה expiryTime של משאב המינוי מוגדר לחותמת זמן קודמת, והשדה subscriptionState מוגדר ל-SUBSCRIPTION_STATE_ON_HOLD:

{
  "kind": "androidpublisher#subscriptionPurchaseV2",
  ...
  "subscriptionState": "SUBSCRIPTION_STATE_ON_HOLD",
  ...
  "lineItems": [
    {
      "productId": "sub_variant_plan01",
      "expiryTime": timestamp_in_past,
      ...
    }
  ],
}

כדי לשחזר את הגישה, המשתמשים צריכים לתקן את אמצעי התשלום. מערכת Play תודיע למשתמשים שהתשלום שלהם נדחה, וגם אתם צריכים לעודד אותם לתקן את אמצעי התשלום.

אחרי שהמשתמש יתקן את אמצעי התשלום, המינוי יחזור למצב פעיל, ואז תצטרכו לשחזר את הגישה לתוכן שאליו המשתמש נרשם. במקרה כזה, אסימון הרכישה זהה לאסימון שהיה לפני תחילת האישור וההחזקה (authorization hold) בחשבון, כי מתבצע שחזור של אותה רכישה, ומקבלים RTDN מסוג SUBSCRIPTION_RECOVERED.

במינויים בתשלומים, ייתכן שיהיו דחיות ותשלומים חוזרים בכל ניסיון תשלום ספציפי.

אחרי השחזור, ספריית החיובים ב-Play מחזירה את המינוי שוב באמצעות השיטה queryPurchasesAsync(). אם אתם משתמשים בשיטה הזו כדי לקבוע אם משתמש זכאי למינוי, האפליקציה שלכם אמורה לטפל באופן אוטומטי בשחזור המינוי לאחר השהיית החשבון.

כדי לקבל התראה כשמינוי יתוקן והמשתמש יוכל לקבל שוב גישה, צריך להאזין להודעה מסוג SubscriptionNotification עם הסוג SUBSCRIPTION_RECOVERED. אם שולחים שאילתה לגבי המינוי אחרי קבלת ההתראה הזו, השדה expiryTime מוגדר לחותמת זמן בעתיד והשדה subscriptionState מוגדר שוב ל-SUBSCRIPTION_STATE_ACTIVE:

{
  "kind": "androidpublisher#subscriptionPurchaseV2",
  ...
  "subscriptionState": "SUBSCRIPTION_STATE_ACTIVE",
  ...
  "lineItems": [
    {
      "productId": "sub_variant_plan01",
      "expiryTime": next_renewal_date,
      ...
    }
  ],
}

אם המשתמש לא יתקן את אמצעי התשלום לפני סיום תקופת האישור וההחזקה של החשבון, תקבלו במקום זאת הודעת RTDN מסוג SUBSCRIPTION_CANCELED. הוראות לטיפול בביטולים מפורטות במאמר ביטולים. כששולחים שאילתה לגבי מינוי שבוטל באופן הזה, השדה expiryTime מוחזר עם חותמת זמן קודמת:

{
  "kind": "androidpublisher#subscriptionPurchaseV2",
  ...
  "subscriptionState": "SUBSCRIPTION_STATE_CANCELED",
  ...
  "lineItems": [
    {
      "productId": "sub_variant_plan01",
      "expiryTime": timestamp_in_past,
      ...
    }
  ],
}

מיד אחרי שתקבלו הודעה על הביטול במהלך השהיית החשבון, תקבלו גם אירוע RTDN מסוג SUBSCRIPTION_EXPIRED כי פג התוקף של המינוי בתשלום של המשתמש והוא בוטל. אתם יכולים לטפל בתוקף התפוגה הזה כמו שאתם עושים בדרך כלל.

המשתמש יכול לקבל שוב גישה על ידי רכישה מחדש של אותו מינוי או של כל מינוי אחר שאתם מציעים דרך האפליקציה במהלך תקופת ההחזקה של החשבון מהרכישה המקורית. במקרה כזה, יונפק אסימון רכישה חדש והערך החדש יוחזר כחלק מאירוע SUBSCRIPTION_PURCHASED שמייצג את המופע החדש.

גישה לחשבון בהשהיה ושחזור

באיור 3 מוצג ציר זמן של מינוי שנכנס להשהיית חשבון ולאחר מכן משוחזר כשהמשתמש מתקן את אמצעי התשלום שלו.

איור 3. ציר זמן של מינוי שנכנס להשהיית חשבון ומתוקן לפני שההשהיה מסתיימת.

בדומה לדוגמה הקודמת, באיור 4 מוצג ציר זמן של מינוי שמתחיל בתקופת החסד לפני שהוא עובר להחזקה בחשבון, ולאחר מכן מתאושש במהלך ההחזקה.

איור 4. ציר זמן של מינוי שנכנס לתקופת חסד, לאחר מכן להשהיית חשבון ולבסוף שחזור לפני שההשהיה תסתיים.

חשוב לזכור את הנקודות הבאות:

  • לפני שמינוי נכנס להחזקה בחשבון, מערכת Google Play תנסה לחייב את אמצעי התשלום במשך עד 48 שעות. המשתמש ימשיך ליהנות מההטבות של המינוי במהלך התקופה הזו. לאחר תקופת הניסיון החוזר, המינוי יועבר להשהיית החשבון והמשתמש אמור לאבד את הגישה להטבות המינוי.
  • המינוי עובר להשהיית חשבון ישירות כשהוא מתחיל מחדש ממצב השהיה עם אמצעי תשלום כושל.
  • כשמינוי חוזר לפעילות לאחר השהיית החשבון, תאריך החידוש מתאפס.

זמני תפוגה

אחרי שתוקף המינוי יפוג, המשתמש אמור לאבד את הגישה למינוי. במקרה כזה, נשלחת הודעה מסוג SubscriptionNotification עם הערך SUBSCRIPTION_EXPIRED. כשמקבלים את ההתראה הזו, צריך לשלוח שאילתה ל-Google Play Developer API כדי לקבל את משאב המינוי העדכני ביותר. אחרי שמוודאים שהערך של subscriptionState הוא SUBSCRIPTION_STATE_EXPIRED, מסירים את ההרשאה ומעדכנים את סטטוס הרכישה כ'לא תקין' בקצה העורפי. משאב המינוי נראה כך:

{
  "kind": "androidpublisher#subscriptionPurchaseV2",
  ...
  "subscriptionState": "SUBSCRIPTION_STATE_EXPIRED",
  ...
  "lineItems": [
    {
      "productId": "sub_variant_plan01",
      "expiryTime": expiration_time_in_past,
      ...
    }
  ],
}

ביטולים

משתמשים יכולים לבטל מינוי מרצונם במרכז המינויים של Play, או שהמינוי שלהם יבוטל באופן אוטומטי אם הם לא ישחזרו את החשבון אחרי החזקה בחשבון. מפתחים יכולים גם להפעיל ביטול באמצעות purchases.subscriptions.cancel. כשמינוי מבוטל, המשתמש שומר על הגישה לתוכן עד לסיום מחזור החיובים הנוכחי. בסיום מחזור החיובים, צריך לבטל את הגישה.

ביטול של מינוי מתחדש אוטומטית ללא תשלומים מפעיל התראה מסוג SUBSCRIPTION_CANCELED. כשמקבלים את ההתראה הזו, השדה subscriptionState במשאב המינוי שמוחזר מ-Google Play Developer API מוגדר כ-SUBSCRIPTION_STATE_CANCELED, והשדה expiryTime מכיל את התאריך שבו המשתמש אמור לאבד את הגישה למינוי. אם התאריך הזה כבר חלף, המשתמש אמור לאבד את ההרשאה באופן מיידי. לדוגמה, המצב הזה יכול לקרות אם משתמש מבטל מינוי בזמן שהחשבון שלו מושהה בגלל דחיית תשלום.

משאב המינוי לרכישה שבוטלה נראה דומה לדוגמה הבאה:

{
  "kind": "androidpublisher#subscriptionPurchaseV2",
  ...
  "subscriptionState": "SUBSCRIPTION_STATE_CANCELED",
  ...
  "lineItems": [
    {
      "productId": "sub_variant_plan01",
      "expiryTime": expiration_time,
      ...
    }
  ],
}

במינויים בתשלומים, תישלח התראה מסוג SUBSCRIPTION_CANCELLATION_SCHEDULED במקרה של ביטול ביוזמת המשתמש, אם עדיין יש תשלומים שנותרו לתקופת ההתחייבות. הביטול נמצא בהמתנה ויכנס לתוקף בסוף תקופת ההתחייבות הנוכחית. כשמקבלים את ההתראה הזו, השדה subscriptionState של משאב המינוי שמוחזר מ-Google Play Developer API מוגדר כ-SUBSCRIPTION_STATE_ACTIVE כי המינוי בתשלומים עדיין פעיל עד לסיום תקופת ההתחייבות. עם זאת, יש אובייקט ריק של pendingCancellation. תישלח התראה מסוג SUBSCRIPTION_CANCELED ולאחר מכן התראה מסוג SUBSCRIPTION_EXPIRED בסוף תקופת ההתחייבות.

משאב המינוי לרכישת מינוי בתשלומים שנמצא בהמתנה לביטול נראה כך:

{
  "kind": "androidpublisher#subscriptionPurchaseV2",
  ...
  "subscriptionState": "SUBSCRIPTION_STATE_ACTIVE",
  ...
  "lineItems": [
    {
      "productId": "sub_plan01",
      "expiryTime": expiration_time,
      "autoRenewingPlan": {
        "autoRenewEnabled": true,
        "recurringPrice": {
          "currencyCode": "USD",
          "units": "1",
          "nanos": 990000000
        },
        "installmentDetails": {
          "initialCommittedPaymentsCount": 6,
          "remainingCommittedPaymentsCount": 5,
          "pendingCancellation": {}
      ...
        }
      }
    }
  ],
}

אפשר לעיין בשדה canceledStateContext במשאב המינוי כדי לבדוק למה המינוי בוטל (לדוגמה, אם המינוי בוטל על ידי המשתמש, על ידי המערכת או על ידכם). אם המשתמש ביטל את המינוי, תוכלו לבדוק את השדה userInitiatedCancellation כדי לראות למה הוא ביטל אותו. המידע הזה יכול לעזור לכם לגבש אסטרטגיות תקשורת.

אם מינוי בוטל אבל עדיין לא פג תוקפו, הוא עדיין מוחזר מ-queryPurchasesAsync(). מומלץ להציג באפליקציה הודעה שמעדכנת את המשתמש על ביטול המינוי ומציינת את תאריך התפוגה.

ביטולים

אפשר לבטל מינוי מסיבות שונות, כולל ביטול המינוי על ידי הקצה העורפי באמצעות purchases.subscriptionsv2.revoke או החזר כספי על הרכישה. במקרה כזה, צריך לבטל את ההרשאה של המשתמש באופן מיידי. במקרה כזה, נשלחת הודעה מסוג SubscriptionNotification עם הערך SUBSCRIPTION_REVOKED. כשמקבלים את ההתראה הזו, השדה subscriptionState במשאב המינוי שמוחזר מ-Google Play Developer API מוגדר כ-SUBSCRIPTION_STATE_EXPIRED.

משאב המינוי לרכישה שבוטלה נראה דומה לדוגמה הבאה:

{
  "kind": "androidpublisher#subscriptionPurchaseV2",
  ...
  "subscriptionState": "SUBSCRIPTION_STATE_EXPIRED",
  ...
  "lineItems": [
    {
      "productId": "sub_variant_plan01",
      "expiryTime": expiration_time,
      ...
    }
  ]
}

מינויים שמושהים

יש כמה סיבות לכך שתרצו להאריך את התוקף של ההרשאה של משתמש. לדוגמה, יכול להיות שתרצו להציע למשתמשים גישה בחינם כמבצע מיוחד, כמו שבוע חינם ברכישת סרט או גישה בחינם ללקוחות כמחווה של רצון טוב. אפשר להשתמש ב-method‏ purchases.subscriptions.defer מ-Play Developer API כדי לקדם את תאריך החיוב הבא של מינוי שמתחדש באופן אוטומטי. הפעולה הזו תגרום לשליחת הודעת SubscriptionNotification מסוג SUBSCRIPTION_DEFERRED. במהלך תקופת ההשהיה, המשתמש יהיה רשום למינוי לתוכן שלכם עם גישה מלאה, אבל לא יחויב. תאריך החידוש של המינוי מתעדכן בהתאם לתאריך החדש.

בתוכניות בתשלום מראש, אפשר להשתמש ב-defer billing API כדי לדחות את מועד התפוגה.

משאב המינוי של מינוי נדחה נראה דומה לדוגמה הבאה:

{
  "kind": "androidpublisher#subscriptionPurchaseV2",
  ...
  "subscriptionState": "SUBSCRIPTION_STATE_ACTIVE",
  ...
  "lineItems": [
    {
      "productId": "sub_variant_plan01",
      "expiryTime": timestamp_in_future,
      ...
    }
  ],
}

מינויים שהושהו

ניתן להפחית נטישה מכוונת כשמאפשרים למשתמשים להשהות את המינוי. כשמפעילים את תכונת ההשהיה, המשתמשים יכולים להשהות את המינוי לפרק זמן של שבוע עד שלושה חודשים, בהתאם לתקופת החידוש.

תדירות המינוי כל שבוע חודשי לשלושה חודשים לשישה חודשים שנתי
משכי ההשהיה הזמינים* שבוע אחד
שבועיים
3 שבועות
4 שבועות		 חודש אחד
חודשיים
3 חודשים		 חודש אחד
חודשיים
3 חודשים		 חודש אחד
חודשיים
3 חודשים		 לא רלוונטי
*המחירים עשויים להשתנות בכל שלב.

השהיה של מינוי תכנס לתוקף רק בסיום תקופת החיוב הנוכחית. כשהמינוי מושהה, למשתמש אין גישה למינוי והוא לא משלם את מחיר החידוש. בסיום תקופת ההשהיה, המינוי יחודש ו-Google תנסה לחדש אותו. אם ההמשך יושלם בהצלחה, המינוי יחזור להיות פעיל. אם ההפעלה מחדש נכשלת בגלל בעיה בתשלום, המשתמש עובר למצב 'החשבון בהשהיה', כפי שמתואר באיורים 5 ו-6:

איור 5. משתמש משהה את המינוי ואז מפעיל אותו מחדש.
איור 6. משתמש משהה את המינוי ואז נכנס למצב השהיית חשבון.

משתמשים יכולים גם להמשיך באופן ידני את המינוי בכל שלב במהלך תקופת ההשהיה, כפי שמוצג באיור 6. כשמשתמש מחדש את המינוי באופן ידני, תאריך החיוב משתנה לתאריך שבו המשתמש הפעיל אותו מחדש באופן ידני.

כשהמינוי של משתמש מושהה, ספריית החיוב ב-Play לא מחזירה את המינוי באמצעות השיטה queryPurchasesAsync(). אם המינוי יופעל מחדש, השיטה queryPurchasesAsync() תחזיר אותו שוב.

כדי לדעת מתי משתמש משהה את המינוי, אפשר להאזין ל-RTND. ההתראות האלה מאפשרות לכם גם להודיע למשתמשים באפליקציה שהם השהינו את המינוי שלהם ואין להם גישה אליו. כדאי גם לספק למשתמש קישור עומק ל-Google Play כדי שיוכל להמשיך את המינוי באופן ידני בכל שלב.

הודעה מסוג SubscriptionNotification עם הערך SUBSCRIPTION_PAUSE_SCHEDULE_CHANGED נשלחת כשהמשתמש מתחיל להשהות את המינוי. בשלב הזה, המשתמש אמור לשמור על הגישה למינוי עד לתאריך החידוש הבא, ומשאב המינוי מכיל את הערך autoRenewEnabled = true. הערך בשדה subscriptionState הוא SUBSCRIPTION_STATE_ACTIVE בשלב הזה.

הודעה מסוג SubscriptionNotification עם הערך SUBSCRIPTION_PAUSED נשלחת כשההשהיה נכנסת לתוקף. במקרה כזה, המשתמש אמור לאבד את הגישה למינוי, המשאב של המינוי יכיל את הערך autoRenewEnabled = true והשדה subscriptionState יוגדר כ-SUBSCRIPTION_STATE_PAUSED. כדי לראות מתי המינוי צפוי להתחדש שוב, אפשר לבדוק את האובייקט PausedStateContext.

הודעה מסוג SubscriptionNotification עם הערך SUBSCRIPTION_RENEWED נשלחת אם המינוי חודש באופן אוטומטי בסיום תקופת ההשהיה, או אם המשתמש בחר להמשיך את המינוי באופן ידני. צריך לטפל בכך כפי שמתואר בקטע חידושים.

הודעה מסוג SubscriptionNotification עם הערך SUBSCRIPTION_ON_HOLD נשלחת אם אירעה כשל בתשלום בזמן הניסיון להמשיך את המינוי אחרי ההשהיה. יש לטפל בבעיה הזו כפי שמתואר בקטע השהיית חשבון.

הרשמה מחדש

בתוכניות בסיסיות של מינויים שמתחדשים אוטומטית, יכול להיות שיופיע בחנות Google Play הלחצן הרשמה מחדש. לחצן שמאפשר למשתמשים לקבל שוב גישה למינוי. יכולות להיות סיבות שונות לכך שהיא לא מופיעה, למשל אם תוקף המינוי פג לפני זמן רב.

איור 7. הקטע חשבון > מינויים באפליקציית חנות Google Play, שבו מוצג מינוי שהתבטל עם הלחצן הרשמה מחדש.

הכיתוב בלחצן הוא תמיד Resubscribe, אבל הפונקציונליות שלו תלויה בסטטוס המינוי.

אם המינוי בוטל אבל התוקף שלו עדיין בתוקף, המשתמש עדיין מנוי ומקבל את ההטבות של המינוי. אם המשתמש מקייש על 'הרשמה מחדש', הביטול בטל והמינוי ימשיך להתחדש. הפעולה הזו נקראת שחזור במסמכי התיעוד למפתחים וב-API של Play.

אחרי שתוקף המינוי לחידוש אוטומטי יפוג, תוכלו לאפשר למשתמשים לרכוש את אותו מינוי בסיסי. הפעולה הזו נקראת resubscribe במסמכי התיעוד וב-API למפתחים של Play. אפשר להגדיר את האפשרות הזו לכל תוכנית בסיס ב-Play Console או באמצעות ה-API.

שחזור לפני התפוגה

אם האפליקציה שלכם מסתמכת אך ורק על השיטה queryPurchasesAsync() כדי לקבוע אם למשתמש יש זכאות למינוי, האפליקציה צריכה לטפל באופן אוטומטי בשחזור, כי השיטה queryPurchasesAsync() ממשיכה להחזיר רכישות שבוטלו לפני תאריכי התפוגה שלהן. המינוי ששוחזר ימשיך להתחדש כאילו לא בוטל.

אם האפליקציה מסנכרנת את מצב המינוי עם הקצה העורפי, צריך להאזין להודעה מסוג SubscriptionNotification עם הסוג SUBSCRIPTION_RESTARTED. אחרי שתקבלו את ההודעה הזו, האפליקציה תוכל להשיב להודעה, לתעד שהמינוי מוגדר עכשיו לחדשה ולהפסיק להציג באפליקציה הודעות על שחזור. המשאב של המינוי נראה דומה לדוגמה הבאה:

{
  "kind": "androidpublisher#subscriptionPurchaseV2",
  ...
  "subscriptionState": "SUBSCRIPTION_STATE_ACTIVE",
  ...
  "lineItems": [
    {
      "productId": "sub_variant_plan01",
      "expiryTime": next_renewal_date
      ...
    }
  ],
}

הרשמה מחדש לאחר תפוגת המינוי

אם הגדרתם מינוי בסיסי שמתחדש אוטומטית באמצעות מסוף Google Play או API כדי לאפשר הרשמה מחדש, המשתמשים יוכלו לרכוש מחדש מינוי שפג התוקף שלו בחנות Google Play.

אלה רכישות חדשות. מערכת Google Play מנפיקה אסימון רכישה חדש לגמרי, והקצה העורפי מקבל RTDN מסוג SUBSCRIPTION_PURCHASED. במקרה כזה, סטטוס הרכישה של רכישה מחוץ לאפליקציה לא כולל את הערך linkedPurchaseToken שמשויך לרכישה המקורית, כי התוקף של המינוי המקורי פג לחלוטין. אלה רכישות חדשות שמערכת הקצה העורפי צריכה לעבד ולאשר כמו כל רכישה אחרת.

שדרוגים, שדרוגים לאחור והרשמה מחדש למינוי

כשמשתמש משדרג, משדרג לאחור או נרשם באפליקציה אחרי ביטול המינוי לפני שתוקף המינוי פג, המינוי הישן לא תקף ונוצר מינוי חדש עם טוקן רכישה חדש.

בנוסף, משאב המינוי שמוחזר מ-Google Play Developer API מכיל את השדה linkedPurchaseToken שמציין את הרכישה הישנה שממנה המשתמש שדרג, ביצע שדרוג לאחור או נרשם מחדש למינוי. אפשר להשתמש באסימון הרכישה בשדה הזה כדי לחפש את המינוי הישן ולזהות את חשבון המשתמש הקיים, וכך לשייך את הרכישה החדשה לאותו חשבון.

לפני שמציעים למשתמשים באפליקציה אפשרויות לשדרוג, לשדרוג לאחור או להרשמה מחדש למינוי, צריך לאשר את המינוי הקיים. אם המינוי הקיים עדיין ממתין לאישור, לא תוכלו לשנות את התוכנית או להירשם מחדש.

אם המשתמש רוכש בהצלחה את השדרוג, השדרוג לאחור או מינוי מחדש, מדובר ברכישה חדשה שעליכם לאשר. הדרך המומלצת לעשות זאת היא להשתמש ב-Google Play Developer API. משאב המינוי נראה כך:

{
  "kind": "androidpublisher#subscriptionPurchaseV2",
  ...
  "subscriptionState": "SUBSCRIPTION_STATE_ACTIVE",
  "linkedPurchaseToken": old_purchase_token,
  ...
  "lineItems": [
    {
      "productId": "sub_variant_plan01",
      "expiryTime": next_renewal_date,
      "autoRenewingPlan": {
        "autoRenewEnabled": true
      }
    }
  ],
}

שינויים במחירים

במדריך לשיטות מומלצות לשינוי מחירים מוסבר איך משנים את מחירי המינויים שמתחדשים באופן אוטומטי ואיך מודיעים למשתמשים במקרים הרלוונטיים.

כששינויים במחיר חלים על מנויים קיימים כהסכמה מדעת, תקבלו אירוע RTDN אם המשתמש יבצע פעולה כדי לאשר או לדחות את המחיר החדש.

טיפול באישור של משתמש לשינוי במחיר שבו נדרש הסכמה מראש

כשמשתמש מאשר את עליית המחיר של המינוי, מופיעה הודעת SubscriptionNotification מסוג SUBSCRIPTION_PRICE_CHANGED_CONFIRMED. במקרה של הורדת מחיר עם אפשרות לביטול ההסכמה, או כשהעלאת המחיר של המינוי מתחדשת, תקבלו הודעה מסוג SubscriptionNotification עם הערך SUBSCRIPTION_RENEWED. צריך להתייחס להודעה הזו כמו לכל תזכורת לחדש.

טיפול במקרים שבהם העלאת מחיר בכפוף להסכמה לא אושרה

אם משתמש לא אישר את ההסכמה להעלאת המחיר לפני שהוא צריך לחדש את המינוי במחיר הגבוה יותר, המינוי שלו יבוטל באופן אוטומטי ותקבלו הודעה מסוג SubscriptionNotification עם הערך SUBSCRIPTION_CANCELED. מטפלים באירוע הזה כפי שמתואר בקטע ביטולים.

המשתמשים יכולים גם לבטל את המינויים שלהם במקרה של עליית מחירים שמוגדרת כהסכמה מראש, לפי אותו מנגנון.

ניהול מחזור החיים של מינויים בתשלום מראש

בדומה למינויים שמתחדשים אוטומטית, צריך לאשר מינויים בתשלום מראש אחרי כל רכישה חדשה. במקרה של מינויים בתשלום מראש, עליכם לעבד באופן מלא גם את הרכישה הראשונית וגם כל הוספת כסף, כי המשתמש צריך לעבור את תהליך הרכישה בכל פעם.

מכיוון שתוכניות בתשלום מראש יכולות להיות לטווח קצר, חשוב לאשר את הרכישה בהקדם האפשרי. תוכניות בתשלום מראש לתקופה של שבוע או יותר צריכות לקבל אישור תוך 3 ימים. תוכניות בתשלום מראש עם משך זמן קצר משבוע צריכות לקבל אישור תוך מחצית משך התוכנית. לדוגמה, למפתחים יש 1.5 ימים לאשר רכישה של תוכנית תשלום מראש ל-3 ימים.

איור 8. מצבי מחזור חיים ואירועי מעבר לרכישות של מינויים.

בכל פעם שמתבצע רכישה של מינוי לתוכנית בתשלום מראש, כולל כל הוספת כסף, נשלחת הודעת SubscriptionNotification מסוג SUBSCRIPTION_PURCHASED ללקוח ה-RTND. קוראים לשיטה purchases.subscriptionsv2.get כדי לבדוק את מצב המינוי העדכני לתוכנית בתשלום מראש.

טוקן רכישה חדש מונפק לרכישות של הוספת כסף, וטוקן הרכישה הקודם מופיע בשדה linkedPurchaseToken כחלק ממצב הרכישה החדש של המינוי. אסימון הרכישה תקף מהרגע שבו נרשמים למינוי ועד 60 יום אחרי תאריך התפוגה. אחרי התאריך הזה, לא ניתן יהיה להשתמש באסימון הרכישה כדי לבצע קריאה ל-Google Play Developer API.

משאב המינוי לרכישה של תוכנית בתשלום מראש נראה דומה לדוגמה הבאה:

{
  "kind": "androidpublisher#subscriptionPurchaseV2",
  "startTime": "2022-04-22T18:39:58.270Z",
  "regionCode": "US",
  "subscriptionState": "SUBSCRIPTION_STATE_ACTIVE",
  "latestOrderId": "GPA.3333-4137-0319-36762",
  "acknowledgementState": "ACKNOWLEDGEMENT_STATE_ACKNOWLEDGED",
  "lineItems": [
    {
      "productId": "prepaid_plan01",
      "expiryTime": expiry_date,
      "prepaidPlan": {
        "allowExtendAfterTime": timestamp_after_which_topups_are_allowed
      }
    }
  ]
}

מתי התוקף של ההנחה יפוג מצוין בשדה expiryTime. רכישות של תוספות זמן מגדילות את משך הזמן של הזכאות על ידי צבירת הזמן. כלומר, אם המשתמש מוסיף נפח לפני שפג התוקף של הזכאות המקוריות שלו, הזמן החדש מתווסף לתאריך התפוגה הקודם.

מומלץ להציג באפליקציה הודעה שמעדכנת את המשתמש שאפשר להאריך את המינויים בתשלום מראש באמצעות הוספת כסף. כדי לדעת מתי משתמש יוכל להוסיף נפח, צריך לבדוק את השדה allowExtendAfterTime במשאב המינוי.

מינויים בתשלום מראש לא מתחדשים באופן אוטומטי, ולכן אי אפשר לבטל אותם. אם משתמש רוצה לבטל תוכנית בתשלום מראש, הוא יכול להמתין עד לתאריך התפוגה שלה.