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

סוג הרכישות מבוטלות שמופיעות בכל תגובה. אם הערך מוגדר ל-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"
    },
  ]
}

מכסות

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

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

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

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

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

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

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

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