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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• זמינות של ספריית החיובים ב-Play: השדה installmentDetails זמין רק בגרסה 7 ואילך של ספריית החיובים ב-Play‏ (PBL). ב-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. יש לו מינוי חודשי לגרסת Tier 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$‎ לשנה = ‎3 $‎ לחודש) גבוה ממחיר המינוי לרמה 1 ליחידת זמן (‎2$‎ לחודש). המינוי של סמואל ל-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 במאי, המינוי לרמה 2 נכנס לתוקף, וסמייז מחויב ב-36 $על רמת המינוי החדשה.

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

CHARGE_FULL_PRICE

המינוי של סמואל ל-Tier 1 מסתיים באופן מיידי. המינוי שלו ל-Tier 2 מתחיל היום והוא יחויב ב-36$. הוא שילם על חודש מלא אבל השתמש רק בחצי ממנו, ולכן חצי מהמינוי החודשי (דולר אחד) יתווסף למינוי החדש שלו. מכיוון שהמינוי החדש עולה 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.

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

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

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

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

כשמשתמשים ב-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. כך המשתמש יוכל לקבל תקופת ניסיון בחינם אחת לכל אפליקציה.

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

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

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

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

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

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

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

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

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

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

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

קידום המינוי

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

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

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

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

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

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

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

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