Taxi Booking Script Knowledge Base

Taxi Booking Script is self-hosted software for receiving and managing online taxi reservations. Customers can enter a journey, view configured prices and vehicles, choose options and place a booking. Your team manages the operation through the administration area.

It is intended for taxi companies, airport-transfer businesses, chauffeur services and other passenger-transport companies that want an online reservation workflow installed on suitable hosting they control.

The product is marketed as software you run on your own suitable hosting. Your exact licence rights, permitted installations, redistribution restrictions and custom-work ownership should always follow the written sales agreement supplied with your purchase.

No. The advertised €450 software price and €1,000 complete website price are one-time package prices. Optional SSD hosting with the complete website is €114 per year. Your domain, providers and other services can also have recurring costs.

The public website currently describes Taxi Booking Script version 9.5, including newer fare controls, search insights, journey sharing, administration improvements and the customer invoice workflow.

You receive the standalone Taxi Booking Script package for installation on suitable hosting. It includes the booking, fare, fleet, availability, language, payment, administration and invoice capabilities described on the current product pages. A new public taxi website is not included.

The complete package combines Taxi Booking Script with a responsive English taxi website containing up to 10 agreed pages. It includes the booking system and professional page design. More pages are possible after consultation. Use your compatible hosting or add our SSD hosting for €114 per year.

€450 and €1,000 are one-time package prices. Optional SSD hosting is €114 per year. Domain renewal, gateway transactions, email services and other providers can also have recurring costs.

Domain registration, hosting unless the €114/year option is selected, payment-provider charges, extra languages, translations, paid media and third-party subscriptions are separate. Custom layouts, modules, integrations and work outside the written package scope cost €80 per development hour after approval of an estimate.

Choose €450 if you already have a suitable website and can handle its integration. Choose €1,000 if you need the complete responsive taxi website and booking system prepared together. Use the comparison page for a detailed table.

The €450 standalone package requires your compatible hosting. With the €1,000 complete website, you can provide compatible hosting or add our super-fast SSD hosting for €114 per year. Your own domain is still required.

Yes. You provide and retain control of the domain. Its DNS must point to the correct hosting environment when the new booking system or website goes live.

Installation normally requires working file or FTP access, database credentials and appropriate hosting control. A complete website can also require domain, DNS, SSL and email settings. Share credentials only through an agreed secure method.

Yes. A professional live booking site should run over HTTPS. SSL is particularly important for personal information, account logins and connections to online payment providers.

Our €114/year hosting includes daily website and database backups retained for three months. With another provider, confirm its backup and restoration conditions directly.

Unlimited SSD storage and data traffic, SSL, email accounts, daily backups retained for three months and a 99.9% uptime target are included. Your domain remains separate.

Test routes, fares, vehicles, passenger and luggage limits, return trips, payments, emails, calendar messages, administration, language options and invoice behaviour on both desktop and mobile.

The customer enters pickup and destination information, chooses the date and time, adds trip options, reviews the calculated fare and vehicle choices, supplies contact details, selects a payment method and confirms the reservation.

Yes. The public booking form shown in the demo contains an extra-stop option so an additional address can be included in the journey flow.

Yes. The booking journey supports return information. Fare and discount behaviour depends on the rules you configure for your taxi company.

The system can use configured distance, zone, fixed-route, vehicle and surcharge logic. The final result depends on your own fare setup, service area and operational rules.

Yes. Version 9.5 includes weekend, night and transaction surcharge controls described in the product overview. Test every rule with realistic routes and times before publishing it.

Yes. Vehicle categories can have their own presentation, passenger capacity, luggage limits and configured pricing.

Yes. The version 9.5 feature overview includes flight-number information for airport pickups and return journeys.

Yes. The administration functions include recurring closing times, availability rules and related surcharge controls. Your team should keep these settings current.

The system presents Mollie, bank transfer and cash as direct choices. It also supports PayPal, Authorize.Net, PayPal Express Checkout, 2Checkout, Stripe, Skrill and Braintree for companies with the required provider account.

No. Enable and configure only the options that suit your business. Additional online gateways require your own approved provider account, credentials and testing.

No. Account approval, subscriptions, transaction fees, chargebacks, payouts and currency costs are controlled and charged by the payment provider.

No. Cash does not pass through an online gateway, so the system cannot collect an online deposit for a cash payment choice.

Your taxi company manages its own cancellation and refund policy. The connected provider controls its technical refund, chargeback and dispute procedures.

Test successful, cancelled and failed payments; duplicate submissions; customer and company notifications; booking status; invoice behaviour; currency; mobile checkout and the provider return page.

Dutch, English, French, Spanish, Italian (Italy), Portuguese (Portugal), Norwegian, Turkish (Turkey), Polish (Poland) and Romanian (Romania).

Yes. The current ten built-in languages use left-to-right text direction in the system.

No. Booking-interface translations and public marketing pages are separate. Website services, policies and SEO pages must also be written and reviewed for every language you publish.

A language outside the published built-in list is custom work. Confirm the translation, technical scope, price and maintenance responsibility separately in writing.

Check field labels, validation messages, buttons, dates, payment wording, email content, long words, mobile layout and the complete reservation flow.

Yes. The invoice workflow can send a professional customer invoice automatically after booking. Your team can also prepare or resend it later.

The workflow uses booking information such as customer, journey and fare details, keeping the invoice connected to the reservation rather than requiring the team to retype everything.

Yes. This is useful when a reservation needs a manual review before the invoice is sent or when a customer requests it again.

No. The feature supports customer invoices connected to bookings. Your own accounting system, accountant and legal process remain responsible for bookkeeping and tax declarations.

Your taxi company must verify company details, tax information, numbering, currency, retention and all legal invoice requirements for the countries where it operates.

The current Taxi Booking Script includes the invoice workflow. Because the €1,000 package includes Taxi Booking Script, the complete website uses the same invoice capabilities.

Manage bookings, customers, fares, vehicle categories, drivers, cities, postcode areas, extras, availability, high-season rates, searched routes, languages, payments, notifications and invoices. Version 9.5 also includes revenue cards, front-end theme previews, integration code, login protection and captcha/spam settings.

Yes. Version 9.5 includes search history with detailed fare components, including searched routes that did not become confirmed reservations.

Yes. The administration overview includes driver profiles and organisation of ride information by driver.

The product overview includes Google Calendar information for the taxi company. You need your own relevant Google account and must test the final configuration.

Version 9.5 includes optional journey sharing through WhatsApp as described in the product overview. The required phone and communication setup remains your responsibility.

Admin access is protected. Use the Admin Demo page to understand the functions and follow its instructions if protected access is made available.

How it works: the pricing order is postcode first, a matching fixed city-to-city fare second, and the configured kilometre price third. The system uses the first applicable base-pricing rule in that order. Example: if the pickup postcode has a configured price, that rule wins even when the two cities also have a fixed fare. If no postcode or city rule matches, the kilometre calculation is used. Watch out: overlapping postcode records can produce an unexpected result, so test the exact pickup, destination and vehicle after every pricing change.

Location: open the vehicle or car pricing area in the administration panel and use the pencil icon for the relevant vehicle. How it works: select the two cities, enter the fixed route price and save the rule for that vehicle. Example: Sedan, Utrecht to Schiphol, €85. Watch out: create or verify the cities first, use the correct vehicle and test a real address in each city. A matching postcode rule still has higher priority.

Location: check the direction or two-way setting in the city-fare editor reached through the vehicle pencil icon. How it works: when the fare is configured as two-way, the same amount can apply from City A to City B and from City B to City A. Otherwise configure the reverse direction separately. Example: Utrecht–Amsterdam and Amsterdam–Utrecht can both use €75. Watch out: never assume the reverse journey is covered; test both directions because postcode and surcharge rules may still change the total.

Location: use City zip codes and the related fare settings in the administration panel. How it works: a matching postcode rule is checked before the city-to-city rule. Pickup costs and other configured additions can then be included according to their own settings. Example: a special airport postcode can use its postcode fare even though the wider cities have a different fixed price. Watch out: postcode ranges must not overlap accidentally, and a space or formatting difference in a postcode should be tested.

Location: open Fleets and edit the price settings for each vehicle separately. Use the vehicle pencil icon for fixed city routes. How it works: base, kilometre and fixed-route prices can differ by vehicle. Example: Sedan €75, Executive €95 and Minivan €110 for the same city pair. Watch out: passenger and luggage limits determine which vehicles a customer can select, so test both capacity and price.

Location: use the fare details and Search Logs to compare the online calculation with the meter-based price used by the taxi company. How it works: the online fare is built from the winning postcode, city or kilometre rule plus applicable additions. Compare that result with the same route, time and vehicle under your meter tariff. Example: test a weekday route, then repeat it at night with the correct surcharge. Watch out: distance, waiting time, traffic and regulated meter components may differ; the company remains responsible for publishing a lawful and accurate price.

How it works: after the base fare has been selected by the postcode, fixed-city or kilometre rule, applicable pickup, night, weekend, high-season, transaction or other configured surcharges are added on top. Example: an €80 fixed route plus a €10 night surcharge produces €90. Watch out: test each surcharge alone and in combination to prevent duplicate additions or unintended percentages.

Location: go to Settings → Reservations and configure Office Location plus Office Location Free Km. How it works: the office is the operating reference point and the configured radius can be treated as free before an outside-area pickup calculation starts. Example: the first 10 km from the office can be free, with pickup costs applied beyond that distance. Watch out: choose the correct mapped office address and test points just inside and outside the boundary.

Location: use Settings → Reservations → Accept bookings X hours earlier. How it works: enter the minimum notice period before the requested pickup time. Example: a value of 2 prevents a new 14:00 booking after 12:00. Watch out: verify the system time zone, daylight-saving changes and the exact boundary time.

Location: use Settings → Reservations for the deposit and the default paid/unpaid statuses, then configure the selected payment gateway. How it works: the deposit determines what should be collected online, while the payment result controls the initial booking status. Example: a successful deposit can create a confirmed booking while a cancelled payment remains pending. Watch out: cash cannot collect an online deposit, and every success, cancellation and failure return must be tested.

Location: go to Settings → Reservations → Country list. How it works: enter the permitted ISO Alpha-2 country codes separated as required by the field, such as nl, be, de. Leave the restriction off only when worldwide suggestions are intended. Example: use nl, be for Dutch and Belgian addresses. Watch out: use two-letter codes, include the intended neighbouring countries and test addresses near borders.

Location: use Settings → Reservations and the Disable house number or Disable extra stop controls. How it works: enable the disable-control for a field you do not want customers to use. Example: a company serving fixed pickup points may hide separate house-number entry. Watch out: hiding information can make an address incomplete; complete a test booking after every form change.

Location: use Settings → Reservations for Thank you page, Cancel page, search slug and English search-result destination. How it works: enter the correct page or route used after each customer action. Example: successful bookings can return to /booking-confirmed while cancelled payments return to /payment-cancelled. Watch out: use working HTTPS URLs, avoid redirect loops and test success, cancellation and failed payment paths.

Location: use Settings → Reservations → Discount percentage and any separate return-trip rule available in your fare configuration. How it works: the percentage reduces the eligible configured fare according to the active rule. Example: a 10% discount reduces an eligible €100 amount by €10 before or after additions as defined by the configuration. Watch out: verify which components receive the discount and make sure multiple discount rules do not stack unintentionally.

Location: open Settings → Reservations → Color or use the front-end preview theme tools. How it works: configure text, button, border, error, body, title and past-calendar-date colours. Example: match the booking button to the taxi company brand while keeping error text clearly visible. Watch out: maintain readable contrast, check focus and error states, and preview desktop, tablet and mobile.

Location: use Settings → Checkout Form. How it works: each supported field can be set to No, Yes or Yes (required). Example: require first name, last name, phone and email; keep company and notes optional. Watch out: do not request unnecessary personal data and test validation plus mobile keyboard behaviour.

Location: use Settings → Checkout Form for Airline company, Flight number, Arrival time and Terminal/Gate. How it works: make each field optional or required for the booking workflow you offer. Example: airport pickups can require a flight number and arrival time while ordinary city rides leave them hidden. Watch out: requiring airport fields for every booking will block non-airport customers.

Location: go to Settings → Notifications. How it works: configure separate notification content for the client, administrator, driver and Google Calendar workflow using the available booking tokens. Example: the client receives confirmation, the administrator receives operational details and the driver receives journey information. Watch out: preview every recipient template, remove unsupported tokens and never expose internal information to the customer.

Location: use Settings → Reservations for the Google Calendar invite switch, title, phone, email and calendar heading; connect the account under System Options → Connect Google. How it works: enabled booking data is placed in the company calendar event. Example: use a clear event title containing the booking reference and customer contact fields. Watch out: protect personal data, use the correct Google account and test outbound and return calendar entries.

Location: use Settings → Non availability and choose Custom or Recurring. How it works: Custom blocks a specific date range and time; Recurring blocks a repeating schedule. Example: close 25 December once and every Sunday from 02:00 to 05:00 repeatedly. Watch out: verify start/end dates, overnight periods, time zone and whether existing bookings need manual attention.

Location: use Settings → High Season Rate Adjustment and choose the dated or recurring charge tab. How it works: select the period, time and price addition that should apply during busy moments. Example: add €15 on New Year’s Eve or a recurring summer-weekend charge. Watch out: confirm whether the field is a fixed amount or percentage in your configuration and test overlaps with night or weekend surcharges.

Location: use Settings → Invoices. How it works: configure company name, invoice title, owner, address, phone, website, logo, account holder, IBAN, BIC, tax number, VAT ID, tax office and starting invoice number. Example: begin with the next legally valid invoice number and upload a readable company logo. Watch out: only your accountant or adviser can confirm the legal requirements and numbering for your country.

Location: use System Options → Email settings. How it works: select the sending method and enter the SMTP host, port, username, password, security, authentication, sender email and sender name supplied by the mail provider. Example: send a booking test to an external mailbox and confirm that replies reach the correct address. Watch out: never publish the password, use the provider’s correct secure port and verify SPF, DKIM and DMARC where applicable.

Location: use System Options → WhatsApp Settings. How it works: configure the Twilio account SID, authentication token, sender number, admin WhatsApp number, enabled status and separate content SIDs for normal and return journeys. Example: use one approved template for a one-way confirmation and another for a return booking. Watch out: WhatsApp/Twilio accounts, template approval and provider charges are separate; keep tokens private and test every active language.

Location: use System Options → Languages and the Languages, Labels and Import/export tabs. How it works: manage active languages, edit interface labels and transfer supported translation files. Example: export a language, review all customer-facing strings and import the completed version. Watch out: keep a backup, preserve identifiers, use the correct text direction and test buttons, validation, emails and mobile layout.

Location: use System Options → Login and protection. How it works: configure minimum password length, allowed characters, special symbols, uppercase requirements, password expiry, one active login, CAPTCHA, failed-login locking and account-owner notifications. Example: require a strong password and temporarily lock an account after repeated failures. Watch out: keep recovery email access working, avoid locking out every administrator and test the forgotten-password process.

Location: use System Options → Captcha and spam. How it works: choose system or Google CAPTCHA separately for customer and administrator forms, configure its mode and length or site keys, and add forbidden IP addresses where necessary. Example: use Google reCAPTCHA on the booking form and a separate backend CAPTCHA after failed logins. Watch out: wrong site keys can block valid customers; test logged-out admin and customer flows before going live.

Location: use Install in the administration panel. How it works: the Standard Code places the full booking journey on a page, while the Compact form is suited to a smaller homepage or call-to-action area. You can also select the starting language and hide its selector. Example: use the compact form on the homepage and the standard form on a dedicated booking page. Watch out: install each code only once per position, preserve required scripts and test cross-domain, desktop and mobile behaviour.

The package combines up to 10 agreed responsive English website pages with Taxi Booking Script, including the booking, language, payment, administration and invoice capabilities described on the product pages. More pages are possible after consultation. Optional SSD hosting costs €114 per year.

Yes. The package is designed for desktop, tablet and mobile layouts, with booking access, navigation and content adapted for smaller screens.

The website can include SEO-ready structure, unique titles, descriptions, headings, internal links, crawlable content and structured data. Rankings and AI citations cannot be guaranteed and still depend on authority, competition, content quality and time.

You should provide accurate company details, services, policies, fleet information and licensed images. Any additional writing, translation, photography or paid assets outside the agreed scope are separate.

The final direction should follow your supplied branding and the written design scope. Use the Taxi Website Examples page for illustrative airport, business and local taxi structures.

Your company is responsible for correct privacy, terms, cancellation, cookie and other legal content. Page implementation can be agreed, but the legal accuracy must be reviewed by a qualified adviser for your business.

Read the relevant knowledge-base category, repeat the exact steps, record the expected and actual result, capture the error and booking reference, and check whether hosting or a third-party provider is unavailable.

Include the page, time, booking reference, exact steps, expected result, actual result, screenshot and recent changes. Never send passwords in an ordinary public message.

The hosting company or selected provider controls its own infrastructure, account approval and outages. Taxi Booking Script support cannot restore an external service that is unavailable.

Yes. Modified templates, custom code and external plugins can require a compatibility review. Back up the complete files and database before any update.

Yes. Rotate temporary credentials after handover, use unique strong passwords, limit administrator access and enable any security controls offered by your hosting and provider accounts.

Contact support after the knowledge-base steps do not solve a reproducible issue with the supplied product or when you need a written quote for additional work outside the standard scope.