Mobile app development for gas stations (refueling)

Mobile app for gas stations: where the fueling scenario breaks

A customer at a gas station rarely compares apps by feature set — they solve one task in a couple of minutes.

What usually breaks is not the interface but the link between smartphone, pump and back office: the price in the mobile app for gas stations is one, on the sign another, remaining stock at the site is already zero, but the app still sells a liter. Then the fueling scenario falls apart, and the person returns to the usual cash desk.

Paying for fuel from a smartphone is the most sensitive area. If the connection at the gas station drops, and the operation is not marked as retryable, the money is debited, the dispensing command does not arrive, and the customer is left with a frozen amount and without fuel.

The symmetric error is double debit on retry, when the app and server blame each other for the timeout.

A separate area is inventory accounting by site, when data is pulled by scheduled exchange every few hours. The operator manually edits limits, removes blocks and closes disputed receipts, while the queue at the cash desk grows exactly during peak at the site.

The more manual operations in the customer journey, the higher the chance that after the first failed attempt the app will simply be deleted and they will not return.

We explain how this is addressed: where local logic on the device is needed, where retryable operations and reconciliation with the gas station are needed, and where honest statuses are enough instead of promises.

What changes at a gas station after service launch: effect in metrics

Implementation metrics make sense only against a baseline taken before launch. Before the first release, we record at a specific site: time from entering to leaving the car, share of completed payments, number of manual operations per shift, volume of support requests per week.

Then the same measurements are repeated in a month and in a quarter — at the same site and in the same peak hours.

• Service time at the gas station. Payment and receipt go to the app, the trip to the cash desk and waiting at the terminal disappear from the cycle. The cycle shortens noticeably, and this is visible not by feel, but by stopwatch on shift.
• Share of successful payments. A saved payment method, retry on connection loss and a clear reason for decline instead of “payment failed” — the share of completed operations grows, and incomplete ones at the pump disappear.
• Operator load. Typical scenarios — payment, receipt, bonuses, fuel cards — are closed in the app. The operator remains for non-standard situations, and during peak hours the cash desk stops being a bottleneck.
• Repeat purchases. The loyalty program is tied to the profile, not to a paper medium: a lost card no longer means the loss of the customer and accumulated liters.
• Support requests. A whole class of requests due to manual entry of the pump number, amount and disputed receipts disappears — instead of phone investigation, the customer sees the history of their operations.

Payment is pulled through Apple Pay and Google Pay, so the share of successful payments is the first metric worth watching after launch. It should be compared with the measurement before implementation: without a baseline, the numbers prove nothing.

Build options: native, cross-platform and web version

The choice is influenced not only by the timeline of the first version, but also by the expense of supporting two platforms, the speed of releasing changes and app behavior when the connection at the site drops.

At gas stations these factors are related: the more native code, the more stable the work with site equipment, but the more expensive each change.

How this affects offline operation

Offline operation is the main criterion of choice. The app must accept operations when there is no connection and transmit them when it appears, without losing order and without duplicating accruals.

Native build gives predictable local storage and queue, cross-platform — the same scenario with careful work with storage, web version — only at the expense of browser cache, which is unreliable on weak devices.

In practice, a combination is more often taken: a cross-platform foundation for interface and loyalty plus native modules for payment and site equipment. This option keeps one team for both platforms and does not break the offline scenario. We explain how this is distributed in your case.

Implementation stages: from scenario audit to handover to the team

An app for gas stations almost never lives separately from the site: it is connected to fuel dispensers, the cash desk node, card processing and the loyalty system.

If you start the build earlier than the fuel dispensing and payment confirmation scenario is described, you have to redo the entire contour — from interface to exchange with the cash desk. Therefore we go from infrastructure analysis to pilot and handover.

How the sequence is structured

1. Infrastructure and scenario audit — pump and controller models, cash software versions, connection quality at the islands, queue behavior during peak hours.
2. Integration scheme — exchange protocols with the cash desk and processing, coupling with loyalty, card payment, SBP and fuel card, rules for reconciliation of disputed operations.
3. Build and offline mode — critical path, operation queue during connection loss, retries without double debit and correct session recovery.
4. Pilot at one site — a limited group of employees and drivers, comparison of the result with regular fueling, rollback check without stopping the gas station.
5. Load testing — morning and evening peaks, processing unavailability, channel outage: we look at where the operation queue accumulates.
6. Acceptance criteria — fuel dispensing time, share of successful payments, number of support requests, behavior during failures.
7. Handover to operation — update and rollback regulations, configurations, shift instructions, support training and on-call during the trial run.

What the customer retains: code, schemes, regulations, access

We hand over not a “finished app” but a working system together with documentation: in a year you can change contractor or assemble an in-house team without restoring logic from screen behavior. We record artifacts in the handover act — each has an owner and storage location.

• Source code and rights — repositories of mobile clients, server side and admin panel with change history; rights are transferred under contract, without modules that only the author can edit.
• Integration schemes — exchange with fuel dispensers, the cash desk node, payment gateway and loyalty program: request sequence, failure handling, resending.
• Interface descriptions — exchange points with fields and response codes plus a test bench where exchanges are run without real fueling.
• Update regulation — version release procedure: build, check, publication in app stores, update timelines when external services change.
• Role and access matrix — what the site operator, manager, accounting and support see and change; separately, access to servers and panels.
• Personnel instructions — memos for gas station operators: how to process payment via the app, what to do on failure, where to route the customer request.

We issue access by roles, not specific people — when an employee leaves, nothing has to be searched through correspondence. External dependencies are marked separately: what works on your side and what remains with the equipment and payment provider.

Case: how a ten-site network eliminated the queue at the cash desk

What was before the pilot

A network of ten sites lived as ten separate businesses: its own cash desk, its own local discount base, its own list of regular customers.

The operator manually linked the pump number with the order, and calculated the cumulative discount on a calculator — during peak hours the queue went beyond the canopy, and an error in the pump number turned into a recalculation and dispute with the customer right at the cash desk.

At the start, the app could only show the nearest site. Buying fuel through it was impossible, so retaining the customer within the network was possible only at the expense of the price on the sign: as soon as the neighboring site lowered the price, the flow went there.

Pilot implementation and metrics

All sites were brought into one contour: a unified directory of pumps, fuel types and shifts, a common customer profile and one bonus balance valid at any site of the network.

The customer selects the pump in the app, pays and starts fuel dispensing themselves — the operator only has to confirm the operation, not enter it manually.

The pilot was placed at three sites, payment and dispensing events were collected in AppMetrica: this showed at which step the customer drops off — pump selection, payment or confirmation.

Average service time during peak fell from four minutes to forty seconds for those who pay from the app, and the share of such receipts grew from zero to a third of turnover.

Operator load decreased: manual operations per shift became about 40% fewer, pump number errors almost disappeared.

Retention was calculated by return to a network site within a month — the share of returners grew by 18%, and transition between sites stopped being a loss: bonuses and purchase history travel with the customer.

What to do if another contractor is already implementing the solution?

Full redevelopment is needed less often than it seems: in an app for gas stations, value is carried not by lines of code but by working connections with the cash desk node, pump controllers and the offline operation queue.

There are three typical entry situations — an unfinished project, tasks spread across several contractors, maintenance without documentation. First we separate the nodes that can be kept and what will have to be changed.

An audit of the existing build answers four questions: what is reproduced from source code, on which environments it builds, which contracts with external systems are fixed, where a cash desk failure will leave the customer without payment.

In parallel we restore documentation — integration schemes, data model, version release regulation, access matrix. From here it is visible where improvements without rewriting are enough.

Changing contractor rests not on code but on handover of maintenance: release regulation, monitoring, access to environments, incident response procedure on pumps. We fix this in writing before work starts — then the transition does not turn into downtime. Describe where the project is now, and we will return with an estimate and entry plan.

Technical doubts before start: briefly and to the point

Before start, the same questions come up — and almost all of them are not about features but about how the app will coexist with already working gas station systems. Below briefly, and we discuss details on each point during assessment.

What happens if connection at the gas station is lost?

The app works in offline mode: the operation is recorded locally and goes to the server when connection returns. The queue preserves order, duplicates are cut off by operation identifier, so payment and point accrual are not doubled.

Can we launch not everything at once?

Yes, and usually that is what we do. First a pilot at one or two stations: basic scenario, payment via the app, loyalty. Then we add functions in stages — each stage ends with a working version that can be given to customers, not “half a screen”.

How is work acceptance performed?

On real scenarios: demonstration on test data, checklist of checks for each scenario, separately — behavior during connection loss and repeated operations. After acceptance we hand over access, documentation and update regulations.

What about support after launch?

We stay in touch according to the regulation: incidents have classes and response times, updates are released for new operating system versions, and changes in loyalty or tariffs are made without rebuilding the entire app.

Let's discuss the task and return with an estimate and work plan

To make the conversation substantive rather than turning into a market overview, it is useful to immediately get a snapshot of your network and current system landscape.

From it we understand where the bottleneck is — in the app, in the cash desk contour or in data exchange between them — and what can actually be taken to pilot.

• Network composition: how many gas stations and modules, cities and regions, formats — classic station, automated, LPG station — and whether expansion is planned.
• Current systems: cash software, fuel card processing, loyalty program, warehouse and accounting, who their vendor is and whether there are open interfaces for exchange.
• Bottlenecks: queues at the cash desk, manual shift reconciliation, repeated data entry, lack of offline mode when connection drops.
• Previous implementation attempts: what was done, at which stage stopped and why — this saves us weeks on the same rake.
• Requirements for roles and access: customer, operator, site manager, head office — who performs which actions.
• Constraints: equipment at sites, offline operation requirements, rules for storage and processing of customer data.

In response we send a stage-by-stage work plan: analytics and prototype of key scenarios, integrations with current systems, pilot at one or two sites, rollout to the entire network, support mode.

For each stage — scope of work, what is needed from your side and a timeline estimate as a range, not a single number: it is visible where the timeline depends on readiness of vendor interfaces.

Describe the task in free form — we will return with an estimate and plan.