The answer most teams reach for is the Google Maps Distance Matrix API. It takes one or more origins and destinations and returns the actual driving distance and duration between them, accounting for real roads rather than straight-line distance. Here's a practical walkthrough of how to wire it into a simple pricing function.

Why Not Just Use Straight-Line Distance

A quick haversine formula will give you the distance "as the crow flies" between two coordinates, but that's a poor proxy for actual travel cost. A route that crosses a bridge, a checkpoint, or takes a highway detour can be 20-40% longer than the straight-line distance. For any pricing model that needs to be defensible to a customer, you want the real driving distance.

Setting Up the Request

You call the API with your origin and destination as lat/lng pairs or place names, plus your API key:

async function getDistanceKm(origin, destination, apiKey) {
  const url = `https://maps.googleapis.com/maps/api/distancematrix/json?origins=${encodeURIComponent(origin)}&destinations=${encodeURIComponent(destination)}&key=${apiKey}`;

  const response = await fetch(url);
  const data = await response.json();

  const element = data.rows[0].elements[0];
  if (element.status !== "OK") {
    throw new Error("Could not calculate distance for this route");
  }

  return element.distance.value / 1000; // meters to km
}

Turning Distance into a Price

Once you have the distance, the pricing function itself is simple: a base fare plus a per-kilometer rate, with a floor so short trips don't get priced unrealistically low.

function calculatePrice(distanceKm, baseFare = 50, perKmRate = 2.2, minimumFare = 150) {
  const price = baseFare + distanceKm * perKmRate;
  return Math.max(price, minimumFare);
}

Caching and Cost Control

The Distance Matrix API is billed per element (each origin-destination pair), so for a route-based business you don't want to call it on every page load. A simple pattern that works well:

1. Pre-calculate and cache the distance for your known fixed routes (city pairs you serve regularly)
2. Only hit the live API for one-off or custom pickup/drop-off combinations
3. Store the cached distance alongside a "last updated" timestamp and refresh it periodically, since road networks and route recommendations do change

Handling Edge Cases

A few things worth handling before this goes into production:

• Multiple route options: the API can return alternate routes; decide upfront whether you price on the fastest route or the shortest
• International/cross-border routes: tolls, border crossings, and checkpoint delays affect real-world pricing but aren't captured in raw distance, so you may need a manual multiplier for specific routes
• API failures: always have a fallback (a cached average rate for the route) rather than blocking checkout if the API call fails

Seeing It in Context

I ended up testing this exact approach while looking at how transfer pricing is presented for real intercity routes. This page on car lift dubai to abu dhabi pricing is a good real-world reference for how a distance-based fare should be communicated to a customer: clear base pricing, and enough transparency that the number doesn't feel arbitrary. That transparency only works if the underlying distance calculation is accurate in the first place, which is exactly what this API gives you.

Wrapping Up

For any developer building a booking, delivery, or transfer product, the Distance Matrix API removes the need to manually maintain a lookup table of routes and prices. Combine it with a caching layer and a sane fallback, and you get pricing that scales to any new route without a manual pricing update every time.