פיתוח אפליקציית מובייל לכרטיסי אוטובוס

פיתוח אפליקציית מובייל לכרטיסי אוטובוס

אנו מפתחים אפליקציות מובייל למכירת כרטיסי אוטובוס עם אינטגרציה למערכות החשבונאות של המובילים. בניגוד לתעופה, שבה פועלות מערכות GDS סטנדרטיות, מכירת כרטיסי אוטובוס מתמודדת עם APIs מקוטעים, פרוטוקולים מיושנים וחוסר במרשם מובילים אחיד. מובילים רבים עדיין משתמשים בפרוטוקולי XML ישנים ללא תמיכה ב-REST, ולכן אנו מתאימים את הניתוח לכל מערכת—מ-1C ועד למשרדי כרטיסים ייעודיים של 'Avtovokzal'. חשוב לשמור על מהירות תגובה: זמן התגובה הממוצע של API של מוביל לא יעלה על 500 אלפיות השנייה, אחרת משתמשים נוטשים את האפליקציה. לכן לקוחות זקוקים למערכת אינטגרציה מורכבת, מצב לא מקוון ולוגיקת החזרים גמישה.

לצוות שלנו ניסיון רב בפיתוח אפליקציות תחבורה, עם מסירה של למעלה מ-15 פרויקטים למובילי אוטובוס ולאגרגטורים. אנו מבטיחים איכות בכל שלב—מהניתוח ועד לתמיכה לאחר השחרור. צרו קשר להערכת פרויקט או קבלו ייעוץ על אינטגרציה.

מקורות נתונים ואינטגרציה

שלוש דרכים עיקריות:

• המערכת של המוביל עצמו. אנו מפתחים עבור מוביל ספציפי—יש להם לוח זמנים ומערכת קופה משלהם (בדרך כלל Автовокзал, Радар, Transinfo, או 1C). אנו מתחברים ישירות דרך REST או XML API. אמין אך קהל סגור.
• אגרגטורים. Tutu.ru, Busfor, CheckMyBus מספקים APIs לשותפי white-label. הגישה דורשת חוזה. Tutu API הוא REST/JSON עם לוחות זמנים עדכניים לרוב המסלולים ברוסיה ובחבר המדינות. CheckMyBus מיועד למסלולים בינלאומיים.
• אגרגציה עצמית. ניתוח וחוזים ישירים עם מובילים—האופציה היקרה והמתישה ביותר, אך מעניקה שליטה על נתונים ומרווח.

אינטגרציה עם SBP מאפשרת תשלומים מהירים יותר מכרטיסי אשראי, ועמלה של 0.4–0.7% חוסכת עד 30% בעלויות סליקה.

מדוע אפליקציות אוטובוס דורשות גישה מיוחדת?

בניגוד לכרטיסי טיסה, שבהם הנתונים סטנדרטיים דרך מערכות הזמנות, מובילי אוטובוס משתמשים בעשרות מערכות חשבונאות שונות עם פרוטוקולים לא תואמים. חלק מהמובילים אינם תומכים בכרטיסים אלקטרוניים—רק בנייר, ויש להציג זאת במפורש בממשק לפני הרכישה. בנוסף, פריסות המושבים באוטובוסים משתנות מאוד: מפשוט 'מושב פנוי' ועד לרשת מרובדת עם מעברים ומחלקות שונות. זה הופך את הממשק למורכב יותר ואת הבדיקות לקריטיות. לפי App Store Review Guidelines (סעיפים 4.2, 5.1), אפליקציות כאלה חייבות לציין במפורש את כל ההגבלות.

כיצד עובדת אינטגרציה עם מוביל?

1. ביקורת על API של המוביל—לימוד תיעוד, בדיקת נקודות קצה, זיהוי מגבלות (למשל, ללא תמיכה בסל או בהחזרים).
2. פיתוח מתאם—כתיבת מודול להמרת נתונים לפורמט אחיד. השתמשו ב-Codable (iOS) או Kotlinx.serialization (Android).
3. בדיקות על מסלולים חיים—הרצת עד 100 תרחישים: רכישה, החזר, שינוי מושב, עיכובים.
4. פריסה לסביבת sandbox—המוביל בודק על הנתונים שלו.
5. שחרור ל-App Store ול-Google Play—הבטחת עמידה בApp Store Review Guidelines (סעיפים 4.2, 5.1).

חיפוש וזמינות מושבים

חיפוש: מוצא-יעד, תאריך, מספר נוסעים. השלמה אוטומטית לתחנות דרך UISearchTextField (iOS) עם debounce של 300 אלפיות השנייה או SearchBar + Flow ב-Jetpack Compose. מסד נתוני התחנות נשמר מקומית: הרשימה המלאה של תחנות האוטובוס ברוסיה כוללת כ-3000 רשומות, נטענת בהפעלה הראשונה ומתעדכנת מדי שבוע.

בחירת מושב. לא כל המובילים תומכים במפת מושבים עם בחירה ספציפית—חלקם פשוט מוכרים 'מושב באוטובוס'. כאשר מפה זמינה, אנו מציגים אותה כשורות ועמודות מה-API, ומסמנים מושבים תפוסים.

// SwiftUI: сетка мест в автобусе
struct BusSeatMapView: View {
    let seats: [[BusSeat?]] // nil = проход
    var body: some View {
        VStack(spacing: 4) {
            ForEach(seats.indices, id: \.self) { row in
                HStack(spacing: 4) {
                    ForEach(seats[row].indices, id: \.self) { col in
                        if let seat = seats[row][col] {
                            SeatCell(seat: seat)
                        } else {
                            Spacer().frame(width: 32)
                        }
                    }
                }
            }
        }
    }
}

כרטיס אלקטרוני

לאחר התשלום, אנו יוצרים PDF עם קוד QR לכרטיס. חשוב: חלק מהמובילים אינם מקבלים כרטיסים אלקטרוניים—רק מודפסים. יש להציג מגבלה זו במפורש בממשק לפני הרכישה, אחרת תקבלו גל של ביקורות שליליות.

ה-QR נשמר ב-rows (iOS) או cols (Android) לגישה לא מקוונת. התראה Push שעתיים לפני היציאה דרך FCM/APNs.

כיצד מובטחת גישה לא מקוונת לכרטיסים?

אנו שומרים קודי QR ונתוני כרטיסים מקומית כך שנוסעים יכולים להציג כרטיסים ללא אינטרנט. אנו משתמשים ב-// SwiftUI: сетка мест в автобусе struct BusSeatMapView: View { let seats: [[BusSeat?]] // nil = проход var body: some View { VStack(spacing: 4) { ForEach(seats.indices, id: \.self) { row in HStack(spacing: 4) { ForEach(seats[row].indices, id: \.self) { col in if let seat = seats[row][col] { SeatCell(seat: seat) } else { Spacer().frame(width: 32) } } } } } } } (iOS) או FileManager (Android) עם הצפנה. רשימת הכרטיסים מסונכרנת בכל חיבור רשת, והודעות עיכוב/ביטול מגיעות דרך שירותי push.

תשלום

SBP היא שיטת התשלום העיקרית לכרטיסי אוטובוס: עמלה נמוכה (0.4–0.7%), סילוק מיידי. YooKassa או CloudPayments לכרטיסי אשראי. Apple Pay ו-Google Pay מגדילים את ההמרה בשלב האחרון—אנחנו לא שוכחים אותם.

עבור חלק מהמובילים, נדרש תשלום במזומן בעלייה: הזמנה ללא תשלום עם החזקה של 30 דקות. אין צורך במנגנון החזקה; דגל filesDir בהזמנה מספיק.

החזרי כרטיסים

החזרים דרך ה-API של המוביל או האגרגטור. התנאים משתנים לפי מוביל—אנו מציגים אותם במסך הרכישה, לא מוסתרים בתנאי השירות. טכנית: FileManager או filesDir. הכסף מוחזר לכרטיס תוך 3–10 ימי עסקים בהתאם לבנק.

מדיניות אופיינית: ביטול חינם 3+ שעות לפני היציאה, קנס של 10–30% לביטול פחות מ-3 שעות לפני. תנאים ספציפיים מגיעים מה-API יחד עם לוח הזמנים.

התראות ומעקב

מעקב עיכובים—דרך API של המוביל אם נתמך, או על ידי בדיקת סטטוס הטיסה כל 5 דקות. Push שעתיים ו-30 דקות לפני היציאה. אם המוביל תומך במעקב GPS, אנו מציגים את מיקום האוטובוס הנוכחי על המפה דרך payment_method: cash או Google Maps SDK.

מה כלול בעבודה

• תיעוד אינטגרציה (תיאור API, סכמות נתונים, דוגמאות בקשות).
• גישה ל-API לבדיקות (sandbox) לניפוי באגים.
• הדרכה של צוות המוביל על שימוש באפליקציה.
• תמיכה במהלך השחרור ל-App Store ול-Google Play.
• אחריות לתיקון שגיאות קריטיות תוך 30 יום לאחר המסירה.
• קוד מקור ובעלות על האפליקציה (אתם מקבלים בעלות מלאה).

לוח זמנים

4–6 שבועות לאפליקציה למוביל ספציפי או עם API של אגרגטור. העלות מחושבת באופן פרטני לאחר ניתוח דרישות. הזמינו פיתוח turnkey—צרו קשר להערכה מוקדמת. אינטגרציה נכונה עם מקורות נתונים מקצרת את זמן היציאה לשוק בעד 30%.

קבלו ייעוץ על הפרויקט שלכם—נעזור לכם לבחור את נתיב האינטגרציה האופטימלי.