מינוי עם חבילות מאפשר לכם לשלב כמה מוצרים במינוי אחד שאפשר לרכוש, לחייב ולנהל יחד. אפשר להציע את המינויים הקיימים לקטלוג המוצרים כתוספים בלי צורך בהגדרה מראש או בהגדרה נוספת. אתם יכולים להפעיל תהליך רכישה עם כמה מוצרי מינוי קיימים ולמכור אותם כחבילות.
שיקולים
כדאי לקחת בחשבון את הנקודות הבאות כשמשתמשים בתכונה 'מינוי עם חבילות ערוצים':
מינוי עם חבילות ערוצים נתמך רק במינויים בסיסיים שמתחדשים אוטומטית.
כל הפריטים ברכישה חייבים להיות עם אותה תקופה של חיוב חוזר. לדוגמה, אי אפשר ליהנות ממינוי עם חיוב שנתי ועם חבילות ערוצים עם חיוב חודשי.
אפשר להוסיף עד 50 פריטים למנוי עם רכישות של חבילות.
התכונה הזו לא זמינה באזורים הודו (IN) וקוריאה הדרומית (KR).
שילוב עם ספריית החיובים ב-Play
בקטע הזה מוסבר איך לשלב את התכונה 'מינוי עם חבילות' עם ספריית החיוב של Play (PBL). ההנחה היא שאתם מכירים את השלבים הראשוניים לשילוב של PBL, כמו הוספת התלות של PBL לאפליקציה, אתחול של BillingClient והתחברות ל-Google Play. החלק הזה מתמקד בהיבטים של שילוב PBL שספציפיים למינוי עם חבילות ערוצים.
הפעלת תהליך רכישה
כדי להפעיל תהליך רכישה של מינוי עם חבילות ערוצים, מבצעים את השלבים הבאים:
אפשר לאחזר את כל פריטי המינוי באמצעות השיטה
BillingClient.queryProductDetailsAsync.מגדירים את אובייקט
ProductDetailsParamsלכל פריט.הפריט שמיוצג על ידי אובייקט
ProductDetailsParams, מציין גם אתProductDetailsשמציין את פריט המינוי, וגם אתofferTokenשבוחר מינוי ספציפיbase planאוoffer.מציינים את פרטי הפריט בשיטה
BillingFlowParams.Builder.setProductDetailsParamsList. המחלקותBillingFlowParamsמציינות את הפרטים של תהליך הרכישה.בדוגמה הבאה אפשר לראות איך מפעילים את תהליך החיוב לרכישת מינוי עם כמה פריטים:
Java
BillingClient billingClient = …; // ProductDetails obtained from queryProductDetailsAsync(). ProductDetailsParams productDetails1 = ...; ProductDetailsParams productDetails2 = ...; ArrayList
productDetailsList = new ArrayList<>(); productDetailsList.add(productDetails1); productDetailsList.add(productDetails2); BillingFlowParams billingFlowParams = BillingFlowParams.newBuilder() .setProductDetailsParamsList(productDetailsList) .build(); billingClient.launchBillingFlow(billingFlowParams);
הכללים שחלים על הפריטים ברכישה
- כדי לוודא שתאריכי החידוש של התוסף יתאימו בסופו של דבר למוצר הבסיסי, יכול להיות ש-Google Play יוסיף חיוב יחסי אחרי תקופת ניסיון או תקופת מחיר היכרות.
- הזכאות למבצע תיבדק בנפרד לכל פריט.
עיבוד רכישות
תהליך העיבוד של מינוי עם חבילות הוא זהה לתהליך העיבוד של רכישות של פריט יחיד, כפי שמתואר במאמר שילוב ספריית החיובים ב-Google Play באפליקציה. ההבדל היחיד הוא שהמשתמש יכול לקבל כמה זכויות גישה ברכישה אחת. רכישת מינוי עם חבילות תוכן
מחזירה כמה פריטים שאפשר לאחזר באמצעות
Purchase.getProducts() בספריית החיוב של Google Play, ואז הרשימה lineItems ב-purchases.subscriptionsv2.get של Google Play Developer API.
שינוי מינויים עם חבילות
כל שינוי במינוי עם חבילות ערוצים מוביל לשדרוג או לשדרוג לאחור. מידע נוסף זמין במאמר בנושא שדרוג או ש הנמכה של מינויים.
כדי לשנות או לשחזר רכישה קיימת של מינוי עם חבילות בערוץ שלכם, אתם צריכים לקרוא ל-API launchBillingFlow עם פרמטרים נוספים, ולוודא את הדברים הבאים:
- תמיד מתקשרים אל
setOldPurchaseTokenעם אסימון הרכישה של רכישת המינוי הנוכחית. - כדי לשדרג, לשדרג לאחור או לשדרג פריט לגרסה אחרת, מתקשרים למספר
SubscriptionProductReplacementParams.setReplacementModeומציינים איך צריך לטפל בשינוי המינוי בין פריט הרכישה הישן לחדש. אחרת, אין צורך להגדיר את הפרמטר הזה. - אם פריט הבסיס לא משתנה, עדיין אפשר להשתמש בשיטה
SubscriptionProductReplacementParams.setSubscriptionReplacementModeכדי להחיל התנהגות החלפה ספציפית. לכללים הרלוונטיים במקרה הזה, אפשר לעיין במאמר חידוש המינוי או מעבר לתוכנית אחרת באותו מינוי. - התוספים החדשים יחולו באופן מיידי, ותחויבו בסכום יחסי כדי שתאריך החידוש הבא יהיה זהה לתאריך החידוש של המינוי הבסיסי.
- התוקף של חבילות הערוצים שהוסרו יפוג בסוף תקופות החיוב הנוכחיות שלהן.
- כשמפעילים את תהליך החיוב, צריך לציין את כל הפריטים הפעילים במינוי עם חבילות, למעט הפריטים שרוצים להסיר, וגם את כל החבילות החדשות.
בדוגמה הבאה אפשר לראות איך קוראים ל-API launchBillingFlow כשמשנים רכישה קיימת של מינוי עם חבילות:
Java
BillingClient billingClient = …; int replacementMode =…; // ProductDetails obtained from queryProductDetailsAsync(). ProductDetailsParams productDetails1 = ...; ProductDetailsParams productDetails2 = ...; ProductDetailsParams productDetails3 = ...; ArrayListnewProductDetailsList = new ArrayList<>(); newProductDetailsList.add(productDetails1); newProductDetailsList.add(productDetails1); newProductDetailsList.add(productDetails1); BillingFlowParams billingFlowParams = BillingFlowParams.newBuilder() .setSubscriptionUpdateParams( SubscriptionUpdateParams.newBuilder() .setOldPurchaseToken(purchaseTokenOfExistingSubscription) // No need to set if change does not affect the base item. .setSubscriptionReplacementMode(replacementMode) .build()) .setProductDetailsParamsList(productDetailsList) .build(); billingClient.launchBillingFlow(billingFlowParams);
תרחישים של שינוי מינוי
בטבלה הבאה מפורטים תרחישים שונים של שינויים במינוי עם חבילות, וההתנהגות המתאימה לכל תרחיש.
כשמשתמשים ב-SubscriptionProductReplacementParams
| פריטים קיימים | פריטים ששונו | צריך להגדיר את מצב ההחלפה ב-SubscriptionProductReplacementParams? | התנהגות |
|---|---|---|---|
| A (פריט בסיס), B | A (פריט בסיסי) | כן (שימוש ב-KEEP_EXISTING) |
|
| A | A (פריט בסיס), B | כן (שימוש ב-KEEP_EXISTING עבור A) |
|
| A (פריט בסיס), B | א' (פריט בסיסי), ג' | כן (שימוש ב-KEEP_EXISTING עבור A) |
|
| A (פריט בסיס), B | B (פריט בסיסי) | לא | A מתוזמן להסרה מושהית. |
| A (פריט בסיס), B | C (פריט בסיסי) | כן |
|
| A (פריט בסיס), B | C (פריט בסיסי), B | כן |
|
| A (פריט בסיס), B | C (פריט בסיס), D | כן |
|
| A (פריט בסיס), B | א' (פריט בסיסי), ג' | כן |
|
| A (פריט בסיס), B, C | ד' (פריט בסיס), ב', ג' | כן |
|
כשמשתמשים ב-SubscriptionUpdateParams
| פריטים קיימים | פריטים ששונו | האם צריך להגדיר את פרטי ההחלפה? | התנהגות |
|---|---|---|---|
| A (פריט בסיס), B | A (פריט בסיסי) | לא |
|
| A | A (פריט בסיס), B | לא |
|
| A (פריט בסיס), B | א' (פריט בסיסי), ג' | לא |
|
| A (פריט בסיס), B | B (פריט בסיסי) | לא | A מתוזמן להסרה מושהית. |
| A (פריט בסיס), B | C (פריט בסיסי) | כן |
|
| A (פריט בסיס), B | C (פריט בסיסי), B | כן | ההחלפה של A -> C תלויה ב-setSubscriptionReplacementMode (הוצא משימוש ב-PBL 8.1). |
| A (פריט בסיס), B | C (פריט בסיס), D | כן |
|
הודעות בזמן אמת למפתחים
השדה subscriptionId לא מסופק ב-RTDN לרכישות של מינוי עם חבילות, שמכילות כמה זכויות לפריטים.
במקום זאת, אפשר להשתמש בממשקי Play Developer API כדי לקבל את הרכישה ולראות את ההרשאות המשויכות לפריט.
שינויים במחיר למנויים קיימים
שינוי מחירי המינויים למנויים קיימים של מינוי עם רכישות של חבילות דומה לשינוי מחירי המינויים של מינויים עם פריט יחיד, כפי שמתואר במאמר שינוי מחירי המינויים. עם זאת, יש כמה מגבלות והבדלים פונקציונליים, כפי שמתואר בקטע הזה.
סיום של קבוצת תמחור קודמת בעלת מאפיינים משותפים
ביטול של קבוצת מחירים קודמת משפיע גם על רכישות של מינויים עם חבילות. הכללים הבאים חלים:
כל העלאות המחיר שממתינות להבעת הסכמה צריכות להיות עם אותו זמן חידוש עם המחיר החדש. אם יש פריט במינוי עם רכישות של חבילות שמוגדרת לו העלאת מחיר בכפוף להסכמה מצד המשתמש, והמשתמש עדיין לא אישר את העלאת המחיר, המערכת תתעלם מכל העלאת מחיר חדשה בכפוף להסכמה של פריטים אחרים ברכישה, אלא אם היא תוביל לאותו מועד חידוש של המחיר החדש כמו העלאת המחיר הקיימת במצב OUTSTANDING. אחרי שהמשתמש יאשר את העלייה במחיר, כל שינוי מחיר חדש יותר יירשם. בנוסף, המשתמשים יכולים לאשר את כל העלאות המחירים שלא אושרו בבת אחת.
דוגמה:
- נניח שיש לכם מינוי עם חבילות (פריטים א' וב'), שמתחדש ב-7 בכל חודש.
- מחיר פריט א' עובר שינוי מ-7 $ ל-10 $, והעלייה במחיר צפויה לחול ב-7 ביולי.
- העברת מחירים חדשה מ-5 $ל-6 $מתחילה בפריט B ב-2 ביוני. מכיוון שהעלאת המחיר עם אפשרות לסירוב מתחילה 37 ימים אחרי ההעברה, העלאת המחיר הכי מוקדמת של פריט ב' תהיה ב-7 באוגוסט.
בתרחיש הזה, עד שהמשתמש יאשר את שינוי המחיר של פריט א' (עד שהסטטוס שלו יהיה CONFIRMED), שינוי המחיר של פריט ב' לא יירשם ברכישת המינוי הזו, והשיטה SubscriptionPurchaseV2 לא תחזיר פרטים על שינוי המחיר של פריט ב'. אחרי שהמשתמש מאשר את שינוי המחיר של פריט א', מתחיל שינוי המחיר של פריט ב'. המשתמש מקבל את העלאת המחיר בכפוף להסכמה על פריט ב' רק אחרי שהוא מאשר את העלאת המחיר בכפוף להסכמה על פריט א'.
האימייל מ-Google Play מכיל רשימה של כל הפריטים שהמחירים שלהם עלו או ירדו באותו היום.
ביטול מינוי עם חבילות
המשתמשים יכולים לבטל את הרכישה כולה של מינוי עם חבילות ערוצים במרכז המינויים של Play, ואתם יכולים לבטל את הרכישה כולה של מינוי עם חבילות ערוצים רק באמצעות Google Play Developer API.
כשמבטלים רכישת מינוי בלי לבטל את הגישה, המינוי לא מתחדש אוטומטית, אבל למשתמש תהיה גישה לפריטים שכלולים במינוי, כולל תקופות ניסיון בחינם, עד סוף תקופת החיוב הרלוונטית.
ביטול מינויים עם חבילות ומתן החזר כספי עליהם
ריכזנו כאן כמה הנחיות לביטול מינויים ולמתן החזרים כספיים:
אפשר להשתמש ב-Play Console כדי להנפיק החזר כספי על סכום מסוים בהזמנה ספציפית בלי לבטל את הגישה למינוי.
מתקשרים אל
orders.refundכדי להחזיר החזר מלא על תשלומים ספציפיים על מינוי שהמשתמש ביצע, בלי לבטל את הגישה למינוי.מתקשרים אל
purchases.subscriptionsv2.revokeכדי לבטל באופן מיידי את הגישה לכל פריטי המינוי. בעזרת ה-API הזה תוכלו:לבטל את הגישה לכל הפריטים ולספק החזר כספי יחסי.
כשמבטלים מינוי עם חבילות, מתבצע החזר כספי יחסי על ההזמנה האחרונה של כל פריט, בהתאם לזמן שנותר עד לחידוש הבא.
לבטל את הגישה לכל הפריטים ולספק החזר כספי מלא.
ביטול הגישה לפריט ספציפי עם החזר כספי מלא על הפריט.
ביטול של פריט בודד במינוי עם חבילות
כדי לבטל פריטי מינוי בודדים במינוי עם חבילות הרחבה בלי לבטל את הרכישה כולה, צריך להתקשר אל purchases.subscriptionsv2.revoke עם השדה ItemBasedRefund שמוגדר ב-RevocationContext. אפשר להגדיר את productId של הפריט שצריך לבטל את הגישה אליו ולזכות את המשתמש בשדה ItemBasedRefund.
אפשר להגדיר את השדה ItemBasedRefund לרכישות של פריט אחד או יותר של מינוי עם חידוש אוטומטי.
- אם עדיין יש פריטים פעילים ברכישת המינוי אחרי ביטול הפריט שצוין ב-
ItemBasedRefund, רק הפריט הזה יבוטל ותקבלו עליו החזר כספי מלא בלי שהסטטוס של המינוי ישתנה. - אם לא נשארו פריטים פעילים ברכישת המינוי אחרי ביטול הפריט שצוין ב-
ItemBasedRefund, הפריט יבוטל, יוחזר עליו החזר כספי מלא והמינוי יבוטל.
שיקולים
- כשמשתמשים ב-
ItemBasedRefundאפשר לבטל את הגישה רק לפריט אחד בכל פעם. אפשר להפעיל את הבקשה כמה פעמים אם צריך לבטל את הגישה לכמה פריטים. - אם רכישת המינוי נמצאת באחד מהמצבים של דחיית התשלום, או אם הפריט שצוין ב-
ItemBasedRefundלא נמצא בבעלות המשתמש או שתוקפו פג, הפריט לא יוחזר. - אי אפשר להפחית את מספר הפריטים במינוי בתשלום מראש.
תוקף הפריט פג במהלך דחיית התשלום
ברכישת מינוי עם תוספים, יכול להיות שחידושים מסוימים יצטרכו רק להאריך קבוצת משנה של הרשאות לפריטים, בלי להשפיע על פריטים עם תאריך תפוגה עתידי.
לא משנה אילו פריטים נכללים בחידוש, אם התשלום על החידוש נדחה, רכישת המינוי הכוללת תיכנס לתקופת חסד והחשבון יוקפא, כמו שמתואר במסמכים הבאים.
בחירת תקופת השחזור
מכיוון שתקופת החסד עדיין מעניקה למשתמש זכאות, אם מתבצעת רכישה של מינוי עם חבילות, התשלום על החידוש נדחה, נבחר הפריט עם תקופת החסד המינימלית מבין כל הפריטים הפעילים, ותקופת החסד ותקופת ההשהיה של החשבון שלו מוחלות כפרק הזמן לשחזור המינוי.
פריטים פעילים כוללים פריטים שהיו פעילים ברכישת מינוי עם חבילות ערוצים ממש לפני הניסיון לחידוש המינוי. הם לא כוללים פריטים חדשים שנוספו (שלא יהיו זכאים עד אחרי השחזור), וגם לא פריטים שכבר לא פעילים כי הם הוסרו או בוטלו.
ההגדרה של השהיית החשבון של הפריט עם תקופת החסד המינימלית שנבחרה מוחלת. אם יש יותר מפריט אחד עם תקופת החסד המינימלית, אבל תקופות שונות של השהיית החשבון, תוחל תקופת ההשהיה הארוכה ביותר.
תקופת חסד
כשנדחה תשלום על חידוש מינוי, המינוי עובר למצב של תקופת חסד. במהלך תקופת החסד, למשתמש תהיה גישה לכל הפריטים הפעילים מתקופת החידוש הקודמת. אם לא תתקנו את אמצעי התשלום במהלך תקופת החסד, כל הרכישה של המינוי תועבר להשהיית החשבון. אם פריטים אחרים יגיעו לתאריך החידוש שלהם במהלך תקופת החסד, יתבצע ניסיון חיוב חדש עבור הפריטים האלה ברגע שהמינוי יחזור לפעולה אחרי שהתשלום ייכשל.
השהיית חשבון
בזמן שהרכישה של המינוי נמצאת בהמתנה בחשבון, הגישה לכל הפריטים במינוי מושעית עד שהתשלום יתקבל.
אם המינוי בהמתנה יחודש, רכישת המינוי תמשיך להתקיים כמו שהיא. אם המינוי לא יחודש, תוקף הפריטים שנדחו בגלל בעיה בתשלום יפוג, והגישה לפריטים האחרים תחודש למשך יתרת תקופות החיוב שלהם.
דוגמה:
למשתמש יש מינוי ל-My Base Plan שמתחדש ב-1 בכל חודש. ב-15 באוגוסט הוא מוסיף מינוי לחבילת ערוצים במחיר של 10 $לחודש עם תקופת ניסיון בחינם למשך שבעה ימים. לא הוגדרה תקופת חסד לאף אחד מהפריטים, ובשניהם הוגדרה תקופת השהיית חשבון של 30 יום.
ב-22 באוגוסט, המשתמש מחויב ב-2.90$ (10*9/31) על החלק היחסי של המינוי עד 31 באוגוסט, אבל אמצעי התשלום של המשתמש פג לפני כן, והמינוי נדחה ב-22 באוגוסט.
כשהמינוי מושהה בגלל דחיית תשלום, למשתמש אין גישה לאף אחד מהפריטים במינוי עם חבילות הערוצים. הזמן שנותר לשימוש בפריטים שלא יחודש יוחזר למשתמשים כשהמינוי יוסר מההמתנה, כי התשלום שוחזר או כי המינוי בוטל.
בדוגמה הקודמת, המינוי נכנס להקפאת החשבון ב-22 באוגוסט.
אם החשבון ישוחזר ב-25 באוגוסט, לפני תאריך החידוש הכללי ב-1 בספטמבר, המשתמש יקבל גישה מחדש ל-My Base Plan ול-Add on plan באותו היום. תאריך החיוב הבא השתנה ל-4 בספטמבר.
אם החשבון לא ישוחזר אחרי 30 יום, המינוי יבוטל ב-21 בספטמבר והמשתמש יאבד את הגישה לתוכנית התוסף, ויקבל גישה לתוכנית הבסיס שלי עד 30 בספטמבר.
בדוגמה הזו, צריך לקבל את הערך המעודכן של expiryTime לכל הפריטים במינוי עם חבילות הערוצים, כי יכול להיות שחלק מהפריטים יחזרו להיות זמינים אחרי תקופת החסד וההשעיה של החשבון.
דיווח פיננסי והתאמה
אפשר להשתמש בדוח הרווחים כדי להשוות בין המינויים הפעילים לבין העסקאות ב-Play. לכל פריט בשורת עסקה יש מזהה הזמנה. אם הרכישות מייצגות כמה פריטים, בדוחות 'רווחים' ו'מכירות משוערות' יופיעו שורות נפרדות לכל עסקה, כמו חיוב, עמלה, מס והחזר כספי, לכל פריט שכלול בעסקה.
ללוחות בקרה ב-Play Console:
הנתונים הסטטיסטיים של ההכנסות שמוצגים בקטע דוחות פיננסיים במסוף מפורטים לפי פריטים.
בניהול ההזמנות משתקפת רכישה של מינוי עם חבילות, ומוצגות רשימות מפורטות של מה שנרכש. בניהול ההזמנות, אפשר לבטל רכישה של משתמש, לבטל את המינוי שלו או להעניק לו החזר כספי מלא.