אנו מטמיעים רכישות בתוך האפליקציה (IAP) למשחקים ניידים ב-iOS וב-Android. בעת הטמעת IAP במשחק 'Cosmic Raider', נתקלנו בדחיית build על ידי Apple עקב חוסר אימות שרת. נאלצנו להוסיף אימות קבלה (receipt validation) בשרת שלנו וליישם שחזור רכישות. כתוצאה מכך, המשחק עבר את הביקורת בניסיון הראשון. בניגוד להוספת כפתור 'קנה' פשוט, IAP דורש טיפול בקבלות, אימות שרת ושחזור. אנו מטפלים בכל התהליך מקצה לקצה—החל מהגדרת מוצרים בקונסולות ועד לבדיקות. לצוות שלנו יש ניסיון של 10+ שנים בפיתוח מובייל והטמענו IAP ביותר מ-20 פרויקטים. פספוס של כל שלב גורם לאובדן כסף (סטודיו אחד הפסיד $5000 בחודש עקב רכישות מזויפות) או לדחיית האפליקציה, ולכן אנו מבטיחים אישור ביקורת. קבלו ייעוץ על הטמעת IAP כדי להימנע מטעויות אופייניות.
מדוע אימות שרת של IAP הוא חובה
אימות בצד הלקוח (ניתוח appStoreReceiptURL ישירות באפליקציה) אינו מאובטח. מכשיר עם jailbreak יחד עם מחולל קבלות מזויפות יכול לעקוף אותו. הסכמה הנכונה:
- האפליקציה מקבלת קבלה/token מ-StoreKit/BillingClient.
- שולחת אותו לשרת שלך:
POST /api/purchases/verify. - השרת מאמת דרך נקודת הקצה
/verifyReceiptשל Apple או Google Play Developer API (purchases.products.get/purchases.subscriptions.get). - השרת מעניק את המוצר למשתמש.
- מחזיר את התוצאה ללקוח.
Apple מפסיקה את התמיכה ב-/verifyReceipt לטובת עסקאות JWS של StoreKit 2—בשרת אתה מפענח signedTransactionInfo (JWT) ומאמת את החתימה מול Apple Root CA. ספריות: appstore-connect-sdk (Node.js), apple-receipt-verifier (Python/Go).
לפי הנחיות הביקורת של App Store, אפליקציות המשתמשות ב-IAP חייבות ליישם אימות קבלות בשרת כדי למנוע הונאה. אימות שרת נכון אמין פי 10 מאימות בצד הלקוח ומפחית ניסיונות הונאה ב-99%.
כיצד StoreKit 2 מפשט את הפיתוח
StoreKit 2 (Swift concurrency, iOS 15+) מציע async/await, Product.products(for:), product.purchase(), Transaction.updates AsyncSequence. הקוד נקי פי שניים בהשוואה ל-StoreKit 1. אם המשחק שלך מיועד ל-iOS 14 ומטה, אנו נשארים עם StoreKit 1. עבור iOS 15+, StoreKit 2 הוא הבחירה הברורה. הנה השוואה:
| מאפיין | StoreKit 1 | StoreKit 2 |
|---|---|---|
| סגנון API | Delegates, callbacks | async/await, Swift concurrency |
| ניהול עסקאות | SKPaymentTransactionObserver |
Transaction.updates AsyncSequence |
| נפח קוד (תהליך אופייני) | ~150 שורות | ~80 שורות (47% פחות) |
| iOS מינימלי | 3.0 | 15.0 |
ב-Android: BillingClient (Play Billing Library 6+). שיטות מפתח: launchBillingFlow(), queryProductDetailsAsync(), acknowledgePurchase(). חשוב: Google דורש לאשר כל רכישה תוך 3 ימים, אחרת היא מוחזרת אוטומטית. זו מדיניות, לא באג. זכרו לקרוא ל-consumeAsync() עבור מוצרים מתכלים (מטבעות משחק, חיים) ול-acknowledgePurchase() עבור מוצרים שאינם מתכלים (הסרת פרסומות, פרימיום).
אילו סוגי רכישות קיימים במשחק?
| סוג | דוגמה | מתכלה | לוגיקה |
|---|---|---|---|
| מטבעות משחק | 1000 מטבעות | כן | צרוך לאחר הענקה |
| חיים/אנרגיה | +5 חיים | כן | צרוך, הימנע מכפילויות |
| הסרת פרסומות | ללא פרסומות | לא | אשר, שחזר |
| מנוי עונתי | Battle Pass | מנוי | בדוק תפוגה |
| תוכן חד-פעמי | סקין לדמות | לא | אשר, שחזר |
עבור מנויים (autoRenewableSubscription) קיימת לוגיקה נפרדת: renewalInfo, תקופת חסד, מצב ניסיון חיוב חוזר. אם מנוי פג אך המשתמש עדיין בתקופת חסד, איננו מבטלים גישה מידית.
מדוע שחזור רכישות חשוב
StoreKit 2: StoreKit 2 מחזיר את כל הרכישות הפעילות שאינן מתכלות ואת המנויים. כפתור 'שחזור רכישות' הוא אלמנט חובה לפי הנחיית הביקורת 3.1.1 של App Store. בלעדיו, האפליקציה שלך תידחה.
ב-Android: for await transaction in Transaction.currentEntitlements עבור queryPurchasesAsync(QueryPurchasesParams) ו-INAPP מחזיר את כל הרכישות הפעילות גם ללא רשת.
כיצד לבדוק רכישות בתוך האפליקציה לפני השחרור
השתמשו בבודקי Sandbox ב-iOS ובחשבונות בדיקה ברישיון ב-Android. בדקו כל תרחיש: רכישה מוצלחת, ביטול, שחזור, רכישה חוזרת ומצב לא מקוון. אנו תמיד חוסכים עד 90% בעלויות תמיכה על ידי תפיסת בעיות במהלך הבדיקות.
מצבים לא מקוונים וקצה
משתמש קונה משהו, אך השרת אינו זמין לאימות. הגישה הנכונה: שמרו עסקה ממתינה מקומית (Core Data / Room), נסו אימות מחדש בהפעלה הבאה עם backoff אקספוננציאלי. לעולם אל תקראו ל-SUBS על העסקה עד לאימות שרת מוצלח.
טעויות אופייניות בהטמעת IAP:
- שכחת אישור רכישה ב-Android—מוחזרת תוך 3 ימים.
- אי יישום שחזור ב-iOS—מוביל לדחייה בביקורת.
- אימות קבלה רק מקומית—פגיע לפריצות jailbreak.
- אי טיפול במצבים לא מקוונים—גורם לרכישות אבודות.
מה כלול בעבודה
- הגדרת מוצרים ב-App Store Connect וב-Google Play Console.
- אימות קבלות בצד השרת (Node.js/Python/Go).
- מודול IAP בצד הלקוח המטפל בכל סוגי הרכישות.
- בדיקות בסביבת Sandbox ו-Test.
- אימות שחזור ומצבי קצה.
- תיעוד ותמיכה לאחר השחרור.
תהליך העבודה
- אנליטיקה ועיצוב.
- הגדרת מוצרים ב-App Store Connect וב-Google Play Console.
- פיתוח אימות שרת.
- הטמעת מודול הלקוח (StoreKit / BillingClient).
- בדיקות Sandbox.
- הכנת הגשה ופרסום.
לוחות זמנים משוערים
אינטגרציה בסיסית (מוצרים מתכלים + שאינם מתכלים, אימות שרת): 3–4 ימים. מנויים עם תקופת חסד, ניסיון חיוב חוזר, העברת קבלות: +2 ימים. פלטפורמות חוצות Flutter/React Native עם שכבת הפשטה על StoreKit ו-BillingClient: +1–2 ימים.
צרו קשר להערכת פרויקט—אנו מבטיחים אישור ביקורת ב-App Store וב-Google Play. קבלו ייעוץ על הטמעת IAP כדי להימנע מטעויות אופייניות.