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

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

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

כשמצב המינוי של משתמש משתנה, שרת הקצה העורפי מקבל הודעת 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 Store. כשמשתמש נכנס לתקופת חסד, כדאי גם לעודד אותו לתקן את אמצעי התשלום במקרה שהכשל היה לא מכוון. דרך פשוטה לעשות זאת היא להשתמש ב-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 Console או 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 במשאב המינוי.

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