Maps and geocoding: the agent answers

I’d start with **Google Maps Platform**, using:

- Places Autocomplete for address entry
- Address Validation where supported
- Geocoding API as the broader fallback
- Maps JavaScript API in React
- Your own point-in-polygon check for delivery zones

The main reason is the messy-address problem: Google can correct, complete, standardize, and geocode an address, instead of merely returning the closest textual match. Its Address Validation coverage includes most major European markets, though not every European country, so verify your actual country list. [Coverage details](https://developers.google.com/maps/documentation/address-validation/coverage), [Address Validation overview](https://developers.google.com/maps/documentation/address-validation/overview).

What I would weigh before committing:

1. **Accuracy on your real addresses.** Build a test set of roughly 200–500 successful, failed, multilingual, abbreviated, and typo-filled addresses. Compare rooftop/building-level accuracy, wrong-city matches, and addresses requiring manual correction. Provider benchmarks matter more than generic coverage claims.

2. **Countries served.** Google Address Validation has gaps in Europe. In unsupported countries, ordinary geocoding still works, but you lose the stronger validation verdict. If those countries are important, test HERE and a local postal-data provider alongside Google.

3. **Can coordinates be retained?** You will presumably store coordinates with each delivery address. Review the provider’s current caching, display, and derivative-data terms carefully. Google also requires Address Validation results displayed on a map to use a Google map. [Google policy](https://developers.google.com/maps/documentation/address-validation/policies). Mapbox distinguishes temporary from permanent geocoding and restricts its results to Mapbox maps. [Mapbox Geocoding documentation](https://docs.mapbox.com/api/search/geocoding/).

4. **Cost per completed address, not per API call.** As of August 2026, Google includes 10,000 monthly Geocoding events and 10,000 Dynamic Map loads, while Address Validation Pro includes 5,000; beyond that, the first-tier prices are respectively $5, $7, and $17 per 1,000. Your modest traffic may remain inside those caps. [Current pricing](https://developers.google.com/maps/billing-and-pricing/pricing).

5. **Privacy and EEA terms.** Delivery addresses are personal data. Geocode server-side, minimize logs, set retention rules, restrict API keys, and review Google’s EEA-specific terms and your DPA before sending production addresses.

For the delivery zone, I would **not buy a provider-specific geofencing product**. Store the zone as GeoJSON or a PostGIS polygon and test the saved coordinate with:

- `ST_Covers(zone, point)` in PostGIS—my preference for authoritative server-side checks; or
- Turf’s `booleanPointInPolygon` for a small client-side preview.

Use `ST_Covers` rather than `ST_Contains` if an address exactly on the boundary should count as inside.

A sensible workflow is:

`autocomplete → user selects/confirms → server validates/geocodes → reject or flag low-confidence results → user adjusts pin if needed → save normalized address + coordinates + precision metadata → check zone`

I would shortlist **HERE** as the strongest alternative when European coverage, vendor geography, or Google’s contractual restrictions dominate. I’d consider **Mapbox** when map styling and frontend experience matter most. I would not use the public OpenStreetMap Nominatim service directly for production delivery-address ingestion; a managed OSM-based service can be economical, but only after it wins your address benchmark.

I’d start with **HERE Geocoding & Search**, then validate it against your real addresses before committing.

HERE fits this use case particularly well because it handles incomplete or partly incorrect addresses, returns structured address components and match scores, and distinguishes exact point addresses from interpolated house numbers. It also returns both a display position and an access/entrance point—the latter can matter considerably for delivery operations. [HERE geocoding documentation](https://docs.here.com/geocoding-and-search/docs/geocode), [address-result details](https://docs.here.com/geocoding-and-search/docs/result-types-address)

### What I would weigh first

1. **Actual match quality, not advertised coverage**

   Run a bake-off using 200–500 representative addresses across your countries, including:

   - misspellings and missing accents;
   - swapped postal code/city fields;
   - apartment and building suffixes;
   - villages sharing street names;
   - Polish-style `12A/4`, German `12a`, French locality details, etc.

   Score providers on correct building, correct street, false-confidence rate, and usable entrance point. HERE would be my starting favorite, but this test should be allowed to overturn that choice.

2. **Collection versus cleanup**

   For new addresses, use autocomplete or structured fields so errors are corrected while the customer is present. For existing free-form addresses, geocode server-side and send uncertain results to review. Never silently accept a street- or postcode-level result as a deliverable building.

3. **Storage and licensing**

   You presumably need coordinates to remain attached to an order and later perform zone checks. Confirm that your chosen HERE contract explicitly permits that storage and downstream use.

   This is one reason I would not automatically select Google: Google generally restricts storage of geocoding content, although place IDs may be stored indefinitely, and its geocoding results have map-display conditions. [Google Geocoding policies](https://developers.google.com/maps/documentation/geocoding/policies)

   Mapbox has explicit temporary and permanent geocoding modes, making it another strong candidate if its licensing and permanent-result pricing suit you. [Mapbox Geocoding API](https://docs.mapbox.com/api/search/geocoding/)

4. **Privacy and operational terms**

   Delivery addresses are personal data. Review:

   - DPA and subprocessor terms;
   - processing location and retention;
   - whether requests may be used to improve the provider’s products;
   - deletion handling;
   - service availability and support.

5. **Map UI**

   Don’t let the React component decide the geocoder. HERE has a JavaScript map SDK, but MapLibre or Mapbox GL may offer a nicer developer experience depending on your team. If licensing permits, the geocoder, map renderer, and spatial database need not be the same product.

### Suggested design

Store:

- the original customer-entered address;
- normalized structured fields;
- latitude and longitude;
- provider result ID;
- result level (`houseNumber`, `street`, etc.);
- point type (`PA` versus interpolated);
- match score;
- display point and, where available, delivery access point;
- provider and geocoding timestamp.

Allow the customer or an operator to move the pin when confidence is insufficient.

For the later delivery-zone check, keep your zone as GeoJSON or, preferably, a PostGIS polygon and run `ST_Covers(zone, point)`. `ST_Covers` includes points exactly on the boundary, whereas `ST_Contains` does not. Do this in your own backend rather than calling the geocoder again.

My shortlist would therefore be:

- **HERE:** first choice for this delivery-oriented European use case.
- **Google:** include in the quality benchmark; likely excellent matching, but examine storage and ecosystem restrictions carefully.
- **Mapbox:** strongest alternative for React/map ergonomics and clearer permanent-geocoding mode.
- **Loqate or another postal-validation specialist:** consider if “can mail be delivered to this address?” matters more than simply finding coordinates.

At modest traffic, the decisive factors are likely false-positive rate, storage rights, and handling of local address formats—not the per-request price.

I’d start with **HERE Geocoding & Search**, then validate it against Google using a sample of your actual addresses.

Why HERE:

- It is well suited to European addressing, including localized names, incomplete or partly incorrect input, and structured/unstructured queries.
- Results expose match scores, address components, result precision, and often separate `position` and road-access coordinates—useful for deliveries. [HERE geocoding documentation](https://docs.here.com/geocoding-and-search/reference/get_geocode)
- Country, bounding-box, and language constraints help enormously with messy input. [HERE search constraints](https://docs.here.com/geocoding-and-search/docs/discover)
- Its modest-traffic tier is likely sufficient initially; the limited plan currently allows 1,000 requests/day at up to 5 geocoding requests/second. [HERE limits](https://www.here.com/get-started/pricing/rps-limits-excluded-use-cases)

Before committing, I would weigh these issues first:

1. **Persistent-use rights.** You need to store coordinates for later zone checks. Confirm this explicitly in the commercial terms. Google generally restricts caching geocoding content and requires mapped results to appear on Google Maps, while allowing place IDs to be retained. [Google policies](https://developers.google.com/maps/documentation/geocoding/policies) Mapbox makes storage explicit through its more expensive `permanent=true` mode, but requires its geocoding results to be used with a Mapbox map. [Mapbox geocoding](https://docs.mapbox.com/api/search/geocoding/)

2. **Accuracy on your addresses, not generic coverage.** Run 300–1,000 historical addresses through HERE, Google, and Mapbox. Score:

   - correct building/entrance
   - wrong-but-plausible matches
   - house-number versus street/postcode centroid
   - handling of accents, abbreviations, reordered fields, and missing postal codes
   - confidence signals that reliably identify manual-review cases

   A silent wrong building is much worse than “no confident match.”

3. **Data protection.** Treat delivery addresses as personal data: call the geocoder from your backend, avoid customer names/instructions in queries, sign the provider’s DPA, document international transfers and retention, and keep API keys out of React.

4. **Workflow design.** Preserve the original address, normalized address, coordinates, precision/result type, provider, provider ID, confidence, and geocoded timestamp. Ask users to confirm or move a pin when confidence is low.

5. **Zone checking.** Do this independently of the visual map. Store delivery zones as GeoJSON/PostGIS polygons and run `ST_Covers` or `ST_Contains` on the backend. The React map should display the result, not decide eligibility. This prevents client tampering and lets you change map vendors later.

I would not use the public OpenStreetMap Nominatim endpoint for production: it caps usage at one request per second, disallows autocomplete, warns commercial applications about availability, and asks users not to submit personal or confidential data. [Nominatim policy](https://operations.osmfoundation.org/policies/nominatim/)

So the practical choice is: **HERE first, PostGIS for authoritative zone checks, and a real-address bakeoff before signing a long-term contract**. If HERE’s persistence terms are unsuitable, Mapbox permanent geocoding would be my next choice; if the benchmark shows materially better match quality and vendor lock-in is acceptable, use Google end-to-end.

I’d start with **Mapbox**, using its Search/Geocoding APIs plus Mapbox GL JS in React.

Why it fits:

- Good multilingual European address coverage and typo-tolerant interactive search.
- Official React search components and a mature web-map SDK.
- Crucially, Mapbox offers a **Permanent Geocoding** mode whose results may be stored indefinitely. Temporary/Search Box results generally may not be retained, so licensing affects the design. [Mapbox geocoding documentation](https://docs.mapbox.com/api/search/geocoding/)
- Delivery zones can be displayed as GeoJSON polygons; containment checks do not require a paid provider call.

I would implement autocomplete for data entry, then server-side permanently geocode the confirmed address and store:

- Original and normalized address
- Longitude/latitude
- Match precision and confidence metadata
- Provider and geocoding date
- Whether the customer manually adjusted the pin

For zone membership, use PostGIS `ST_Covers(zone, point)` if you have PostgreSQL/PostGIS. That gives one authoritative server-side answer and includes points lying exactly on the boundary. Turf’s `booleanPointInPolygon` is suitable for an immediate UI preview, but I would not make the browser’s result authoritative.

What I’d weigh before committing:

1. **Real-address accuracy.** Run a bake-off using 200–500 representative failed, incomplete, accented, transliterated, apartment-level, and rural addresses from your actual countries. Compare Mapbox, Google, and HERE. Provider reputation is less useful than country-specific results.
2. **Storage rights.** You need coordinates later, so a cheap temporary-geocoding price is misleading. Mapbox explicitly separates temporary and permanent results; permanent geocoding currently starts at a materially higher per-request price. [Mapbox pricing](https://www.mapbox.com/pricing)
3. **Input workflow.** Autocomplete during collection will improve quality more than trying to repair arbitrary free text afterward. Preserve manual entry and pin correction for legitimate addresses the provider cannot resolve.
4. **Coverage by country.** Postal systems vary sharply across Europe. Test house-number interpolation, postal codes, diacritics, new developments, rural properties, and country-language variants separately.
5. **Confidence handling.** Automatically accept rooftop/address-level matches; send street-, postcode-, or locality-level results to review. Never treat every returned coordinate as equally trustworthy.
6. **Privacy and residency.** Addresses are personal data. Review subprocessors, retention, DPA/SCC terms, access controls, and whether server-side requests fit your GDPR posture.
7. **Lock-in.** Keep your internal address schema, GeoJSON zones, and spatial checks provider-neutral. Store `provider` and `provider_result_id`, but don’t make those IDs your primary keys.
8. **Operational details.** Debounce autocomplete, restrict results to supported countries, bias searches toward the delivery region, monitor low-confidence rates, and keep API tokens restricted by origin/scope.

Google would be my fallback if the bake-off shows a meaningful accuracy advantage; its address data is often excellent, but usage and caching/display terms require more care. HERE deserves particular testing for continental Europe and logistics. I would not use the public OpenStreetMap Nominatim service for production customer entry: modest traffic does not solve its service-policy, support, or address-quality variability.

So the recommendation is **Mapbox provisionally, subject to a short real-data bake-off**. At your traffic level, accuracy, storage rights, and operational simplicity matter considerably more than fractions of a cent per lookup.

I’d start with **HERE Geocoding & Search**, then confirm it with a bake-off against Mapbox using your own addresses.

HERE is a good fit because its search supports incomplete and misspelled free-form addresses, country filtering, multiple European scripts/languages, and separate address/autosuggest endpoints. It also returns both a general position and, where available, an access point—useful for deliveries. [HERE Geocoding documentation](https://docs.here.com/geocoding-and-search/docs/here-geocoding-and-search-api-v7-endpoints), [HERE Autosuggest documentation](https://docs.here.com/geocoding-and-search/docs/autosuggest)

What I would weigh first:

- **Accuracy on your data:** Test 300–1,000 representative addresses across your countries, including typos, missing postcodes, apartment text, diacritics and rural locations. Measure correct building, street-only fallback, wrong-city matches and no-results. No provider wins every European country.
- **Storage rights:** You need persistent coordinates for later zone checks. Get explicit contractual confirmation that your HERE plan permits this. Mapbox is the clearest alternative: `permanent=true` explicitly permits indefinite storage; temporary results do not. [Mapbox Geocoding API](https://docs.mapbox.com/api/search/geocoding/)
- **Map coupling:** Google often performs very well, but its policies generally restrict storing geocoding content and require results shown on a map to appear on Google Maps. That makes it less attractive for a provider-neutral delivery database. [Google Geocoding policies](https://developers.google.com/maps/documentation/geocoding/policies)
- **Delivery precision:** Prefer rooftop/building or entrance coordinates over street centroids. Preserve the provider’s match type and confidence rather than treating every result as equally reliable.
- **Operational cost:** Count autocomplete keystrokes, geocoding, map loads and retries separately. Modest traffic makes accuracy and licensing more important than tiny per-request differences.
- **Privacy:** Send only the address fields required for geocoding; don’t send customer names, phone numbers or order metadata. Review the provider’s EU data-processing terms.

Implementation-wise, I’d geocode on your backend, store the original address, normalized address, coordinates, precision/confidence, provider ID and provider/version timestamp, and let uncertain matches go through user confirmation or manual review. Render the coordinates in React with HERE Maps or MapLibre, depending on licensing and styling needs.

For delivery zones, don’t call the geocoder again. Store zones as GeoJSON/PostGIS polygons and run a point-in-polygon check—ideally `ST_Covers`, which handles boundary points more naturally than strict containment. Keep longitude/latitude order consistent and define an explicit rule for addresses lying exactly on the boundary.

I’d start with **HERE Geocoding & Search plus HERE Maps**.

HERE is a strong fit for European delivery data: it accepts structured, free-form, incomplete, and partly incorrect addresses, supports country/geographic filtering, autocomplete, and returns normalized address components alongside coordinates. That combination matters more here than having the prettiest basemap. [HERE geocoding documentation](https://docs.here.com/geocoding-and-search/reference/get_geocode)

Before committing, I would run a small bake-off using 300–1,000 representative addresses from your actual countries. Compare HERE against Google and Mapbox on:

- Correct building or entrance—not merely the right postcode or street.
- Misspellings, diacritics, swapped fields, abbreviations, and local address conventions.
- Rooftop versus interpolated/street-level coordinates.
- Ambiguous results and whether confidence/match details let you flag them for review.
- Permanent-storage rights, privacy/DPA terms, and predictable cost.
- Autocomplete quality, because correcting addresses while users enter them is much better than repairing them afterward.

Why I wouldn’t automatically choose the alternatives:

- **Google** is the likely accuracy challenger and must be in the bake-off, but its caching/storage and display rules create architectural coupling. Google says storage is generally restricted, place IDs are the main indefinitely storable item, and geocoding results shown on a map generally need a Google Map. [Google’s Geocoding policy](https://developers.google.com/maps/documentation/geocoding/policies)
- **Mapbox** has an excellent React/web-map experience and transparent pricing, but you need its paid Permanent Geocoding mode if coordinates will remain in your delivery database; temporary results cannot be cached. [Mapbox storage rules](https://docs.mapbox.com/api/search/geocoding/) Its current web-map free tier is generous for modest traffic. [Mapbox pricing](https://www.mapbox.com/pricing)
- **Public Nominatim** is unsuitable as the production backend: it has strict shared-service limits and no SLA. Self-hosted Nominatim or a commercial OSM geocoder can make sense when openness and vendor independence outweigh operations and accuracy concerns. [Nominatim policy](https://operations.osmfoundation.org/policies/nominatim/)

I’d structure the application so the provider remains replaceable:

1. Send the original address plus known country/postcode to your backend.
2. Store the original input, normalized address, WGS84 coordinates, provider, precision/confidence, and geocoding timestamp.
3. Require confirmation or a draggable-pin correction for weak or ambiguous matches.
4. Render the saved point in React; don’t geocode it again on every page load.
5. Store delivery zones as GeoJSON or PostGIS polygons and perform the authoritative check server-side with `ST_Covers(zone, point)`. Turf’s `booleanPointInPolygon` is useful for immediate client feedback, but not as the final business decision.

The biggest decision gate is licensing: confirm that your HERE plan expressly permits retaining and reusing the coordinates for delivery operations. HERE’s entry plan currently limits unpaid accounts to 1,000 daily requests and 5 geocoding requests per second, which is likely sufficient for a modest pilot. [HERE plan limits](https://www.here.com/get-started/pricing/rps-limits-excluded-use-cases)

So: **provisional choice HERE, validated against Google and Mapbox with your own failed-address corpus before signing a longer commitment**. Accuracy differences are very country-specific, and a real-address benchmark is more reliable than any global provider ranking.

I’d start with **HERE Geocoding & Search**, while keeping the map and delivery-zone logic provider-independent.

HERE is a good fit because its geocoder accepts structured, unstructured, and hybrid input and explicitly handles incomplete or partly incorrect addresses—useful for messy European data. It also returns normalized address components and match information you can use to reject weak results. [HERE Geocoding API](https://docs.here.com/geocoding-and-search/reference/get_geocode)

My stack would be:

- HERE `/geocode` called from your backend.
- Store the original address, normalized address, coordinates, provider ID, precision/result type, and match confidence.
- MapLibre GL JS or Leaflet in React for display.
- Turf.js for a simple client-side point-in-polygon check, or PostGIS `ST_Covers` on the backend when the delivery decision must be authoritative.
- Require user confirmation—a pin adjustment or corrected address—when the result is ambiguous or only street/postcode/locality-level.

What I would weigh before choosing:

1. **Real accuracy, not feature lists.** Run a blind comparison using several hundred or ideally a few thousand actual addresses, stratified by country and common failure type: missing postal codes, abbreviations, accents, swapped fields, apartment information, and misspellings. Measure correct building, correct street, false-positive, and unresolved rates.

2. **Result storage rights.** You need coordinates later for zone checks, so indefinite storage must be explicitly allowed by your contract. This substantially affects vendor choice. Mapbox, for example, distinguishes temporary results that cannot be cached from substantially more expensive permanent geocoding. [Mapbox storage rules](https://docs.mapbox.com/api/search/geocoding/) Google also generally restricts caching and storage of its mapping content, while allowing Place IDs to be stored indefinitely. [Google policies](https://developers.google.com/maps/documentation/geocoding/policies)

3. **Confidence and granularity.** Never interpret “the API returned a point” as “this is a deliverable address.” Reject or review results that resolve only to a postcode, locality, interpolated street position, or approximate point. Google itself warns that partial and synthetic/approximate matches need additional handling. [Google matching guidance](https://developers.google.com/maps/architecture/geocoding-address-validation)

4. **Country-specific coverage.** “Europe” is not one dataset. Test your actual country mix, including non-Latin scripts and local address conventions.

5. **Collection workflow.** Address autocomplete with separate house-number, postcode, and country fields will improve results more than repeatedly geocoding one uncontrolled text box. Pass the known country as a hard filter or bias.

6. **Privacy and operations.** Addresses are personal data. Check processing location, DPA/subprocessors, retention, deletion, API-key restrictions, SLA, rate limits, and whether requests can remain server-side.

I would benchmark **HERE against Google and Geoapify** before signing. Google may win raw correction quality—its Address Validation product is specifically intended for poor-quality input—but its storage and map-display terms create more coupling. [Google Address Validation guidance](https://developers.google.com/maps/architecture/geocoding-address-validation) Geoapify is an attractive lower-cost, OSM-based alternative and exposes explicit confidence and match-type fields, but I would only choose it if your country-weighted test shows acceptable building-level accuracy. [Geoapify geocoding documentation](https://apidocs.geoapify.com/docs/geocoding/)

So the short answer is: **HERE first, chosen after a representative bake-off; MapLibre for rendering; PostGIS for the eventual delivery-zone decision.** Keep a small internal geocoder interface so changing the winning provider does not affect the rest of the application.

I’d start with **HERE Geocoding & Search**, but only after a short bake-off using your real addresses.

HERE fits this case well because it offers:

- Free-form and structured geocoding, plus autocomplete that handles incomplete and misspelled input.
- Country hard-filters, language controls, normalized address components, match scoring, and address-level result types—useful for rejecting a city-centroid result masquerading as a successful delivery address. [HERE geocoding reference](https://docs.here.com/geocoding-and-search/reference/get_geocode), [autocomplete documentation](https://docs.here.com/geocoding-and-search/docs/autocomplete)
- Strong road/logistics orientation and a coherent path into routing or delivery optimization later.
- A JavaScript map SDK that can be integrated into React, although I would isolate it behind your own map component.

What I would weigh before committing:

1. **Accuracy on your actual addresses**

   Provider reputation is less useful than a test corpus. Run 300–1,000 representative addresses through HERE, Google, and one cheaper/open-data option. Include misspellings, omitted postcodes, apartment numbers, accented characters, local abbreviations, and rural addresses.

   Manually score:

   - correct building or entrance;
   - correct street but interpolated number;
   - postcode/locality only;
   - wrong but plausible result;
   - no result.

   False positives matter much more than no-results for deliveries.

2. **Whether coordinates may be stored permanently**

   This is a first-class requirement, not legal fine print. Delivery systems normally persist coordinates and reuse them for zone checks. Mapbox, for example, explicitly separates temporary from permanent geocoding; permanent results currently start at $5 per 1,000 and require the appropriate product terms. [Mapbox geocoding terms and pricing](https://www.mapbox.com/geocoding), [pricing](https://www.mapbox.com/pricing)

   Google commonly restricts caching/storage of Maps content, with place IDs being a notable indefinite-storage exception. Its Address Validation results also carry display and attribution requirements. Verify the precise EEA contract before building around persisted Google-derived coordinates. [Google Address Validation policies](https://developers.google.com/maps/documentation/address-validation/policies)

3. **Geocoding versus address validation**

   Geocoding answers “where is this string?” It does not necessarily prove that the address is deliverable. Google’s dedicated Address Validation API is more forgiving of bad input and reports unconfirmed or corrected components, but introduces another SKU and stricter usage terms. [Google’s comparison](https://developers.google.com/maps/architecture/geocoding-address-validation)

   For HERE, retain its match level/scoring and reject or manually review anything below a house-number match.

4. **Known country and local context**

   Capture country separately and pass it as a hard filter. Where possible, also supply postcode, city, and the expected service-area bounding box. HERE explicitly supports country and bounding-area constraints; these materially reduce convincing cross-border mistakes. [HERE location filtering](https://docs.here.com/geocoding-and-search/docs/here-geocoding-and-search-api-v7-endpoints)

5. **Map coupling**

   Don’t make the map provider your domain model. Store ordinary WGS‑84 coordinates and your original/normalized address, provider ID, precision, confidence, and geocoding version/date. That preserves the option to use HERE for search while rendering with MapLibre or another tile source later.

6. **Cost shape**

   At modest traffic, autocomplete can generate more calls than completed orders. Debounce it, begin after 3–4 characters, use a session model where available, and geocode only after selection or form submission. Compare total checkout sessions and map loads—not merely the advertised per-request rate. Google currently gives Geocoding and Dynamic Maps separate monthly free caps and charges them separately. [Google pricing](https://developers.google.com/maps/billing-and-pricing/pricing)

For the delivery zone, I would **not call a provider on every check**. Store the zone as GeoJSON or a PostGIS polygon and perform a point-in-polygon test server-side—PostGIS `ST_Covers` is a good choice because it gives you an explicit policy for boundary points. Render the same polygon in React for visual confirmation. This is faster, deterministic, inexpensive, and avoids provider lock-in.

A sensible flow is:

`raw address → autocomplete/user confirmation → backend geocode → precision/confidence gate → persist coordinates + metadata → PostGIS zone check → show marker and zone on map`

The most important UX detail is letting the customer move the pin when the match is uncertain. For messy European addresses, that fallback will prevent more failed deliveries than switching between two otherwise strong providers.

I’d start with **HERE Geocoding & Search**, and initially use HERE’s map stack too. HERE is particularly well suited to European delivery data: its geocoder accepts structured, unstructured, and hybrid input, including incomplete or partially incorrect addresses, and returns normalized components and match information. [HERE Geocoding documentation](https://docs.here.com/geocoding-and-search/reference/get_geocode)

I would treat that as a provisional choice until it wins a bake-off using your own addresses.

What I’d weigh first, in order:

1. **Accuracy on your actual delivery data.** Test 300–1,000 representative addresses across countries, languages, diacritics, abbreviations, swapped fields, missing postcodes, and apartment/unit suffixes. Measure rooftop/parcel/street/postcode accuracy and the percentage needing human correction. Generic provider benchmarks are much less useful.

2. **Rights to retain and reuse coordinates.** You presumably need to store coordinates for future deliveries and zone checks. Confirm this explicitly in the selected plan. This can be more decisive than price: Google generally restricts caching and storage of geocoding content, while Mapbox distinguishes temporary from permanent geocoding and charges permanent storage separately. [Google geocoding policies](https://developers.google.com/maps/documentation/geocoding/policies), [Mapbox pricing](https://www.mapbox.com/pricing)

3. **Input experience.** Use autocomplete during address entry, biased by the selected country and, where known, postcode or city. Let the customer confirm the pin when the match is ambiguous. HERE supports incomplete or partly incorrect queries; Mapbox is also a strong contender and offers a ready-made React search library with European language coverage. [Mapbox Search Box](https://docs.mapbox.com/api/search/search-box/)

4. **Match-quality signals.** Store more than `lat/lon`: raw input, normalized address, provider result ID, precision/result type, match quality, country, timestamp, and whether a user manually confirmed or moved the pin. Automatically accept house-level results; review weaker street/postcode/locality matches.

5. **Privacy and data residency.** Addresses are personal data. Check the DPA, subprocessors, retention, processing locations, deletion arrangements, and whether queries are used for other purposes—not merely whether the vendor calls itself “GDPR compliant.”

6. **Whole-workflow cost and lock-in.** Model autocomplete sessions, final geocodes, map loads, retries, and later routing—not just the headline geocoding price. HERE currently offers free entry and usage-based growth, although exact pricing should be confirmed for your account. [HERE pricing](https://www.here.com/get-started/pricing)

For implementation, I’d geocode through your backend, persist the accepted result, and render markers in React with HERE Maps. Keep an internal provider-neutral model such as GeoJSON so you can switch later.

For the delivery-zone check, I would **not** call the geocoder again or make provider geofencing a dependency. Store the zone as a GeoJSON polygon or PostGIS geometry and evaluate the saved point with `ST_Covers(zone, point)`—preferable to `ST_Contains` when points on the boundary should count. Also validate polygon geometry and define explicitly whether boundary addresses are accepted.

The shortlist I’d benchmark against HERE would be:

- **Google:** likely a strong accuracy baseline, but storage, display, and ecosystem restrictions deserve careful review.
- **Mapbox:** excellent React developer experience; permanent geocoding licensing is a notable cost consideration.
- **Geoapify:** attractive for modest traffic and an OSM-oriented stack—its free plan currently includes 3,000 credits per day—but I’d verify country-by-country address quality before choosing it. [Geoapify pricing](https://www.geoapify.com/pricing/)
- **TomTom:** worth including if routing and fleet capabilities will become central.

So: **HERE first, chosen by a country-stratified address bake-off—not by the basemap’s appearance.**

I’d start with **Geoapify**, using its Geocoding/Autocomplete APIs and MapLibre GL JS for the React map.

Why: for modest European traffic, it offers a practical balance of OSM-based European coverage, straightforward React integration, reasonable pricing, and—critically—permission to store and reuse geocoding results. Geoapify explicitly permits building a reusable address database from results, subject to attribution. [Geoapify overview and storage terms](https://www.geoapify.com/) [Geocoding documentation](https://apidocs.geoapify.com/docs/geocoding/)

Before committing, I’d weigh these in order:

1. **Accuracy on your actual addresses.** Run 300–1,000 representative examples—including typos, diacritics, reordered components, apartment numbers, rural addresses, and multiple countries—through Geoapify, HERE, Google, and Mapbox. Score rooftop/building accuracy, wrong-city matches, no-results, and confidence calibration. Published “coverage” matters less than this bake-off.

2. **Storage and reuse rights.** You will retain coordinates for later delivery-zone checks, so temporary-geocoding licenses are a poor fit. Mapbox supports permanent results, but currently charges substantially more for permanent geocoding than temporary queries. [Mapbox pricing](https://www.mapbox.com/pricing) Google’s standard policy generally restricts caching and storage apart from place IDs, and its results are tied to Google display requirements. [Google Geocoding policy](https://developers.google.com/maps/documentation/geocoding/policies)

3. **Input experience.** Add country-biased autocomplete during address entry. It will improve results more than sophisticated cleanup after accepting unconstrained text. Still allow manual entry and map-pin correction.

4. **Result quality signals.** Reject or review matches lacking the expected house number/postcode/country, and distinguish building-level, street-level, postcode-centroid, and city-level results. Geocoding is not the same as confirming that an address exists or is deliverable.

5. **Privacy and operations.** Send full addresses from your backend, not directly from the browser; treat them as personal data; restrict and rotate keys; record provider, confidence, normalized components, timestamp, and the user-confirmed coordinates.

6. **Lock-in.** Store a provider-neutral record such as GeoJSON plus normalized address fields. Keep map rendering separate from geocoding so HERE or another provider can become a fallback without rewriting the React map.

For the later zone check, I would not call a geocoding provider again. Store the delivery zone as GeoJSON and run point-in-polygon with Turf.js for simple client-side feedback or PostGIS on the server for the authoritative decision. Be explicit about whether points on the boundary count as inside.

I would avoid the public Nominatim endpoint for production. Self-hosted Nominatim can become attractive at higher volume, but its operational burden and inconsistent address completeness make it a poor first choice here. Geoapify is my default; **HERE would be my likely fallback if the country-by-country accuracy test shows a meaningful advantage**.

Do zaszumionych europejskich adresów wziąłbym Google Maps Platform (Geocoding API + Maps JS do wyświetlania), bo najlepiej sobie radzi z niedokładnym, "ludzkim" wpisem adresu, a strefę dostawy można potem sprawdzić przez turf.js albo geometry lib z tego samego SDK. Po drodze odrzuciłem Nominatim/OSM (za darmo, ale rate limity i słabe dopasowanie przy literówkach, do produkcji trzeba by hostować samemu) oraz rozważałem HERE jako tańszą alternatywę z bardzo dobrym pokryciem Europy - to realny konkurent, jeśli koszt per request zacznie boleć. Przy skromnym ruchu cena Google raczej nie jest problemem, ale to główny kompromis: płacisz więcej za wygodę integracji i jakość dopasowania.

Powiedz, jeśli wolisz żebym poszedł w stronę HERE zamiast Google, albo od razu zaczniemy implementację.

Dla tego zestawu wymagań (geokodowanie bałaganiarskich europejskich adresów, wyświetlanie na mapie w React, późniejszy point-in-polygon check, ruch umiarkowany) postawiłbym na **Mapbox**: geokodowanie dobrej jakości dla Europy, natywna integracja z React (`react-map-gl`), i co najważniejsze - permisywny licencyjnie na trwałe przechowywanie współrzędnych, co jest kluczowe skoro chcecie później sprawdzać je względem strefy dostawy.

Co odpadło po drodze:
- **Google Geocoding API** - najlepsza surowa trafność na bałaganiarskich adresach, ale ToS mocno ogranicza cache'owanie współrzędnych poza mapami Google (bez umowy enterprise nie wolno trzymać ich długoterminowo w swojej bazie), więc kłóci się z use case'em "zapisz i sprawdź później".
- **Nominatim/OSM** - darmowy, ale limit 1 req/s na publicznym serwerze i słabsze dopasowanie fuzzy dla niechlujnych adresów; własny hosting to dodatkowy operacyjny koszt bez realnej korzyści przy modest traffic.
- **HERE** - porównywalne pokrycie w Europie, ale słabsze tooling/SDK pod Reacta niż Mapbox.

Chcesz, żebym rozpisał to bardziej konkretnie (np. szacunek kosztów przy Waszym wolumenie albo strukturę point-in-polygon checka)?

Na start rozważyłbym cztery opcje: Google Geocoding (najlepsza jakość dla bałaganiarskich adresów, ale ToS wymaga wyświetlania wyników na mapie Google - problem, jeśli w React chcecie własną mapę np. na MapLibre/Leaflet), Mapbox Geocoding (podobne ograniczenie licencyjne przy trwałym zapisie współrzędnych), self-hosted Nominatim/OSM (darmowy, ale słabiej radzi sobie z niechlujnymi adresami i wymaga utrzymania) oraz OpenCage (agreguje kilka źródeł włącznie z OSM/HERE, nie ma lock-inu do konkretnego dostawcy mapy, sensowny free tier przy skromnym ruchu).

Przy Waszej kombinacji (bałaganiarskie europejskie adresy + własna mapa w React + późniejszy point-in-polygon na strefę dostawy) skłaniałbym się ku **OpenCage** - to sprawdzanie strefy to już czysta logika (turf.js) niezależna od dostawcy, więc kluczowy wybór to geokoder bez licencyjnego przywiązania do jego własnej mapy. Główny kompromis: dokładność dla bardzo pokracznych adresów bywa gorsza niż u Google, więc jeśli jakość geokodowania okaże się wąskim gardłem, warto przetestować oba na próbce Waszych realnych adresów przed decyzją.

Wziąłbym Mapbox Geocoding API. Dla bałaganiarskich europejskich adresów jakość jest zbliżona do Google, a do tego Mapbox naturalnie spina się z mapą w Reakcie (react-map-gl) i z point-in-polygon do sprawdzania strefy dostawy.

Główny czynnik, który przeważył nad Google: reguły przechowywania wyników. Google Geocoding API formalnie zabrania cache'owania współrzędnych dłużej niż jakiś czas bez wyświetlania ich na mapie Google - a wy chcecie zapisać lat/lng i porównywać je później ze strefą, czyli właśnie długoterminowo je przechowywać. Mapbox i HERE na to pozwalają, więc przy skromnym ruchu (koszt nie jest decydujący) to one wygrywają z Google mimo minimalnie gorszej jakości na trudniejszych adresach.

Google Geocoding API (razem z Google Maps JS API do wyświetlania) - przy niechlujnych europejskich adresach liczy się przede wszystkim jakość fuzzy-matchingu, a Google wciąż radzi sobie z tym najlepiej z całej stawki. Skoro i tak potrzebujecie mapy do wyświetlenia wyników, wymóg licencyjny "geokodowane przez Google trzeba pokazywać na mapie Google" przestaje być problemem.

Odrzuciłem po drodze: Nominatim/OSM (za darmo, ale limit 1 req/s i ToS zabraniające cięższego użycia komercyjnego, a fuzzy-matching słabszy przy adresach z literówkami), Mapbox (tańszy i wygodniejszy w React, ale gorzej radzi sobie z bałaganem w danych wejściowych) oraz HERE (mocne pokrycie Europy, warte rozważenia jako plan B, ale mniej odporne na naprawdę "brudne" stringi niż Google). Przy skromnym ruchu koszt per request nie jest tu decydujący, więc warto postawić na dokładność.

Jedna rzecz niezależna od dostawcy: geokodujcie raz i trzymajcie lat/lng w bazie zamiast odpytywać API przy każdym renderze - to i tak obniży koszty bardziej niż wybór providera. Sprawdzanie przynależności do strefy dostawy (point-in-polygon) zróbcie osobno, np. turf.js po stronie serwera na już zapisanych współrzędnych.