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

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

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

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

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

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

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

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

קבלת גישה

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

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

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

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