Vérification de localisation : géorepérage et distance IP

L’étape de vérification de localisation de Didit confirme où se trouve une personne pendant sa vérification, en relevant la position de l’appareil une seule fois (navigateur ou SDK natif) ou la localisation IP de la connexion, et en la comparant aux zones autorisées et bloquées, à la localisation IP et à l’adresse figurant sur ses documents. Dans les workflows et l’API, il s’agit de la fonctionnalité GEOLOCATION, ses paramètres correspondent aux clés geolocation_*, et son résultat figure dans geolocation_checks[] au niveau de la décision de la session.

​

Quand l’utiliser

• Vous ne détenez une licence que pour certaines juridictions (jeux d’argent, courtage, prêt) et devez prouver que la personne s’y trouvait lorsqu’elle a fait sa demande.
• Vous devez empêcher l’accès aux personnes situées dans des zones bloquées, comme une région sous sanctions ou un État que vous ne desservez pas.
• Vous souhaitez un signal de fraude supplémentaire : une position d’appareil éloignée de la localisation IP ou de l’adresse figurant sur la pièce d’identité, une position simulée, un VPN ou un émulateur.
• Vous n’avez pas besoin des déplacements ou de l’historique de la personne, mais seulement d’un relevé unique effectué pendant la session.

​

Comment cela fonctionne

​

Sources de position

Vous choisissez la provenance de la position avec geolocation_position_source. Sur un nœud qui sollicite l’appareil, une tentative sans position est considérée comme le refus ou l’échec qu’elle représente : la localisation IP ne la remplace jamais.

​

Valeurs par défaut et limites de configuration

Toutes les clés sont facultatives. La liste complète se trouve dans la référence de configuration des fonctionnalités de workflow.

​

Préréglages

geolocation_preset définit la valeur par défaut de chaque action que vous laissez non configurée. licensing refuse toute position située en dehors des zones autorisées, dans une zone bloquée, derrière un VPN ou Tor, ou sur un émulateur, et soumet les proxys à un examen manuel. fraud_screening applique les mêmes constats mais transmet en examen tout ce que licensing refuserait. Une action que vous définissez explicitement prévaut toujours.

​

Géorepérage

Activez is_geolocation_geofencing_enabled et listez geolocation_areas. Une zone peut être un pays entier, des régions (ISO 3166-2) d’un pays, un cercle (1 à 500 km) ou un polygone (3 à 200 points). Seule une position située à l’intérieur d’une zone autorisée est validée, et une zone bloquée prévaut toujours sur une zone autorisée. Une liste peut contenir jusqu’à 50 zones et requiert au moins une zone autorisée. Didit évalue l’ensemble du cercle de précision de la position, et pas seulement son centre :

• Un cercle entièrement situé en dehors de toute zone autorisée renvoie LOCATION_OUTSIDE_GEOFENCE.
• Un cercle qui traverse une limite déterminante renvoie LOCATION_GEOFENCE_UNDETERMINED, jamais « en dehors ».
• Un cercle entièrement situé à l’intérieur d’une zone bloquée renvoie LOCATION_IN_BLOCKED_AREA, et cet avertissement est généré en plus du verdict sur la zone autorisée.

Un pays ou une région se termine là où commence une autre terre, et non à son littoral. La personne peut voir où le service est disponible, mais jamais quelles zones sont bloquées. Les règles de zones fonctionnent également sur une étape ip_only, évaluée à partir de la localisation IP. L’ancien paramètre geolocation_geofencing_by_country fonctionne toujours mais ne peut pas être combiné avec geolocation_areas.

​

Contrôles de distance

geolocation_document_distance_basis choisit l’adresse : document (le document d’identité, puis le justificatif de domicile), proof_of_address ou declared (expected_details.address lors de la création de la session). Avec geolocation_travel_tolerance_enabled, une personne vue à proximité de son adresse au cours des geolocation_travel_max_days derniers jours n’est pas signalée pour en être éloignée actuellement. La tolérance de déplacement n’excuse jamais un VPN, une position usurpée, une zone bloquée ou une position en dehors des zones autorisées.

​

Signaux d’usurpation et d’intégrité

• Fournisseurs de positions fictives : Android et iOS signalent lorsqu’une position est simulée plutôt que mesurée.
• Attestation de l’appareil : les SDK natifs peuvent joindre une attestation d’appareil. Un échec d’attestation entraîne toujours un refus. Une attestation manquante est enregistrée et n’entraîne aucune action par défaut. Les navigateurs ne peuvent pas fournir d’attestation et sont enregistrés comme unsupported, et non comme un échec.
• VPN, proxy et Tor : détectés sur la connexion ayant partagé la localisation. Lorsque votre action pour l’un d’eux n’est pas NO_ACTION, il est demandé à la personne de le désactiver et de réessayer tant qu’il reste des tentatives.
• Émulateurs : signalés uniquement par les applications natives. Un émulateur met fin à l’étape dès cette tentative, car aucune nouvelle tentative ne modifiera l’appareil.
• Rejeu : un défi présenté lors d’une autre session est toujours refusé.

​

Résultats

La tentative retenue pour l’étape a un outcome : Tant qu’il reste des tentatives, un constat de rayon trop large, de position obsolète, approximative, refusée ou hors zone invite la personne à réessayer, et seule la dernière tentative émet des avertissements. Une position simulée, ou un émulateur sur lequel votre workflow intervient, met fin à l’étape dès la tentative qui l’a signalé.

​

Expérience utilisateur

​

Consentement et autorisation

Aucune donnée n’est lue avant que la personne n’accepte l’avis et ne réponde à la demande du système. L’avis indique que la localisation est lue une seule fois, pour cette vérification, et ne constitue pas un historique de ses déplacements. Une personne qui refuse est traitée selon geolocation_refusal_path :

• retry_then_handoff demande à nouveau tant qu’il reste des tentatives, puis propose de continuer sur un téléphone.
• continue_without_location propose de continuer sans localisation et enregistre le refus comme résultat.
• end_session met fin à l’étape et à la session dès le premier refus. Il nécessite que geolocation_permission_denied_action soit défini sur REVIEW ou DECLINE, et la session n’est jamais approuvée.

Lorsque geolocation_allow_skip est activé, la personne peut continuer sans localisation à tout moment, et l’étape est évaluée selon geolocation_unavailable_action.

​

Navigateur

Le flux hébergé demande la position au navigateur et affiche une aide pas à pas pour Chrome et Safari lorsque la localisation est désactivée pour le site. Un navigateur ne peut pas distinguer une autorisation précise d’une autorisation approximative ; les résultats web ne déclenchent donc jamais LOCATION_APPROXIMATE_ONLY, et il ne signale jamais de fournisseur de position fictive, d’émulateur ni d’attestation. Un ordinateur ne pouvant pas partager une position précise, le flux propose un code QR pour poursuivre la même vérification sur le téléphone de la personne (geolocation_allow_qr_handoff, activé par défaut), et l’ordinateur passe automatiquement à la suite lorsque le téléphone a terminé. Lorsque vous intégrez le flux dans une iframe, incluez geolocation dans l’attribut allow, voir iframe en contexte. Une page qui bloque la politique d’autorisation de géolocalisation est traitée comme une décision du site, et non comme un refus de la personne.

​

SDK natifs

Les SDK iOS et Android interrogent le système d’exploitation et peuvent joindre l’attestation de l’appareil ainsi que les indicateurs de position fictive. Sur iOS, ajoutez NSLocationWhenInUseUsageDescription à Info.plist, et sur Android, le SDK déclare ACCESS_FINE_LOCATION et ACCESS_COARSE_LOCATION et sollicite l’autorisation au moment de l’exécution uniquement si un workflow comporte cette étape. Consultez les SDK natifs. Une autorisation approximative sur iOS ou Android déclenche LOCATION_APPROXIMATE_ONLY, sauf si geolocation_accuracy_mode est défini sur approximate_allowed. Une version d’application ou de SDK antérieure à cette étape est clôturée avec unsupported_client au lieu de laisser la session bloquée.

​

Ce que renvoie la décision

La décision de session et le webhook status.updated comportent deux listes :

• geolocation_checks[] : un élément par étape Location, contenant la tentative acceptée de cette étape, avec ses warnings.
• geolocation_attempts[] : chaque tentative de chaque étape Location, de la plus ancienne à la plus récente.

Consultez le rapport de vérification de localisation pour le détail de chaque champ. Les coordonnées, la précision, la ville et le pays constituent des données personnelles de l’utilisateur final, de sorte que les attributs de réponse d’un workflow peuvent restreindre les champs de geolocation_checks que votre décision renvoie.

​

Tarifs

La vérification de localisation coûte $0.05 par vérification, et elle ne fait pas partie de l’offre gratuite. Didit facture une seule fois par étape Location dans une session, quel que soit son résultat, car la vérification a été exécutée et a renvoyé une réponse. Les nouvelles tentatives au sein de la même étape sont gratuites. Une nouvelle soumission qui termine à nouveau l’étape est de nouveau facturée.

​

Sandbox

Les sessions sandbox exécutent la même étape dans le même flux hébergé, et l’appareil ou le navigateur transmet toujours une position réelle. Les sessions sandbox ne sollicitent jamais le service de recherche d’IP, la comparaison d’IP utilise donc uniquement ce que la session contient déjà. L’utilisation est enregistrée à un prix de 0, de sorte qu’une session sandbox n’est jamais facturée. Il n’existe aucune valeur magique pour cette étape.

​

Voir aussi

• Rapport de vérification de localisation - chaque champ de geolocation_checks[] et geolocation_attempts[].
• Avertissements de vérification de localisation - chaque code LOCATION_* et son action.
• Configurations des fonctionnalités de workflow - chaque clé geolocation_*.
• Analyse de l’appareil et de l’IP - géolocalisation IP et vérifications de VPN pour la session.