Aller au contenu principal

Modèles d'intégration

Afin d'intégrer Shield, vous devez d'abord être enregistré en tant que client et vous devez avoir fourni au moins un service.

info

Bien que Shield soit conçu pour une intégration simple, une détection efficace des fraudes nécessite une mise en œuvre minutieuse. Les fraudeurs font continuellement évoluer leurs techniques, exploitant même des lacunes d'intégration mineures pour contourner les systèmes de protection. La précision de Shield dépend de la réception de données complètes et cohérentes tout au long du parcours utilisateur, du chargement initial de la page jusqu'à l'abonnement final. Les petits détails comptent : le moment du chargement de Shield, les pages qui incluent l'extrait, la façon dont les données de session circulent entre les pages et la garantie que les informations d'en-tête restent intactes. Une intégration bien exécutée maximise non seulement la détection des fraudes, mais minimise également les faux positifs qui pourraient bloquer les utilisateurs légitimes. L'effort initial investi dans une intégration appropriée porte ses fruits en termes de sécurité et de taux de conversion, protégeant vos revenus tout en maintenant une expérience utilisateur fluide.

Commencer​

Tout d’abord, vous devez être très clair sur qui exécutera l’appel JS API et l’appel Block API. Plusieurs appels du Block API pour la même transaction entraîneront des réponses Block.

Shield prend en charge les méthodes d'intégration suivantes. Chaque scénario d'intégration ci-dessous comprend un flux logique et un diagramme de séquence pour clarifier la manière dont MCP Shield est invoqué.

Points de terminaison régionaux​

La technologie Shield est déployée dans plusieurs régions pour offrir la meilleure latence entre vos serveurs et nos points de terminaison régionaux.

Dans chaque région, l'architecture est configurée pour fournir une haute disponibilité grâce à la technologie d'autoscaling. Comme Shield s'appuie sur une technologie de détection en temps réel, la disponibilité de notre serveur doit correspondre aux besoins et aux variations de capacité de nos clients.

RégionPoint de terminaison API
Afrique australehttps://sa.apiserver.shield.monitoringservice.co
Singapourhttps://sg.apiserver.shield.monitoringservice.co
Royaume-Unihttps://uk.apiserver.shield.monitoringservice.co
Émirats arabes unishttps://dc-ae-01.apiserver.mena.mcpshield.com

Test de latence​

Nous fournissons un script pour tester la latence entre vos serveurs Web et chaque région du bouclier. Ce script bash exécutera quelques commandes curl et imprimera les résultats des performances.

wget https://docs.shield.monitoringservice.co/shield-latency 
sh shield-latency

Page de destination hébergée par CSP avec exécution divisée de API​

Scénario : CSP exécute le JS API, tandis que la décision Block API est appliquée par un agrégateur.

Flux​

  • L'utilisateur accède à la page hébergée par CSP.
  • Le serveur Web CSP récupère l'extrait JS MCP Shield.
  • La page Web est livrée à l'utilisateur avec Shield intégré au HTML.
  • MCP Shield JS API est exécuté dans le navigateur pour collecter les signaux d'appareil, de réseau et de comportement.
  • L'utilisateur clique sur le bouton CTA.
  • Le backend CSP envoie une demande d'abonnement à Aggregator
  • L'agrégateur appelle le Block API pour valider la transaction.
  • MCP Shield renvoie une décision clear / suspect / block avant la confirmation du paiement.

CSP Page de destination hébergée avec les deux API

Avantages et inconvénients​

Avantages :

  • L'appel serveur à serveur JS API est plus sécurisé que l'appel côté client
  • En étant intégré dans le HEAD de la page HTML, le snippet Shield est actif dès le chargement de la page
  • L'agrégateur impose l'utilisation de MCP Shield en effectuant un appel Block API avant de facturer
  • Le parcours utilisateur reste entièrement sur les pages CSP jusqu'à la facturation
  • Aucune complexité de redirection
  • CSP a un contrôle total sur le contenu (dans le respect des règles de conformité)

Inconvénients :

  • Chaque CSP doit s'intégrer à Shield

Page de paiement hébergée par l'agrégateur avec application complète de Shield​

Scénario : dans ce scénario, l'agrégateur intègre directement MCP Shield, en exécutant le JS API sur la page de paiement et en appliquant la décision Block API lors de la confirmation de l'abonnement de l'utilisateur.

Flux​

  • L'utilisateur visite la page 1 hébergée par CSP
  • L'utilisateur clique sur S'abonner
  • L'utilisateur arrive sur la page de confirmation de paiement hébergée par l'agrégateur
  • L'agrégateur appelle JS API pour récupérer l'extrait JS
  • La page Web est livrée à l'utilisateur avec Shield intégré au HTML.
  • MCP Shield JS API est exécuté dans le navigateur pour collecter les signaux d'appareil, de réseau et de comportement
  • L'utilisateur clique sur Confirmer le CTA
  • Le backend de l'agrégateur appelle le Block API pour valider la transaction
  • MCP Shield renvoie une décision clear / suspect / block avant que l'agrégateur ne déclenche la facturation de l'opérateur.

Page de paiement hébergée par l'agrégateur avec application complète de Shield

Avantages et inconvénients​

Avantages :

  • L'appel serveur à serveur JS API est plus sécurisé que l'appel côté client
  • En étant intégré dans le HEAD de la page HTML, le snippet Shield est actif dès le chargement de la page
  • L'agrégateur impose l'utilisation de MCP Shield puisqu'il héberge la page de paiement
  • Seul l'agrégateur doit intégrer MCP Shield

Inconvénients :

  • L'utilisateur est redirigé entre deux serveurs Web différents
  • MCP Shield n'a la visibilité que de la deuxième page
  • Le contenu des pages de paiement est contrôlé par l'agrégateur, limitant les choix des CSP

Pages hébergées CSP et appels API​

Scénario : CSP héberge les pages de destination, appelle le Shield JS API et appelle le Shield Block API lors de la tentative d'abonnement, avant de lancer la facturation.

Flux​

  • L'utilisateur arrive sur la page de destination hébergée par CSP.
  • Le CSP appelle le Shield JS API (serveur à serveur) pour initialiser une session Shield.
  • La page Web est livrée à l'utilisateur avec Shield intégré au HTML.
  • Lorsque l'utilisateur atteint le point de déclenchement de l'abonnement, le CSP appelle le Shield Block API.
  • MCP Shield renvoie une décision effacer/suspect/bloquer.

CSP-Pages hébergées et appels API

Avantages et inconvénients​

Avantages :

  • Seul le CSP doit intégrer le MCP Shield. Indépendant de l’agrégateur et de l’opérateur.
  • L'appel serveur à serveur JS API est plus sécurisé que l'appel côté client
  • En étant intégré dans le HEAD de la page HTML, le snippet Shield est actif dès le chargement de la page
  • Aucune complexité de redirection. Le parcours utilisateur reste entièrement sur les pages CSP jusqu'à la facturation.

Inconvénients :

  • Limité aux scénarios où le CSP a le contrôle total

Page de paiement hébergée par MCP avec application complète de Shield​

Scénario : l'utilisateur est redirigé d'une page de destination CSP vers une page de paiement hébergée par MCP où Shield effectue une analyse comportementale complète et applique la décision de facturation finale.

Flux​

  • L'utilisateur accède à la page de destination CSP et lance un parcours d'abonnement.
  • Le CSP redirige l'utilisateur vers une page de paiement hébergée par MCP.
  • MCP Shield est initialisé sur la page de paiement.
  • Les empreintes digitales de l'appareil et les signaux comportementaux sont collectés directement à partir de l'appareil de l'utilisateur.
  • Lorsque l'utilisateur confirme le paiement, MCP invoque le Shield Block API.
  • MCP Shield renvoie une décision en temps réel (Clear / Suspect / Block).

Page de destination hébergée par CSP avec les deux exécutions API

Avantages et inconvénients​

Avantages :

  • Intégration minimale du partenaire requise, MCP gère tout
  • Sécurité la plus forte possible

Inconvénients :

  • Moins de flexibilité autour du contenu et du style de la page

Flux d'entrée MSISDN et PIN avec application Shield sur les deux pages​

Scénario : flux MSISDN et PIN en deux étapes dans lequel Shield corrèle l'activité sur les deux pages avant la facturation.

Couler​

  • L'utilisateur arrive sur la page d'entrée MSISDN et saisit son numéro de mobile.
  • MCP Shield est initialisé sur la page d'entrée MSISDN et génère un Step-1 UNIQID.
  • Les empreintes digitales de l'appareil et les signaux comportementaux sont collectés lors de la saisie MSISDN. - Le UNIQID de l'étape 1 est transmis de la page d'entrée MSISDN à la page d'entrée PIN via l'URL.
  • Le uniqid est conservé ou ajouté à l'URL lors de la redirection vers la page deux : https://example.com/page2?uniqid=page1_uniqid
  • L'utilisateur est redirigé vers la page de saisie PIN pour saisir le PIN reçu.
  • MCP Shield est initialisé sur la page d'entrée PIN et génère un UNIQID Step-2, tout en recevant également l'UNIQID Step-1, permettant à Shield de corréler les deux étapes en un seul parcours.
  • Des signaux comportementaux supplémentaires sont collectés lors de l'entrée PIN.
  • Lors de la soumission de PIN, le backend appelle le Shield Block API à l'aide de Step-2 UNIQID.
  • MCP Shield évalue le parcours complet (comportement MSISDN + PIN) et renvoie une décision clear / suspect / block avant la confirmation du paiement.

Page de destination hébergée par CSP avec les deux exécutions API

Avantages et inconvénients​

Avantages :

  • Shield intégré sur deux pages, offrant une sécurité accrue
  • L'appel serveur à serveur JS API est plus sécurisé que l'appel côté client
  • En étant intégré dans le HEAD de la page HTML, le snippet Shield est actif dès le chargement de la page

Inconvénients :

  • Intégration un peu plus complexe puisqu'il faut passer uniqid de la page 1 à la page 2

Flux MSISDN et PIN avec application Shield sur une seule page​

Scénario : Shield est implémenté sur une seule page d'un flux MSISDN et PIN en deux étapes, soit la page d'entrée MSISDN ou la page d'entrée PIN / OTP et applique la décision finale avant la facturation.

Couler​

  • L'utilisateur arrive sur la page d'entrée MSISDN et saisit son numéro de mobile.
  • L'utilisateur est redirigé vers la page d'entrée PIN / OTP pour saisir le PIN reçu.
  • MCP Shield est initialisé sur une seule page sélectionnée :
  • Soit la Page d'entrée MSISDN, ou
  • La Page d'entrée PIN / OTP.
  • MCP Shield génère un UNIQID sur la page où il est déployé.
  • Les empreintes digitales de l'appareil et les signaux comportementaux sont collectés uniquement sur cette page.
  • Lors de la soumission de PIN, le backend appelle le Shield Block API à l'aide de l'UNIQID généré.
  • MCP Shield renvoie une décision clear / suspect / block avant la confirmation du paiement.

Flux MSISDN et PIN avec application Shield sur une seule page

Avantages et inconvénients​

Avantages :

  • Intégration plus simple, Shield est déployé sur une seule page
  • L'appel serveur à serveur JS API est plus sécurisé que l'appel côté client
  • En étant intégré dans le HEAD de la page HTML, le snippet Shield est actif dès le chargement de la page

Inconvénients :

  • Shield n'observe qu'une seule étape du parcours utilisateur.
  • Les comportements MSISDN et PIN ne sont pas entièrement liés.
  • Diminution de la précision de la détection des fraudes. Certains modèles de fraude en plusieurs étapes peuvent ne pas être détectés.
  • L'efficacité dépend du déploiement de Shield sur la page MSISDN ou PIN.

Quand utiliser ce scénario​

  • Campagnes à risque faible à moyen
  • Exigences de déploiement rapide
  • Flux hérités avec une portée de modification limitée
  • Environnements d'opérateur permettant une application en un seul point

Intégration du flux de redirection (Shield sur la page de redirection)​

Scénario : le client contrôle une étape de redirection, où Shield JS est exécuté et la décision Block API est appliquée avant de transférer l'utilisateur.

Contactez l'assistance si vous souhaitez des instructions supplémentaires sur la façon de mettre en œuvre l'intégration de redirection.

Intégration frontale​

attention

Ce modèle d'intégration n'est pas recommandé

Front-end

Avantages et inconvénients​

Avantages :

  • Intégration simple
  • Compatible avec les déploiements de pages statiques du réseau de diffusion de contenu

Inconvénients :

  • Expose des informations sensibles dans le code frontal
  • Plus sujet à la falsification par de mauvais acteurs
  • La détection de fraude ne commence pas au moment du chargement de la page