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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• זמינות של ספריית החיובים ב-Play: השדה installmentDetails זמין רק בגרסה 7 ואילך של ספריית החיובים ב-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 ובשם חבילת ה-APK של האפליקציה בהתאמה:

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 באפריל, סמייז בחר לשדרג לגרסה השנתית של מינוי Tier 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 במאי, המינוי Tier 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 = this.billingClient
val replacementModeForBasePlan: Int = 1
val replacementModeForAddon: Int = 1

val purchaseTokenOfExistingSubscription: String = "your_old_purchase_token"

// ProductDetails instances obtained from queryProductDetailsAsync();

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

val productDetailsParams2 =
    ProductDetailsParams.newBuilder()
        .setProductDetails(productDetails2) // 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) // 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)
Subscriptions.kt

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 הוצא משימוש בגרסה 6 של Play Billing Library. בטבלה הבאה מוסבר איפה יש הבדלים בהתנהגות:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

// Note: To display the in-app message, PBL requires an activity instance that
// can provide a valid window token. This token is necessary for the Play Store
// to display the message overlay correctly on top of the application's window.
// The passed Activity must be in a state where its window is created and
// attached to the WindowManager.
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
                // is recovered from a suspended state, or a user confirms a
                // price increase. Developers should expect the purchase
                // token to be returned with this response code and use
                // the purchase token with the Google Play Developer API.
            }
        }
    }
)
Subscriptions.kt

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

// Note: To display the in-app message, PBL requires an activity instance that
// can provide a valid window token. This token is necessary for the Play Store
// to display the message overlay correctly on top of the application's window.
// The passed Activity must be in a state where its window is created and
// attached to the WindowManager.
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
                    // is recovered from a suspended state, or a user confirms a
                    // price increase. Developers should expect the purchase
                    // token to be returned with this response code and use
                    // the purchase token with the Google Play Developer API.
                }
            }
        });

טיפול בביטולים ובמצבים בהמתנה

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

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

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

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

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

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

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

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

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

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