מידע על מינויים

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

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

סקירת מינויים

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

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

סקירה מפורטת של מוצרים מבוססי-מינוי, תוכניות בסיסיות ומבצעים זמינה במסמכים במרכז העזרה של Play Console.

ספריית החיוב של Play תומכת בסוגי המינויים הבאים:

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

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

שילוב של מינויים בתשלום מראש

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

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

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

אחרי טעינה, השדות הבאים באובייקט התוצאה Purchase מתעדכנים כדי לשקף את רכישת הטעינה האחרונה:

• מזהה הזמנה
• שעת הרכישה
• חתימה
• טוקן רכישה
• מסירה אושרה

השדות הבאים Purchase תמיד מכילים את אותם נתונים שנמצאים ברכישה המקורית:

• שם חבילה
• מצב הרכישה
• מוצרים
• חידוש אוטומטי

אישור רכישה בתשלום מראש

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

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

צריך לאשר מינויים בתשלום מראש עם משך שימוש של שבוע או יותר תוך שלושה ימים.

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

שילוב של מינויים עם תשלומים

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

שיקולים נוספים לגבי מינויים בתשלומים:

• זמינות לפי מדינה: התכונה 'מינויים בתשלומים' זמינה רק בברזיל, בצרפת, באיטליה ובספרד (כדאי לבדוק ב-Play Console את הזמינות העדכנית).
• הגדרת המחיר: כשמגדירים את המחיר למינוי בתשלומים במסוף, המחיר מייצג את סכום התשלום החודשי. הסכום הזה, יחד עם תקופת ההתחייבות שמוגדרת, יוצר את הסכום הכולל של המינוי במסך הרכישה.
• תקופת ההתחייבות: משך הזמן הכולל של ההתחייבות הראשונית למינוי, שבמהלכה נדרשים תשלומים חודשיים. לדוגמה, אם תוכנית בסיס כוללת תקופת התחייבות של 15 חודשים, המשתמש ישלם 15 תשלומים חודשיים במהלך התקופה הזו.
• חידושים: בהקשר של מינויים בתשלומים, 'חידוש' מציין את סיום תקופת ההתחייבות, בין אם מדובר בתקופת ההתחייבות הראשונית או בתקופת התחייבות עוקבת. אחרי ההרשמה הראשונית, החידוש הראשון מתרחש בסיום תקופת ההתחייבות הראשונית כולה. חידושים עוקבים מתרחשים אחרי שכל תקופת התחייבות עוקבת מסתיימת. סוגי החידוש של מינויים בתשלומים יכולים להיות auto-renews monthly (מתחדש אוטומטית מדי חודש) או auto-renews for the same duration (מתחדש אוטומטית למשך אותו פרק זמן). במינוי עם חידוש אוטומטי חודשי, אין התחייבות נוספת והתוכנית מתנהגת כמו מינוי חודשי שבו כל חיוב חודשי מהווה חידוש.
• תקופת חיוב: בהקשר של מינויים בתשלומים, הכוונה היא למרווח החוזר שבו מתבצעים תשלומים בודדים, כפי שמצוין בתוכנית הבסיסית.
• התנהגויות שונות בשינוי תוכנית לעומת שינוי מחיר: במקרה של שינויי מחיר וביטולים, ההתחייבות היא סופית. כלומר, אם משתמש רוצה לבטל או אם מפתח רוצה לשנות את המחיר, השינוי ייכנס לתוקף בסוף תקופת ההתחייבות. בשינויים בתוכנית, ההתחייבות לא סופית. כלומר, לא צריך לחכות עד לסיום תקופת ההתחייבות כדי לשנות את התוכנית. השינוי ייכנס לתוקף באופן מיידי או בתאריך התשלום הבא, בהתאם למצב ההחלפה שהוגדר.
• שינוי באותו מינוי: אי אפשר לעבור ממינוי עם תשלומים למינוי ללא תשלומים באותו מוצר מינוי.

• התראות בזמן אמת למפתחים (RTDN): התראת RTDN של SUBSCRIPTION_CANCELLATION_SCHEDULED נשלחת באופן מיידי כשמשתמש מבטל מינוי במהלך תקופת ההתחייבות, אם נותרו תשלומים לתקופה הזו. הביטול בהמתנה וייכנס לתוקף רק בסוף תקופת ההתחייבות. לאחר מכן, אם המשתמש לא ישחזר את הנתונים, יישלחו מספרי הטלפון הווירטואליים של SUBSCRIPTION_CANCELED ושל SUBSCRIPTION_EXPIRED בסוף תקופת ההתחייבות.

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

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

• זמינות של ספריית החיובים ב-Google Play: השדה installmentDetails זמין רק בגרסה 7 ואילך של ספריית החיובים ב-Google Play. ב-PBL 5 ואילך, המינוי לתשלומים מוחזר באמצעות queryProductDetails(), אבל המינוי לא יכלול פרטים מפורטים על התשלומים, כמו מספר התשלומים שנדרשים במסגרת התוכנית.

שימוש בקישורי עומק כדי לאפשר למשתמשים לנהל מינוי

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

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

קישור למרכז המינויים

כדי להפנות משתמשים לדף שבו מוצגים כל המינויים שלהם, כמו שמוצג באיורים 1 ו-2, משתמשים בכתובת ה-URL הבאה:

https://play.google.com/store/account/subscriptions

קישור העומק הזה יכול לעזור למשתמש לשחזר מינוי שבוטל ממרכז המינויים של חנות Play.

קישור לדף ספציפי לניהול מינויים (מומלץ)

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

כדי להפנות משתמשים למסך ספציפי לניהול מינויים, צריך להשתמש בכתובת ה-URL הבאה ולהחליף את your-sub-product-id ואת your-app-package בproductId ובשם חבילת האפליקציה, בהתאמה:

https://play.google.com/store/account/subscriptions?sku=your-sub-product-id&package=your-app-package

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

לאפשר למשתמשים לשדרג, לשנמך או לשנות את המינוי שלהם

אתם יכולים לספק למנויים קיימים מגוון אפשרויות לשינוי תוכנית המינוי כדי שתתאים יותר לצרכים שלהם:

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

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

איור 3 מציג אפליקציה לדוגמה עם שלוש תוכניות שונות:

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

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

מצבי החלפה

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

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

הגדרת מצב ההחלפה לרכישה

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

הרשמה מחדש או מעבר בין תוכניות באותו מינוי

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

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

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

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

כדי לספק נכון את ReplacementMode ב-SubscriptionProductReplacementParams או ב-SubscriptionUpdateParams כחלק מהגדרת תהליך הרכישה בזמן הריצה, חשוב לשים לב להגבלות הבאות:

• כשמשדרגים, מורידים את רמת המינוי או מתחילים להחליף מינוי זהה ל מינוי בתשלום מראש מ מינוי בתשלום מראש, מינוי שמתחדש אוטומטית או מינוי בתשלומים, מצב ההחלפה היחיד שמותר הוא CHARGE_FULL_PRICE. אם מציינים מצב החלפה אחר, הרכישה נכשלת ומוצגת למשתמש שגיאה.
• כשעוברים בין תוכניות באותו מינוי לתוכנית שמתחדשת אוטומטית מתוכנית בתשלום מראש או מתוכנית שמתחדשת אוטומטית, מצבי החלוקה היחסיים התקפים הם CHARGE_FULL_PRICE ו-WITHOUT_PRORATION. אם מציינים מצב פרו-רייטינג אחר, הרכישה נכשלת ומוצגת למשתמש שגיאה.
• אי אפשר לעבור בין תוכניות בסיסיות באותו מוצר מינוי, אם אחת מהן מבוססת על תשלומים והשנייה לא.
• כשמשתמשים במצב החלפה KEEP_EXISTING ב-SubscriptionProductReplacementParams כדי לשמור על אמצעי התשלום של פריט ללא שינוי במהלך ההחלפה, מזהה המוצר הישן צריך להיות זהה למזהה המוצר החדש. מצב KEEP_EXISTING לא נתמך ב-SubscriptionUpdateParams.

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

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

לשמואל יש מינוי לתוכן אונליין באפליקציה Country Gardener. יש לו מינוי חודשי לגרסת רמה 1 של התוכן, שהיא גרסה טקסטואלית בלבד. המינוי הזה עולה לו 2$‎ לחודש, והוא מתחדש ב-1 בחודש.

ב-15 באפריל, סמואייז בחר לשדרג לגרסה השנתית של מינוי רמה 2, שכוללת עדכוני סרטונים ועולה 36$‎ לשנה.

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

WITH_TIME_PRORATION

המינוי של סמואל ל-Tier 1 מסתיים באופן מיידי. הוא שילם על חודש מלא (1-30 באפריל), אבל שדרג באמצע תקופת המינוי, ולכן חצי מהמינוי החודשי (1$) יתווסף למינוי החדש שלו. עם זאת, מכיוון שהמינוי החדש עולה 36 $לשנה, יתרת הקרדיט בסך 1 $מספיקה ל-10 ימים בלבד (16 באפריל עד 25 באפריל). לכן, ב-26 באפריל הוא יחויב ב-36 $על מינוי חדש, ועוד 36 $ב-26 באפריל של כל שנה לאחר מכן.

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

CHARGE_PRORATED_PRICE

אפשר להשתמש במצב הזה כי מחיר המינוי לרמה 2 ליחידת זמן (‎36 USD לשנה = ‎3 USD לחודש) גבוה ממחיר המינוי לרמה 1 ליחידת זמן (‎2 USD לחודש). המינוי של סמואל ל-Tier 1 מסתיים באופן מיידי. הוא שילם על חודש מלא אבל השתמש רק בחצי ממנו, ולכן חצי מהמינוי החודשי (1$) יתווסף למינוי החדש שלו. עם זאת, מכיוון שהמינוי החדש עולה 36 $לשנה, עלות 15 הימים שנותרו היא 1.50$. לכן, הוא יחויב בהפרש של 0.50 $על המינוי החדש. ב-1 במאי, סמואיז מחויב ב-36 $‎ על רמת המינוי החדשה שלו, ועוד 36 $‎ ב-1 במאי בכל שנה לאחר מכן.

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

WITHOUT_PRORATION

המינוי של סמיווייז ברמה 1 משודרג מיד לרמה 2 ללא חיוב נוסף, וב-1 במאי הוא מחויב ב-36 $על רמת המינוי החדשה שלו, ועוד 36 $ב-1 במאי בכל שנה שלאחר מכן.

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

DEFERRED

המינוי של סמואל ל-Tier 1 יימשך עד שהוא יפוג ב-30 באפריל. ב-1 במאי, המינוי Tier 2 נכנס לתוקף, וסמואייז מחויב ב-36 $על רמת המינוי החדשה.

צריך להפעיל את שיטת PurchasesUpdatedListener של האפליקציה ברגע שהרכישה מצליחה, ואפשר לאחזר את הרכישה החדשה כחלק מהפעלה של queryPurchasesAsync(). הקצה העורפי שלכם מקבל באופן מיידי SUBSCRIPTION_PURCHASED התראה בזמן אמת למפתחים. צריך לעבד את הרכישה באותו אופן שבו מעבדים כל רכישה חדשה אחרת בשלב הזה. חשוב במיוחד לאשר את הרכישה החדשה. שימו לב שהתאריך startTime של המינוי החדש מתעדכן ברגע שההחלפה נכנסת לתוקף, כלומר כשתוקף המינוי הישן פג. בשלב הזה, תקבלו SUBSCRIPTION_RENEWED RTDN לתוכנית המינוי החדשה. מידע נוסף על אופן הפעולה של ReplacementMode.DEFERRED

CHARGE_FULL_PRICE

המינוי של סמואל ל-Tier 1 מסתיים באופן מיידי. המינוי שלו ל-Tier 2 מתחיל היום והוא יחויב ב-36$. הוא שילם על חודש מלא אבל השתמש רק בחצי ממנו, ולכן חצי מהמינוי החודשי (1$) יתווסף למינוי החדש שלו. מכיוון שהמינוי החדש עולה 36 $לשנה, הוא יקבל תוספת של 1/36 משנה לתקופת המינוי שלו (כ-10 ימים). לכן, החיוב הבא של סמיווייז יהיה בעוד שנה ו-10 ימים מהיום, על סך 36$. לאחר מכן, הוא יחויב ב-36 $‎ בכל שנה.

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

KEEP_EXISTING

לסמואייז יש מינוי לתוכן אונליין באפליקציה Country Gardener. יש לו מינוי חודשי לתוכנית 1 לתוכן בסיסי. מחיר המנוי הזה הוא מחיר היכרות של 2 $לחודש למשך 3 חודשים, ואחר כך 4 $לחודש. סמואל רכש את הפריט הזה ב-1 באפריל. אפליקציית Country Gardener מציעה את תוכנית 2 כתוכן מיוחד בתשלום נוסף, במחיר של 3 $לחודש. ב-15 באפריל, סמואייז הוסיף את תוכנית 2 למינוי שלו לאפליקציית Country Gardener, והמשיך להשתמש בתוכנית 1 הקיימת. תוכנית התשלומים של סמואל היא כזו:

• מחיר יחסי של 1.50 $למינוי Plan 2, לתשלום ב-15 באפריל.
• מחיר של 5.00 $לחודש למשך 2 החודשים הבאים, שכולל גם את מחיר המבצע של Plan 1 וגם את המחיר הרגיל של Plan 2.
• לאחר מכן, תשלום חודשי קבוע של 7.00$.

הפעלת שינויים במינוי בתוך האפליקציה

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

שימוש ב-SubscriptionProductReplacementParams להחלפה (מומלץ)

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

• לאובייקט BillingFlowParams.ProductDetailsParams יש עכשיו שיטה setSubscriptionProductReplacementParams() לציין מידע על החלפה ברמת המוצר.

• ל-SubscriptionProductReplacementParams יש שתי שיטות setter:

  • setOldProductId:זהו המוצר הישן שיוחלף במוצר שמופיע בשורה הנוכחית ProductDetails.
  • ‫setReplacementMode:זהו מצב ההחלפה ברמת הפריט. המשמעות של המצבים זהה לזו של SubscriptionUpdateParams, אבל מיפוי הערכים עודכן.

• צריך ליצור את הפרמטרים הקיימים של עדכון ברמת הרכישה BillingFlowParams.setSubscriptionUpdateParams() באמצעות setOldPurchaseToken().

• אחרי שמפעילים את setSubscriptionProductReplacementParams() עבור אחד מהפרמטרים ProductDetailsParams,‏ SubscriptionUpdateParams.setSubscriptionReplacementMode(), לא תהיה לו השפעה.

בדוגמת הקוד הבאה מוצג איך לשנות תוכנית מינוי מ-(old_product_1, old_product_2) ל-(product_1, product_2, product_3). בתרחיש הזה, product_1 מחליף את old_product_1,‏ product_2 מחליף את old_product_2, ו-product_3 מתווסף למינוי באופן מיידי.

val billingClient: BillingClient = ...
val replacementModeForBasePlan: Int = ...
val replacementModeForAddon: Int = ...

val purchaseTokenOfExistingSubscription: String = "your_old_purchase_token"

// ProductDetails instances obtained from queryProductDetailsAsync();

val productDetailsParams1 =
    ProductDetailsParams.newBuilder()
        .setProductDetails(productDetails1_obj) // Required: Set the ProductDetails object
        .setSubscriptionProductReplacementParams(
            SubscriptionProductReplacementParams.newBuilder()
                .setOldProductId("old_product_id_1")
                .setReplacementMode(replacementModeForBasePlan)
                .build()
        )
        .build()

val productDetailsParams2 =
    ProductDetailsParams.newBuilder()
        .setProductDetails(productDetails2_obj) // Required: Set the ProductDetails object
        .setSubscriptionProductReplacementParams(
            SubscriptionProductReplacementParams.newBuilder()
                .setOldProductId("old_product_id_2")
                .setReplacementMode(replacementModeForAddon)
                .build()
        )
        .build()

// Example for a third item without replacement params
val productDetailsParams3 =
    ProductDetailsParams.newBuilder()
        .setProductDetails(productDetails3_obj) // Required: Set the ProductDetails object
        .build()

val newProductDetailsList = listOf(
    productDetailsParams1,
    productDetailsParams2,
    productDetailsParams3
)

val billingFlowParams =
    BillingFlowParams.newBuilder()
        .setSubscriptionUpdateParams(
            SubscriptionUpdateParams.newBuilder()
                .setOldPurchaseToken(purchaseTokenOfExistingSubscription)
                .build()
        )
        .setProductDetailsParamsList(newProductDetailsList)
        .build()

// To launch the billing flow:
// billingClient.launchBillingFlow(activity, billingFlowParams)

BillingClient billingClient = …;

int replacementModeForBasePlan =…;
int replacementModeForAddon =…;
// ProductDetails obtained from queryProductDetailsAsync().
ProductDetailsParams productDetails1 =
  ProductDetailsParams.newBuilder()
      .setSubscriptionProductReplacementParams(
           SubscriptionProductReplacementParams.newBuilder()
               .setOldProductId("old_product_id_1")
               .setReplacementMode(replacementModeForBasePlan))
               .build();
ProductDetailsParams productDetails2 =
  ProductDetailsParams.newBuilder()
      .setSubscriptionProductReplacementParams(
           SubscriptionProductReplacementParams.newBuilder()
               .setOldProductId("old_product_id_2")
               .setReplacementMode(replacementModeForAddon))
               .build();
ProductDetailsParams productDetails3 = ...;

ArrayList newProductDetailsList = new ArrayList<>();
newProductDetailsList.add(productDetails1);
newProductDetailsList.add(productDetails2);
newProductDetailsList.add(productDetails3);

BillingFlowParams billingFlowParams =
    BillingFlowParams.newBuilder()
        .setSubscriptionUpdateParams(
          SubscriptionUpdateParams.newBuilder()
              .setOldPurchaseToken(purchaseTokenOfExistingSubscription)
             .build())
        .setProductDetailsParamsList(productDetailsList)
        .build();

billingClient.launchBillingFlow(billingFlowParams);

הגדרת SubscriptionUpdateParams להחלפה (הוצא משימוש)

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

val offerToken = productDetails
        .getSubscriptionOfferDetails(selectedOfferIndex)
        .getOfferToken()

val billingParams = BillingFlowParams.newBuilder().setProductDetailsParamsList(
       listOf(
           BillingFlowParams.ProductDetailsParams.newBuilder()
               .setProductDetails(productDetails)
               .setOfferToken(offerToken)
               .build()
       )
       ).setSubscriptionUpdateParams(
           BillingFlowParams.SubscriptionUpdateParams.newBuilder()
               .setOldPurchaseToken("old_purchase_token")
               .setSubscriptionReplacementMode(
                 BillingFlowParams.ReplacementMode.CHARGE_FULL_PRICE
               )
               .build()
       ).build()

billingClient.launchBillingFlow(
    activity,
    billingParams
   )
// ...

String offerToken = productDetails
    .getSubscriptionOfferDetails(selectedOfferIndex)
    .getOfferToken();

BillingFlowParams billingFlowParams = BillingFlowParams.newBuilder()
    .setProductDetailsParamsList(
        ImmuableList.of(
            ProductDetailsParams.newBuilder()
                // fetched via queryProductDetailsAsync
                .setProductDetails(productDetails)
                // offerToken can be found in
                // ProductDetails=>SubscriptionOfferDetails
                .setOfferToken(offerToken)
                .build()))
    .setSubscriptionUpdateParams(
        SubscriptionUpdateParams.newBuilder()
            // purchaseToken can be found in Purchase#getPurchaseToken
            .setOldPurchaseToken("old_purchase_token")
            .setSubscriptionReplacementMode(ReplacementMode.CHARGE_FULL_PRICE)
            .build())
    .build();

BillingResult billingResult = billingClient.launchBillingFlow(activity, billingFlowParams);
// ...

המלצות להחלפה

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

טיפול ברכישות של שינויים במינוי

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

ההתנהגות באפליקציה זהה להתנהגות של כל רכישה חדשה. תוצאת הרכישה החדשה מתקבלת באפליקציה בPurchasesUpdatedListener, והרכישה החדשה זמינה בqueryPurchasesAsync.

ממשק Google Play Developer API מחזיר linkedPurchaseToken בsubscription resource כשמתבצעת רכישה שמחליפה רכישה קיימת. כדי להבין את פרטי ההחלפה ברמת הפריט, אפשר לבדוק את itemReplacement בקטע SubscriptionPurchaseLineItem ברכישה החדשה. בנוסף, אפשר להשתמש בשדה offerPhase כדי לזהות את השלב הנוכחי של המינוי החדש (למשל, תקופת חיוב יחסי או תקופת ניסיון בחינם) כדי לספק חוויות משתמש מותאמות אישית. חשוב לבטל את הטוקן שסופק ב-linkedPurchaseToken כדי לוודא שלא נעשה שימוש בטוקן הישן כדי לקבל גישה לשירותים שלכם. מידע על רכישות של שדרוגים ושדרוגים לאחור מופיע במאמר בנושא שדרוגים, שדרוגים לאחור וחידוש מינוי.

כשמקבלים את טוקן הרכישה החדש, צריך לבצע את אותו תהליך אימות כמו אימות של טוקן רכישה חדש. חשוב לאשר את הרכישות האלה באמצעות BillingClient.acknowledgePurchase() מ-Google Play Billing Library או באמצעות Purchases.subscriptions:acknowledge מ-Google Play Developer API.

טיפול בהחלפה נדחית

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

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

בעבר, אפשר היה להשיג את חוויית המשתמש הזו באמצעות ProrationMode.DEFERRED שהוצא משימוש, אבל ProrationMode.DEFERRED הוצא משימוש עם Play Billing Library 6. בטבלה הבאה מוסבר איפה יש הבדלים בהתנהגות:

מעכשיו צריך להשתמש ב-ReplacementMode.DEFERRED במקום ב-ProrationMode.DEFERRED שיצא משימוש, כי הוא פועל באותו אופן מבחינת שינויים בזכאות, אבל הוא מאפשר לנהל את הרכישה בצורה עקבית יותר עם אופן הפעולה של רכישות חדשות אחרות.

ניהול לקוחות

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

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

לפני שתוקף המינוי יפוג – באפליקציה

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

ברוב המקרים, כדאי להציע למשתמש את אותו מחיר ואותו מק"ט שהוא כבר רשום אליהם, באופן הבא:

• מתחילים רכישה חדשה של מינוי עם אותו מק"ט.
• המינוי החדש מחליף את המינוי הישן ומתחדש באותו תאריך תפוגה. המינוי הישן מסומן מיד כמינוי שפג תוקפו.
• לדוגמה, אכילס מנוי לאפליקציית המוזיקה Example, והמינוי אמור לפוג ב-1 באוגוסט. ב-10 ביולי הוא נרשם מחדש למינוי לחודש אחד באותו מחיר לחודש. המינוי החדש מחושב באופן יחסי עם יתרת הקרדיט, הוא פעיל באופן מיידי והוא עדיין מתחדש ב-1 באוגוסט.

אם רוצים להציע מחיר אחר – למשל תקופת ניסיון חדשה בחינם או הנחה למשתמשים חוזרים – אפשר להציע למשתמש מק"ט אחר:

• מתחילים שדרוג או שדרוג לאחור עם מק"ט אחר באמצעות מצב ההחלפה WITHOUT_PRORATION.
• המינוי החדש מחליף את המינוי הישן ומתחדש באותו תאריך תפוגה. המשתמש יחויב במחיר של המק"ט החדש, כולל מחירי מבצע, בתאריך התפוגה המקורי. אם המינוי הישן נוצר באמצעות מזהה חשבון שעבר הסתרה, צריך להעביר את אותו מזהה אל BillingFlowParams לשדרוגים ולשנמוכים.
• לדוגמה, אכילס מנוי לאפליקציית המוזיקה Example, והמינוי אמור לפוג ב-1 באוגוסט. ב-10 ביולי הוא נרשם מחדש למינוי שנתי במחיר היכרות. המינוי החדש פעיל באופן מיידי, והמשתמש יחויב במחיר המבצע ב-1 באוגוסט.
• אם אתם מחליטים לכלול תקופת ניסיון בחינם או מחיר מבצע ב-SKU של קמפיין להחזרת לקוחות לא פעילים, עליכם לוודא שהמשתמש עומד בדרישות. לשם כך, צריך לבטל את הסימון של התיבה אפשר תקופת ניסיון בחינם אחת לכל אפליקציה ב-Google Play Console. כך המשתמש יוכל לקבל תקופת ניסיון בחינם אחת לכל אפליקציה.

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

לפני שתוקף המינוי יפוג – בחנות Play

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

מידע נוסף על שחזור מינויים

אחרי שתוקף המינוי יפוג – באפליקציה

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

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

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

אחרי שתוקף המינוי יפוג – בחנות Play

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

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

קידום המינוי

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

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

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

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

ביטול או ביטול הרשאה

אפשר להשתמש ב-Google Play Developer API כדי לבטל או לשלול מינוי. הפונקציונליות הזו זמינה גם ב- Google Play Console.

• ביטול: משתמשים יכולים לבטל מינוי ב-Google Play. אתם יכולים גם לספק למשתמשים אפשרות לבטל את המינוי באפליקציה או באתר שלכם. האפליקציה שלכם צריכה לטפל בביטולים האלה כמו שמתואר בקטע ביטולים.

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

בטבלה הבאה מפורטים ההבדלים בין ביטול לבין ביטול הרשאה.

דחיית החיוב של מנוי

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

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

חיוב נדחה מאפשר לכם:

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

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

לדוגמה, לדרסי יש מינוי חודשי לתוכן אונליין באפליקציה Fishing Quarterly. בדרך כלל היא מחויבת ב-1.25 ליש"ט ביום הראשון בכל חודש. במרץ, היא השתתפה בסקר אונליין של בעל האפליקציה. המוציא לאור מתגמל אותה בשישה שבועות חינם על ידי דחיית התשלום הבא עד 15 במאי, שישה שבועות אחרי תאריך החיוב הקודם שלה, 4 באפריל.

1. דארסי לא מחויבת על אפריל או על תחילת מאי, ועדיין יש לה גישה לתוכן. ב-15 במאי היא מחויבת בדמי המינוי הרגילים של 1.25 ליש"ט לחודש. תאריך החידוש הבא שלה הוא עכשיו 15 ביוני.

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

טיפול בדחיית תשלומים

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

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

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

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

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

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

העברת הודעות באפליקציה

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

מומלץ לקרוא ל-API הזה בכל פעם שהמשתמש פותח את האפליקציה כדי לקבוע אם להציג את ההודעה.

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

שילוב של העברת הודעות באפליקציה

כדי להציג הודעות למשתמשים באפליקציה, משתמשים ב-BillingClient.showInAppMessages().

דוגמה להפעלת תהליך הצגת הודעות באפליקציה:

val inAppMessageParams = InAppMessageParams.newBuilder()
        .addInAppMessageCategoryToShow(InAppMessageCategoryId.TRANSACTIONAL)
        .build()

billingClient.showInAppMessages(activity,
        inAppMessageParams,
        object : InAppMessageResponseListener() {
            override fun onInAppMessageResponse(inAppMessageResult: InAppMessageResult) {
                if (inAppMessageResult.responseCode == InAppMessageResponseCode.NO_ACTION_NEEDED) {
                    // The flow has finished and there is no action needed from developers.
                } else if (inAppMessageResult.responseCode
                        == InAppMessageResponseCode.SUBSCRIPTION_STATUS_UPDATED) {
                    // The subscription status changed. For example, a subscription
                    // has been recovered from a suspend state. Developers should
                    // expect the purchase token to be returned with this response
                    // code and use the purchase token with the Google Play
                    // Developer API.
                }
            }
        })

InAppMessageParams inAppMessageParams = InAppMessageParams.newBuilder()
        .addInAppMessageCategoryToShow(InAppMessageCategoryId.TRANSACTIONAL)
        .build();

billingClient.showInAppMessages(activity,
        inAppMessageParams,
        new InAppMessageResponseListener() {
            @Override
            public void onInAppMessageResponse(InAppMessageResult inAppMessageResult) {
                if (inAppMessageResult.responseCode
                        == InAppMessageResponseCode.NO_ACTION_NEEDED) {
                    // The flow has finished and there is no action needed from developers.
                } else if (inAppMessageResult.responseCode
                        == InAppMessageResponseCode.SUBSCRIPTION_STATUS_UPDATED) {
                    // The subscription status changed. For example, a subscription
                    // has been recovered from a suspend state. Developers should
                    // expect the purchase token to be returned with this response
                    // code and use the purchase token with the Google Play
                    // Developer API.
                }
            }
        });

טיפול בעסקאות מינוי בהמתנה

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

שינוי סטטוס המינוי ברכישה ראשונית עם עסקאות בהמתנה הוא פשוט. האפליקציה מקבלת Purchase עם סטטוס PENDING כשהמשתמש יוזם עסקה בהמתנה. כשהעסקה תושלם, האפליקציה תקבל שוב את Purchase עם הסטטוס המעודכן PURCHASED. הודעה מסוג SUBSCRIPTION_PURCHASED נשלחת אל לקוח ה-RTDN שלך.SubscriptionNotification פועלים לפי התהליך הרגיל לאימות הרכישה, מעניקים למשתמש גישה לתוכן ומאשרים את הרכישה. אם התוקף של העסקה פג או שהיא בוטלה, הודעה מסוג SubscriptionNotification עם הערך SUBSCRIPTION_PENDING_PURCHASE_CANCELED נשלחת ללקוח RTDN. במקרים כאלה, למשתמשים אסור לקבל גישה לתוכן.

הוספת כסף, שדרוג או שדרוג לאחור עם עסקאות בהמתנה כוללים שינויים בסטטוס של המינויים הישנים והחדשים. כשהמשתמש יוזם עסקה של טעינת יתרה, שדרוג או שנמוך, האפליקציה מקבלת Purchase למינוי הישן עם אובייקט PendingPurchaseUpdate. בשלב הזה, המשתמש עדיין בעל המינוי הישן ולא קיבל עדיין את המינוי החדש. הפעלת getProducts() ו-getPurchaseToken() באובייקט PendingPurchaseUpdate מחזירה את מזהי המוצרים ואת אסימון הרכישה של המינוי החדש. כשהעסקה תושלם, האפליקציה תקבל Purchase עם טוקן הרכישה ברמה העליונה שמוגדר למינוי החדש, והסטטוס מוגדר ל-PURCHASED. הודעה מסוג SUBSCRIPTION_PURCHASED עם הערך SubscriptionNotification נשלחת ללקוח RTDN. רק בשלב הזה צריך להחליף את אסימון הרכישה הישן באסימון הרכישה החדש ולעדכן את הגישה של המשתמש לתוכן. אם תוקף העסקה יפוג או שהיא תבוטל, הודעה מסוג SUBSCRIPTION_PENDING_PURCHASE_CANCELED עם הערך SubscriptionNotification תישלח ללקוח RTDN. במקרים כאלה, למשתמש עדיין צריכה להיות גישה לתוכן של המינוי הישן.