נלחמים בהונאות ובהתנהלות פוגעת

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

העברת לוגיקה רגישה לחלק האחורי של האתר

ככל שעיצוב האפליקציה מאפשר זאת, כדאי להעביר נתונים רגישים ולוגיקה לשרת backend שאתם שולטים בו. ככל שיש יותר נתונים ולוגיקה במכשיר קצה, כך הוא פגיע יותר לשינויים או לזיוף.

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

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

אימות רכישות לפני הענקת הרשאות

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

  1. שולחים את ה-purchaseToken המתאים לשרת העורפי. המשמעות היא שאתם צריכים לשמור תיעוד של כל הערכים של purchaseToken לכל הרכישות.
  2. מוודאים שהערך של purchaseToken ברכישה הנוכחית לא זהה לאף אחד מהערכים הקודמים של purchaseToken. הערך של purchaseToken הוא ייחודי באופן גלובלי, כך שאפשר להשתמש בו בבטחה כמפתח ראשי במסד הנתונים.
  3. כדי לוודא עם Google שהרכישה לגיטימית, אפשר להשתמש בנקודות הקצה Purchases.products:get או Purchases.subscriptionsv2:get ב-Google Play Developer API.
  4. אם הרכישה לגיטימית ולא נעשה בה שימוש בעבר, אפשר להעניק בבטחה זכאות לפריט או למינוי באפליקציה.
  5. במינויים, כשמגדירים את הערך linkedPurchaseToken ב-Purchases.subscriptionsv2:get, צריך גם להסיר את linkedPurchaseToken ממסד הנתונים ולבטל את הזכאות שניתנה ל-linkedPurchaseToken, כדי לוודא שכמה משתמשים לא זכאים לאותה רכישה.
  6. צריך להעניק זכאות רק כשמצב הרכישה הוא PURCHASED, ולהקפיד לטפל ברכישות PENDING בצורה נכונה. אם יש עלייה חדה במספר הרכישות, יכול להיות שאתם מעניקים זכויות גישה כשהרכישה עדיין במצב PENDING.CANCELED מידע נוסף זמין במאמר בנושא טיפול בעסקאות בהמתנה.

  7. אחרי שהמשתמשים יאשרו את הרכישה, אם רוצים להשלים את הרכישה של מוצר מתכלה ולאשר אותה, צריך להשתמש ב-Purchases.products:consume Play Developer API בשרת הקצה העורפי המאובטח. כדי לאשר מוצר חד-פעמי או מינוי, צריך לבצע קריאה לנקודת הקצה הרלוונטית של Play Developer API, כלומר Purchases.products:acknowledge או Purchases.subscriptions:acknowledge, בשרת הקצה העורפי המאובטח. האישור נדרש כי הוא מודיע ל-Google Play שהמשתמש קיבל הרשאה לרכישה. אחרי שהמשתמשים יאשרו את הרכישה, באפליקציה שלך חייב להופיע אישור על הרכישה.

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

    מידע נוסף על אישור רכישות ועל צריכה זמין במאמר בנושא עיבוד רכישות.

הגנה על תוכן לא נעול

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

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

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

זיהוי וטיפול ברכישות מבוטלות

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

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

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

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

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

איך עוזרים ל-Google לזהות הונאות לפני שהן קורות

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

אפשר להשתמש בשיטות setObfuscatedAccountId ו- setObfuscatedProfileId בכלי ליצירת אפליקציות BillingFlowParams כדי לעזור ל-Google למפות חשבונות Google לחשבונות בתוך האפליקציה.

‫Google משתמשת בנתונים האלה כדי לזהות התנהגות חשודה ולחסום סוגים מסוימים של עסקאות הונאה לפני שהן מושלמות.

פעולות נגד הפרות של סימנים מסחריים וזכויות יוצרים

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