Mobile app development for transport: bottlenecks
Schedule and payment in a transport app are tied together, and they most often break at the junction. Carriers provide trip data at different intervals and in their own formats: one updates the export once a day, another sends changes only after a cancellation.
A passenger sees a bus on the map, arrives at the stop, but the trip is not there — and this is no longer a data error but undermined trust in the carrier's mobile app.
A separate category is fare payment failures. A request goes to the payment gateway, the response does not return: connection was lost in a tunnel, the transaction hung at the operator.
As long as the debit moment and confirmation moment are not separated, the passenger either pays twice or rides without a ticket, and the carrier gets a discrepancy in reporting and a queue of support investigations.
Peak hours finish the picture. At boarding, dozens of devices simultaneously try to validate a ticket online, the channel at the stop is overloaded, validation takes seconds — the queue grows, the driver loses time on the route.
What solves this is not server capacity but the fact that validation must happen locally, and synchronization later, when connectivity returns.
We explain how this is addressed: where we place the local cache and queue of deferred operations, how we make payment retry safe, and how we deliver up-to-date schedules to the carrier without manual edits.
What changes after implementation: impact in numbers and timelines
The impact of app implementation is measured by four values: share of successful payments, discrepancy between actual service and schedule, number of support requests, and incident response time.
Before launch, if these were counted at all, it was manually from dispatcher logs, and the assessment remained anecdotal. We connect metrics to the same data collection as the app — the numbers are verifiable after handover.
The share of successful payments no longer depends on connection quality: the transaction is first recorded on the device and then sent when the channel is restored, so charges are not lost on stretches between stops or in underpasses.
Travel is confirmed by a previously saved ticket, and reconciliation with billing runs in the background — the passenger does not wait for a server response at the turnstile. On high-traffic routes, this removes the main cause of repeat entries and disputes with inspectors.
Schedule stability relies on data from onboard systems that arrives automatically, while manual dispatcher input remains only a fallback.
The discrepancy between actual service and plan is reduced to tens of seconds, arrival predictions are recalculated every few stops rather than once per shift. The passenger sees current time, the carrier sees deviations for specific trips.
The reduction in support requests comes from typical questions being resolved inside the app: payment status, transport location, trip history, refund. Operators handle complex cases instead of repeating the same thing over the phone.
Incident response time decreases because the signal comes from inside the system: a drop in the share of successful payments or growing discrepancy is visible before passengers start calling.
Measurements are taken before launch and after a month of operation on the same routes — at acceptance, it is clear what exactly changed and what needs refinement.
Implementation options: ready-made solution, platform, custom build
The choice of approach is determined by one question: how much the transportation logic differs from the standard.
If the schedule comes from an existing dispatch system, there is one fare, and routes are stable, there is no need to write everything from scratch — a ready-made transport solution covers such scenarios immediately.
As soon as zonal fares, transfer tickets, concession categories, or payment by actual mileage appear, the template starts to get in the way: every change runs into the limitations of someone else's data model.
This is where platform development works — a standard core with maps, payments, personal accounts, and notifications plus configuration of processes for the carrier. Custom app development is justified when the transportation rules are the product.
Comparison of approaches
| Option | When it fits | Limitations |
|---|---|---|
| Ready-made industry solution | Standard routes, one fare, schedule from an existing system | Non-standard logic has to be worked around, modifications depend on the vendor |
| Platform build | Own fares, zones, concessions, but without unique transportation logic | Configuration boundaries are finite, deep core rework is unavailable |
| Custom development | Transportation logic is a competitive advantage: dynamic fares, multimodality, own rules | Longer first version, support by your own team |
In practice, the approach is rarely pure: teams start on a platform and write unique components separately. We look at the fare model, current dispatch system, and plans for two to three years: if rules change more often than once a quarter, we allow a margin for modifications.
Work stages: from data audit to handover to support
We start not with mockups but with data: schedules, fares, and payment rules at each carrier exist in their own form — spreadsheets, exports from the dispatch system, sometimes paper regulations.
Until the sources are understood, any screen is built on guesses and diverges from reality on the very first shift. Below are the stages the project goes through.
- Carrier data audit. We consolidate schedule, stops, fares, and concessions into one model, and note where data is late, duplicated, or comes only from the dispatcher. The output is a source map with update frequency and owner for each.
- Integration scheme. We decide what the app retrieves directly and what goes through an intermediate layer with a local data copy. The layer covers carrier system unavailability: schedule and trip statuses remain in the app even when the external service is silent.
- Payment setup. We separate scenarios: single ticket, pass, concession travel, refund when a trip is canceled. We separately describe connection loss at the moment of charge and how the operation is completed on the next launch.
- Load testing. We run the morning peak and an hour of mass cancellations: simultaneous schedule updates, purchases on one route, a spike in support requests.
- Pilot on one route or fleet. We compare app data with actual vehicle departures and catch discrepancies before a city-wide release.
- Handover to support. Configurations, integration schemes, schedule update regulations, rollback and escalation procedures, on-call access to service monitoring systems.
What we hand over: schemes, access, and regulations
Project handover is not an archive with source code but a package your team or another contractor can use to release without us.
We fix the scope in an acceptance checklist: for each item at the final meeting we run a demonstration on a clean environment rather than showing slides. Below is what exactly remains with the customer.
- Integration schemes — how the app exchanges data with the schedule system (including the GTFS format), payment gateway, and validators: call sequence, queues, retry on failure, request rate limits.
- Data model description — dictionary of entities route, trip, stop, journey, payment, their relationships, history retention rules, and migration procedure when the structure changes.
- Access policies and roles — who can do what in the admin panel and in storage, where keys are stored, their rotation period, separation of development, testing, and production environments.
- Update regulations — version release procedure: which checks are mandatory, how the build is formed, how it is published in app stores, what happens on rollback to the previous one.
- On-call and response regulations — incident levels, response time for each, notification channels, who decides on rollback and based on what signs.
- App documentation — architecture diagram, local launch instructions, list of environment variables, known limitations, and technical debt with priorities.
- Maintenance instructions — how to update the schedule, add routes, change texts and fare rules without releasing a new app version.
Each item is considered handed over only after your specialists have reproduced it themselves. We go through acceptance together, answer questions, and stay in touch during the support period.
Implementation case study: schedule and payment in a transport service
A passenger transport service came with two related problems: the schedule in the app diverged from actual movement, and some payments did not reach confirmation.
The passenger waited for transport "according to schedule," paid, and was left without a travel document — support handled each such request manually.
What it was like before rework
The schedule was updated in one batch once a day: if a trip was delayed or canceled, no change data arrived, and the app showed the plan instead of the actual service.
Payment was charged on the provider side, but the response did not reach the app — the operation remained in an uncertain state, and reconciliation was done by daily export, so stuck payments were found after the fact.
What we changed and what resulted
The schedule was switched to incremental updates with a local cache: the app stores the current snapshot and works without network.
Payments were made retryable — a repeated request does not create a second charge, the operation state is restored when returning to the app, and automatic reconciliation closes discrepancies within a short interval.
- schedule discrepancy: 18% of requests → 3%
- stuck payments: 6% of operations → 0.4%
- disputed payment resolution time: day → minutes
- first-line support load: −42%
Metrics are confirmed by two sources: a support load report from City Passenger Transport Operator and a technical audit by the payment gateway integrator.
What to do if the schedule and payment are already in another service?
If the schedule and payment already live in another service, what needs to be migrated is not the "app" but the entire circuit: builds and signatures, store accounts, payment gateway, route data flows.
We start with an inventory: what is responsible for what, where the keys are, and who has access. Without this step, migration turns into working blind.
We migrate data separately because its nature is different. Schedules and route geometry are exported in the open GTFS format — any planning system can read it, so there is no loss during migration.
Bank card tokens are not migrated: they remain with the payment provider; we migrate transaction identifiers and reconcile the register — payments, refunds, unclosed payment sessions.
No downtime is needed to stop sales.
Both circuits run in parallel for some time: the new one receives a mirrored flow, reconciliation is performed for each operation, and switching is done in shares via a controllable toggle in the build — first a portion of users, then half, then all.
Rollback is setting the share back to zero; by that point the old service is still fully operational.
Changing the support contractor is a separate risk. We hand over the project in full: repository with history, build signing keys via a secure channel, developer accounts to the owner, documentation on exchange contracts.
Acceptance is technical: we build a release from the transferred source code, it passes store checks, and a test payment is completed.
In practice, this means: the schedule and payment migrate without stopping sales, and the owner retains keys, access, and a clear release procedure.
Technical concerns: offline, load, updates
Below are the questions that most often come up when a transport app already handles schedule and payment. We answer directly: what exactly happens with poor connectivity, how the system behaves at peak, and what can be changed without a new build.
What happens to payment when connectivity is unstable?
Payment does not hit a "no network" screen.
The operation goes into a local queue with the trip identifier, and the passenger sees the status "processing." When connectivity returns, the queue goes to the server, repeated sends are suppressed by the same identifier — no double charge occurs.
The app's offline mode stores the schedule and recent passes, so the validator and trip screen work without network.
Will the app withstand a sharp increase in trips?
The app's load is separated: schedule and fares are served from local cache, only payments and statuses go to the server. The morning peak and a mass login after an incident are handled the same way — first we record the operation, then reconcile it with the provider. We check capacity with load tests based on your route profile, not average numbers.
Can fares be updated without releasing a new version?
Yes — payment rules, zones, and discounts live in server configuration; the app fetches and caches it at launch. An update without releasing a version takes minutes; rollback is returning the previous set of rules.
We version the configuration schema: old builds do not break because they continue to read a compatible set of fields.
Let's discuss the task: what is needed to start work
Work starts not with a contract but with analyzing the task: the more precise the customer's input data, the fewer assumptions in the project estimate and the less often the implementation plan is rewritten midway.
Below is what is sufficient to prepare so the discussion is substantive rather than full of general words.
- Transport model: modes of transport, number of routes, stops, and trips, seasonal and weekend schedule options.
- Schedule source: dispatch system, regular export, or manual edits — and who is responsible for data currency.
- Fares and tickets: zones, concessions, passes, single trips, transfer and refund rules.
- Payment scenarios: payment by card, wallet, code on the validator or in the vehicle; how refunds and cancellations are processed.
- State of integrations: acquiring, ticketing system, validator supplier — whether there is documentation and a test environment for payment checks.
- Offline operation: what should open offline — saved ticket, trip history, deferred payment confirmation.
- Constraints and benchmarks: platforms, geography, languages, personal data requirements, and points where a pilot launch on one route is needed.
Based on the analysis, we come back with an estimate and stage plan: boundaries of the first version, order of integration connections, roles on the customer side, and control points. Then you decide whether to start work — discussing the task does not commit you to any timelines.