API לרכישות מבוטלות

Google Play Voided Purchases API מספק רשימת הזמנות משויכות לרכישות שמשתמשים ביטלו. אפשר להשתמש במידע מהרשימה הזו כדי ליישם מערכת ביטול שמונעת מהמשתמש גישה למוצרים מההזמנות האלה.

ה-API הזה חל על הזמנות חד-פעמיות מתוך האפליקציה ועל מינויים לאפליקציה.

אפשר לבטל רכישה בדרכים הבאות:

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

  • המפתח מבטל את ההזמנה או מבצע החזר כספי עליה.

  • Google מבטלת את ההזמנה או מבצעת החזר כספי עליה.

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

קבלת גישה

כדי לעבוד עם Voided Purchases API, נדרשת הרשאה לצפייה מידע פיננסי. אתם מספקים הרשאה באמצעות לקוח OAuth או חשבון שירות. אם משתמשים בחשבון שירות, מפעילים את האפשרות 'הצגת מידע פיננסי' דוחות" בחשבון הזה.

למידע נוסף על קבלת גישה מורשית לממשקי ה-API של Google Play למפתחים: את המדריכים הבאים:

צפייה ברכישות שבוטלו

משתמשים בשיטה GET כדי לבקש רשימה של רכישות מבוטלות. בבקשה שלכם, כוללים את שם החבילה המלא של האפליקציה — כמו com.google.android.apps.maps — ואסימון ההרשאה שאתם שהתקבלו כאשר מקבלים גישה ל-API.

GET https://www.googleapis.com/androidpublisher/v3/applications/
your_package_name/purchases/voidedpurchases?access_token=your_auth_token

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

startTime

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

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

endTime

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

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

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

includeQuantityBasedPartialRefund

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

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

{
  "tokenPagination": {
    "nextPageToken": "next_page_token"
  },
  "voidedPurchases": [
    {
      "kind": "androidpublisher#voidedPurchase",
      "purchaseToken": "some_purchase_token",
      "purchaseTimeMillis": "1468825200000",
      "voidedTimeMillis": "1469430000000",
      "orderId": "some_order_id",
      "voidedSource": "0",
      "voidedReason": "4"
    },
    {
      "kind": "androidpublisher#voidedPurchase",
      "purchaseToken": "some_other_purchase_token",
      "purchaseTimeMillis": "1468825100000",
      "voidedTimeMillis": "1470034800000",
      "orderId": "some_other_order_id",
      "voidedSource": "2",
      "voidedReason": "5"
    },
  ]
}

מכסות

ב-Voided Purchases API מוגדרות המכסות הבאות לכל חבילה:

  • 6,000 שאילתות ביום. (היום מתחיל ומסתיים בחצות לפי שעון החוף המערבי של ארה"ב).
  • 30 שאילתות בכל פרק זמן של 30 שניות.

הנחיות לבקשות ראשוניות

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

  • שימוש בערך ברירת המחדל של הפרמטר maxResults. כך, אם משתמשים את כל מכסת השאילתות ליום אחד, אפשר לאחזר את הפרטים של 6,000,000 רכישות מבוטלות.
  • אם תשובה כוללת ערך עבור nextPageToken, יש להקצות את הערך הזה ל token במהלך הבקשה הבאה.

שיטות מומלצות

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

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