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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

קישור למרכז המינויים

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

https://play.google.com/store/account/subscriptions

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

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

מצבי החלפה

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

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

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

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

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

אפשר לציין מצב ברירת מחדל להחלפה ב-Google Play Console. ההגדרה הזו מאפשרת לכם לבחור מתי לחייב מנויים קיימים אם הם רוכשים מינוי בסיסי שונה או מבצע שונה עבור אותו מינוי, או נרשמים מחדש אחרי ביטול. האפשרויות הזמינות הן Charge immediately (חיוב מיידי), שזהה ל-CHARGE_FULL_PRICE, ו-Charge at the next billing date (חיוב במועד התשלום הבא), שזהה ל-WITHOUT_PRORATION. אלה הם מצבי ההחלפה הרלוונטיים היחיד כשעוברים בין מינויים בסיסיים באותו מינוי.

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

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

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

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

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

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

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

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

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

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

WITH_TIME_PRORATION

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

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

WITHOUT_PRORATION

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

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

DEFERRED

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

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

CHARGE_FULL_PRICE

המינוי של Samwise ל-Tier 1 יסתיים באופן מיידי. המינוי שלו לרמה 2 מתחיל היום והוא חויב ב-36$. מכיוון שהוא שילם על חודש שלם אבל השתמש רק בחצי ממנו, חצי מהמינוי לחודש (1$) יוחל על המינוי החדש שלו. מכיוון שהמינוי החדש עולה 36 $לשנה, יתווסף לו 1/36 שנה לתקופת המינוי (כ-10 ימים). לכן, החיוב הבא של Samwise יהיה 36 $בעוד שנה ו-10 ימים. לאחר מכן, הוא יחויב ב-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 במשאב המינוי. חשוב לבטל את התוקף של האסימון שסופק ב-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 באוגוסט.
• אם החלטתם לכלול תקופת ניסיון בחינם או מחיר מבוא במחיר המוצר לשחזור הלקוחות, עליכם לוודא שהמשתמש עומד בדרישות. לשם כך, צריך לבטל את הסימון בתיבה Allow one free trial per app (מתן אפשרות לתקופת ניסיון בחינם אחת לכל אפליקציה) ב-Google Play Console. הסימון בתיבה הזו מגביל את המשתמש לקבלת תקופת ניסיון בחינם אחת לכל אפליקציה.

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

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

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

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

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

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

• כדי להציע למשתמשים הנחה, כדאי להציע מזהה מוצר עם מחיר מיוחד למינוי, שנקרא גם מק"ט להחזרת לקוחות. אתם יכולים להציג את המבצע באפליקציה, או להודיע למשתמש על המבצע מחוץ לאפליקציה, למשל באימייל.
• כדי להתחיל מינוי להחזרת משתמשים, מפעילים את תהליך הרכישה באפליקציה ל-Android באמצעות ספריית החיוב ב-Google Play. זהו אותו תהליך כמו של מינוי חדש, אבל אתם יכולים לקבוע את המק"ט שזמין למשתמש.
• אם החלטתם לכלול תקופת ניסיון בחינם או מחיר מבוא במחיר המוצר לשחזור המשתמשים, עליכם לוודא שהמשתמש עומד בדרישות. לשם כך, צריך לבטל את הסימון של התיבה Allow one free trial per app (מתן אפשרות לתקופת ניסיון בחינם אחת לכל אפליקציה) ב-Google Play Console. הסימון של התיבה הזו מגביל את המשתמש לקבלת תקופת ניסיון בחינם אחת לכל אפליקציה.
• אם המשתמש יירשם מחדש לאותו מק"ט, הוא כבר לא יהיה זכאי לתקופות ניסיון בחינם או למחיר היכרות. חשוב לוודא שכך מוצג הממשק המשתמש.

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

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

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

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

קידום המינוי

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

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

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

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

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

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

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

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

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

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

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

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