הרגע הטמעתם את מערכת החיוב של Play באפליקציית Android או ב-Progressive Web App, והמשתמשים יכולים לרכוש את המוצרים הדיגיטליים שלכם. עכשיו צריך להטמיע כמה רכיבים מרכזיים של מערכת החיובים ב-Play בשרת העורפי.
Google Play Developer API
ל-Google Play Developer API יש שני רכיבים: Subscriptions and In-app Purchases API ו-Publishing API. ה-API של מינויים ורכישות באפליקציה כולל את משאבי ה-REST הבאים, שעוזרים לנהל מוצרים ורכישות:
-
inappproducts: ניהול קטלוג של מוצרים מתוך האפליקציה ומינויים -
purchases.products: סטטוס הרכישה של מוצרים באפליקציה -
purchases.subscriptions: סטטוס הרכישה וניהול המינויים
אפשר להשתמש ישירות ב-Google Play Developer API כ-REST API, או להשתמש בספריות הלקוח כדי להתחיל לפתח במהירות. כאן אפשר למצוא את ספריות הלקוח לכל השפות הנתמכות. פועלים לפי המדריך לתחילת העבודה עם Google Play Developer API כדי לקשר את פרויקט ה-API ולהגדיר לקוחות עם גישה ל-API.
הצגת רשימה של כל המוצרים מתוך האפליקציה
כשמבצעים שאילתה לגבי פרטי מוצרים שזמינים בחלק הקדמי (באפליקציית Android או באפליקציית אינטרנט מתקדמת), צריך לציין את רשימת מזהי המוצרים. אפשר להטמיע את זה בשרת הקצה העורפי באמצעות השיטה inappproducts.list של Play Developer API, שתציג רשימה של כל המוצרים והמינויים בתוך האפליקציה שיצרתם ב-Play Console. חשוב לבדוק את status של כל מוצר ולשלוח ללקוח האפליקציה רק את המוצרים עם active.
אימות רכישות לפני הענקת הרשאות
חלק חשוב בהטמעה של מערכת החיוב של Play באפליקציית Android או באפליקציית אינטרנט מתקדמת הוא לוודא שאתם מאמתים רכישות לפני שאתם מעניקים למשתמש זכאות. כשמעניקים למשתמש זכות גישה, נותנים לו גישה להטבות או לתוכן שמשויכים לפריט שהוא רכש. מכיוון שנדרש טיפול בנתונים רגישים, הטיפול צריך להתבצע בשרת העורפי.
ממשק Google Play Developer API מספק את השיטות purchases.products:get ו-purchases.subscriptions:get. אפשר להשתמש בהם עם אסימוני רכישה שאוחזרו מתוך האפליקציה או מאוחסנים בשרת העורפי כדי לוודא שהרכישה לגיטימית. כדאי לעקוב אחרי אסימוני הרכישה בשרת העורפי כדי לאמת רכישות נוספות והרשאות משתמשים. כדי לקבל פרטים נוספים על השלבים שצריך לבצע, אפשר לעיין בתיעוד של מערכת החיוב של Google Play בנושא אימות רכישות.
רכישות מתוך האפליקציה
אחרי קבלת טוקן הרכישה מהלקוח, הקצה העורפי צריך להפעיל את Google Play Developer API ולאמת שהוא עדיין לא בשימוש. הערך בשדה purchaseState של רכישה תקינה הוא 1.
אם הרכישה תקפה, הלקוח צריך לאשר את הרכישה ולהעניק את הזכאות אחרי קבלת התגובה מהשרת.
רכישות של מינויים
בדומה לאימות רכישות מתוך האפליקציה, השרת העורפי צריך להפעיל את Google Play Developer API אחרי קבלת טוקן הרכישה מהלקוח, ולאמת שהמינוי עדיין בתוקף.
הלקוח צריך להעניק את הזכאות אם הערך בשדה expiryTimeMillis של המינוי גדול מהשעה הנוכחית.
זה גם זמן טוב לבדוק את השדה linkedPurchaseToken ולעדכן את מסד הנתונים של המינויים בהתאם, כדי לטפל בשדרוגים, בשנמוכים ובזרימות אחרות של מינויים. בהמשך הדף מפורטים פרטים נוספים.
עדכון של סטטוס ה-backend
אם האפליקציה שלכם זמינה בפלטפורמות שונות (שעשויות להשתמש גם באמצעי תשלום שונים), מעקב אחרי המשתמשים והרכישות שלהם בשרת העורפי יבטיח שהמשתמשים יוכלו לגשת לזכויות שלהם במכשירים ובפלטפורמות שבהם הם משתמשים באפליקציה.
זה יכול להיות פשוט כמו מסד נתונים שבו שומרים רשומה של המשתמשים וההרשאות הנוכחיות שלהם. לאחר מכן, כשהם מבצעים רכישות או משתמשים בהרשאות שלהם, אתם מעדכנים את הנתונים בהתאם. בפעם הבאה שהם ייגשו לאפליקציה שלכם מפלטפורמה אחרת, תוכלו לאחזר את ההרשאות המתאימות מהקצה האחורי שלכם כדי שהמשתמש יוכל לגשת אליה.
טיפול בשינויים במצב המינוי
מינוי יכול לעבור שינויים שונים במצב שלו במהלך מחזור החיים שלו, וחשוב להגיב בהתאם לכל שינוי. מידע נוסף על ניהול מחזור החיים של המינוי
Subscription linkedPurchaseToken
כפי שמתואר במסמכי המינויים, כל תהליך רכישה חדש ב-Google Play (רכישה ראשונית, שדרוג או החלפה לתוכנית זולה יותר) יוצר אסימון רכישה חדש. השדה linkedPurchaseToken מאפשר לזהות מקרים שבהם כמה טוקנים של רכישה שייכים לאותו מינוי.
בכל פעם שמאמתים מינוי, ה-backend צריך לבדוק אם השדה linkedPurchaseToken מוגדר. אם כן, הערך בשדה הזה מייצג את האסימון הקודם שהוחלף. צריך לסמן מיד את הטוקן הקודם כלא תקף, כדי שהמשתמשים לא יוכלו להשתמש בו כדי לגשת לתוכן שלכם.
לדוגמה, כשהקצה העורפי מקבל את אסימון הרכישה A עבור הרכישה הראשונית, עם שדה linkedPurchaseToken ריק, הוא מאפשר זכאות לאסימון הזה. בהמשך, כשהקצה העורפי מקבל את אסימון הרכישה החדש B אחרי השדרוג, הוא בודק את השדה linkedPurchaseToken, רואה שהוא מוגדר ל-A ומשבית את ההרשאה לאסימון הרכישה A.
לדיון מפורט בנושא הטמעה של linkedPurchaseToken, אפשר לעיין במאמר הטמעה linkedPurchaseToken נכונה כדי למנוע כפילויות במינויים.
התראות בזמן אמת למפתחים
השיטה purchases.subscriptions:get של Google Play Developer API היא המקור המהימן לניהול מינויים של משתמשים. אם אתם מנהלים את הסטטוס של המנויים בשרת מאובטח בעורף, אתם צריכים לשמור על סנכרון הסטטוס עם השרתים של Google. עם זאת, ביצוע סקרים תכופים של Google Play Developer API עלול לגרום לחריגה ממגבלות המכסה של ה-API ולעיכובים בקבלת התראות על פעולות חשובות של משתמשים (כמו ביטול או שדרוג של מינוי).
התראות בזמן אמת למפתחים (RTDN) הן תכונה של מערכת החיובים של Google Play ששולחת לשרת שלכם התראה מיידית כשמשתנה מצב הזכאות של מנוי (למשל, רכישת מינוי, ביטול מינוי, השהיית מינוי). בעזרת RTDN, אתם יכולים לשמור על סנכרון של מסד הנתונים של המנויים רק באמצעות תגובה להתראות האלה, במקום לבצע שאילתות ב-Google Play Developer API באופן קבוע.
השרת העורפי יקבל SubscriptionNotification לאירועים שמשפיעים על מצב המינוי, כמו חידושים וביטולים. לאחר מכן, מפעילים את Google Play Developer API עם אסימון הרכישה בהתראה כדי לקבל את הסטטוס המלא ולעדכן את מצב ה-backend שלכם.
כדי להגדיר RTDN לאפליקציה, פועלים לפי ההוראות האלה. לאחר מכן צריך להגדיר את שרת הקצה העורפי כך שיקבל את ההודעות האלה.
מידע נוסף זמין במפרט המלא של RTDN.