מדריך מלא לעדכון ופריסה של ספריית החיוב של Google Play גרסה 7

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

לאורך מאמר זה תראו כיצד עדכון ויישום של ספריית החיוב של Google Play גרסה 7 שלב אחר שלב: מהשוני מ-PBL 5 ו-6, דרך שילוב מנויים, רכישות חד פעמיות, RTDN, בדיקות עם Play Billing Lab, וכיצד לשרוד במערכות אקולוגיות כמו .NET MAUI, שבהן התמיכה הרשמית מפגרת מאחור. הרעיון הוא שכאשר תסיימו לקרוא, תוכלו להכין את ההגירה שלכם בביטחון ובלי להוציא שקל.

סקירה כללית של ספריית החיוב של Google Play גרסה 7

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

גרסה זו מתמקדת בשלושה תחומים עיקריים: אפשרויות מנוי חדשות (כגון מכסות וירטואליות), תמיכה טובה יותר עבור רכישות ממתינות בתוכניות פריפיידושינויים ב-API שמנקים את מה שכבר היה מיושן בגרסאות קודמות (PBL 5 ו-6). בנוסף, גוגל מתקנת חלק מהטיפול בשגיאות וכיצד יש לטפל בעסקאות ממתינות כדי למנוע חוסר עקביות.

כדי להתחיל, במודול האפליקציה שלך עליך לעדכן את התלות בקובץ שלך. build.gradle:

dependencies {
    def billingVersion = "7.0.0"
    implementation "com.android.billingclient:billing:$billingVersion"
}

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

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

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

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

• המשתמש בוחן את המוצרים הזמינים ובוחר אחד מהם.
• האפליקציה מתחילה את תהליך החיוב של Google Play כדי להשלים את התשלום.
• הרכישה הושלמה והאפליקציה שלך מקבלת את התוצאה.
• השרת שלך מאמת את הרכישה מול ממשק ה-API של Google Play Developer.
• התוכן או הזכות המתאימים מוענקים למשתמש במערכת שלך.
• גוגל מקבלת הודעה שהרכישה עובדה (נצרכה או אושרה).

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

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

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

התראות מפתחים בזמן אמת (RTDN) ו-Google Cloud Pub/Sub

שימוש ב-RTDNs Google Cloud Pub/Sub כמערכת העברת הודעות בזמן אמת בין Google Play לשרת שלך. Google Play מפרסם אירועים בנושא Pub/Sub, ואתה נרשם לנושא זה כדי לקבל הודעות בכל פעם שסטטוס הרכישה או המנוי משתנה.

הזרימה הבסיסית פשוטה: Google Play שולח הודעה מקודדת ב-base64 לנושא Pub/Sub, המנוי שלך מחלץ אותה, מפענח אותה ומעבד את ההתראה. בתוך השדה data בתוך ההודעה תמצאו אובייקט JSON הודעת מפתחהכולל מידע כגון גרסת הודעה, שם חבילה, שעת אירוע ונתונים ספציפיים על רכישות חד פעמיות, מנויים, רכישות שבוטלו או גרסאות ניסיון.

{
  "version": string,
  "packageName": string,
  "eventTimeMillis": long,
  "oneTimeProductNotification": OneTimeProductNotification,
  "subscriptionNotification": SubscriptionNotification,
  "voidedPurchaseNotification": VoidedPurchaseNotification,
  "testNotification": TestNotification
}

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

תצורת Cloud Pub/Sub עבור RTDN

לפני הפעלת RTDN בקונסולת Google Play, עליך להכין פרויקט ב- פלטפורמת הענן של גוגל (GCP) ולהגדיר שם את Pub/Sub. התהליך פשוט יחסית, אך עדיף לעקוב אחריו בקפידה כדי להימנע מהפתעות בנוגע להרשאות או שמות משאבים.

יצירת הנושא

ראשית עליך ליצור נושא פרסום/סאב אשר ישמש כנקודת הפרסום שלך ב-Google Play. מקונסולת Google Cloud, בחר את הפרויקט שלך, עבור למקטע Pub/Sub וצור נושא חדש בהתאם למדריך הרשמי "יצירת נושא". לתוצאה יהיה שם בפורמט הבא:

projects/{project_id}/topics/{topic_name}

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

יצירת מנוי

כדי לקרוא את ההודעות בשרשור הזה, אתה צריך מנוי Pub/Subאתה יכול להגדיר את זה כ לדחוף או כמו למשוךבמעבדת הקוד של הייחוס, אנו עובדים עם מנוי pull, שבו ה-backend שלך יוזם את הבקשות לאחזור הודעות.

עליך לעיין באפשרויות במדריך המנויים של Cloud Pub/Sub כדי להחליט האם גישה לפונקציות push או pull מתאימה יותר לארכיטקטורה שלך. לאחר שתחליט, עקוב אחר התיעוד של "הוסף מנוי" וקשר אותו לנושא שיצרת קודם לכן. מנקודה זו ואילך, כל הודעה ש-Google Play מפרסם בנושא תהיה נגישה למנוי שלך.

הרשאות ל-Google Play לפרסם בתבנית שלך

Pub/Sub לא יאפשר ל-Google Play לפרסם דבר אלא אם כן תעניקו לו אישור מפורש. חשבון שירותבמסוף Google Cloud, עליך לעבור להגדרות הרשאות הנושא ולהוסיף את הרשאת הנושא הראשית:

google-play-developer-notifications@system.gserviceaccount.com

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

הפעלת RTDN ב-Google Play Console

לאחר שתצורת Pub/Sub מוגדרת, עליך להורות ל-Play Console לאן לשלוח התראות. בתוך האפליקציה שלך ב-Google Play Console, עבור אל מונטיזציה עם Play > הגדרות מונטיזציה ואתר את מדור התראות המפתחים בזמן אמת.

שם תצטרכו:

• סמן את התיבה כדי להפעיל התראות בזמן אמת.
• הזן את שם הנושא המלא של Pub/Sub בשדה המתאים, תוך הקפדה על הפורמט projects/{project_id}/topics/{topic_name}.
• שלח הודעת ניסיון באמצעות כפתור הניסיון.

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

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

Artaculo relacionado:

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

לבסוף, תוכלו להגדיר אילו סוגי התראות תרצו לקבל: רק מנויים ורכישות שבוטלו, או כל ההתראות כולל רכישות חד פעמיות (אירועים כגון ONE_TIME_PRODUCT_PURCHASED ו- ONE_TIME_PRODUCT_CANCELED). אם אתם משתמשים גם במוצרים ייחודיים, מקובל להפעיל את כל הסט כדי לשמור על נראות על הכל.

בנה מנוי Pub/Sub ב-backend שלך

לאחר שהנושא והמנוי מוכנים, הגיע הזמן ליישם מנוי שקורא ומעבד RTDNsגוגל מספקת דוגמאות במספר שפות; מקרה טיפוסי בג'אווה משתמש בספריות הלקוח של Cloud Pub/Sub כדי להפעיל Subscriber מי שומע הודעות ומתקשר MessageReceiver.

הדפוס הכללי הוא תמיד זהה: אתה מאחזר את ההודעה, אתה מפענח את השדה data אתה ממיר base64 לטקסט, מנתח את ה-JSON ומחלץ את השדות הרלוונטיים (כגון packageName, oneTimeProductNotification o subscriptionNotification) ולהחליט מה לעשות במערכת שלך. לאחר עיבוד מוצלח של ההודעה, עליך אשר את ההודעה באמצעות אישור כדי ש-Pub/Sub לא ישלח את זה שוב.

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

קישור התראות למשתמש: באמצעות obfuscatedAccountId

בעיה נפוצה בעת ניהול רכישות מהשרת היא לדעת לאיזה משתמש שייכת הודעת RTDN ספציפית. לשם כך, ממשק ה-Billing Client API מאפשר לך לצרף מזהה חשבון מעורפל כאשר אתה מפעיל את תהליך הרכישה: obfuscatedAccountId.

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

בצד הלקוח, בעת הכנת ה- BillingFlowParamsאתה רק צריך לבנות את הרשימה של ProductDetailsParams ולהתקשר setObfuscatedAccountId(obfuscatedAccountId) לפני הפעלת הזרימה. זה לא משנה את חוויית המשתמש הנראית לעין, אבל זה מפשט מאוד את התהליך. לוגיקת הקצאת רכישות אחורית ועוזר לגוגל לזהות הונאות.

אימות רכישות באמצעות Google Play Developer API

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

במקרה של מוצרים ייחודיים, תשתמשו בנקודת הקצה purchases.products:getעבור מנויים, הנתיב מוביל דרך purchases.subscriptionsv2:getהזרימה המומלצת היא:

• חלץ את purchaseToken מהודעת Pub/Sub.
• בדוק את מסד הנתונים שלך כדי לראות אם כבר עיבדת אותו; כל אסימון הוא ייחודי ברמה עולמיתאז זה מושלם כמפתח ראשי כדי למנוע כפילויות.
• אם זה חדש, קרא ל-Google Play Developer API עם החבילה, ה-SKU וה- purchaseToken.
• ודא שהתגובה מציינת סטטוס רכישה נרכש (לא בהמתנה או מבוטל).
• אם הכל תואם, רשום את הטוקן והענק את ההרשאה המתאימה למשתמש המשויך.

כדי לתקשר עם ממשק ה-API של Play Developer מ-Java, ניתן להשתמש מפרסם אנדרואיד, מאותחל עם אישורי חשבון שירות בפורמט JSON. אתה מגדיר את ההיקף AndroidPublisherScopes.ANDROIDPUBLISHERאתה בונה את הלקוח וקורא למתודה purchases().products().get(...)אם השיחה נכשלת עקב בעיית רשת או שירות זמנית, מומלץ יישום ניסיונות חוזרים עם נסיגה אקספוננציאלית כדי לא לפספס את האירוע.

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

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

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

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

בעזרה של AndroidPublisher ניתן להוסיף שיטות כמו executeProductPurchasesConsume y executeProductPurchasesAcknowledge שקוראים לנקודות הקצה המתאימות. שוב, מומלץ ליישם ניסיונות חוזרים במקרה של כשלים מזדמנים, כדי להבטיח שאף אסימון לא יישאר במצב ביניים מסוכן.

בדיקות מתקדמות עם Play Billing Lab

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

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

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

<manifest ... >
  <application ... >
    ...
    <meta-data
        android:name="com.google.android.play.largest_release_audience.NONPRODUCTION"
        android:value="" />
    <meta-data
        android:name="com.google.android.play.billingclient.enableBillingOverridesTesting"
        android:value="true" />
  </application>
</manifest>

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

לאחר התצורה, מאפליקציית Play Billing Lab, התחבר באמצעות חשבון בודק רישיון, הפעל את האפשרות "סימולציה של תגובת Play Billing Library" ובחר אילו קודי שגיאה ברצונך להחזיר עבור כל API (לדוגמה, שגיאה ספציפית ב- consumeAsyncלאחר מכן, פשוט פותחים את האפליקציה ומריצים את הזרימה שברצונכם לבדוק: הסימולטור יחזיר את התגובות שהוגדרו ותוכלו לוודא שלוגיקת הניסיון החוזר, טיפול השגיאות וה-RTDN מתנהגים כצפוי.

שינויים עיקריים ב-API בעת המעבר לספריית החיוב של Play 7

מעבר ל-RTDN ולבדיקות, המעבר ל-PBL 7 כרוך בטיפול בנקודות API ספציפיות. עבור אלו המגיעים מ-PBL 5 או 6, כדאי לבדוק את השינויים הרלוונטיים ביותר כדי להבטיח שהפרויקט יתבצע בצורה חלקה ושהלוגיקה העסקית תישאר עקבית.

ראשית, ממשקי ה-API הקשורים ל- מצב יחסי אפשרויות שינוי המנוי הוסרו. כעת, נעשה שימוש באפשרויות הבאות: מצב החלפה לניהול שינויים בתוכנית (שדרוגים, שדרוגים לאחור וכו'). אם אתם עדיין משתמשים בשיטות כמו setReplaceProrationMode o setReplaceSkusProrationModeתצטרך להעביר אותם לגרסאות החדשות של setSubscriptionReplacementMode ולהתאים את הלוגיקה בהתאם לתיעוד המעודכן.

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

נקודה חשובה נוספת היא ה- ממשקי API חלופיים לחיובהשיטות BillingClient.Builder.enableAlternativeBilling, AlternativeBillingListener y AlternativeChoiceDetails נעלמו לטובת מינוח מיושר יותר: כעת עליך להשתמש BillingClient.Builder.enableUserChoiceBilling() ליד UserChoiceBillingListener y UserChoiceDetailsלפי גוגל עצמה, מדובר בעצם בשינוי שם ללא שינויים בהתנהגות, בהקשר המאופיין בהסכמים כגון גוגל ואפיק גיימס הסכימו לפתוח את אנדרואיד.

לבסוף, מזין קוד שגיאה חדש. שגיאת_רשת en BillingResultוהמשמעויות והתנאים של SERVICE_TIMEOUT ו-SERVICE_UNAVAILABLEאם יש לכם לוגיקת טיפול בשגיאות מותאמת אישית (לדוגמה, החלטה מתי להציג הודעה למשתמש, מתי לנסות שוב באופן שקט וכו'), מומלץ לבדוק אותה כדי לקחת בחשבון את הניואנסים החדשים הללו.

עסקאות ממתינות והיעדר קוד הזמנה עד לרכישה

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

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

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

יכולות אופציונליות חדשות ב-PBL 7: תשלומים וירטואליים ותשלומים מראש

בין התכונות החדשות "הנחמדות" של PBL 7 נמצאות ה- מנויים בתשלום וירטואלי (מנויים בתשלומים וירטואליים) ותמיכה מורחבת ברכישות ממתינות עבור מנויים בתשלום מראש. תכונות אלו אינן חובה, אך הן יכולות להעניק לך גמישות רבה יותר בעת התאמת מודל העסק שלך לשווקים שונים.

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

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

במקביל, התמיכה מתרחבת רכישות ממתינות עבור מנויים מראשכעת ניתן להציע מודלים שבהם המשתמש מתחיל את הרכישה באפליקציה ומשלים את התשלום מאוחר יותר באמצעים אחרים, וספריית החיוב יודעת כיצד לטפל בתהליך זה בצורה נכונה. ההפעלה מתבצעת על ידי קריאה enablePendingPurchases() בעת אתחול BillingClient, ובמיוחד עבור תוכניות פריפייד, באמצעות PendingPurchasesParams.Builder.enablePrepaidPlans().

תקופות פחת עבור ספריית החיוב של Play 5 ו-6

עם PBL 7 בזירה, גוגל קבעה תאריכים ברורים עבור הפסקת התמיכה בגרסאות 5 ו-6אם אתם עדיין נמצאים באחת מהן, עליכם לסמן את לוח השנה באדום:

• גרסה 5 של ספריית החיוב של Google Play תצא משימוש רשמית ב-31 באוגוסט 2024, עבור אפליקציות ועדכונים חדשים. ניתן לבקש הארכה עד ה-1 בנובמבר 2024, אך לא כדאי להסתמך על זה לטווח ארוך.
• ניתן להשתמש בספריית החיוב של Google Play גרסה 6 לפרסום אפליקציות חדשות עד ה-1 באוגוסט 2025, ולעדכון אפליקציות קיימות עד ה-1 בנובמבר 2025.

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

המקרה של .NET MAUI והמגבלות הנוכחיות

אם אתם עובדים עם .NET MAUI ומנויים באנדרואיד, סביר להניח שכבר קראתם או חוויתם שזה לא כל כך פשוט. פרויקטים רבים השתמשו... חיוב באפליקציה (Plugin.InAppBilling) מאת ג'יימס מונטמניו, אך התוסף מאוחסן בארכיון ואינו מתוחזק, כך שהוא לא יעודכן לתמיכה ב-Billing Library 7. במקביל, החבילה הרשמית Xamarin.Android.Google.BillingClient הוא נותר מעוגן במערכת האקולוגית Xamarin.Android ואינו תואם ישירות ל- .NET MAUI.

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

בהקשר זה, קבוצות רבות שוקלות חלופות כגון ערכות פיתוח תוכנה (SDK) של צד שלישי שירותים אלה כבר תומכים ב-PBL 7 הבסיסי וחושפים API יציב יותר, חוצה פלטפורמות (לדוגמה, פתרונות backend למנויים עם ערכות SDK עבור אנדרואיד, iOS ופלטפורמות אחרות). שירותים אלה בדרך כלל מטפלים בהעברת גרסאות של ספריית החיוב וחושפים מעטפת יציבה, מה שמפחית משמעותית את הלחץ עם כל הוצאה משימוש חדשה של גוגל.

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

Artaculo relacionado:

כיצד לבקש החזר כספי עבור רכישות ב-Google Play שלב אחר שלב

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