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

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

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

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

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

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

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

צריך להפעיל את שיטת PurchasesUpdatedListener של האפליקציה ברגע שהרכישה מצליחה, ואפשר לאחזר את הרכישה החדשה כחלק מהפעלה של queryPurchasesAsync(). הקצה האחורי שלכם מקבל באופן מיידי SUBSCRIPTION_PURCHASED התראה בזמן אמת למפתחים. צריך לעבד את הרכישה באותו אופן שבו מעבדים כל רכישה חדשה אחרת בשלב הזה. בפרט, חשוב לאשר את הרכישה החדשה. שימו לב שהתאריך startTime של המינוי החדש מתעדכן ברגע שההחלפה נכנסת לתוקף, כלומר כשתוקף המינוי הישן פג. בשלב הזה, תקבלו RTDN של SUBSCRIPTION_RENEWED לתוכנית המינוי החדשה. מידע נוסף על אופן הפעולה של 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 כשמתבצעת רכישה שמחליפה רכישה קיימת. חשוב לבטל את הטוקן שסופק ב-linkedPurchaseToken כדי לוודא שלא נעשה שימוש בטוקן הישן כדי לקבל גישה לשירותים שלכם. במאמר שדרוגים, שדרוגים לאחור וחידוש מינוי יש מידע על רכישות של שדרוגים ושדרוגים לאחור.

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

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

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

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

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

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

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

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

אפשר להקדים את תאריך החיוב הבא של מינוי שמתחדש אוטומטית באמצעות Purchases.subscriptions:defer מ-Google Play Developer API. במהלך תקופת הדחייה, המשתמש מנוי לתוכן שלכם עם גישה מלאה, אבל לא מחויב. תאריך חידוש המינוי מתעדכן בהתאם לתאריך החדש.

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