From Website Form to Driver's Phone: How a Taxi Booking Form and a Dispatch Board Fit Together

BookTaxiService is booking and dispatch software for small Australian taxi operators. This post follows one booking from the form on an operator's website to the driver's phone, and explains the design choices along the way, including the ones with obvious costs.

Here is the whole path:

Customer browser
| embed snippet, iframe, or hosted link
v
Booking page
| one-time code by email or SMS (10 min, 5 tries)
v
Pricing
|-- fare resolves + plan allows -> instant price
|-- otherwise -> quote request
v
Operator workflow (a booking record with state, not an email)
|-- Stripe on the operator's own account
| charge at booking (default) | authorise now, capture later
v
Dispatch board
|-- manual (every plan)
|-- offer / automatic (Growth)
v
Driver web portal (polls every 15 s while open, optional chime)
|
v
driver on way -> arrived -> passenger on board -> completed

Getting the form onto someone else's website

Small operators run their sites on everything from WordPress to a page their nephew built years ago. So there are three ways in, all pointing at the same booking page.

Embed snippet

The operator copies a widget snippet from their settings and pastes it into a page. The booking page loads inside their site, so the customer never leaves it. WordPress needs no plugin for this; it is a paste into a page like anywhere else.

Direct iframe

For site builders that only accept an iframe, there is a direct iframe snippet. It is the most portable option, at the usual cost of iframes: the form lives in its own box, and the host page has limited say over it. Premium Taxi Service, an Australian operator, embeds its form this way.

Hosted link

A branded booking page with its own address. No website needed. It goes in a Google Business Profile, a text to a regular, an email signature or a QR code. Operators can run the hosted link and an embed side by side from one account.

Checking who is booking

A public form accepts any name and any phone number. A fake booking costs a driver a wasted trip, so the form asks for a one-time code, sent by email or SMS, and checks it before accepting a direct booking.

The rules are tight on purpose. Each code expires after 10 minutes and allows five tries. Resending needs the same email or phone, waits out a cooldown and runs into request limits. SMS code attempts have their own budgets per phone number and per IP address, because every code text costs the operator money and is an easy target for someone trying to run up a bill.

Quote or instant price

Starter accounts get a quote-only public form out of the box. Growth accounts can show an instant price when the widget's direct-booking setting is on, quote-only mode is off and the pricing rules can resolve the journey.

The last condition matters most. A fare engine has to be allowed to say "I can't price this". When the operator's rates do not cover a journey, it becomes a quote request, the operator prices it, and the customer accepts the quote online.

A workflow, not an inbox

An enquiry form that emails the office creates a message, not a booking. Someone re-types it, and the typos happen there.

Here the request lands in the operator's workflow as a record with a status. That record is what the payment, dispatch and trip steps hang off. Phone bookings go into the same place, so the office works from one list.

Payments on the operator's own Stripe account

Card payments go through Stripe using the operator's own keys, straight into the operator's account. BookTaxiService does not collect fares and pass them on later.

The default is to charge the card when the customer books. Operators who prefer a hold can use authorise-then-capture instead, with capture at one of three points they choose: on confirmation, on completion, or a set number of days before pickup, subject to checks. The authorisation window is 48 hours by default.

That means payment state is not a boolean. A booking can be authorised but not captured, captured, partly refunded, or waiting on an extra charge sent as a payment link. Refunds, full or partial, are a staff decision, not automatic. On the webhook side, each event's signing secret is checked, duplicates are ignored and failed events are retried, because Stripe can send the same event twice or late.

The dispatch board

Confirmed bookings show up on the dispatch board. Manual dispatch, where staff pick the driver, is on every plan. Offer and automatic dispatch start on Growth, and Scale adds tiered dispatch.

Automatic dispatch applies the operator's availability rules at pickup time and ranks eligible drivers by their recorded coordinates, using straight-line distance rather than the fastest route. For ASAP jobs, it only offers to, or auto-assigns, drivers who are online.

Straight-line distance is a trade-off. It is cheap to compute for every candidate on every job, and it needs no routing call per driver. The cost is that it can be wrong: a driver across a river or on the far side of a freeway can look closer than they are by road. Keeping manual dispatch on every plan means a dispatcher who knows the area can always override the ranking.

The driver portal, and why it polls

There is no store driver app. Drivers use a web portal in their phone's browser. The offers page refreshes every 15 seconds while it is open and can play a chime when a new offer arrives. The portal does not send background push alerts.

Polling is the plain choice. It works in any phone browser with nothing to install, and the server load is easy to predict. The cost is just as plain: the page has to be open. For drivers who need to hear about jobs with the phone in their pocket, offer texts can be switched on. They start switched off, as do customer texts and driver assignment texts.

Trip statuses

Once a driver has the job, they move it through driver on way, arrival, passenger on board and completion from the active-job page.

What a weekend build leaves out

The form is the easy part. Identity codes, payment state, webhooks, dispatch rules and a driver view are where the work is, and all of it has to keep running at night. There is a longer list of what a taxi booking system has to handle after launch for anyone scoping a build of their own.