מינוי עם תוספים

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

שיקולים

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

• מינוי עם חבילות ערוצים נתמך רק במינויים בסיסיים שמתחדשים אוטומטית.

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

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

• התכונה הזו לא זמינה באזורים הודו (IN) וקוריאה הדרומית (KR).

שילוב עם ספריית החיובים ב-Play

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

הפעלת תהליך רכישה

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

1. אפשר לאחזר את כל הפריטים במינוי באמצעות השיטה BillingClient.queryProductDetailsAsync.

2. מגדירים את אובייקט ProductDetailsParams לכל פריט.

   הפריט שמיוצג על ידי אובייקט ProductDetailsParams, מציין גם את ProductDetails שמציין את פריט המינוי, וגם את offerToken שבוחר מינוי ספציפי base plan או offer.

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

BillingClient billingClient = …;

int replacementMode =…;

// ProductDetails obtained from queryProductDetailsAsync().
ProductDetailsParams productDetails1 = ...;
ProductDetailsParams productDetails2 = ...;
ProductDetailsParams productDetails3 = ...;

ArrayList newProductDetailsList = 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

כשמשתמשים ב-SubscriptionUpdateParams

הודעות בזמן אמת למפתחים

השדה 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. בשדה ItemBasedRefund אפשר להגדיר את productId של הפריט שצריך לבטל את הגישה אליו ולזכות את המשתמש על הרכישה שלו.

אפשר להגדיר את השדה 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:

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

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