אפליקציית בנקאות סלולרית לא סולחת על טעויות. הצגת יתרה שגויה, העברה שבוצעה ללא אישור, אובדן סשן במהלך עסקה — כל אחד מאלה עולה באמון המשתמש ובכסף. ההחלטות הארכיטקטוניות כאן מונעות על ידי אבטחה, לא על ידי נוחות פיתוח. אנו מפתחים אפליקציות בנקאות סלולרית מזה למעלה מ-5 שנים, והעברנו 15+ פרויקטים לבנקים באירופה ובאסיה. כל פרויקט עובר סקירת ארכיטקטורת אבטחה ובדיקות עומס. אנו מציעים פיתוח מפתח-ביד: מניתוח ועד פרסום בחנות ותמיכה. קבלו הערכה לפרויקט שלכם תוך 2 ימי עסקים — צרו קשר.
אתגרים מרכזיים בפיתוח אפליקציות בנקאות סלולרית
בנק סלולרי חייב לפעול ללא רבב תחת עומסים של עד 10,000 עסקאות בדקה, ולהישאר בלתי ניתן לפריצה. נתקלנו במקרים שבהם חוסר אידמפוטנטיות גרם למשתמשים לאבד כסף ולבנקים לאבד מוניטין. בפרויקט אחד, יישום של הצמדת אישורים (certificate pinning) מנע מתקפת MITM כאשר רשות אישורים (CA) נפרצה. לכן כל פרויקט מתחיל במודל איומים וסקירת ארכיטקטורת אבטחה.
אימות וביומטריה
נתחיל במה שקורה בכל הפעלת אפליקציה. גישה קלאסית: JWT ב-Keychain (iOS, .whenUnlockedThisDeviceOnly) / EncryptedSharedPreferences דרך Android Keystore. בעת ההפעלה — BiometricPrompt (Android) / LAContext.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics) (iOS).
ביומטריה פותחת מפתח הצפנה שמגן על ה-refresh token — לא על הטוקן עצמו. אם blob מוצפן נגנב מה-Keychain ללא המפתח הפרטי מ-Secure Enclave, הפענוח בלתי אפשרי. זה קריטי לדרישות הסמכה בנקאית.
PIN כגיבוי: אחסן hash של ה-PIN ב-Keychain. לעולם אל תאחסן את ה-PIN בפועל. לעולם אל תשלח את ה-PIN לשרת. אימות השרת משתמש בטוקנים; ביומטריה ו-PIN משמשים רק לפתיחת סשן מקומי.
זיהוי Jailbreak/Root הוא דרישה עבור רוב הבנקים. iOS: בדוק cydia://, mobile substrate, גישת כתיבה ל-/, fork() מוצלח. Android: ספריית RootBeer או SafetyNet Attestation API / Play Integrity API (נוכחי). אם מתגלה root, האפליקציה מסרבת לפעול או פועלת במצב מוגבל.
למה אידמפוטנטיות חשובה להעברות
טופס ההעברה פשוט טכנית אך קריטי ל-UX. לאחר הזנת הסכום והנמען, מסך אישור מציג את כל הפרטים לפני השליחה. לכפתור האישור יש השהיה מלאכותית של 1–2 שניות (מונעת לחיצה כפולה מקרית). עבור סכומים גדולים, נדרש אימות חוזר באמצעות ביומטריה או PIN.
אידמפוטנטיות להעברות: כל בקשת העברה מכילה idempotency_key ייחודי (UUID שנוצר בלקוח). אם הרשת אובדת והבקשה נשלחת שוב, השרת מחזיר את התוצאה של הבקשה הראשונה מבלי ליצור כפילות. זה קריטי — ללא אידמפוטנטיות, משתמש עם אינטרנט לא יציב עלול לשלוח את ההעברה פעמיים. בזכות מנגנון זה, צמצמנו עסקאות כפולות ל-0.01%.
היסטוריית עסקאות: רשימה מפולחת, מבוססת cursor. מקובצת לפי תאריך. חיפוש לפי תיאור, סכום, נמען. דף עסקה מפורט: כל הפרטים, סטטוס, קבלה ב-PDF (נוצר בשרת, ניתן להורדה במכשיר).
כיצד להבטיח הגנת מידע בבנקאות סלולרית
אפליקציית בנקאות סלולרית לעולם אינה מאחסנת מספרי כרטיס PAN בטקסט רגיל בשום מקום. אפילו מספרים מוסווים (**** 1234) מיועדים רק לתצוגה, לא ללוגים. Firebase Crashlytics ו-Analytics חייבים להיות עם איסוף PII מושבת: FirebaseCrashlytics.crashlytics().setCrashlyticsCollectionEnabled(false) עד להסכמה מפורשת של המשתמש.
תעבורת רשת — הצמדת אישורים (Certificate Pinning). ב-iOS: NSURLSession עם URLSessionDelegate.urlSession(_:didReceive:completionHandler:), השוואת SHA256 של המפתח הציבורי של האישור. ב-Android: OkHttp CertificatePinner. זה מגן מפני מתקפות MITM אפילו עם CA שנפרץ.
אנו מעדכנים את הצמדת ה-SSL כאשר אישורים מתחלפים דרך עדכוני תצורה OTA (Firebase Remote Config או נקודת קצה משלנו) — לא דרך עדכוני חנות. אחרת, כל גרסאות האפליקציה הישנות יפסיקו לפעול לאחר פקיעת האישור.
התראות עסקאות
Push לכל פעולה הוא סטנדרט. דרישות: מסירה תוך שניות, לא דקות. FCM עם priority: high ל-Android, APNs עם apns-priority: 10 ל-iOS. קריטי: אם push לא נמסר (מכשיר לא מקוון), בפתיחת האפליקציה הבאה — סנכרון עסקאות שלא אושרו.
Push עשיר: סכום, סוג פעולה, 4 ספרות אחרונות של הכרטיס. ב-iOS — UNNotificationServiceExtension לפענוח payloads מוצפנים מקצה לקצה (בנקים לעתים קרובות מצפינים נתונים רגישים ב-push). זמן תגובה ל-push — מתחת ל-500 אלפיות השנייה.
חשבונות וכרטיסים
מסך ראשי: רשימת חשבונות עם יתרות. ווידג'ט כרטיס (ייצוג פיזי או ויזואלי). ניהול כרטיס: חסימה, מגבלות, צפייה בפרטים (CVV רק לאחר ביומטריה, לא מאוחסן בזיכרון יותר מ-30 שניות).
טוקניזציה של Apple Pay / Google Pay: להוספת כרטיס ל-Wallet — PKAddPaymentPassViewController (iOS) / PushProvisioningActivity (Android). זה לא אינטגרציית תשלום סטנדרטית — זה דורש הסכם מיוחד עם Visa/Mastercard והסמכה. התהליך אורך חודשים; התחילו מוקדם.
צ'אט תמיכה באפליקציה
צ'אט באפליקציה עם נציג בנק. Stream Chat SDK או Sendbird — פתרונות מוכנים לארגונים עם היסטוריה, חיפוש, push על הודעה חדשה. הודעות מוצפנות במעבר ומאוחסנות בשרתי הספק — אנו מוודאים עמידה בדרישות רגולטוריות.
ארכיטקטורה: Native לעומת Cross-Platform
| קריטריון | Native (Swift + Kotlin) | Flutter | React Native |
|---|---|---|---|
| גישה ל-Secure Enclave/חומרה | מלאה | דרך שכבת הפשטה (דורש ביקורת) | דרך גשר (אימות נוסף) |
| ביצועים | מקסימליים | גבוהים (90%+) | בינוניים (60-80%) |
| ביקורת אבטחה | קלה יותר — ממשקי API מקוריים | דורשת בדיקות נוספות | דורשת בדיקות נוספות |
| זמן פיתוח | ארוך יותר (שני בסיסי קוד) | מהיר יותר (בסיס קוד אחד) | מהיר יותר (בסיס קוד אחד) |
Native Swift (iOS) + Kotlin (Android) מועדף עבור FinTech. סיבה: שליטה מירבית באבטחה, גישה מקורית ל-Secure Enclave, BiometricPrompt, Apple Pay provisioning. בנוסף, ביקורת אבטחה פשוטה יותר.
Clean Architecture: Domain (Use Cases) / Data (Repository, API) / Presentation (MVVM, ViewModels). יכולת בדיקה של כל שכבה היא חובה — בדיקות יחידה על Use Cases, בדיקות אינטגרציה על Repository.
Flutter — מקובל עבור FinTech אם יש לכם מפתחי Flutter מנוסים. מגבלות: flutter_secure_storage משתמש ב-Keychain/Keystore אך דרך שכבת הפשטה שדורשת ביקורת. local_auth לביומטריה עובד כראוי.
שלבי פיתוח ולוחות זמנים
| שלב | משך |
|---|---|
| סקירת ארכיטקטורת אבטחה | 1–2 שבועות |
| עיצוב ו-UX | 2–4 שבועות |
| אימות, ביומטריה | שבועיים |
| חשבונות, העברות, היסטוריה | 4–6 שבועות |
| כרטיסים ו-Apple/Google Pay | 3–4 שבועות |
| התראות Push, צ'אט | שבועיים |
| ביקורת אבטחה ואישור רגולטורי | 2–4 שבועות |
| פרסום בחנות | שבוע |
דוגמה למבנה פרויקט
```
Project/
├── app/
│ ├── src/
│ │ ├── main/
│ │ │ ├── kotlin/com/bank/
│ │ │ │ ├── domain/
│ │ │ │ ├── data/
│ │ │ │ └── presentation/
│ │ │ └── res/
│ └── build.gradle
├── domain/
├── data/
└── presentation/
```
מה כלול
- סקירת ארכיטקטורת אבטחה ומודל איומים
- מערכת עיצוב למותג שלכם
- אימות: ביומטריה, PIN, JWT, זיהוי root
- חשבונות ויתרות, העברות עם אידמפוטנטיות
- אינטגרציית מערכת תשלומים: Apple Pay, Google Pay
- התראות Push עם תוכן עשיר
- SDK לצ'אט לתמיכה
- תיעוד: ארכיטקטורה, API, מדיניות אבטחה
- גישה למאגרי קוד, CI/CD, חשבונות חנות
- הכשרת צוות הלקוח
- תמיכה לאחר השקה: אחריות ל-3 חודשים
תהליך
סקירת ארכיטקטורת אבטחה → עיצוב → אימות וביומטריה → חשבונות ויתרה → העברות עם אידמפוטנטיות → היסטוריית עסקאות → כרטיסים ו-Apple/Google Pay → התראות push → ביקורת אבטחה → אישור רגולטורי → פרסום.
הערכות לוחות זמנים
אפליקציית FinTech MVP (אימות, חשבונות, העברות, היסטוריה): 8–12 שבועות. בנק סלולרי מלא עם כרטיסים, Apple/Google Pay provisioning, צ'אט תמיכה, מודול השקעות: 4–8 חודשים. השקעה ל-MVP מתחילה מ-2 מיליון רובל; עלות מדויקת נקבעת לאחר ניתוח דרישות והיקף אבטחה.
צרו קשר כדי להעריך את הפרויקט שלכם — קבלו חישוב מדויק תוך יומיים. בקשו ייעוץ, ונכין הצעה מסחרית עם תוכנית עבודה מפורטת ולוח זמנים.