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

קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

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

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

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

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

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

קבלת גישה

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

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

הצגת רכישות מבוטלות

יש להשתמש בשיטה 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 (שעת התחלה)

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

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

endTime (שעת סיום)

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

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

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

התגובה היא מחרוזת 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"
    },
  ]
}

מכסות

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

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

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

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

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

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

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

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