פיתוח מסך תשלום לאפליקציות מובייל
מסך התשלום הוא הנקודה שבה משתמשים נוטשים את הרכישה ביותר. טופס ארוך עם שדות כתובת, אפשרויות משלוח והזנת כרטיס על מסך מובייל הופך למבחן אם אינו מעוצב במיוחד לאינטראקציית מגע. הצוות שלנו מפתח מסכים כאלה תוך התחשבות בכל מאפייני הפלטפורמה — מטיפול נכון ב-KeyboardAvoidingView ועד אינטגרציה עם Apple Pay ו-Google Pay. הניסיון מראה שעד 60% מהמשתמשים נוטשים את התשלום עם טופס מעוצב בצורה גרועה. טכנית, זהו המסך המורכב ביותר באפליקציית מסחר אלקטרוני: אינטגרציית תשלומים, ולידציה בזמן אמת, טיפול במקלדת, אזורי גלילה מרובים. ב-5 שנות פעילות בשוק, סיפקנו מעל 50 מסכי תשלום ל-iOS ו-Android, והפחתנו את שיעור נטישת העגלה ב-30-40% בממוצע. הניסיון שלנו מבטיח עמידה בכל דרישות App Store ו-Google Play.
מדוע מסך התשלום הוא המורכב ביותר?
השילוב של דרישות תשלום, ניואנסים של UX וביצועים הופך את התשלום לצוואר בקבוק. לדוגמה, ב-iOS יש לטפל נכון ב-PKPaymentAuthorizationViewController על ה-thread הראשי, אחרת האפליקציה קורסת. ב-Android, יש לבדוק IsReadyToPayRequest לפני הצגת Google Pay. כל השדות חייבים לעבור ולידציה מבלי לחסום קלט, והמקלדת לא צריכה לכסות את השדה הפעיל. אנו פותרים בעיות אלה באמצעות תבניות מוכחות.
כיצד אנו מבטיחים אבטחת תשלומים?
PCI DSS אוסר על העברת נתוני כרטיס גולמיים דרך השרת שלך. רק טוקניזציה דרך ה-SDK של הספק מותרת. Apple App Review דוחה אפליקציות עם טפסי כרטיס מתארחים עצמית מסיבה זו. אנו משתמשים ב-SDK מוכנים: stripe-react-native או Stripe SDK מקורי, CloudPayments SDK, YooKassa. עבור כל ספק, אנו מגדירים טוקניזציה ו-3D Secure. כתוצאה מכך, נתוני כרטיס לעולם לא מגיעים לשרת שלך.
אינטגרציות תשלום
זהו החלק עתיר העבודה ביותר. לכל ספק יש SDK משלו עם דרישות ספציפיות.
Stripe — stripe-react-native או Stripe iOS/Android SDK מקורי. רכיב CardField מטפל בהזנת כרטיס עם עיצוב אוטומטי וולידציה. PaymentSheet הוא bottom sheet מוכן מ-Stripe, עם התאמה מינימלית אך אמינות מקסימלית. ל-UI מותאם אישית, השתמש ב-useStripe().confirmPayment() עם PaymentIntent client secret מהשרת.
Apple Pay / Google Pay. ב-iOS — PKPaymentAuthorizationViewController, ב-React Native דרך @stripe/stripe-react-native עם useApplePay(). ב-Android — PaymentsClient מ-Google Pay API + IsReadyToPayRequest. שני הכפתורים מוצגים רק אם אמצעי התשלום זמין במכשיר — stripe.isApplePaySupported() / paymentsClient.isReadyToPay(). חיסכון בפיתוח באמצעות SDK מוכנים יכול להגיע עד 20%.
| ספק | SDK | מאפיינים |
|---|---|---|
| Stripe | stripe-react-native | PaymentSheet, CardField, 3D Secure |
| CloudPayments | CloudPayments SDK | Cryptogram, תשלומים חוזרים |
| YooKassa | YooKassa | Yandex.Kassa, Apple Pay ב-iOS |
כיצד אינטגרציות תשלום משפיעות על הארכיטקטורה?
כל ספק דורש תרחיש משלו: Stripe זקוק ל-PaymentIntent, CloudPayments דורש cryptogram, YooKassa מצפה ל-token. אנו מתכננים שכבת תשלום עם פרוטוקול מופשט כך שמעבר בין ספקים לא משפיע על ה-UI. לדוגמה, ב-React Native אנו משתמשים בתבנית Provider עם ממשק משותף processPayment(token: String). זה מפחית את עלות השינויים בעת החלפת שער התשלום.
| פלטפורמה | מאפייני יישום מסך תשלום |
|---|---|
| iOS | PKPaymentAuthorizationViewController, Core Data לשמירת כתובות במטמון, SwiftUI או UIKit |
| Android | Google Pay API, Room לאחסון נתונים, Jetpack Compose |
| Cross-platform | לוגיקת ולידציה אחידה, גשרים מקוריים לתשלומים |
ניהול טופס
טופס תשלום מכיל בדרך כלל 10–15 שדות. ללא ניווט נכון בין שדות (returnKeyType="next" + ref.focus() על הקלט הבא) הוא הופך לבלתי נסבל. ב-React Native Hook Form — Controller + מערך useRef לשדות + setFocus אוטומטי על שגיאה לאחר שליחה.
המקלדת היא הכאב העיקרי. KeyboardAwareScrollView מ-react-native-keyboard-aware-scroll-view עובד טוב יותר מ-KeyboardAvoidingView הסטנדרטי: הוא גולל אוטומטית לשדה הפעיל ומטפל נכון בשינויי גובה בעת שינוי כיוון.
ב-iOS, שדות מספריים (מיקוד, CVV) חייבים לפתוח UIKeyboardType.numberPad. decimalPad לסכומים. emailAddress למייל. keyboardType שגוי הוא פרט קטן שכל המשתמשים שמים לב אליו אך לא מזכירים בקול.
ולידציה ו-UX
ולידציה בזמן אמת מיועדת רק לשדות עם פורמט דטרמיניסטי: טלפון, מייל, מיקוד, מספר כרטיס. לשדות טקסט (שם, כתובת) — רק ב-onBlur, אחרת שגיאה כמו "שם לא תקין" מופיעה על האות השלישית.
השלמה אוטומטית של כתובת דרך Google Places Autocomplete API או Dadata API (לרוסיה) היא חובה. הזנה ידנית של רחוב, בית ודירה בשדות נפרדים מגדילה את זמן ההזנה פי 3-4 ומגבירה שגיאות משלוח. השלמה אוטומטית מקצרת את זמן מילוי הטופס מ-3-4 דקות ל-30 שניות ומפחיתה שגיאות משלוח ב-25%.
מהניסיון: אפליקציית משלוחים, React Native + Stripe. בעת תשלום עם Apple Pay ב-iPhone XR פיזי, האפליקציה קרסה עם NSException מיד לאחר האישור. הסיבה — PKPaymentAuthorizationController נקרא מ-thread ברקע. העברתו ל-DispatchQueue.main במודול המקורי פתרה את הבעיה. גשר React Native אינו מבטיח את ה-thread הראשי עבור callbacks.
מדוע ולידציה בזמן אמת היא קריטית?
המשתמש מצפה למשוב מיידי. אם השגיאה מוצגת רק לאחר לחיצה על "שלם", הם נאלצים לתקן מספר שדות בבת אחת, מה שמגביר את הסבירות לנטישה. אנו מיישמים ולידציה על קלט לשדות עם פורמט ברור, ולאחרים לאחר איבוד פוקוס. זה משפר את ההמרה ב-10-15%.
תשלום רב-שלבי
לתשלום ארוך אנו משתמשים ב-stepper (שלבים: כתובת → משלוח → תשלום → אישור). כל שלב הוא רכיב נפרד עם ולידציה משלו. המצב נשמר ב-store יחיד, לא מועבר דרך props בין מסכים. ProgressBar בחלק העליון מציג את השלב הנוכחי.
כפתור "חזור" חייב לשמר נתונים שכבר הוזנו — אין לאפס את הטופס בעת חזרה לשלב קודם.
מה כלול בעבודה
- טופס כתובת עם השלמה אוטומטית (דרך Places API)
- בחירת שיטת משלוח עם הערכת עלות וזמן
- רשימת כתובות שמורות של משתמשים
- אינטגרציית ספק תשלומים (Stripe, CloudPayments, YooKassa ואחרים)
- Apple Pay / Google Pay עם בדיקת זמינות
- ולידציה בזמן אמת + טיפול בשגיאות API
- מסך אישור הזמנה עם מספר ופרטים
- שמירת הכתובת והכרטיס האחרונים בשימוש
- תיעוד אינטגרציה ותמיכה לאחר השקה
לוח זמנים ועלות
3–5 ימי עסקים — תלוי במספר ספקי התשלום, במורכבות לוגיקת ההנחות ובדרישות ולידציית הכתובת. אינטגרציה של ספק אחד עם Apple Pay/Google Pay אורכת 2–3 ימים. העלות מחושבת באופן אישי. נבחן את הפרויקט שלך — צור קשר כדי לדון בפרטים. קבל ייעוץ מהנדס והערכת לוח זמנים מדויקת עוד היום.