כיצד לחבר מסוף POS לאפליקציה ניידת?
חיבור אפליקציה ניידת למסוף POS אינו רק "שליחת הסכום למסוף". מדובר באינטגרציה עם פרוטוקולי חומרה קנייניים—לכל יצרן יש פרוטוקול משלו—בנוסף לטיפול בכל כשלי התקשורת האפשריים במהלך עסקה פיננסית. לחברה שלנו ניסיון של 7+ שנים בפיתוח נייד וביצענו מעל 20 אינטגרציות עם מסופי POS עבור סולקים שונים. הגישה שלנו מכסה את כל מקרי הקצה כדי להבטיח שכל עסקה תושלם כראוי.
תרחיש טיפוסי: קופאי בסופרמרקט מעבד תשלום דרך אפליקציה ניידת, המסוף מאשר את הכרטיס, אך החיבור נופל. מה עושים? הפתרון שלנו כולל בקשת סטטוס אוטומטית לעסקה האחרונה ומנגנון התחברות מחדש עם 5 ניסיונות, ומשיג שיעור הצלחה של 99% בקביעת הסטטוס. הזמינו אינטגרציה במפתח מוכן—אנחנו מטפלים בכל השלבים: מניתוח פרוטוקול ועד בדיקות על חומרה אמיתית. נעריך את הפרויקט שלכם תוך שני ימי עסקים.
פרוטוקולים ויצרנים
רוב מסופי ה-POS בקמעונאות מתקשרים באמצעות אחד מפרוטוקולי הממשק הסטנדרטיים:
- פרוטוקול ECR (Electronic Cash Register) — קבוצת פקודות לשליחת הסכום מאפליקציית הקופה למסוף. לכל בנק-סולק או יצרן יש יישום משלו: Sberbank (SBOL), VTB, Ingenico, Verifone—כולם שונים בתחביר הפקודות ובשדות התגובה.
- OPI (Open Payment Initiative) / OPOS (OLE for POS) — פרוטוקולים סטנדרטיים יותר, פופולריים באירופה.
- SDKs קנייניים: PAX A-series, Sunmi V2, Newland—יש להם SDKs אנדרואיד משלהם (המסוף עצמו רץ על אנדרואיד, אנו קוראים לממשקי AIDL או Intents).
לפני תחילת הפיתוח, אנו מבררים עם הלקוח: איזה מסוף ספציפי, איזה בנק-סולק, איזה פרוטוקול נתמך. זו לא בחירה טכנית של מפתח—זו עובדה לגבי הציוד המותקן.
| פרוטוקול | יצרנים | מורכבות | מהירות | תקינה |
|---|---|---|---|---|
| ECR | Sberbank, VTB, Alfa-Bank | בינונית | גבוהה | אין, יישום עצמי |
| OPI/OPOS | Ingenico, Verifone | גבוהה | בינונית | כן |
| SDK קנייני | PAX, Sunmi, Newland | נמוכה | גבוהה | לא |
אילו ממשקים משמשים?
Bluetooth (BLE + Classic). המסוף משמש כשרת GATT (BLE) או כמכשיר טורי Bluetooth קלאסי. ב-iOS: CoreBluetooth עבור BLE; Bluetooth קלאסי רק דרך מסגרת ExternalAccessory עם הסמכת MFi. זהו מגבלה חשובה: רוב מסופי ה-POS משתמשים בפרופיל SPP של Bluetooth קלאסי, וללא הסמכת MFi מיצרן המסוף, iOS לא יכול להתחבר דרך BT קלאסי. לאנדרואיד אין הגבלות—BluetoothSocket + RFCOMM.
USB. אנדרואיד: UsbManager, UsbDeviceConnection. iOS: אביזר Lightning/USB-C—גם כאן נדרשת MFi. בפועל, חיבורי USB נדירים יותר מ-Bluetooth.
TCP/IP (Wi-Fi / LAN). המסוף נמצא ברשת המקומית; האפליקציה מתחברת דרך IP:Port ושולחת פקודות בפורמט טקסט או בינארי. URLSession / OkHttp עבור פקודות HTTP או CFStream / Java Socket עבור TCP גולמי. הממשק הצפוי ביותר מנקודת מבט של iOS.
זרימת תשלום
- האפליקציה יוצרת פקודת "מכירה" עם הסכום ופרמטרים נוספים.
- שולחת אותה למסוף.
- המסוף מציג למשתמש את מסך התשלום ומקבל את הכרטיס.
- מחזיר תגובה: סטטוס (
approved/declined/error), קוד אישור, RRN, PAN מוסווה. - האפליקציה מעבדת את התגובה וממשיכה את הזרימה העסקית (סוגרת קבלה, מעדכנת את ההזמנה).
שלבים 2–4 עשויים להימשך עד 60–90 שניות עם עיבוד תשלום איטי. במהלך זמן זה, אנו מציגים ספינר עם ההודעה "ממתין לתגובת המסוף" וכפתור "ביטול" (השולח פקודת ביטול למסוף, לא רק סוגר את המסך).
מה לעשות כשהחיבור נופל במהלך עסקה?
המקרה הלא נעים ביותר: העסקה נשלחה למסוף, החיבור אבד—האפליקציה לא יודעת אם התשלום עבר. המסוף אישר את הכרטיס, אך התגובה לא הגיעה.
הגישה הנכונה: בעת אובדן חיבור—לנסות לקבל את הסטטוס של העסקה האחרונה (פקודת "בקשת פעולה אחרונה"). אם המסוף מגיב, אנו לוקחים את הסטטוס משם. אם לא, אנו מציגים למפעיל "סטטוס לא ידוע, בדוק את המסוף" ושומרים את העסקה בסטטוס PENDING. חיוב אוטומטי כאשר הסטטוס לא ידוע אינו מקובל.
לוגיקת התחברות מחדש: בעת ניתוק Bluetooth—התחברות אוטומטית עם 5 ניסיונות, backoff אקספוננציאלי. סטטוס החיבור תמיד גלוי בממשק המשתמש (אייקון סטטוס).
Void והחזר כספי
Void (ביטול) — לפני סגירת היום הפיננסי. החזר כספי — אחרי. שניהם דורשים פקודות נפרדות למסוף עם ה-RRN של העסקה המקורית. אנו מיישמים את שני התרחישים כך שהמפעיל יוכל לתקן שגיאות.
השוואת פלטפורמות: אנדרואיד מול iOS
| היבט | אנדרואיד | iOS |
|---|---|---|
| BT קלאסי (SPP) | טבעי, BluetoothSocket |
רק מכשירי MFi |
| BLE | BluetoothGatt |
CoreBluetooth |
| USB | UsbManager |
רק MFi |
| TCP/IP | Socket / OkHttp |
CFStream / URLSession |
אם הלקוח דורש iOS והמסוף עובד רק עם Bluetooth קלאסי ללא MFi, הדרך היחידה היא TCP/IP דרך מתאם ביניים או מעבר למסוף עם תמיכה ב-BLE/TCP.
אגב, פרוטוקול BLE בדרך כלל מספק זמן השהיה נמוך יותר (עד 50 אלפיות השנייה) בהשוואה ל-Bluetooth קלאסי (100–200 אלפיות השנייה), ומאיץ את העסקה פי 2–4. זה חשוב לתרחישים עם תפוקה גבוהה. פרטים נוספים בתיעוד CoreBluetooth של Apple.
טעויות אינטגרציה נפוצות
- אי התחשבות בהסמכת MFi ב-iOS עבור Bluetooth קלאסי—גורם לחוסר אפשרות חיבור.
- חוסר בלוגיקת ניסיון חוזר בעת ניתוק—עסקאות אבודות.
- שימוש בפרוטוקול שגוי (למשל, ECR עבור מסוף שתומך רק ב-OPI).
- ניתוח שגוי של תגובת המסוף (קודי שגיאה שונים מיצרנים שונים).
מה כלול בעבודה
- ניתוח ציוד ופרוטוקולי סולק.
- יישום שכבת התעבורה (Bluetooth/USB/TCP).
- פיתוח פרוטוקול הפקודות (מכירה, void, החזר, בקשת סטטוס).
- טיפול במקרי קצה (ניתוק חיבור, timeout, סטטוס לא ידוע).
- בדיקות על מסוף אמיתי במצב בדיקה של הסולק.
- תיעוד אינטגרציה לתמיכת הלקוח.
- אחריות על שכבת התעבורה: 6 חודשי תמיכה חינם.
עלות האינטגרציה קבועה בשלב המפרט, וההחזר על ההשקעה מושג באמצעות אוטומציה של הזנת נתונים ידנית. קבלו ייעוץ לפרויקט שלכם—נעריך את המורכבות ואת לוח הזמנים.
תהליך
קביעת דגם המסוף והפרוטוקול → לימוד תיעוד הסולק → יישום שכבת התעבורה (BT/USB/TCP) → פרוטוקול הפקודות (מכירה, void, החזר, בקשת סטטוס) → טיפול במקרי קצה (ניתוק חיבור, timeout) → בדיקות על מסוף אמיתי במצב בדיקה של הסולק → בדיקות ייצור → פריסה.
הערכות לוחות זמנים
אינטגרציה בסיסית (מכירה + תגובה) על פרוטוקול יחיד עם ממשק אחד: 3–5 ימים. סט מלא של פעולות (מכירה, void, החזר, בקשת סטטוס) עם לוגיקת ניסיון חוזר/התחברות מחדש ומספר ממשקים: 2–3 שבועות.
הצוות שלנו מורכב ממפתחים ניידים עם ניסיון של 7+ שנים ב-iOS (Swift, SwiftUI, CoreBluetooth) ובאנדרואיד (Kotlin, Jetpack Compose, BluetoothSocket). עבדנו עם מסופים של PAX, Ingenico, Verifone, Sunmi. אנו מבטיחים איכות אינטגרציה ושקיפות בכל שלב.
הזמינו אינטגרציה של מסוף POS—ואנו נבטיח פעולה יציבה של מודול התשלום באפליקציה שלכם.







