A customer enters a pickup address, chooses a destination and gets a price. That looks simple on a transport website. Behind the form, though, several decisions matter: which requests run in the browser, how distance becomes a charge, and what happens when a route cannot be calculated.
If you are planning a delivery, towing or vehicle transport quote form, start with those decisions before polishing the map. A useful form should give customers a clear estimate and give the business enough information to check it.
Give the browser and server different jobs
Let the browser handle address selection and display the result. Let your backend validate the request, obtain the route and apply your pricing rules. In WordPress, that might be a custom plugin endpoint. In Laravel or a custom web application, it might be a dedicated controller and pricing service.
The customer should send the selected locations and service type. They should not be able to set the final amount by changing a hidden form field. Recalculate the price on the server before saving an accepted quote or creating a payment request.
For example, a visitor could change a displayed distance from 180 kilometres to 18 in their browser. If the backend trusts that value, the resulting order could be priced incorrectly. The page can show an estimate, but the server needs to decide what amount is valid.
Use API key restrictions that match the request
For a browser map, follow the Maps JavaScript API setup guide. A key used by browser JavaScript is observable in the browser; putting it in a frontend environment variable does not make it a server secret.
Use a separate key for backend web-service calls. Restrict the browser key to approved websites and required APIs. For a server key, use the supported server restriction, such as the public outbound IP address, and allow only the APIs it needs. Google explains these choices in its Maps Platform security guidance.
Check your hosting setup before choosing an IP restriction: a serverless application's outbound address may not be fixed. Also avoid relying on a full website path as a referrer restriction, because browsers can omit the path on cross-origin requests.
When changing an existing integration, inspect key usage first and test the replacement before removing the old key. Otherwise, a security improvement can accidentally interrupt a working form.
Treat address selection as part of the quote
A typed address is not always a selected location. Someone may choose a suggestion and then edit the text. Clear the stored selection when that happens, and ask them to select a location again before calculating.
Check service coverage on the backend too. A form that serves one country should reject an unsupported destination even if someone bypasses the browser controls. Explain the problem beside the relevant field instead of silently changing the address.
If you implement Autocomplete (New), follow Google's session pricing documentation. A session token groups a search interaction through its terminating Place Details or Address Validation request. Use a new token for a new interaction; do not reuse one indefinitely. Abandoned sessions and different terminating requests have different billing behaviour, so a token does not make every search free.
Request the route information you actually need
A basic distance quote may need only distance and duration. For a REST Compute Routes request, an example response header is X-Goog-FieldMask: routes.distanceMeters,routes.duration. Add a route polyline only if the interface needs to draw it.
Google's Routes API field-mask guide says a field mask is required. It also advises against requesting every field with a wildcard in production. Keep the response specific so the application does not depend on data it never uses.
Choose route options deliberately. A distance-based estimate and an arrival-time estimate have different needs. According to the Routes API usage and billing guide, request features affect the billed SKU; traffic-aware routing is one example. Check the current documentation before enabling extra features.
Photorealistic AI-generated editorial image of a laptop and notebook at a parcel dispatch counter. The indistinct screen is conceptual and is not a screenshot of a client application.
Conceptual editorial image generated with AI; not a screenshot of a client application.
Write down the pricing rules before coding
Consider an illustrative service with a €40 base fee and a €1.20 charge per kilometre. A route of 125,000 metres becomes 125 kilometres, so the calculation is €40 + (125 × €1.20) = €190. These are example rates, not a recommended tariff.
Now settle the questions that the formula leaves open. Is there a minimum charge? Does the business charge for a return journey? Are tolls included? Does the displayed amount include tax? Should a cross-border journey require manual approval?
Keep the rounding rule explicit. If a route is 12.4 kilometres, charging for 12.4 and rounding up to 13 are different policies. Use one policy consistently in the on-screen breakdown, saved record and customer email. Use an appropriate decimal or minor-unit money representation to avoid accidental floating-point rounding errors.
For an estimate that needs approval, save the selected service, calculation inputs and pricing-rule version in your own quote record. Review the applicable Maps data storage terms before deciding which provider response fields to retain. Label the amount as an estimate and state what the business still needs to confirm.
Handle failures without inventing a price
A timeout, unavailable route or exhausted quota should never turn into a zero-price booking. Offer a manual quote request instead, preserve the customer's entered information where practical, and explain that an automatic estimate is unavailable.
Prevent repeated clicks from starting several calculations. If the visitor changes the destination while a request is running, ignore an older response that arrives later. Otherwise, the form can show the right address with a price for the previous journey.
Rate-limit the public backend endpoint and validate its inputs before calling a paid service. Moving a key to the server protects the key itself, but an unrestricted public proxy can still be abused.
A short checklist before launch
- Test supported and unsupported destinations, edited addresses and missing selections.
- Check a short trip, a long trip and a journey that requires manual approval.
- Change the displayed price in the browser and confirm the backend rejects it or recalculates.
- Simulate a route failure and confirm no order is saved with an accidental zero amount.
- Submit twice and change an address mid-request to check duplicate and stale results.
- Review API usage and quota settings, and test the fallback customers see when limits are reached.
Google notes that quota limits can stop requests from being served. Choose limits with that interruption in mind and monitor usage after launch. A technically correct form still needs an operational plan for busy periods and failures.
Putting it into a real website
For related portfolio work, see my Snowbirdship multistep quotation and order plugin, which covers a WordPress shipping quote workflow with Google Maps and API integrations. The examples in this article are general design guidance, not a description of that project's private configuration.
If you need a quote form for your own service, I can help turn the pricing rules into a WordPress plugin or custom application. A useful starting brief is a list of supported journeys, charge rules and situations that need a human review.
Technical references checked on 25 October 2026. API features, billing rules and regional availability can change; use the linked Google documentation when implementing.
