Taxi Booking Form for WordPress

A taxi booking form for WordPress is the frontend interface that customers use to request a ride on a WordPress website. It collects pickup and dropoff addresses, date and time, vehicle preference, passenger count, luggage count, and contact details, then sends the booking through the taxi booking plugin for WordPress‘s REST API to the WordPress backend for fare calculation and checkout. It’s the single piece of the taxi booking system the customer ever sees, and the only piece that directly determines whether a visitor becomes a paying booking.

This page explains how the form should be structured, what components belong in it, why multi-step layout outperforms single-page forms on mobile, how Google Places autocomplete and native HTML5 pickers work, what multi-form configuration enables, and how the form communicates with the WordPress backend through the REST API.

What is a taxi booking form for WordPress?

A taxi booking form for WordPress is the frontend interface that customers use to request a ride on a WordPress website. The form collects pickup and dropoff addresses, date and time, vehicle preference, passenger count, luggage count, and contact details, then sends the booking through the taxi plugin’s REST API to the WordPress backend for fare calculation and checkout.

The form is the single piece of the taxi booking system the customer ever sees. Everything else, the calendar, the driver dashboard, the invoice templates. Exists for the operator. If it is slow, confusing, or visually broken, customers leave before completing a booking. Every other feature of the plugin is wasted if the form doesn’t work well.

A well-designed taxi booking form is multi-step, mobile-first, and built with Google Places Autocomplete on the address fields, a live route map between pickup and dropoff, native mobile date and time pickers, and a vehicle selection grid that shows real-time prices per vehicle. It’s rendered through a WordPress shortcode and styled with CSS custom properties so the design integrates with any theme.

How does a WordPress taxi booking form work?

The booking form runs through three customer-facing steps and four backend operations.

Between each step the form validates inputs, fetches data from REST endpoints, and persists state in local React-style component state. A first-time customer completes the entire form in 60 to 90 seconds on mobile. Returning customers, if the plugin remembers them through WooCommerce, complete it in under 45 seconds.

What components make up a complete taxi booking form?

A production-grade taxi booking form has nine essential components. The form is one of seven layers in a complete WordPress taxi booking system — the customer-facing layer that determines whether visitors become bookings.

Why should the booking form be multi-step?

A multi-step form splits a long input set into focused, digestible screens. The customer sees three or four fields per screen instead of fifteen at once. This produces higher completion rates on mobile, where a screen full of inputs feels overwhelming and bookings are abandoned.

The trade-off is that multi-step forms can hide errors until later steps. Good plugins validate each step before allowing progression and show clear error messages inline. A bad multi-step form lets the customer fill three steps before discovering the date they chose is in the past.

The recommended structure for a taxi booking form:

• Step 1: Trip details, pickup, dropoff, date, time, passengers, luggage
• Step 2: Vehicle selection, fare grid, customer picks one
• Step 3: Summary and confirm, review, submit, redirect to checkout

The customer’s contact details (name, email, phone) are collected on the WooCommerce checkout page, not inside the booking form. This separation keeps the form short and uses WooCommerce’s existing validation, country handling, and saved-customer features.

How does Google Places autocomplete work in the form?

Google Places Autocomplete is a service from Google Maps that suggests real addresses and business names as the customer types. The integration is a small JavaScript snippet attached to each address input field.

When the customer types “lon”, Places returns matches like London Heathrow Airport, London Bridge, London King’s Cross, and London Victoria. They selects one with a tap or arrow key. The field is filled with the formatted address and the latitude and longitude coordinates are stored as hidden values.

Configuration options

A good booking form lets the admin restrict autocomplete results:

• Country restriction: only show results from one or more specified countries
• Location bias: prefer results near a configured city or coordinate
• Type filter: only show street addresses, or only show establishments (hotels, airports, train stations)

For a UK taxi business, restricting autocomplete to gb prevents a customer from accidentally selecting “London, Ontario” when they meant the one in England, a real source of booking errors in cross-Atlantic markets.

Why does the form need native mobile date and time pickers?

Native HTML5 < input type="date"> and < input type="time"> trigger the operating system’s own date and time picker on mobile devices. On iOS this is the rolling wheel picker iOS users know. On Android it’s the Material Design picker. Both are accessible, fast, and familiar.

The alternative, JavaScript date pickers built with libraries like flatpickr, jQuery UI Datepicker, or custom React components. Looks visually consistent across browsers but performs worse on mobile. The custom picker is smaller, slower, requires extra taps, and breaks accessibility for screen reader users.

Over 60 percent of taxi bookings come from mobile devices. Forcing a custom date picker on those users costs bookings. The right choice is the native picker, styled to match the rest of the form through CSS variables.

Can I have multiple taxi booking forms on one WordPress site?

Yes, on plugins that support multi-form configurations. A site can have several independent booking forms, each with its own settings, on different pages.

Each form is referenced by ID in the shortcode: [ridecab_form id="1"], [ridecab_form id="2"], [ridecab_form id="3"]. The admin creates each form in the plugin’s Forms screen and configures its colours, enabled features, time interval, default map location, and which vehicles to display.

This separation lets the business build a dedicated landing page per service, one for general taxi service, one for airport transfers, one for chauffeur hire, without writing custom code. Each landing page gets its own SEO-optimised content and its own narrowly-focused booking form.

How is the booking form added to a WordPress page?

The booking form is embedded through a WordPress shortcode. A shortcode is a small placeholder, written in square brackets, that WordPress replaces with the plugin’s output when the page is rendered.

The standard pattern:

1. Create a new WordPress page (Pages → Add New)
2. Set the page title to something descriptive (“Book a Taxi”, “Online Booking”, “Reserve Your Ride”)
3. Add a Custom HTML block (Gutenberg) or shortcode block
4. Paste the shortcode: [ridecab_form id="1"] — replacing 1 with the actual form ID
5. Publish the page

The form renders inline at the position of the shortcode. The rest of the page, heading, intro paragraph, surrounding content. Is normal WordPress content and works with any theme or page builder.

Page builders

Modern page builders (Elementor, Bricks, Oxygen, Beaver Builder, Divi) provide a shortcode widget. Drop the widget on the canvas, paste the shortcode, and the booking form renders inside the builder layout. No code changes needed.

Can the booking form design be customized?

Yes. Customization happens at three levels.

Level 1 — Admin colours

The plugin’s form settings include primary and secondary colour pickers. The admin selects a brand colour, it generates a darker shade automatically for hover and active states, and the entire form recoloured immediately. This level requires no code.

Level 2 — Field visibility toggles

Each form has toggles for individual fields, waypoints, return trip, passenger input, luggage input, special requests textarea, waiting time. The admin enables or disables each per form.

Level 3 — CSS variables

The form’s stylesheet uses CSS custom properties throughout. A theme developer can override the visual design in roughly 20 lines of CSS by setting the relevant variables in the theme’s stylesheet:

• --rc-primary, primary brand colour
• --rc-secondary, secondary brand colour
• --rc-bg — form background
• --rc-text, body text colour
• --rc-border-radius, corner roundness on inputs and buttons
• --rc-font-family. Font stack
• --rc-spacing, base spacing unit

This is the cleanest way to align the form’s design with the rest of the site without modifying plugin files. Customizations survive plugin updates because they live in the theme’s stylesheet, not in the plugin folder.

What is instant booking mode?

Instant booking, also called “now booking” or “ASAP booking”, is a mode where the customer requests a ride for the current moment rather than scheduling for a future time.

When instant booking is enabled, the form shows a “Book now” toggle. When activated, the date and time fields are hidden and the booking is assigned a pickup time of “as soon as possible”. On the operator’s side, instant bookings appear at the top of the admin queue with a visual indicator so they get prioritised over scheduled rides.

Instant booking is a useful feature for businesses that handle both pre-booked and short-notice rides. A taxi service that takes airport transfers (scheduled) and city centre pickups (often immediate) benefits from a single form that handles both modes through one toggle.

Instant booking is not the same as real-time ride-hailing. A WordPress plugin handling instant bookings still requires the business to assign a driver manually and respond promptly, it does not auto-dispatch the nearest driver with live GPS tracking. For that level of automation, a SaaS dispatch platform is required.

How does the form communicate with the WordPress backend?

The booking form communicates with the WordPress backend through the WordPress REST API. The form is a JavaScript application that runs in the browser and makes HTTP requests to plugin-specific REST endpoints to fetch fare quotes, validate availability, and submit bookings.

Typical endpoint structure for RideCab:

• GET /wp-json/ridecab/v1/forms/{id}, form configuration (colours, enabled fields, vehicles)
• POST /wp-json/ridecab/v1/fare/estimate, fare quote for current trip details
• POST /wp-json/ridecab/v1/cart/add, submit booking to WooCommerce cart

Every request includes the WordPress REST API nonce for CSRF protection. Server-side, every endpoint validates inputs, sanitises strings, and recalculates fares from scratch to prevent client manipulation. The fare value the form displays is for the customer’s eyes only, the server’s recalculated value is what gets charged. For the operator’s view of how bookings flow into dispatch and invoicing, see our online taxi reservation system on WordPress guide.

Frequently asked questions