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

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

שיקולים

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

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

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

• אפשר לכלול עד 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 של ממשק API של Google Play למפתחים.

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

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

כדי לשנות או לשחזר רכישה קיימת של מינוי עם חבילות, אתם צריכים לקרוא ל-API‏ launchBillingFlow עם פרמטרים נוספים, ולוודא את הדברים הבאים:

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

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

ביטול מינויים עם חבילות ומתן החזר כספי עליהם

ריכזנו כאן כמה מההנחיות לביטול מינויים ולמתן החזרים כספיים:

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

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

• מתקשרים אל purchases.subscriptionsv2.revoke כדי לבטל באופן מיידי את הגישה לכל פריטי המינוי. בעזרת ה-API הזה תוכלו:

  • לבטל את הגישה לכל הפריטים ולספק החזר כספי יחסי.

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

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

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

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

כדי לבטל פריטי מינוי בודדים במינוי עם חבילות הרחבה בלי לבטל את הרכישה כולה, צריך להתקשר אל purchases.subscriptionsv2.revoke עם השדה ItemBasedRefund שמוגדר ב-RevocationContext. אפשר להגדיר את productId של הפריט שצריך לבטל את הגישה אליו ולזכות את הלקוח בשדה ItemBasedRefund.

אפשר להגדיר את השדה ItemBasedRefund לרכישות של פריט אחד או יותר של מינוי עם חידוש אוטומטי.

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

שיקולים

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

דחיית החיוב

אפשר להקדים את תאריך החיוב הבא של מינוי עם חבילות תכונות באמצעות השיטה Purchases.subscriptionsv2:defer.

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

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

SUBSCRIPTION_DEFERRED התראה בזמן אמת למפתחים מופעלת כשמתבצעת הפעולה הזו.

תוקף הפריט פג במהלך דחיית התשלום

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

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

בחירת תקופת שחזור

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

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

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

תקופת חסד

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

השהיית חשבון

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

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

דוגמה:

• למשתמש יש מינוי ל-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:

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

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