אנו מפתחים מערכת מטבע וירטואלי (נקודות ומטבעות) עבור אפליקציות מובייל מאפס או משתלבים בפרויקט קיים. באגים בהענקת מטבעות מובילים או לארנקי משתמשים ריקים (ביקורות רעות, ירידה של 20% ב-DAU) או לגלישה (הפסדים עסקיים, לעיתים עד 15% מההכנסות). הניסיון שלנו: 5+ שנים בפיתוח מובייל מסחרי, 15+ פרויקטי גיימיפיקציה. במשך הזמן הזה צברנו דפוסים לארכיטקטורות שונות—מ-MVP ועד מונוריפו מודולריים. פיתוח מפתח מלא מעיצוב ספר חשבונות ועד פריסת חנות.
עלייה של 25% ב-LTV לאחר יישום מערכת מטבע אינה נדירה. כרטיס ה-IAP הממוצע הוא $4.99, אשר עם כוונון נכון מעלה את ה-ARPU ב-$1.50. עם זאת, ללא הגנת אנטי-צ'יט מתאימה, אתה יכול להפסיד עד 30% מההכנסות עקב הגדלות הונאה. הפתרונות שלנו מוכחים בפרויקטים עם מיליוני משתמשים.
פנה אלינו לייעוץ כדי לבחור את הארכיטקטורה האופטימלית עבור הפרויקט שלך.
טרנזקציונליות כבסיס
כל פעולת יתרה היא טרנזקציה אטומית עם רישום debit/credit בטבלת ledger, לא רק UPDATE balance = balance + N. סיבה: ללא אטומיות, בקשות צבירה ומשיכה במקביל מובילות ליתרה שגויה. טרנזקציות אטומיות אמינות פי 5 מעדכונים פשוטים. אנו משתמשים ב-SELECT FOR UPDATE בשרת או בנעילה אופטימית (UPDATE balance WHERE balance = :expected).
הלקוח מקבל תשובה מלאה עבור כל טרנזקציה:
{ "balance": 1250, "delta": 100, "transaction_id": "uuid", "reason": "daily_bonus" } אנו אף פעם לא מחשבים מחדש את היתרה בצד הלקוח—רק מציגים את הערך מהשרת.
כיצד להגן על מערכת המטבע מפני רמאות?
פרוקסי דיבאג. Charles Proxy או mitmproxy מאפשרים ללכוד בקשות ולשנות תשובות. אם תשובת { "balance": 1250, "delta": 100, "transaction_id": "uuid", "reason": "daily_bonus" } מחזירה /rewards/daily-bonus ללא חתימת שרת—הלקוח עשוי להראות "התקבלו 100 מטבעות", אבל השרת צריך להעניק אותם באופן עצמאי ולא לסמוך על ערך התשובה.
הצמדת SSL. הגנת MITM בסיסית: {"coins": 100} (iOS) / TrustKit (אנדרואיד). לא מוחלטת—Frida או root + SSL Kill Switch יכולים לעקוף את ההצמדה. אבל זה חוסם 90% מניסיונות של סקריפט-קידי.
הגבלת קצב. לחיצה כפולה על כפתור "אסוף בונוס": דיבונס בצד הלקוח (250ms OkHttp CertificatePinner) בתוספת הגנת שרת באמצעות throttle (UUID מהלקוח). השרת מתעלם מבקשות חוזרות עם אותו מפתח בתוך 60 שניות.
מידע נוסף על הגבלת קצב
אנו משתמשים באלגוריתם דלי עם מגבלה של 5 בקשות בשנייה למשתמש עבור פעולות צבירה. מפתח האידמפוטנציה נשמר ב-Redis עם TTL של 120 שניות.ממשק משתמש: אנימציית צבירת מטבעות
מטבעות "עפים" למונה—אנימציית תגמול סטנדרטית. יישום: חלקיקים דרך idempotency_key (iOS) או CAEmitterLayer עם Jetpack Compose Canvas מותאם אישית. מספר אייקוני מטבע עפים מהמקור (מיקום כפתור/אייקון האירוע), נעים לאורך עקומת בזייה לווידג'ט היתרה, וכל "פגיעה" מגדילה את המונה ב-1. אפקט הסלמה חלק דרך Modifier עם CAKeyframeAnimation.
מונה היתרה בעדכון משתמש באנימציית גלגול מספרים: ספרות גוללות מלמעלה למטה כמו מד מרחק. ב-iOS: path עם UILabel או CATransition מותאם אישית ב-SwiftUI. באנדרואיד: AnimatedNumberView עם ValueAnimator. האנימציה נמשכת 1.5-2 שניות כך שהמשתמש מבחין בצבירה.
| סוג אנימציה | iOS | אנדרואיד |
|---|---|---|
| טיסת מטבעות | CAEmitterLayer + CAKeyframeAnimation | Canvas + ObjectAnimator |
| מונה מד מרחק | AnimatedNumberView (SwiftUI) | ValueAnimator + TextSwitcher |
מדוע ספר חשבונות בצד השרת אמין יותר מאשר בצד הלקוח?
| היבט | ספר חשבונות בצד השרת | יתרה בצד הלקוח |
|---|---|---|
| אטומיות | מובטחת (טרנזקציות DB) | סיכון לתנאי מרוץ |
| אבטחה | מוגן על ידי אימות שרת | קל לשינוי |
| ביקורת | היסטוריית פעולות מלאה | אין יומן מהימן |
ספר החשבונות הענני שלנו אמין פי 10 מאחסון בצד הלקוח, ומפחית עלויות תמיכה ב-$0.20 למשתמש.
רכישת מטבעות דרך IAP
מוצרים מתכלים ב-StoreKit 2: "100 מטבעות ב-$0.99", "550 מטבעות ב-$4.99" וכו'. TextSwitcher → Product.purchase() לאחר זיכוי יתרה בצד השרת—סדר חשוב: תחילה זיכוי מטבעות דרך השרת (אימות קבלה בשרת), ואז סיום הטרנזקציה. אם תסיים את הטרנזקציה לפני הזיכוי והאפליקציה קורסת, המשתמש שילם אבל לא קיבל מטבעות.
באנדרואיד: Transaction.finish() → BillingClient.launchBillingFlow() → אימות בצד השרת דרך Google Play Developer API → Purchase.getPurchaseState() == PURCHASED (מוצר מתכלה חייב להיות נצרך, אחרת לא זמין לרכישה חוזרת).
טרנזקציות ממתינות (רכישות דחויות באנדרואיד דרך Google Pay משפחתי או אישור בנק) מטופלות דרך BillingClient.consumeAsync(), וממתינות לאישור לפני זיכוי מטבעות.
לפי תיעוד המפתחים של Apple, אימות בצד השרת הוא חובה עבור מוצרים מתכלים.
כיצד להגדיר אימות IAP בצד השרת: שלב אחר שלב
- קבל קבלה (iOS) או אסימון רכישה (אנדרואיד) בצד הלקוח.
- שלח לשרת שלנו (POST /validate-purchase).
- השרת מבצע בקשת HTTP ל-Apple Verify Receipt או Google Play Developer API.
- בעת אימות מוצלח, זיכוי מטבעות בספר החשבונות והחזר אישור.
- הלקוח מסיים את הטרנזקציה (Transaction.finish() / consumeAsync()).
היסטוריית טרנזקציות
משתמשים רוצים להבין לאן הלכו המטבעות שלהם. BillingClient.PurchasesUpdatedListener—רשימה מפולחת (TransactionHistory-פאג'ינציה) עם סוגים: cursor, earned_daily_bonus, earned_referral, spent_purchase, spent_unlock. סינון לפי סוג. מטמון מקומי של 50 הפעולות האחרונות ב-Core Data / Room להצגה מיידית ללא בקשת רשת.
מה כלול ביישום
- עיצוב סכמת ספר חשבונות והגנת אנטי-צ'יט
- פיתוח IAP (מוצרים מתכלים) + אימות בצד השרת
- ממשק יתרה + אנימציות
- היסטוריית טרנזקציות
- QA (כולל בדיקת בקשות במקביל, טרנזקציות ממתינות)
- תיעוד API ואינטגרציה
- תמיכה לאחר השקה (אופציונלי)
הערכות זמנים
יישום מלא של מערכת מטבע וירטואלי עם IAP, אנימציות והיסטוריית טרנזקציות—3–5 ימי עסקים עם API שרת מוכן. אם כולל עיצוב ספר חשבונות בשרת—1–2 שבועות. התמחור מחושב באופן אישי.
קבל ייעוץ ובקש הערכת פרויקט. אנו מבטיחים שקיפות וניסיון בכל שלב.
מערכת המטבע הווירטואלי שלנו כוללת ספר חשבונות טרנזקציונלי עם חיוב/זיכוי אטומי, הגנת אנטי-צ'יט באמצעות הצמדת SSL והגבלת קצב, רכישות IAP מתכלות באמצעות StoreKit 2 או Billing 6, אנימציות צבירת מטבעות, ותצוגת היסטוריית טרנזקציות.