Radar
Location verification and device-risk infrastructure
Radar at radar.com is a separate company from Stripe Radar. Protect checks physical location and device integrity. Reveal assesses device and network risk before requesting location permission. Geofencing, region detection, maps, address tools, and trip tracking supply location context. These tools can support account and payment risk policies; they do not establish payment authorization, identity-document verification, AML transaction monitoring, or sanctions-list screening.
Our assessment
A focused location and device-risk layer with detailed public integration documentation. Evaluate it for physical-presence evidence and geographic controls alongside the systems that own payment decisions, identity checks, and financial-crime investigations.
Best fit and limitations
Useful for teams that need stronger evidence about where an account or device is operating, especially when location spoofing, geographic access restrictions, or physical activity affect loss. Reveal can precede a permission request; Protect supplies a more demanding verification step. Maps and trip tools add operational context rather than broadening the product into a full financial-crime suite.
- Radar and Stripe Radar are separate vendors. Similar names do not imply shared infrastructure, data, or payment controls.
- A permitted country or state is a geographic policy result, not an OFAC, PEP, adverse-media, or entity-screening result.
- Address validation and inferred home location do not establish KYC, legal residence, document authenticity, or beneficial ownership.
- Verified-location coverage depends on SDK, plugin, permissions, device services, and desktop mode. Browser-only checks have a different detection scope from the companion app.
- Documentation still describes some features as Enterprise, while current pricing is organized by Protect, Reveal, and other products. Confirm access, billing, and support in the contract.
- The reviewed webhook guide does not specify retry timing, acknowledgment timeout, delivery order, or duplicate guarantees. No general API idempotency contract was found.
- Public sources do not establish AML monitoring, credit decisions, merchant reserve management, settlement execution, regulatory filing, or AI-agent authority.
Tools 22
Radar ProtectPhysical-location verification+
- Combine device and location evidence to assess whether reported physical presence is credible
- Support checks for account takeover, spoofed activity, and promotion abuse alongside an existing fraud stack
Radar RevealDevice and network checks before location permission+
- Assess a web or mobile session without first asking for precise-location access
- Return risk context that the application can use to request a stronger location check
Verified location tokens and fraud flagsServer-verifiable location evidence+
- Return signed tokens, pass state, expiry, and failure reasons from trackVerified()
- Flag spoofing, impossible movement, tampering, low accuracy, VPNs, and remote access; check jurisdiction results separately
Jurisdiction controlsGeographic access policy+
- Combine configured country and state permissions with optional border buffers and exclusion areas
- Supply geographic pass or fail results for the application to enforce; this is not sanctions-name matching
User and device risk scoresConfigurable location-risk history+
- Weight recent fraud flags and shared user/device identifiers with configurable strikes and lookback periods
- Propagate risk across linked identifiers and optionally block high-risk users; access requires vendor enablement
Fraud SDK and device attestationClient integrity checks+
- Add the fraud plugin and configured Apple App Attest or Google Play Integrity checks
- Choose browser-only verification or the Radar Verify desktop companion; detection scope differs
GeofencesCustom geographic boundaries+
- Create circles, polygons, and travel-time boundaries through the dashboard, imports, or API
- Generate entry, exit, and dwell events with optional stop detection, schedules, and user restrictions
- Update an existing boundary through its tag and external ID; this is not a general request-idempotency guarantee
RegionsAdministrative geography and coarse travel context+
- Identify countries globally and states or provinces in the United States and Canada
- Detect US postal codes and media markets; optional home-region and travel context needs enablement
- Return region entry and exit events without verifying a person's legal identity or residence
User insightsInferred home, work, travel, and commute context+
- Infer recurring places from stopped-location history and return context when confidence is sufficient
- Emit changes in home, work, travel, or commute state; unavailable insights can be omitted
- Keep these probabilistic inferences separate from fraud and jurisdiction decisions
Geocoding APIsAddress and IP location data+
- Convert addresses into coordinates, coordinates into addresses, and IP addresses into geographic context
- Check the published country-by-country coverage table for the chosen endpoint and use case
- Use geocoding as supporting context; a resolved address does not establish identity or physical presence
Address autocomplete and validationAddress capture and quality checks+
- Suggest addresses while a user types and validate supplied address data
- Search places and project geofences for nearby-location experiences
- Support cleaner onboarding inputs without treating address validity as KYC or proof of residence
Routing APIsTravel estimates and route processing+
- Calculate distances, travel-time matrices, and directions for supported travel modes
- Match recorded paths to roads and optimize the order of multiple destinations
- Keep operational route analysis separate from the fraud-verification result
Trips and arrival monitoringPickup and delivery operations+
- Track single- or multi-stop journeys, arrival state, ETAs, and trip events
- Detect configured delays or arrival at a different destination with the same geofence tag
- Review trip activity and analytics or send events into an external operations system
PlacesPoint-of-interest visit detection+
- Recognize place visits and return categories, chains, and confidence context
- Filter eligible places and match a custom geofence to the vendor's place geometry
- Treat a detected visit as location evidence, not a verified transaction or account relationship
Webhooks and event integrationsDelivery to existing systems+
- Send event and user context to a configured HTTP endpoint or supported destination
- Filter event types and selected fields before delivery to connected systems
- Keep downstream payment, authentication, and case actions in the receiving application
Simulator and User ActivityIntegration testing and location inspection+
- Test location updates and inspect user activity while separating test and live environments
- Investigate permission, background execution, rate-limit, and event-delivery issues
- Use controlled real-device checks to complement simulated locations
Access, retention, and audit controlsLocation-data administration+
- Apply account roles and project-level data controls; review administrator activity through audit logs
- Configure retention, export a user's records, or delete a user through the dashboard or API
- Minimize submitted identifiers and metadata; precise location still requires appropriate handling
REST API and location lifecycleProgrammatic location infrastructure+
- Track coordinates and accuracy against device and optional user identifiers; receive user context and generated events
- Manage users, geofences, trips, beacons, and selected project settings
- Separate publishable client keys from server-only secret keys and record request IDs for diagnosis
Bluetooth BeaconsIndoor and short-range location context+
- Detect iBeacon signals on iOS and Android, with Eddystone-UID additionally supported on Android
- Generate proximity events around installed hardware after the required permissions are granted
- Manage beacon identifiers through the dashboard, imports, or API
Radar MapsLocation display and operator context+
- Render maps and markers with Radar's extension of MapLibre GL JS
- Build location views and locators around the maps, search, and routing APIs
- Map visualization does not add a fraud verdict or compliance decision by itself
Network ExplorerUser and device relationship investigation+
- Start with user or device identifiers and inspect their connections in a visual network
- Review, block, or export linked records from the same view
- Scope the investigation to account/device relationships; no general graph-query API or ownership graph was verified
Residential and mobile proxy detectionNetwork-obfuscation signals+
- Flag location checks associated with known residential or mobile proxy addresses
- Use connected datasets whose providers and refresh terms are not named in the announcement
AI capabilities
Documented risk rules and location inference; AI scope unconfirmed
The fraud guide describes configurable strike-based scores and relationships between user and device identifiers. User insights infer recurring locations, with explicit uncertainty. Neither establishes a predictive payment-fraud model, a generative investigator, or an autonomous AI agent. Treat those capabilities as unconfirmed until Radar provides product-specific evidence.
What to validate
Validate signed results on the backend, enforce expiry, and distinguish missing evidence from a failed check. Review strike weights, linked-account effects, and block settings. Test bypass controls separately. Keep sensitive account and payment actions behind the application's own policy and audit trail.
Implementation
Integration checklist
- Use separate test and live keys. Keep Secret endpoints on the backend and avoid names or email addresses in the tracking user ID.
- Choose Reveal, verified location, or ordinary tracking by use case. An ordinary track response is not a signed fraud-verification result.
- Validate token signatures, expiry, user context, and geographic result on the server. Handle permission, plugin, location, and network errors explicitly.
- For a repeated check, distinguish trackVerified() from the cached-token path. Set freshness requirements at the protected business action.
- Validate the documented webhook header signature and acknowledge accepted events with 2xx. Design deduplication and recovery after confirming the delivery contract with Radar.
- Test border cases, travel, VPN use, shared devices, accessibility tools, and poor positioning. Set review paths using measured false-positive results.
- Limit retained location history and integration fields. Review data access, deletion, retention, and administrative block or bypass permissions before launch.
Commercial scope
The September 18 pricing page lists usage-based starting rates, annual agreements with monthly commitments, and no free tier. It advertises Protect from $0.04 per monthly tracked user and Reveal from $2 per 1,000 API calls. These are public starting rates, not a customer quote. Confirm minimums, feature enablement, overages, verification frequency, desktop components, support, and data terms. Maps has separate usage rates.
Questions for the demo
- Which Reveal, Protect, Regions, desktop verification, risk-score, and automatic-blocking features are enabled in our plan?
- Which signals remain available after denied location permission, limited accuracy, unavailable attestation, or an unsupported desktop environment?
- What exactly produces each risk level, how do linked users inherit it, and which settings or manual actions can override it?
- What is the signed-token validation contract, including freshness, user binding, key rotation, jurisdiction constraints, and replay protection?
- What are the webhook retry, timeout, ordering, duplicate, retention, and backfill guarantees? Which write APIs support safe retries?
- Which countries, state boundaries, exclusion areas, and product versions are approved for our specific use case?
- Can we measure location-check completion, false positives, latency, permission drop-off, and review outcomes on our own devices and population?
Engineering
- Inputs
- POST /v1/track: deviceId, latitude, longitude, and accuracy; optional userId and context · Configured SDK and fraud plugin, client identity, and device/location signals · Web or mobile session with device and network information · JavaScript SDK initialized with a publishable project key · Geofence geometry plus customer-assigned tag and externalId · Recurring stopped-location history and subsequent location updates · Partial address query, structured address, or location-search parameters · Registered beacon identifiers and device proximity measurements · User or device IDs entered into Network Explorer
- Outputs
- JSON user context and generated events · X-Radar-Request-ID response header · trackVerified(): signed token, pass state, failure reasons, expiry, user context, and events · revealRisk(): risk level/reasons, network and device context, and signed token · Session-risk context usable before precise-location permission · Client callbacks and location context for enabled SDK functions · POST with event plus user, or events array plus user; multiple-event batches contain at most five events · Country, state/province, supported media-market and postal-code context; region events · Server-generated entry, exit, and dwell events for configured boundaries · Filtered events and user context sent to supported marketing, analytics, or custom destinations · Optional home, work, traveling, and commuting states · Autocomplete suggestions, address-validation results, or matching places/geofences · Beacon proximity context and entry/exit events · Relationship visualization with operator review, block, and export actions
- Webhooks
- Select Test or Live and single- or multiple-event delivery. Acknowledge accepted requests with 2xx. X-Radar-Signature is the HMAC-SHA1 of X-Radar-Signing-Id using the webhook security token. The guide does not establish retry timing, acknowledgment timeout, ordering, or duplicate guarantees.
- Decision timing
- Tracking returns the processed context and events. A general request-idempotency guarantee was not found; the published track rate limit is one request per second per device. trackVerified() performs a fresh check; getVerifiedLocationToken() can reuse an unexpired token. startTrackingVerified() refreshes on relevant connection changes or configured timing. Confirm freshness at the protected action. Historical stopped locations are processed daily; subsequent updates return usable context when there is enough evidence.
- Deployment
- Hosted API · iOS SDK · Android SDK · Web SDK · React Native SDK · Flutter SDK · Cordova plugin · Capacitor plugin · MAUI SDK
- Dependencies
- Authorization header with endpoint-appropriate Publishable or Secret key · Separate Test and Live keys; Secret endpoints are server-only · Fraud enabled for the project and vendor access for Reveal/risk scoring · Server-side JWT signature and expiry validation · Platform-specific plugin and permission configuration · Check the feature-specific SDK and plugin support; the platform list alone does not establish equal fraud coverage · Appropriate device location permission and operating-system background behavior · Project retention settings and role-based administrative access · Installed compatible beacon hardware and location permissions; Android also requires Bluetooth permissions · Unnamed third-party datasets for known residential and mobile proxy addresses
Verified details 55
- Inputs
POST /v1/track: deviceId, latitude, longitude, and accuracy; optional userId and context
Source Checked 2026-09-18 - Outputs
JSON user context and generated events
Source Checked 2026-09-18 - Outputs
X-Radar-Request-ID response header
Source Checked 2026-09-18 - Decision timing
Tracking returns the processed context and events. A general request-idempotency guarantee was not found; the published track rate limit is one request per second per device.
Source Checked 2026-09-18 - Deployment
Hosted API
Source Checked 2026-09-18 - Dependency
Authorization header with endpoint-appropriate Publishable or Secret key
Source Checked 2026-09-18 - Dependency
Separate Test and Live keys; Secret endpoints are server-only
Source Checked 2026-09-18 - Inputs
Configured SDK and fraud plugin, client identity, and device/location signals
Source Checked 2026-09-18 - Outputs
trackVerified(): signed token, pass state, failure reasons, expiry, user context, and events
Source Checked 2026-09-18 - Outputs
revealRisk(): risk level/reasons, network and device context, and signed token
Source Checked 2026-09-18 - Decision timing
trackVerified() performs a fresh check; getVerifiedLocationToken() can reuse an unexpired token. startTrackingVerified() refreshes on relevant connection changes or configured timing. Confirm freshness at the protected action.
Source Checked 2026-09-18 - Connected provider
Apple App Attest
Source Checked 2026-09-18 - Connected provider
Google Play Integrity
Source Checked 2026-09-18 - Dependency
Fraud enabled for the project and vendor access for Reveal/risk scoring
Source Checked 2026-09-18 - Dependency
Server-side JWT signature and expiry validation
Source Checked 2026-09-18 - Dependency
Platform-specific plugin and permission configuration
Source Checked 2026-09-18 - Inputs
Web or mobile session with device and network information
Source Checked 2026-09-18 - Outputs
Session-risk context usable before precise-location permission
Source Checked 2026-09-18 - Deployment
iOS SDK
Source Checked 2026-09-18 - Deployment
Android SDK
Source Checked 2026-09-18 - Deployment
Web SDK
Source Checked 2026-09-18 - Deployment
React Native SDK
Source Checked 2026-09-18 - Deployment
Flutter SDK
Source Checked 2026-09-18 - Deployment
Cordova plugin
Source Checked 2026-09-18 - Deployment
Capacitor plugin
Source Checked 2026-09-18 - Deployment
MAUI SDK
Source Checked 2026-09-18 - Dependency
Check the feature-specific SDK and plugin support; the platform list alone does not establish equal fraud coverage
Source Checked 2026-09-18 - Inputs
JavaScript SDK initialized with a publishable project key
Source Checked 2026-09-18 - Outputs
Client callbacks and location context for enabled SDK functions
Source Checked 2026-09-18 - Deployment
Web SDK
Source Checked 2026-09-18 - Outputs
POST with event plus user, or events array plus user; multiple-event batches contain at most five events
Source Checked 2026-09-18 - Webhooks
Select Test or Live and single- or multiple-event delivery. Acknowledge accepted requests with 2xx. X-Radar-Signature is the HMAC-SHA1 of X-Radar-Signing-Id using the webhook security token. The guide does not establish retry timing, acknowledgment timeout, ordering, or duplicate guarantees.
Source Checked 2026-09-18 - Outputs
Country, state/province, supported media-market and postal-code context; region events
Source Checked 2026-09-18 - Country scope
United States
Source Checked 2026-09-18 - Country scope
Canada
Source Checked 2026-09-18 - Inputs
Geofence geometry plus customer-assigned tag and externalId
Source Checked 2026-09-18 - Outputs
Server-generated entry, exit, and dwell events for configured boundaries
Source Checked 2026-09-18 - Outputs
Filtered events and user context sent to supported marketing, analytics, or custom destinations
Source Checked 2026-09-18 - Connected provider
Segment
Source Checked 2026-09-18 - Connected provider
Braze
Source Checked 2026-09-18 - Connected provider
Amplitude
Source Checked 2026-09-18 - Connected provider
Mixpanel
Source Checked 2026-09-18 - Dependency
Appropriate device location permission and operating-system background behavior
Source Checked 2026-09-18 - Dependency
Project retention settings and role-based administrative access
Source Checked 2026-09-18 - Inputs
Recurring stopped-location history and subsequent location updates
Source Checked 2026-09-18 - Outputs
Optional home, work, traveling, and commuting states
Source Checked 2026-09-18 - Decision timing
Historical stopped locations are processed daily; subsequent updates return usable context when there is enough evidence.
Source Checked 2026-09-18 - Inputs
Partial address query, structured address, or location-search parameters
Source Checked 2026-09-18 - Outputs
Autocomplete suggestions, address-validation results, or matching places/geofences
Source Checked 2026-09-18 - Inputs
Registered beacon identifiers and device proximity measurements
Source Checked 2026-09-18 - Outputs
Beacon proximity context and entry/exit events
Source Checked 2026-09-18 - Dependency
Installed compatible beacon hardware and location permissions; Android also requires Bluetooth permissions
Source Checked 2026-09-18 - Inputs
User or device IDs entered into Network Explorer
Source Checked 2026-09-18 - Outputs
Relationship visualization with operator review, block, and export actions
Source Checked 2026-09-18 - Dependency
Unnamed third-party datasets for known residential and mobile proxy addresses
Source Checked 2026-09-18
Vendor example
Published vendor example. Confirm the current version and required credentials.
{
"meta": {
"code": 400,
"param": "latitude",
"message": "latitude: Invalid latitude. Valid range: [-90, 90]."
}
}Integration limits
- Published vendor payload example, linked to its source. It is not a complete integration or a tested production request.
- Empty country, deployment, or provider lists mean not verified in this review. A documented country refers to the specific product noted in its source, not universal platform coverage.
- The shown vendor JSON is the documented invalid-latitude error response, not a successful fraud decision.
- Record request IDs and handle HTTP 402, 429, 451, and 5xx responses explicitly. Ordinary tracking does not substitute for trackVerified().
- These providers supply app/device attestation, not KYC or sanctions data. Desktop SDK access and some checks need vendor enablement.
- Temporary client auth tokens are a separate option from returned verification tokens: the customer signs constrained credentials with its own private key.
- The guide describes a default 20-minute verification-token expiry that can shorten near borders; do not treat that default as a regulatory requirement or an acceptable freshness threshold for every action.
- The application chooses whether to request a Protect check and how to act on its result. The product description is not a payment execution API or measured detection benchmark.
- The public delivery model combines client SDKs with hosted services. No self-hosted Radar service was verified.
- SDK installation is separate from fraud-plugin configuration. Confirm how denied browser permissions, origin configuration, and desktop verification affect the chosen flow.
- Follow the documented header-signing scheme; do not replace it with an invented raw-body signature algorithm. Confirm replay protection and delivery recovery with Radar.
- Countries above identify explicit state/province detection support. Country detection is global; postal-code and media-market detection are US-only. These are data-coverage statements, not gaming approvals or blanket product availability.
- Allow/block configuration and optional coarse-home features need vendor coordination.
- Reimporting the same tag/externalId updates that geofence. This bounded upsert behavior is not a universal idempotency-key contract.
- GeoJSON coordinates use longitude before latitude; Test and Live boundaries are configured separately.
- Listed providers are outbound integration destinations, not bundled fraud or identity-data suppliers. Filter event types, geofence tags, and selected payload fields where supported.
- The FAQ lists default retention of one year for users/events, 90 days for trips, and seven days for location updates; settings can vary by project. Confirm contracted retention and deletion behavior.
- Use opaque internal identifiers rather than names or email addresses. Enterprise audit logs describe dashboard requests; this does not establish a full downstream decision audit.
- General vendor latency figures were not adopted as measured results or a verified-location SLA.
- Inferred places are probabilistic and can change. SDK responses do not include inferred home/work coordinates. This feature does not independently establish a predictive fraud model or legal residence.
- Use the endpoint's published coverage table. Address quality does not establish document verification, beneficial ownership, or physical presence.
- iBeacon is supported on iOS and Android; Eddystone-UID is supported on Android. Beacon proximity is not identity authentication.
- July 23, 2026 product announcement. No graph API contract, licensed dataset identity, refresh guarantee, or autonomous-action authority was established. Confirm permissions and entitlement.
Sources 23
Source review dates are shown above. Product claims come from public sources. Fit, limits, and evaluation questions are our analysis. This is not a hands-on performance test. Methodology · Changelog