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

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

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

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

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

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

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

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

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

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

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

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

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

  • מזהה הזמנה
  • זמן הרכישה
  • חתימה
  • טוקן רכישה
  • התקבל

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

https://play.google.com/store/account/subscriptions
במסך המינויים בחנות Play מוצג הסטטוס של כל המינויים של המשתמש שמחויבים ב-Google Play.
איור 1. במסך המינויים בחנות Play מוצג הסטטוס של כל המינויים של המשתמש שמחויבים ב-Google Play.


מקישים על מינוי כדי לראות פרטים נוספים.
איור 2. צריך להקיש על מינוי כדי לראות אפשרויות נוספות פרטים נוספים.

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

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

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

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

אמצעי החלפה

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

מצב החלפה

תיאור

שימוש לדוגמה

תשלומים התחייבות שנרשמו כתשלומים ששולמו (להחלפת מינוי בתשלומים)

WITH_TIME_PRORATION

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

אפשר לשדרג לרמה יקרה יותר ללא צורך בתשלום נוסף מיידי.

0

CHARGE_PRORATED_PRICE

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

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

אפשר לשדרג לרמה יקרה יותר בלי לשנות את תאריך החיוב.

1

CHARGE_FULL_PRICE

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

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

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

1 (הערה: 0 אם המינוי החדש כולל תקופת ניסיון בחינם).

WITHOUT_PRORATION

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

שדרוג לרמת מינוי גבוהה יותר תוך שמירה על התקופה שנותרה בחינם.

0

DEFERRED

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

שדרוג לאחור לרמה נמוכה יותר.

1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

WITH_TIME_PRORATION

המינוי ל-Tier 1 של Samwise מסתיים מיד. מפני שהוא שילם עבור בחודש (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 של Samwise מסתיים מיד. כי הוא שילם על חודש שלם אבל השתמש רק במחצית ממנו, חצי מהמינוי לחודש (4 ש"ח) מוחל על המינוי החדש שלו. עם זאת, מכיוון שהמינוי החדש עולה 36 $לשנה, ו-15 הימים הנותרים עולים 1.50$; ולכן הוא מחויב הפרש של 0.50 $על המינוי החדש שלו. ב-1 במאי, סמויס מחויב ב-36$ על רמת המינוי החדשה שלו וב-36 $נוספים ב-1 במאי בכל שנה לאחר מכן.

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

WITHOUT_PRORATION

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

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

DEFERRED

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

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

CHARGE_FULL_PRICE

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

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

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

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

Kotlin

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
   )
// ...

Java

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);
// ...

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

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

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

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

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

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

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

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

החלפה מראש של נקודת האחיזה

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

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

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

שעה

ProrationMode.DEFERRED (הוצא משימוש)

ReplacementMode.DEFERRED

מיד לאחר שתהליך הרכישה מסתיים בהצלחה (אפליקציה)

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

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

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

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

queryPurchasesAsync() מחזיר מיד את הרכישה עם אסימון הרכישה החדש, ואת ההרשאה המקורית שמשויכת אליו.

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

מיד לאחר שתהליך הרכישה מסתיים בהצלחה (הקצה העורפי)

subscription_PURCHASED RTDN לא נשלח אחרי תהליך הרכישה. הקצה העורפי עדיין לא מודע לרכישה החדשה.

subscription_PURCHASED RTDN עם ה-product_id הישן נשלח מיד לאחר תהליך הרכישה עבור אסימון הרכישה החדש.

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

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

SUBSCRIPTION_EXPIRED נשלח עבור אסימון הרכישה הישן. כשמפעילים את השיטה purchases.subscriptionsv2.get עם אסימון הרכישה הישן, נראה שהתוקף שלו פג (ההרשאה לתוכנית הישנה מועברת לרכישה החדשה עבור הזמן שנותר).

במכשיר חלופי – חידוש ראשון אחרי תהליך הרכישה (אפליקציה)

הפונקציה queryPurchasesAsync() מחזירה אובייקט רכישה חדש עם אסימון הרכישה החדש וההרשאה.

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

queryPurchasesAsync() מחזיר מיד את הרכישה עם אסימון הרכישה החדש, ואת ההרשאה החדשה שמשויכת אליו.

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

במסגרת החלפה – חידוש ראשון לאחר תהליך הרכישה (הקצה העורפי)

עכשיו אפשר לעבד את הרכישה החדשה ולאשר אותה כשנשלח ה-Subscription_RENEWED RTDN הראשון.

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

רכישה חדשה עובדה ואושרה כאשר ה-RTDN Subscription_PURCHASED נשלח עבור אסימון הרכישה החדש ונרשם כ-startTime.

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

כששולחים קריאה לשיטה purchases.subscriptionsv2.get עם אסימון הרכישה החדש, מוחזרת רכישה עם שני פריטים:

  • אחת שמייצגת את ההרשאה הישנה, עם 'expiryTime' בעבר וללא ערך מוגדר עבור DeferredItemReplacement.
  • אחד שמייצג את ההרשאה החדשה, עם 'expiryTime' בעתיד והסימון auto_renewing_enabled מופעל.

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

ניהול לקוחות

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

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

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

אפליקציות ללא ספריית חיובים מגרסה 2.0 ואילך: לא

אפליקציות עם ספריית חיובים מגרסה 2.0 ואילך: כן. מפתחים יכולים לבטל את ההסכמה לשימוש בתכונה ב-Play Console.
מתי המשתמש מחויב

אם משתמשים באותו מק"ט: סיום תקופת החיוב הנוכחית.

אם משתמשים במק"ט אחר: תלוי במצב יחסי.

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

זיהוי שינוי במצב המינוי

קישור עומק לחנות Play

 צריך לספק ממשק משתמש להרשמה מחדש באפליקציה טיפול ברכישות מתוך האפליקציה

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

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

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

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

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

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

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

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

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

קטע המינויים באפליקציה של חנות Google Play, שבו מוצג ביטול המינוי באמצעות לחצן להרשמה מחדש
איור 8. חשבון > הקטע 'מינויים' באפליקציה של חנות Google Play שבה מוצג מינוי שבוטל עם לחצן הרשמה מחדש.

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

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

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

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

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

לאחר תפוגת המינוי – בחנות Play

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

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

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

קידום המינוי שלך

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

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

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

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

ביטול, החזר כספי או ביטול

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

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

בטבלה הבאה מפורטים ההבדלים בין ביטול, החזר כספי, לבטל.

הפסקת החידוש החזר כספי ביטול הגישה
ביטול כן לא לא
החזר כספי לא כן לא
ביטול כן כן כן

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

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

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

חיוב שנדחה מאפשר לבצע את הפעולות הבאות:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kotlin

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.
                }
            }
        })

Java

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

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