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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

WITH_TIME_PRORATION

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

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

CHARGE_PRORATED_PRICE

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

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

WITHOUT_PRORATION

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

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

DEFERRED

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

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

CHARGE_FULL_PRICE

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

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

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

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

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 באוגוסט.

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

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

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

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

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

מידע נוסף על שחזור מינויים זמין במאמר שחזורים.

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

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

• כדי להציע למשתמשים הנחה, כדאי להציע מזהה מוצר עם תמחור מיוחד למינוי, שנקרא גם מק"ט להחזרת לקוחות. אתם יכולים להציע את המבצע באפליקציה או להודיע למשתמש על המבצע מחוץ לאפליקציה, למשל באימייל.
• כדי להתחיל מינוי להחזרת לקוחות, מפעילים את תהליך הרכישה באפליקציית Android באמצעות ספריית החיובים ב-Google Play. זהו אותו תהליך כמו במינוי חדש, אבל אתם יכולים לקבוע את מספר המלאי (SKU) שיהיה זמין למשתמש.
• אם אתם רוצים לכלול תקופת ניסיון בחינם או מחיר מבצע במק"ט של קמפיין להחזרת לקוחות לא פעילים, אתם צריכים לוודא שהמשתמש עומד בדרישות. לשם כך, צריך לבטל את הסימון של התיבה אפשר תקופת ניסיון אחת בחינם לכל אפליקציה ב-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 במאי, שישה שבועות אחרי תאריך החיוב הקודם שלה, 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. הודעה מסוג SubscriptionNotification SUBSCRIPTION_PURCHASED נשלחת ללקוח RTDN. רק בשלב הזה צריך להחליף את אסימון הרכישה הישן באסימון הרכישה החדש ולעדכן את הגישה של המשתמש לתוכן. אם תוקף העסקה יפוג או שהיא תבוטל, הודעה מסוג SUBSCRIPTION_PENDING_PURCHASE_CANCELED עם הערך SubscriptionNotification תישלח ללקוח RTDN. במקרים כאלה, למשתמש עדיין צריכה להיות גישה לתוכן של המינוי הישן.