אינטגרציה של רכישות בתוך האפליקציה
לעתים קרובות אנו רואים פרויקטים שבהם Unity IAP מוגדר תוך שעה—ולמחרת הם מקבלים InitializationFailureReason.PurchasingUnavailable בייצור ב-iOS 17. חופרים פנימה ומגלים שההרשאה לרכישות בתוך האפליקציה ב-App Store Connect לא מוגדרת, והבודק בסביבת הארגז חול לא נוסף. זה רק קצה הקרחון.
אינטגרציית IAP היא חוליה מקשרת בין הלקוח, מערכת התשלומים של החנות והשרת האחורי, שחייבת לפעול כראוי תחת אינטרנט לא יציב, עסקאות מופרעות וניסיונות הונאה. שגיאות כאן עולות כסף: ההפסד הממוצע מעסקה בודדת שלא עובדה הוא $2–3, וחיוב חוזר יכול לעלות למוציא לאור $4.5k–6.5k.
אילו בעיות מתעוררות במהלך אינטגרציית IAP?
עסקאות ממתינות. המשתמש לוחץ על "קנה", הכסף נוכה, החיבור נופל—ProcessPurchase לא נקרא. Unity IAP שומר את העסקה בתור ומנסה להשלים אותה בהפעלה הבאה. אבל אם השרת האחורי לא מיישם אידמפוטנטיות לפי transactionID, השחקן מקבל את הפריט פעמיים או לא מקבל אותו כלל. ראינו פרויקטים שבהם PendingOrderResponse הצטברו במשך שבועות בגלל חוסר ConfirmPendingPurchase() במקום הנכון.
אימות קבלות. ללא אימות קבלות בצד השרת, המשחק חשוף לרכישות הונאה דרך APK מהונדסים או מכשירים עם פריצת jailbreak. אפל מחזירה קבלה מקודדת ב-base64 בתוך Product.receipt, גוגל מחזירה JSON עם חתימה. אימות מקומי דרך UnityEngine.Purchasing.Security.CrossPlatformValidator הוא מחסום מינימלי, אך לא מספק. אימות מלא: שליחת הקבלה לשרת שלך, בדיקה דרך Apple App Store Server API (/verifyReceipt או אסימון JWS חדש של StoreKit 2) או Google Play Developer API (purchases.products.get). סטטיסטיקה: אימות בצד השרת מפחית חיובים חוזרים ב-95%.
שחזור רכישות ב-iOS. אפל דורשת כפתור שחזור רכישות עבור מוצרים שאינם מתכלים ומנויים—בלעדיו, האפליקציה לא תעבור את הביקורת. IAppleExtensions.RestoreTransactions() חייב להיות נגיש מממשק המשתמש, ומטפל OnTransactionsRestored חייב לעדכן כראוי את מצב המלאי ללא כפילויות.
כאב נפרד הוא מנויים. SubscriptionManager ב-Unity IAP יכול לנתח את תאריך התפוגה ומצב החידוש, אבל רק עם קבלה תקפה. באנדרואיד עם Google Play Billing Library 5+, יש לבקש במפורש queryPurchasesAsync בכל התחלה—המטמון הופך למיושן. אי עדכון משאיר למשתמש גישה חופשית לתוכן בתשלום.
למה אימות בצד השרת חשוב?
לפי התיעוד של Apple StoreKit, אימות בצד השרת מבטל זיוף קבלות במכשיר. נשווה בין שתי גישות:
| קריטריון | אימות מקומי | אימות בצד השרת |
|---|---|---|
| מורכבות יישום | נמוכה (מתודה אחת) | גבוהה (backend + API) |
| הגנה מפני הונאה | 60% — נשבר במכשירים עם root | 99% — העסקה נבדקת בשרת של אפל/גוגל |
| עדכוני מנויים | רק לפי קבלה בלקוח | בזמן אמת: התראות push על סטטוס |
| אמינות | בינונית: קבלה מזויפת בלקוח | גבוהה: אידמפוטנטיות, ניסיונות חוזרים בזמן timeout |
אימות בצד השרת אמין ב-40% יותר מאשר מקומי ומפחית את הסיכון לחיובים חוזרים למינימום. בלעדיו, מוציאים לאור גדולים לא משחררים משחקים. חיסכון מאימות שרת: עד 30% מהכספים שאחרת היו הולכים לחיובים חוזרים.
רשימת בדיקה של טעויות IAP נפוצות
- חוסר
ConfirmPendingPurchase()לסיום העסקה. - שחזור רכישות שגוי ב-iOS (חוסר כפתור בממשק המשתמש).
- שימוש באותו מזהה מוצר לשתי הפלטפורמות.
- התעלמות מ-
queryPurchasesAsyncבאנדרואיד לבדיקת סטטוס המנוי. - חוסר אידמפוטנטיות בשרת האחורי.
איך אנחנו עושים את זה: טכנולוגיה וגישה
אנחנו מתחילים בבדיקת המצב הנוכחי: האם יש backend, האם נדרש אימות שרת, מה מודל המונטיזציה (מתכלה, לא מתכלה, מנויים, או כולם יחד). בהתאם לכך, אנחנו מתכננים תוכנית.
אנחנו מגדירים הגדרות מוצר ב-Unity IAP דרך ProductCatalog או פרוגרמטית דרך ConfigurationBuilder. למשחקים רב-פלטפורמיים—קטלוג אחיד עם מזהים ספציפיים לפלטפורמה (אפל/גוגל דורשות לעתים קרובות מזהים שונים). אנו משתמשים בתיעוד Apple StoreKit כדי להגדיר בודקי ארגז חול ולאמת מנויים.
אנחנו מיישמים את המחזור המלא: אתחול UnityPurchasing.Initialize() → טיפול ב-ProcessPurchase → אישור ConfirmPendingPurchase() → הענקת הפריט → רישום במסד הנתונים. אם יש backend, אנחנו מוסיפים אימות בצד השרת עם לוגיקת ניסיונות חוזרים בזמן timeout.
עבור iOS בנוסף: הגדרת סביבת StoreKit לבדיקות (Xcode Sandbox), טיפול בהצעות קידום דרך IAppleExtensions.SetStorePromotionOrder(), עבודה נכונה עם Family Sharing אם נדרש. עבור אנדרואיד: הגדרת חשבונות בדיקה ב-Google Play Console, אימות פעולה במסלולי alpha/internal לפני פרסום.
מה כלול בעבודה
- תיעוד: תוכנית ארכיטקטונית של רכישות, תיאורי מוצרים, דיאגרמת עסקאות.
- קוד מקור: סקריפט מנהל IAP מלא עם תמיכה בכל הפלטפורמות.
- חלק שרת: API לאימות קבלות (אופציונלי) עם אידמפוטנטיות וניסיונות חוזרים.
- גישה: הגדרת App Store Connect ו-Google Play Console, יצירת חשבונות בדיקה.
- הדרכה: הסבר כיצד להוסיף מוצרים חדשים ולטפל בשגיאות.
- תמיכה: ייעוץ במשך שבוע לאחר המסירה.
אנחנו מבטיחים שאחרי האינטגרציה שלנו, המשחק שלך יעבור את הביקורת של אפל וגוגל בניסיון הראשון, ובקשות לחיובים חוזרים יבוטלו.
בדיקות—שלב נפרד
תרחישים שאנחנו חייבים לבדוק:
- רכישה מוצלחת—מתכלה, לא מתכלה, מנוי.
- רכישה עם ניתוק רשת במהלך העסקה—בדיקת
Pendingושחזור. - בקשת רכישה חוזרת—ביטול כפילויות.
- שחזור רכישות במכשיר חדש.
- רכישה במכשיר ללא אמצעי תשלום—טיפול נכון בשגיאות.
- שדרוג/הורדת מנוי—עדכון נכון של תאריך התפוגה.
בדיקות ארגז חול ב-iOS כוללות מגבלות—חלק מהתרחישים (למשל, ניסיון חיוב חוזר) ניתנים לשחזור רק ב-TestFlight. באנדרואיד—דרך מסלול בדיקה פנימי עם חשבונות בדיקה מורשים.
לוח זמנים
| מורכבות | לוח זמנים |
|---|---|
| IAP מתכלה, פלטפורמה אחת, ללא backend | 2–4 ימים |
| אינטגרציה מלאה (שתי פלטפורמות + אימות שרת) | 1–2 שבועות |
| מנויים עם ניהול backend + אנליטיקה | 2–4 שבועות |
העלות מחושבת לאחר ניתוח ארכיטקטורת הפרויקט ודרישות מודל המונטיזציה. צרו קשר לייעוץ והערכת עלות מדויקת לפרויקט שלכם. הזמינו אינטגרציה סוהר—נכין הצעה מסחרית תוך יום עסקים אחד. קבלו ייעוץ לפרויקט שלכם—כתבו לנו.