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

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

שיקולים

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

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

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

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

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

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

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

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

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

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

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

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

   הערה: כל הפריטים בProductDetails צריכים להיות מאותה אפליקציה.

3. מציינים את פרטי הפריט בשיטה BillingFlowParams.Builder.setProductDetailsParamsList. המחלקה BillingFlowParams מציינת את הפרטים של תהליך הרכישה.

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

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

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

   הערה: רכישה באפליקציה עדיין תיוצג על ידי האובייקט Purchase. השיטה getProducts() מחזירה זכויות גישה לכל הפריטים שהמשתמש רכש.

כללים שחלים על פריטים ברכישה

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

עיבוד רכישות

תהליך העיבוד של מינוי עם חבילות זהה לתהליך העיבוד של רכישת מינוי יחיד, כפי שמתואר במאמר שילוב של ספריית החיובים ב-Google Play באפליקציה. ההבדל היחיד הוא שהמשתמש יכול לקבל כמה הרשאות ברכישה אחת. רכישה של מינוי עם חבילות מחזירה כמה פריטים שאפשר לאחזר באמצעות Purchase.getProducts() בספריית החיובים ב-Google Play, ואז את הרשימה lineItems ב-purchases.subscriptionsv2.get של ממשק API של Google Play למפתחים.

הערה: לכל קריאה של launchBillingFlow API, יש מגבלה של 50 פריטים (פריטים פעילים + פריטים חדשים). אם יש בעגלה יותר מ-50 פריטים, Google Play חוסם את תהליך הרכישה.

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

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

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

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

בדוגמה הבאה אפשר לראות איך קוראים ל-API‏ launchBillingFlow כשמשנים רכישה קיימת של מינוי עם חבילות:

Java

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

פריטים קיימים	פריטים ששונו	האם צריך להגדיר את מצב ההחלפה ב-SubscriptionProductReplacementParams?	התנהגות
A (פריט בסיסי), B	‫A (פריט בסיסי)	כן (שימוש ב-KEEP_EXISTING)	פריט ב' מתוזמן להסרה מושהית. פריט א' נשמר. המשתמשים ימשיכו לשלם את המחיר הנוכחי של פריט א', כולל כל יתרה של תשלומים במחיר מבצע שהם קיבלו בזמן ההרשמה.
A	‫A (פריט בסיס), B	כן (משתמשים ב-KEEP_EXISTING עבור A)	פריט ב' נוסף באופן מיידי עם חיוב יחסי. פריט א' נשמר. המשתמשים ימשיכו לשלם את המחיר הנוכחי של פריט א', כולל כל יתרה של תשלומים במחיר מבצע שהם קיבלו בזמן ההרשמה.
A (פריט בסיסי), B	‫A (פריט בסיסי), C	כן (משתמשים ב-KEEP_EXISTING עבור A)	הסרת B נדחית. המשתמש C יתווסף מיד עם חיוב יחסי. פריט א' נשמר. המשתמשים ימשיכו לשלם את המחיר הנוכחי של פריט א', כולל כל יתרה של תשלומים במחיר מבצע שהם קיבלו בזמן ההרשמה.
‫A (פריט בסיס), B	B (פריט בסיסי)	לא	מתוזמנת הסרה מושהית של A.
A (פריט בסיסי), B	C (פריט בסיסי)	כן	התחליף ל-A -> C תלוי ב-SubscriptionProductReplacementParams replacementMode הסרת B נדחית.
A (פריט בסיסי), B	C (פריט בסיסי), B	כן	ההחלפה של A -> C תלויה ב-SubscriptionProductReplacementParams replacementMode. כדי להשאיר את פריט B ללא שינוי, מגדירים את מצב ההחלפה שלו כ-KEEP_EXISTING.
A (פריט בסיסי), B	C (פריט בסיס), D	כן	ההחלפה של A -> C תלויה ב-SubscriptionProductReplacementParams replacementMode. הסרת B נדחית. המשתמש D יתווסף מיד עם חיוב יחסי.
‫A (פריט בסיס), B	‫A (פריט בסיסי), C	כן	ההחלפה של A -> A ו-B -> C תלויה במצב ההחלפה שמופיע ב-SubscriptionProductReplacementParams replacementMode בכל ProductDetailsParams. כדי להשאיר את פריט א' ללא שינוי, מגדירים את מצב ההחלפה שלו כ-KEEP_EXISTING.
א' (פריט בסיס), ב', ג'	‫D (פריט בסיסי), B, ‏ C	כן	ההחלפה של A->D ו-B->B, C->C תלויה במצב ההחלפה שמופיע ב-SubscriptionProductReplacementParams replacementMode בכל ProductDetailsParams. כדי שהפריטים B ו-C יישארו ללא שינוי, צריך להגדיר את מצב ההחלפה שלהם כ-KEEP_EXISTING.

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

פריטים קיימים	פריטים ששונו	האם צריך להגדיר את פרטי ההחלפה?	התנהגות
A (פריט בסיסי), B	‫A (פריט בסיסי)	לא	פריט ב' מתוזמן להסרה מושהית. ההתנהגות של פריט א' תלויה בהגדרה שינויים במינוי הבסיסי ובמבצע של המינוי הבסיסי. המחיר של פריט א' מתעדכן למחיר העדכני, ויכול להיות שהמשתמשים יאבדו את התשלומים הראשוניים שקיבלו במהלך ההרשמה, בהתאם לקריטריונים לזכאות להטבה.
A	A (פריט בסיסי), B	לא	פריט ב' נוסף באופן מיידי עם חיוב יחסי. ההתנהגות של פריט א' תלויה בהגדרה שינויים במינוי הבסיסי ובמבצע של המינוי הבסיסי. המחיר של פריט א' מתעדכן למחיר האחרון, ויכול להיות שהמשתמשים יאבדו את התשלומים הראשוניים שקיבלו במהלך ההרשמה, בהתאם לקריטריונים לזכאות להטבה.
A (פריט בסיסי), B	‫A (פריט בסיסי), C	לא	הסרת B נדחית. המשתמש C יתווסף מיד עם חיוב יחסי. ההתנהגות של פריט א' תלויה בהגדרה שינויים במינוי הבסיסי ובמבצע של המינוי הבסיסי.
A (פריט בסיסי), B	B (פריט בסיסי)	לא	מתוזמנת הסרה מושהית של A.
A (פריט בסיסי), B	C (פריט בסיסי)	כן	ההחלפה של A -> C תלויה ב-setSubscriptionReplacementMode (הוצא משימוש ב-PBL 8.1). הסרת B נדחית.
A (פריט בסיסי), B	C (פריט בסיסי), B	כן	ההחלפה של A -> C תלויה ב-setSubscriptionReplacementMode (הוצא משימוש ב-PBL 8.1).
A (פריט בסיסי), B	C (פריט בסיס), D	כן	ההחלפה של A -> C תלויה ב-setSubscriptionReplacementMode (הוצא משימוש ב-PBL 8.1). הסרת B נדחית. המשתמש D יתווסף מיד עם חיוב יחסי.

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

השדה 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.subscriptions.refund (deprecated) בנוגע למינוי עם חבילות.

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

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

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

דיווח פיננסי והתאמה

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

ללוחות בקרה ב-Play Console:

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

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