Système d Analyse des Commandes : Dispositif Technique

Transcription

1 Mars 2010 Système d Analyse des Commandes : Dispositif Technique Présentation et intégration ANNEXE 1 DU CONTRAT D ANALYSE DES COMMANDES FIA-NET 39, rue St-Lazare PARIS V5.6.3-dispositif_technique.doc Page 1 sur 81

2 1 Introduction Architecture générale Intégration du Système d Analyse des Commandes Comprendre le système Quand et comment envoyer les informations? Quand et comment récupérer les informations? Quand et comment envoyer l information sur la livraison? Quand et comment envoyer l information sur les fraudes? Quand et où tester l intégration? Pays acceptés pour l analyse de vos transactions Envoi des informations du bon de commande Avantages et inconvénients des différentes méthodes Envoi des informations «on-line» Envoi des informations «off-line» Flux XML contenant les informations : flux <control> Récupération de l analyse Connexion automatique au Back-Office FIA-NET Récupération de l analyse : transaction par transaction Récupération de l analyse : transactions par paquets Interrogation des transactions réévaluées Structures renvoyées Envoi de l information livraison (Obligatoire) Communication des informations en mode manuel Communication des informations par fichier Communication des informations par appel à un script Envoi de l information sur les fraudes (Obligatoire) Déclaration de fraude en mode manuel Déclaration de fraude par fichier Protocole de tests Pourquoi un système test Système en test Type de structure XML à tester Outil d analyse de flux XML Bascule en Production Annexe 1 : Exemples Flux XML <control> simple Flux XML <control> avec adresse de facturation et adresse de livraison Flux XML <stack> pour stacking.cgi ou stackfast.cgi Intégration en méthode GET avec tag <img> Intégration en méthode POST en PHP Intégration en méthode POST en ASP Intégration en méthode POST en javascript Envoi «off-line» multiple en méthode POST Lien au Back-Office FIA-NET en «auto-login» Appels à get_validation.cgi Appel à redirect_validation.cgi Flux <result> (mode «full») en réponse à get_validation.cgi Flux <result> (mode «mini») en réponse à get_validation.cgi Appel à get_validstack.cgi Flux <stack> en réponse à get_validstack.cgi par liste Flux <stack> en réponse à get_validstack.cgi par date V5.6.3-dispositif_technique.doc Page 2 sur 81

3 9.17 Erreurs sur les scripts de récupération Extraction d une partie du mode «help» de get_validation.cgi Appels et retours du script delivery.cgi Annexe 2 : Format général des champs pour tous les pays Annexe 3 : Format spécifique des champs par pays Préambule relatif à l interprétation des caractères non latins Allemagne Autriche Belgique (francophone) Bulgarie Chypre Danemark Espagne Estonie Finlande France Grèce Hollande et les Pays-Bas Hongrie Irlande Italie Lettonie Lituanie Luxembourg Malte Monaco Pologne Portugal Royaume-Uni Slovaquie Slovénie Suède Suisse (francophone) République Tchèque Roumanie Annexe 4 : Contacts techniques V5.6.3-dispositif_technique.doc Page 3 sur 81

4 PARTIE I INTRODUCTION ET INFORMATIONS GENERALES V5.6.3-dispositif_technique.doc Page 4 sur 81

5 1 Introduction L objectif de ce document est triple : 1, brosser un descriptif général de l environnement technique du «Système d Analyse des Commandes» (SAC) de FIA-NET. Vous y trouverez aussi la cinématique d analyse entre votre système et le nôtre. 2, décrire les éléments nécessaires à son intégration sur votre site. Vous trouverez dans cette partie la structure des informations que vous devez nous renvoyer afin de faire fonctionner le SAC, ainsi que la façon de récupérer automatiquement notre analyse. 3, fournir un certain nombre d exemples de code à intégrer afin de permettre la redirection des informations nécessaires au bon fonctionnement du SAC, selon que votre site fonctionne en ASP, PHP ou que vous souhaitez utiliser des formulaires Javascript. ATTENTION : il est impératif que vous nous préveniez dès que vous aurez intégré ce code, afin que nous le testions ensemble sur notre URL de test, avant de procéder à la mise en vigueur définitive du détecteur de fraudes sur votre site. Si vous avez souscrit la garantie «commerçant adhérent», nous vous rappelons que les transactions postées sur l URL de test ne sont jamais garanties et ne pourront donc ouvrir droit à aucune indemnité d assurance au titre du présent contrat. Seules les transactions postées sur l URL de production sont susceptibles d être garanties sous réserve des dispositions de votre contrat (territorialité, exclusions, etc ) Notre équipe technique est à votre entière disposition (contacts en fin de documentation) pour détailler plus encore ce document ou vous aider à intégrer ce code dans vos pages. V5.6.3-dispositif_technique.doc Page 5 sur 81

6 2 Architecture générale Dans la mesure où nous souhaitons offrir un fort service, l emploi de serveurs construits dans cette optique ainsi que la redondance de tout matériel employé, réseau ou hardware, est inévitable. La sécurité est une composante essentielle de ce produit. L emploi de firewalls en redondance couplés avec des logiciels d alertes et un suivi régulier est obligatoire. De plus, la base de données est protégée spécifiquement par une seconde série de firewall différente des premiers (OS + matériel) Internet SSL SSL Administration VPN VPN DMZ DMZ Firewall Sas 1 failover Firewall Sas 2 Failover Public Load Balancer réseau en failover Base de données SQL en failover Serveur HTTP Baies de Disques Le schéma ci-dessus respecte les principes généraux de toute plate-forme web. Nous pouvons citer : scalabilité du matériel, équilibrage de charge, redondance du matériel, etc. Notons aussi la présence d une sonde DOS, Denial Of Service, absente du schéma. Les partenaires et les fournisseurs avec lesquels nous avons travaillé sont : SUN, CISCO, CheckPoint, Sybase, IBSolution (spécialiste en sécurité/réseau). Ces partenaires sont reconnus pour leur expertise dans leur domaine de compétences respectif. L hébergement se fait en salle blanche chez Interxion à Aubervilliers (93). Une ligne multi-homée à 2048 kbits/s chez Witbe assure la connectivité de cette plate-forme à Internet. Cette ligne permet de changer instantanément de fournisseur d accès en cas de problème de ce dernier. Les machines sont rangées dans nos propres baies (pas de mutualisation) et l accès à cette salle se fait sur liste restreinte. Tous les échanges de données entre FIA-NET et le marchand se font via le protocole SSL (chiffrement 128 bits). L administration des machines se fait sous VPN à partir de deux postes chez FIA-NET. V5.6.3-dispositif_technique.doc Page 6 sur 81

7 3 Intégration du Système d Analyse des Commandes 3.1 Comprendre le système L analyse d une transaction effectuée sur votre site se passe en quatre phases. Phase I : le marchand envoie les informations à notre système. Phase II : FIA-NET reçoit les informations et procède généralement à l évaluation du risque en quelques secondes : les résultats du SAC sont destinés au Back-Office du site marchand. Ces résultats n influent donc pas sur le processus de transaction du client, qui reste transparent pour lui. Nous ne bloquons en aucun cas la commande et le client n a pas à attendre les résultats du SAC pour valider la transaction. Ces informations sont destinées aux opérateurs du marchand qui décideront ou non de la mise en livraison. Si l analyse du risque se fait la plupart du temps en quelques secondes, le SAC n est toutefois pas un système conçu pour être utilisé en temps réel. Outre le fait qu il ne doit pas bloquer le processus de commande du consommateur, le système connaît aussi des périodes de maintenance, d interventions qui peuvent durer de quelques minutes à quelques heures (dans ce dernier cas, il s agit généralement d interventions de nuit). L important est que le commerçant récupère les réponses de FIA-NET avant la mise en livraison de ses articles. Phase III : Le marchand récupère le résultat de l analyse et prend une décision ou prend contact avec l internaute (ou confie cette prise de contact à FIA-NET dans le cadre de l option Contrôle Expert). Si la préparation de l envoi prend du temps, le marchand peut venir chercher le résultat de l analyse en cours juste avant la livraison (le résultat peut évoluer avec le temps) pour prendre éventuellement une nouvelle décision. Phase IV : Le marchand livre ou ne livre pas et envoie cette information (livraison / non-livraison) à FIA-NET. Phase V : le marchand déclare ses fraudes éventuelles à FIA-NET. Ci-dessous une cinématique d interconnexion entre le système marchand et le système FIA-NET. Première prise de décision du commerçant Décision finale du commerçant Site Web Paiement Commande Première demande d évaluation Traitement logistique de la commande Ceci peut prendre un certain nombre de jours durant lesquels les données de l internaute continuent d évoluer Dernière demande d évaluation Livraison à l internaute Informations livraison / non-livraison Fia-Net Les traitements se déroulent sur une dizaine de secondes et sont dès lors consultables Déclarations de fraude V5.6.3-dispositif_technique.doc Page 7 sur 81

8 3.2 Quand et comment envoyer les informations? Vous devez nous transmettre uniquement les transactions ayant passé correctement la phase de paiement. Dans le cas d un envoi pendant le processus de commande, celui-ci doit se trouver après la solution de paiement. Les informations qui sont envoyées correspondent à celles déposées sur votre bon de commande ainsi qu un certain nombre de données complémentaires (adresse IP, produits, livraison, etc.). Ce sont ces données que le SAC va analyser. Vous avez la possibilité de saisir manuellement dans notre Back-Office les transactions passées sur votre site ou d envoyer automatiquement (développement plus ou moins important de votre côté) vos données vers notre système. ATTENTION : l intégralité des informations fournies par l internaute lors de sa commande sur le site du marchand doit être envoyée au SAC en vue de leur analyse. Nous vous rappelons que l absence de l une de ces informations entraînera de plein droit la non-garantie de la transaction (Intercalaire «Commerçant Adhérent» Article «Transactions incomplètes»). Les balises <utilisateur>, <adresse>, <infocommande> et <paiement> comportent des balises obligatoires qui doivent être impérativement transmises pour permettre l analyse d une transaction. Les transactions transmises par le marchand qui ne comportent pas ces balises obligatoires seront systématiquement considérées par le SAC comme des transactions invalides. Nous vous rappelons que toute transaction définie par le «Système d Analyse des Commandes» comme «Transaction Invalide» ne pourra ouvrir droit à une quelconque indemnisation (Intercalaire «Commerçant Adhérent» Article «Transactions invalides»). 3.3 Quand et comment récupérer les informations? Le système traite rapidement les transactions mais un phénomène de «pile» peut apparaître à certains moments. Une fois l évaluation terminée, vous pouvez venir la consulter sur notre Back-Office ou récupérer la totalité de notre analyse automatiquement pour l intégrer à vos propres outils. Vous pouvez récupérer uniquement le niveau de validation de votre transaction pour l intégrer à vos outils et créer un lien automatique vers notre Back-Office pour afficher le détail de cette analyse. Le niveau de validation des transactions peut évoluer avec le temps en fonction de nouvelles données du système (déclaration de sinistre, transactions supplémentaires, analyses manuelles, ). Vous pouvez à tout moment venir consulter les dernières évaluations de vos transactions. Il est intéressant, par exemple, de consulter à nouveau le niveau de validation juste avant la mise en livraison. 3.4 Quand et comment envoyer l information sur la livraison? Lorsque vous avez pris votre décision finale de livrer ou de ne pas livrer, vous nous envoyez cette information. Vous pouvez le faire automatiquement, en envoyant un fichier ou en utilisant l interface de notre Back-Office. 3.5 Quand et comment envoyer l information sur les fraudes? Lorsque vous recevez une fraude (avis de débit de votre banque), vous nous envoyez cette information. Vous pouvez le faire automatiquement, en envoyant un fichier ou en utilisant l interface de notre Back-Office. 3.6 Quand et où tester l intégration? Pendant la première phase et à chaque fois que vous voulez tester la liaison entre nos systèmes et/ou le format des informations envoyées, vous devez utiliser notre système de pré-production qui se trouve à partir de l URL suivante : V5.6.3-dispositif_technique.doc Page 8 sur 81

9 3.7 Pays acceptés pour l analyse de vos transactions Le SAC permet d'évaluer la fiabilité d'une commande en provenance de ou vers les différents pays listés cidessous : Allemagne Autriche Belgique Bulgarie Chypre Danemark Espagne Estonie Finlande France (+DOM ; les TOM ne sont pas analysés) Grèce Hongrie Irlande Italie Lettonie Lituanie Luxembourg Malte Monaco Pays-Bas Pologne Portugal République Tchèque Roumanie Royaume-Uni Slovaquie Slovénie Suède Suisse Certains pays utilisent des caractères particuliers, nécessitant parfois un retraitement spécifique pour permettre nos analyses. Pour connaître précisément les valeurs acceptées et les éventuels retraitements effectués par le SAC, veuillez vous reporter aux sections : Annexe 2 : Format général des champs pour tous les pays et Annexe 3 : Format spécifique des champs par pays. V5.6.3-dispositif_technique.doc Page 9 sur 81

10 PARTIE II LES OUTILS TECHNIQUES V5.6.3-dispositif_technique.doc Page 10 sur 81

11 4 Envoi des informations du bon de commande Vous avez à votre disposition un grand nombre de solutions pour envoyer les informations nécessaires vers notre système. Vous pouvez soit envoyer ces informations pendant le processus de commande (on-line) en utilisant le navigateur de l internaute comme moyen d envoi des données, soit les envoyer indépendamment du processus de commande (off-line) par des traitements automatiques (batch) transaction par transaction ou en transactions groupées. Dans tous les cas, vous devez nous transmettre uniquement les transactions ayant passé correctement la phase de paiement. Dans le cas d un envoi «on-line», l envoi à notre système doit se trouver après la solution de paiement. Lorsque vous utilisez la méthode «on-line», vous avez à disposition un envoi en méthode «post» via le script redirect.cgi qui vous redirige vers la page suivante du processus de commande et un envoi en méthode «get» via le script singet.cgi qui renvoie une image vide sur la page où l appel est effectué. Lorsque vous utilisez la méthode «off-line», vous pouvez, bien entendu, utiliser les deux scripts indiqués cidessus ainsi que deux scripts, stacking.cgi et stackfast.cgi, permettant d envoyer plusieurs transactions en une fois. L envoi des données se fait toujours sous la forme d un flux au format XML comportant l ensemble des informations nécessaires à l analyse. Celui-ci est détaillé plus bas dans ce document. 4.1 Avantages et inconvénients des différentes méthodes Envoi «on-line» méthode POST Avantages : Facilité de mise en œuvre Pas de perte de données Inconvénients : Tributaire de l état du site SAC Visible par l internaute Dépendant du navigateur de l internaute Envoi «on-line» méthode GET Avantages : Facilité de mise en œuvre N interfère pas avec la navigation de l internaute Inconvénients : Certains navigateurs bloquent les ressources externes Perte de données Dépendant du navigateur de l internaute Envoi «off-line» Avantages : Pas de perte de données Grand contrôle sur les données N interfère pas avec la navigation de l internaute Non dépendant du navigateur de l internaute Inconvénients : Développement plus ou moins important V5.6.3-dispositif_technique.doc Page 11 sur 81

12 4.2 Envoi des informations «on-line» Intégration par méthode POST En bref L utilisateur passe de façon quasi-transparente sur le site FIA-NET entre deux pages du processus de commande. Cette redirection doit être intégrée après la page de paiement du prestataire bancaire dans le cas où ce dernier renvoie l internaute sur votre site après paiement. Le schéma d intégration du système FIA-NET en méthode POST doit ressembler au suivant : Site Marchand Page n Site Marchand Page n + 1 Avant intégration Fraud Screener Site FIA-NET XML Intégration Fraud Screener Redirection par url CallBack Techniquement L intégration de la méthode POST consiste à placer un formulaire sur la page n de votre site dans lequel la variable «controlcallback» est utilisée pour nous envoyer le flux XML de données. Formulaire de redirection à intégrer sur la page marchand : <form method= post action= > <input type= hidden name= siteid value= > <input type= hidden name= controlcallback value= > <input type= hidden name= urlcallback value= > <input type= hidden name= paracallback value= > </form> ATTENTION : Afin d effectuer les tests d intégration du système, vous devez impérativement utiliser l URL de pré-production. Le but est de tester la mise en place du système et le bon format des données envoyées. Pendant la phase de pré-production le formulaire doit être le suivant : <form method= post action= > <input type= hidden name= siteid value= > <input type= hidden name= controlcallback value= > <input type= hidden name= urlcallback value= > <input type= hidden name= paracallback value= > </form> Les différentes variables d entrée sont : siteid : controlcallback : urlcallback : paracallback : Identifiant numérique du site fourni par FIA-NET Flux XML contenant l ensemble des informations pour l analyse (détail plus loin) URL de la page de retour vers le site marchand Flux XML contenant les paramètres qui seront retournés sur l URL de retour V5.6.3-dispositif_technique.doc Page 12 sur 81

13 Le paramètre «paracallback» est de la forme suivante : <!DOCTYPE ParamCBack [ <!ELEMENT ParamCBack (obj)+> <!ELEMENT obj(name, value)> <!ELEMENT name (#PCDATA)> <!ELEMENT value (#PCDATA)> <ParamCBack> <obj> <name>xxxx</name> <value>xxx</value> </obj> <obj> </obj> </ParamCBack> Chaque ensemble <obj> </obj> représente une variable que vous voulez recevoir en retour, où <name> donne le nom de cette variable et <value> sa valeur. Exemple : <ParamCBack> <obj> <name>sessionid</name> <value>azertyuip45ofgsdfh046</value> </obj> <obj> <name>montant</name> <value>12,25</value> </obj> </ParamCBack> Encodage des informations: Pour envoyer les variables controlcallback et paracallback, vous devez au préalable les encoder au format URL afin de ne pas avoir de problème de transmission de données. V5.6.3-dispositif_technique.doc Page 13 sur 81

14 4.2.2 Intégration par méthode GET En bref L envoi est effectué soit sur la page n du marchand grâce à une balise <img>, soit à l intérieur du script de la page via l appel à un programme de connexion http. Dans le premier cas, sur la page HTML est placée une balise <img> dont l URL est l appel à notre script qui simule en retour une image vide. En revanche, certains navigateurs offrent la possibilité de bloquer les «webtags» (récupération de ressource externe) et empêchent ce système de fonctionner. Dans ce cas, vous pouvez utiliser l autre méthode. Pour pallier ce problème ou contrôler l envoi d information, vous pouvez utiliser les programmes de connexion http suivants : HTTPConnect pour les systèmes Windows, wget ou curl pour les systèmes UNIX, LINUX ou MacOSX. Ainsi l envoi du flux est exécuté et géré par le serveur et ne dépend plus des spécificités du navigateur de l internaute. Ces deux méthodes d appel offrent une plus grande facilité d intégration mais comportent une limitation sur la taille des informations renvoyées à 2048 caractères. Le schéma d intégration du système FIA-NET en méthode GET doit ressembler au suivant : Site Marchand Page n Site FIA-NET XML Intégration Fraud Screener Techniquement L URL du script appelé est la suivante : &controlcallback= ATTENTION : Afin d effectuer les tests d intégration du système, vous devez impérativement utiliser l URL de pré-production. Le but est de tester la mise en place du système et le bon format des données envoyées. Pendant la phase de pré-production l URL du script appelé est la suivante : &controlcallback= Les différentes variables d entrée sont : siteid : controlcallback : Identifiant numérique du site fourni par FIA-NET Flux XML contenant l ensemble des informations pour l analyse (detail plus loin) Encodage des informations: Pour envoyer la variable controlcallback, vous devez au préalable l encoder au format URL afin de ne pas avoir de problème de transmission de données. V5.6.3-dispositif_technique.doc Page 14 sur 81

15 4.3 Envoi des informations «off-line» Pour ne pas impacter l interface internaute et/ou contrôler au mieux les informations envoyées, vous pouvez préférer envoyer vos informations de façon différée au processus de paiement. En utilisant cette méthode, vous contrôlez aussi que les transactions envoyées sont réellement validées sur votre système. Vous pouvez par exemple, faire l envoi à partir de votre Back-Office sur demande de vos opérateurs, ou envoyer uniquement toutes les deux heures l ensemble des transactions effectuées Les interrogations se font, par exemple, en utilisant des utilitaires de type wget ou curl. Vous pouvez décider d envoyer les transactions une à une ou bien créer des paquets (au maximum 25 transactions par paquet). Les deux scripts permettant l envoi des transactions par paquets fonctionnent sur le principe d un envoi en méthode GET et retournent une réponse sur la bonne, ou mauvaise, réception de notre système. Le premier (stacking.cgi) effectue, contrairement aux autres, une pré-analyse sur le format des champs Transaction par transaction Lorsque vous décidez d envoyer chaque transaction séparément, vous pouvez bien entendu, utiliser les deux méthodes de l envoi «on-line» (ci-dessus), c est-à-dire utiliser les scripts «singet.cgi» ou «redirect.cgi». Vous pouvez aussi utiliser les scripts permettant d envoyer les transactions par paquets et qui sont définis cidessous Transactions groupées, script «stacking.cgi» En bref Ce script reçoit les transactions par paquets (au maximum 25 transactions par paquet), analyse rapidement le formatage des différents champs et vous retourne un flux XML qui vous donne pour chaque transaction le résultat de ce diagnostic. Ce script peut prendre un peu plus de temps que le suivant (stackfast.cgi). Si le détail de la réception transaction par transaction ne vous intéresse pas, vous avez intérêt à utiliser «stackfast.cgi». Attention! Si le flux regroupant l ensemble des transactions n est pas valide (non compréhensible par un parseur XML), la totalité du paquet sera rejetée. Si vous décidez d utiliser ce script, vous devez nous contacter au préalable pour que nous vous autorisions à faire des envois par paquets. Techniquement L URL du script appelé est la suivante : &controlcallback= ATTENTION : Afin d effectuer les tests d intégration du système, vous devez impérativement utiliser l URL de pré-production. Le but est de tester la mise en place du système et le bon format des données envoyées. Pendant la phase de pré-production l URL du script appelé est la suivante : &controlcallback= Les différentes variables d entrée sont : siteid : controlcallback : Identifiant numérique du site fourni par FIA-NET Flux XML contenant l ensemble des informations pour l analyse (détail plus loin) La balise principale du flux «controlcallback» devient alors <stack> </stack> et englobe les différentes transactions (<control> </control>). V5.6.3-dispositif_technique.doc Page 15 sur 81

16 Encodage des informations: Pour envoyer la variable controlcallback, vous devez au préalable l encoder au format URL afin de ne pas avoir de problème de transmission de données. Réponse du script : <?xml version="1.0" encoding="iso "?> <validstack> <result site= refid= avancement= encours error > <detail>detail sur la réception et/ou sur l erreur</detail> </result> <result> </result> </validstack> Exemple : <?xml version="1.0" encoding="iso "?> <validstack> <result site= 678 refid= TEST_001 avancement= encours > <detail>flux xml validé </detail> </result> <result site= 678 refid= TEST_002 avancement= error > <detail>code postal non numérique </detail> </result> <result site= 678 refid= TEST_003 avancement= encours > <detail>flux xml validé </detail> </result> </validstack> Transactions groupées, script «stackfast.cgi» En bref Ce script reçoit les transactions par paquets (au maximum 25 transactions par paquet), et renvoie le nombre de transactions inscrites. Le format des données n est pas analysé, il est donc possible que certaines transactions soient invalides. ATTENTION : Si le flux regroupant l ensemble des transactions n est pas valide (non compréhensible par un parseur XML), la totalité du paquet sera rejetée. Si vous décidez d utiliser ce script, vous devez nous contacter au préalable pour que nous vous autorisions à faire des envois par paquets. Techniquement L URL du script appelé est la suivante : &controlcallback= ATTENTION : Afin d effectuer les tests d intégration du système, vous devez impérativement utiliser l URL de pré-production. Le but est de tester la mise en place du système et le bon format des données envoyées. Pendant la phase de pré-production l URL du script appelé est la suivante : &controlcallback= Les différentes variables d entrée sont : siteid : controlcallback : Identifiant numérique du site fourni par FIA-NET Flux XML contenant l ensemble des informations pour l analyse (détail plus loin) V5.6.3-dispositif_technique.doc Page 16 sur 81

17 La balise principale du flux «controlcallback» devient alors <stack> </stack> et englobe les différentes transactions (<control> </control>). Encodage des informations : Pour envoyer la variable controlcallback, vous devez au préalable l encoder au format URL afin de ne pas avoir de problème de transmission de données. Réponse du script : <?xml version="1.0" encoding="iso "?> <validstack> <result site= avancement= encours error > <detail>detail sur la réception et/ou sur l erreur du paquet</detail> </result> </validstack> Exemple : <?xml version="1.0" encoding="iso "?> <validstack> <result site= 678 avancement= encours > <detail>3 transactions réceptionnées</detail> </result> </validstack> V5.6.3-dispositif_technique.doc Page 17 sur 81

18 4.4 Flux XML contenant les informations : flux <control> En bref L intégralité des informations fournies par l internaute lors de sa commande sur le site du marchand doit être envoyée au SAC en vue de leur analyse. Nous vous rappelons que l absence de l une de ces informations entraînera de plein droit la non-garantie de la transaction (Intercalaire «Commerçant Adhérent» Article «Transactions incomplètes»). Les balises <utilisateur>, <adresse> <infocommande> et <paiement> comportent des balises obligatoires qui doivent être impérativement transmises pour permettre l analyse d une transaction. Les transactions transmises par le marchand qui ne comportent pas ces balises obligatoires seront systématiquement considérées par le SAC comme des transactions invalides. Nous vous rappelons que toute transaction définie par le «Système d Analyse des Commandes» comme «Transaction Invalide» ne pourra ouvrir droit à une quelconque indemnisation (Intercalaire «Commerçant Adhérent» Article «Transactions invalides»). La balise <control> </control> englobe l ensemble des informations concernant une transaction. Lorsque les transactions sont envoyées par paquets (scripts «stacking.cgi» et «stackfast.cgi»), la balise <stack> </stack> englobe l ensemble des transactions (balises <control> </control>). Définition du flux <control> Voici la définition (format DTD donné pour information non-exploitable directement) du flux qui contient l ensemble des informations pour une transaction. Vous trouverez des exemples de flux en annexe de cette documentation. <!DOCTYPE control [ <!ELEMENT control (utilisateur+, adresse+, infocommande, paiement?)> <!ELEMENT utilisateur (nom, prenom?, societe?, telhome, teloffice?, telmobile?, fax?, , siteconso? )> <!ATTLIST utilisateur type (facturation livraison) #REQUIRED> <!ATTLIST utilisateur qualite (1 2) #REQUIRED <!ELEMENT nom (#PCDATA)> <!ATTLIST nom titre (monsieur madame mademoiselle) > <!ELEMENT prenom (#PCDATA)> <!ELEMENT societe (#PCDATA)> <!ELEMENT telhome (#PCDATA)> <!ELEMENT teloffice (#PCDATA)> <!ELEMENT telmobile (#PCDATA)> <!ELEMENT fax (#PCDATA)> <!ELEMENT (#PCDATA)> <!ELEMENT siteconso (nb?, ca?, datepremcmd?, datederncmd?)> <!ELEMENT nb (#PCDATA)> <!ELEMENT ca (#PCDATA)> <!ELEMENT datepremcmd (#PCDATA)> <!ELEMENT datederncmd (#PCDATA)> <!ELEMENT adresse (rue1, rue2?, cpostal, ville, pays, appartement?)> <!ATTLIST adresse type (facturation livraison) #REQUIRED> <!ATTLIST adresse format (1) #REQUIRED> <!ELEMENT rue1 (#PCDATA)> <!ELEMENT rue2 (#PCDATA)> <!ELEMENT cpostal (#PCDATA)> <!ELEMENT ville (#PCDATA)> <!ELEMENT pays (#PCDATA)> <!ELEMENT appartement (digicode1?, digicode2?, batiment?, escalier?, etage?, nporte?)> <!ELEMENT digicode1 (#PCDATA)> <!ELEMENT digicode2 (#PCDATA)> <!ELEMENT escalier (#PCDATA)> <!ELEMENT etage (#PCDATA)> <!ELEMENT nporte (#PCDATA)> <!ELEMENT infocommande (siteid, refid, montant, ip?, transport?, list?, saisiecommande?)> <!ELEMENT siteid (#PCDATA)> <!ELEMENT refid (#PCDATA)> V5.6.3-dispositif_technique.doc Page 18 sur 81

19 <!ELEMENT transport(type, nom?, rapidite, pointrelais?)> <!ELEMENT type (#PCDATA)> <!ELEMENT nom(#pcdata)> <!ELEMENT rapidite (#PCDATA)> <!ELEMENT pointrelais (identifiant?, enseigne?, adresse?)> <!ELEMENT identifiant (#PCDATA)> <!ELEMENT enseigne (#PCDATA)> <!ELEMENT list (produit +)> <!ATTLIST list nbproduit CDATA #REQUIRED> <!ELEMENT produit(#pcdata)> <!ATTLIST produit type CDATA> <!ATTLIST produit ref CDATA> <!ATTLIST produit nb CDATA> <!ATTLIST produit classement CDATA> <!ATTLIST produit prixunit CDATA> <!ELEMENT montant (#PCDATA)> <!ATTLIST montant devise CDATA #REQUIRED> <!ELEMENT ip (#PCDATA)> <!ATTLIST ip timestamp CDATA #REQUIRED> <!ELEMENT saisiecommande (#PCDATA)> <!ATTLIST saisiecommande type ( ) #REQUIRED> <!ELEMENT paiement (type, bin?, numcb?, dateval?, bin4?, bin42?, nom?)> <!ELEMENT type(#pcdata)> <!ELEMENT bin (#PCDATA)> <!ELEMENT numcb (#PCDATA)> <!ELEMENT dateval (#PCDATA)> <!ELEMENT bin4 (#PCDATA)> <!ELEMENT bin42 (#PCDATA)> ]> Les différentes balises : obligation / description Nous listons ici le détail des différents champs intervenant dans la structure <control>. Les règles de formatage par pays de ces différentes balises se trouvent dans l annexe de ce document. Balise <control> La balise <control> décrit les informations relatives à la transaction. Elle comprend au minimum une balise <utilisateur>, une balise <adresse>, une balise <infocommande> et une balise <paiement>. <utilisateur> : <adresse> : <infocommande> : <paiement> : Obligatoire / Informations sur l utilisateur (existe en double s il y a un utilisateur de facturation et un utilisateur de livraison) Obligatoire / Informations sur l adresse (existe en double s il y a une adresse de facturation et une adresse de livraison) Obligatoire / Informations sur la commande Obligatoire / Informations sur le paiement V5.6.3-dispositif_technique.doc Page 19 sur 81

20 Balise <utilisateur> : Informations sur le ou les utilisateurs Propriété «type» : Obligatoire / facturation livraison / Indique de quel utilisateur il s agit («facturation» dans le cas où il n y a qu un utilisateur) Propriété «qualite» : Obligatoire / 1 2 / Indique s il s agit d une entreprise (1) ou d un particulier (2) <nom> : Obligatoire / Nom de l utilisateur propriété «titre» de <nom> : Civilité de l utilisateur (ex : monsieur) <prenom> : Prénom de l utilisateur / obligatoire si l internaute l a fourni <societe> : Société de l utilisateur / obligatoire si l internaute l a fourni <telhome> : Numéro de téléphone personnel / obligatoire si l internaute l a fourni <teloffice> : Numéro de téléphone professionnel (ou second numéro) / obligatoire si l internaute l a fourni <telmobile> : Numéro de téléphone portable (mobile) / obligatoire si l internaute l a fourni <telfax> : Numéro de fax / obligatoire si l internaute l a fourni < > : Adresse de l utilisateur / obligatoire si l internaute l a fourni <siteconso> : Bloc d informations sur l historique de consommation de l utilisateur, fourni par le site marchand. Balise <siteconso> : Informations sur la consommation de l utilisateur sur le site marchand. Note : <nb> : <ca> : <datepremcmd> : <datederncmd> : Cette balise fait partie de la balise <utilisateur>. Elle ne doit pas être employée en dehors. Les informations contenues dans la balise sont facultatives. Si le site marchand en dispose, il est toutefois utile de les transmettre afin d obtenir des scores plus précis. Nombre d achats effectués par l utilisateur avant la transaction en cours, sur le site marchand en question. Montant total des achats effectués par l utilisateur avant la transaction en cours, sur le site marchand en question, dans la même devise que la commande en cours. Date et heure (voir le format ci-dessous) de la première commande de l utilisateur sur le site marchand en question. Date et heure (voir le format ci-dessous) de la dernière commande de l utilisateur sur le site marchand en question. Par «dernière commande», on entend la dernière commande avant la commande courante. Balise <adresse> : Informations sur la ou les adresses Propriété «type» : Obligatoire / facturation livraison / Indique de quelle adresse il s agit («facturation» dans le cas où il n y a qu une adresse) Propriété «format» : Obligatoire / 1 / Cette propriété est présente pour un usage ultérieur. Vaut «1» <rue1> : <rue2> : <cpostal> : <ville> : <pays> : <appartement> : Obligatoire / Numéro et nom de la rue Suite et/ou détail de l adresse Obligatoire / Code postal Obligatoire / Ville Obligatoire / Pays (ex : France) (cf. section 1.1 pour la liste des pays disponibles) Précision sur l emplacement de l appartement (décrit plus loin) V5.6.3-dispositif_technique.doc Page 20 sur 81

21 Balise <appartement> : Informations relatives aux immeubles collectifs (optionnelle) <digicode1> : Digicode <digicode2> : Second digicode <escalier> : Indicatif de l escalier (ex : F) <etage> : Numéro d étage (ex : 3) <nporte> : Numéro de porte (ex : 31) <batiment> : Indicatif du bâtiment (ex : A) ATTENTION : lors de commandes avec livraison en magasin (cf. page suivante, type de transport 1 : retrait chez le marchand) ou via des points-retrait tiers (type de transport 2 : Kiala, Alveol, etc.) ou encore dans le cas de retrait en gare, aéroport ou agence de voyage (type de transport 3), les informations de livraison (utilisateur et adresse) ne doivent pas être communiquées à FIA-NET pour analyse, car ces points de vente/retrait ne correspondent pas à la véritable adresse du client. C'est en renseignant le type du transport (cf. balise <transport>) que vous nous indiquez si un mode de retrait a été utilisé. Le non respect de ce point peut entraîner une augmentation des transactions non assurées (en créant une multitude de clients ayant une même adresse 'physique' de livraison - autrement dit celle du magasin ou du point de retrait - ) et fausse les informations personnelles de vos clients analysés par le système. Balise <infocommande> : Informations sur la transaction <siteid> : Obligatoire / Identifiant numéro du site fourni par FIA-NET <refid> : Obligatoire / Référence interne du marchand pour la commande <montant> : Obligatoire / Montant de la transaction propriété «devise» de <montant> : Obligatoire / Devise de la transaction (ex : EUR) <ip> : Obligatoire / Adresse IP de l internaute (Attention! Cette adresse IP fournie ne doit pas être celle du serveur qui envoie les données vers notre système) propriété «timestamp» de <ip> : Obligatoire / Heure de la récupération de l adresse IP <transport> : Obligatoire / Informations sur le transport (décrit plus loin) <list> : Obligatoire / Liste des produits de la commande (décrit plus loin) <saisiecommande> : Obligatoire si disponible / Libellé associé au contexte de saisie de la commande Propriété «type» de <saisiecommande> : Obligatoire / Indique le contexte de saisie de la commande effectuée par un acheteur. Types de contextes de saisie : 1 : Commande sur Internet 2 : Commande en guichet magasin 3 : Commande sur borne électronique en magasin 4 : Commande via centre d appel téléphonique 5 : Commande via téléphone mobile Balise <transport> : Informations sur le transport <type> : Obligatoire / / Type de transport choisi (détail ci-dessous) <nom> : Obligatoire / Libellé de la boutique, du transporteur, du réseau de points-retrait, <rapidite> : Obligatoire / 1 2 / Rapidité de livraison - 1 : Express (- de 24 heures) 2 : Standard <pointrelais> : Obligatoire si disponible / Informations sur le point de retrait du réseau du marchand (type de transport 1), ou sur le point-relais du réseau de points-relais (type 2), ou sur le point retrait de type voyagiste (type 3). Types de transport : 1 : Retrait de la marchandise chez le marchand 2 : Utilisation d'un réseau de points-retrait tiers (type kiala, alveol, etc.) 3 : Retrait dans un aéroport, une gare ou une agence de voyage 4 : Transporteur (La Poste, Colissimo, UPS, DHL... ou tout transporteur privé) 5 : Emission d un billet électronique, téléchargements V5.6.3-dispositif_technique.doc Page 21 sur 81

22 Balise <pointrelais> : Informations sur le point de retrait <identifiant> : <enseigne> : <adresse> : Obligatoire si disponible / Libellé technique de l identifiant du point retrait tel qu utilisé ou fourni par le réseau employé Obligatoire si disponible / Libellé de l enseigne (boutique en propre, enseigne du point relais, enseigne du comptoir aéroport ) Obligatoire si disponible / Informations sur l adresse Balise <adresse> : Informations sur le point de retrait <rue1> : <rue2> : <cpostal> : <ville> : <pays> : Numéro et nom de la rue Suite et/ou détail de l adresse Obligatoire / Code postal Obligatoire / Ville Obligatoire / Pays Attention : lors de commandes avec livraison en magasin (type de transport 1 : retrait chez le marchand) ou via des points-retrait tiers (type de transport 2 : Kiala, Alveol, etc.) ou encore dans le cas de retrait en gare, aéroport ou agence de voyage (type de transport 3), les informations de livraison (utilisateur et adresse) doivent absolument, le cas échéant, être communiquées à FIA-NET dans la balise <pointrelais> pour analyse, mais jamais en adresse utilisateur livraison car ces points de vente/retrait ne correspondent pas à la véritable adresse du client. Le non respect de ce point peut entraîner une augmentation des transactions non assurées (en créant une multitude de client ayant une même adresse 'physique' de livraison - autrement dit celle du magasin ou du point de retrait - ) et fausse les informations personnelles de vos clients analysés par le système. Balise <list> : Listes des produits de la commande Propriété «nbproduit» : Indique le nombre total des produits de la commande <produit> : Obligatoire / Intitulé du produit propriété «classement» de <produit> : Code rayon ou classement interne du produit chez le marchand propriété «type» de <produit> : Obligatoire / Numéro de catégorie générale du produit (détail ci-dessous) propriété «ref» de <produit> : Obligatoire / Référence interne du marchand pour le produit propriété «nb» de <produit> : Nombre de produits identiques propriété «prixunit» de <produit> : Facultatif, indique le prix unitaire du produit, dans la même devise que le montant de la commande. Catégories générales de produits : 1 : Alimentation & Gastronomie 2 : Auto & Moto 3 : Culture & Divertissements 4 : Maison & Jardin 5 : Electroménager 6 : Enchères et Achats groupés 7 : Fleurs & Cadeaux 8 : Informatique & Logiciels 9 : Santé & Beauté 10 : Services aux particuliers 11 : Services aux professionnels 12 : Sport 13 : Vêtements & Accessoires 14 : Voyage & Tourisme 15 : Hifi, Photo & Vidéos 16 : Téléphonie & Communication 17 : Bijoux & Métaux précieux 18 : Articles et Accessoires pour bébé 19 : Sonorisation & Lumière Le marchand peut envoyer l ensemble des informations mais peut aussi ne pas renseigner la référence et/ou le type de catégorie du produit. V5.6.3-dispositif_technique.doc Page 22 sur 81

23 Balise <paiement> : Informations sur le paiement et données bancaires <type> : <nom> : <numcb> : <dateval> : <bin> : <bin4> : <bin42> : Obligatoire / carte cheque contre-remboursement virement cb en n fois paypal 1euro.com / Type du paiement Nom de carte privative marchand Numéro de carte hashé en MD5 (sans caractère de séparation avant hashage)* Date de validité hashée en MD5 (date au format MM/YYYY avant hashage)* 6 premiers chiffres (non hashés) du numéro de carte* 4 premiers chiffres (non hashés) du numéro de carte* (à indiquer si vous possédez uniquement les 4 premiers chiffres et non si vous connaissez les 6 premiers ou les 2 derniers) 4 premiers chiffres (non hashés) du numéro de carte + 2 derniers chiffres (non hashés) de la carte au format XXXX-XX * *obligatoire si le site en dispose Les deux tags numcb et dateval sont hachés à l aide d un algorithme MD5 dont la clef est spécifique à FIA- NET. Cette clef vous sera fournie sur demande. V5.6.3-dispositif_technique.doc Page 23 sur 81

24 5 Récupération de l analyse Une fois l analyse effectuée, vous avez la possibilité de venir consulter le résultat de celle-ci de plusieurs manières. Le système analyse, en général, une transaction en moins de dix secondes, mais un phénomène de «pile» peut apparaître à certains moments de la journée, augmentant cette durée. Si vous récupérez les informations de façon automatique, nous vous conseillons d attendre environ cinq minutes après l envoi d information avant de récupérer notre évaluation pour être presque sûr d obtenir un résultat. En outre, le système connaît aussi des périodes de maintenance, d interventions qui peuvent durer de quelques minutes à quelques heures (dans ce dernier cas, il s agit généralement d interventions de nuit). L important est que le commerçant récupère les réponses de FIA-NET avant la mise en livraison de ses articles. Certaines de ces pauses sont hebdomadaires et correspondent à notre maintenance récurrente. Il s agit des périodes suivantes : Du lundi au dimanche, sauvegarde quotidienne de la base de données de 0h15 à 1h du matin environ ; Le samedi et lundi, sauvegarde additionnelle de 7h00 à 7h45, le dimanche de 12h à 12h45 ; Les calculs d évaluation sont également fortement ralentis pendant différents traitements ayant lieu le samedi, dimanche et lundi de 1h à 3h du matin. Ces traitements se prolongent le dimanche jusqu à 4h30 du matin ; Enfin, nous chargeons certaines informations de la table hebdomadairement pour maintenir le système avec les données les plus récentes possible : ces chargements ralentissent les évaluations pendant 10 minutes environ le mardi à 13h20 et 20 minutes environ le mercredi à 13h20. Ceci signifie qu il n est pas utile de développer un processus de récupération de l analyse en temps réel, ou de relancer instantanément les requêtes en cas d absence de réponse, pendant les périodes de maintenance du système. Il vous suffit d indexer les requêtes de récupération sur votre rythme de mise en livraison, par exemple une ou deux fois par jour si vous faites une préparation d expédition par jour. La méthode la plus simple pour consulter notre évaluation est de venir vous connecter directement sur notre Back-Office ( en production ou en pré-production). Vous avez aussi la possibilité d effectuer une connexion automatique à partir de votre Back-Office sur notre page résumant l analyse pour une transaction (recommandé). Dans ce cas, vous pouvez dans un premier temps, récupérer, dans un flux XML, uniquement le niveau de validation pour l intégrer à vos outils ; le lien en connexion automatique permettra ensuite d afficher le détail de cette analyse. Vous pouvez encore récupérer dans un flux XML l ensemble du détail de notre évaluation afin de l intégrer directement dans votre Back-Office. Si vous n utilisez pas l ensemble des informations renvoyées, il est conseillé de récupérer uniquement le niveau de validation et de l associer avec un lien automatique vers le détail de la transaction. En effet, le Système d Analyse des Commandes a vocation à évoluer dans le temps pour toujours suivre au plus près les tentatives de fraudes. Le flux XML détaillé que nous vous adressons est donc susceptible d évoluer régulièrement. Si vous souhaitez récupérer la totalité de ce flux, vous serez donc contraint de faire des mises à jour régulières pour pouvoir interpréter les nouvelles analyses FIA-NET. Un lien vers le détail de la transaction est donc le moyen le plus simple d être à jour au niveau du détail des analyses FIA-NET. Attention, si vous décidez d utiliser une évaluation customisée, le contenu du flux XML envoyé devra être modifié : des balises supplémentaires seront insérées pour vous donner, en complément le résultat d évaluation qui aurait été obtenue sans customisation. Ces modifications sont décrites dans la section structure. Le Système d Analyse des Commandes (SAC) peut faire évoluer le niveau d évaluation des transactions en fonction de nouvelles données (transactions multiples, réutilisation de données, mises à jour FIA-NET, ) : il s agit de réévaluations. Lorsque vous utilisez régulièrement notre Back-Office, vous pouvez consulter les alertes de réévaluation directement à partir du menu principal. Vous avez aussi la possibilité de venir régulièrement et automatiquement chercher celles-ci ainsi que de recevoir des mails pour vous informer de ces réévaluations. V5.6.3-dispositif_technique.doc Page 24 sur 81

25 5.1 Connexion automatique au Back-Office FIA-NET En bref Vous pouvez créer un lien à partir de votre Back-Office qui pointe directement sur notre page qui résume notre évaluation avec connexion automatique (auto-login). En utilisant cette solution, vous n avez pas de mise à jour à faire lorsque nous ajoutons des fonctionnalités ou faisons des modifications structurelles. La page visitée est le cœur de notre Back-Office et est donc toujours maintenue par rapport aux évolutions. Recommandé : vous pouvez, dans un premier temps, récupérer uniquement le niveau de validation global de la transaction (point suivant 5.2) pour l intégrer à vos outils et mettre en place le lien en auto-login décrit ici pour afficher le détail de cette analyse. Techniquement L URL de la page appelée est la suivante : &log= &pwd= &rid= ATTENTION : lorsque vous effectuez les tests d intégration du système, vous devez impérativement utiliser l URL de pré-production. Pendant la phase de pré-production l URL de la page appelée est la suivante : &log= &pwd= &rid= Les paramètres d entrée sont : sid : log : pwd : rid : Identifiant numérique du site fourni par FIA-NET Login utilisé pour se connecter sur le système FIA-NET Mot de passe utilisé pour se connecter sur le système FIA-NET (url-encodé) Référence interne du marchand pour la transaction demandée (case sensitive) Encodage des informations: Pour envoyer le mot de passe (pwd), vous devez au préalable l encoder au format URL afin de ne pas avoir de problème de transmission de données. La référence (rid) demandée doit être au même format (majuscules/minuscules) qu à l envoi d informations 5.2 Récupération de l analyse : transaction par transaction Vous pouvez récupérer notre analyse pour chaque transaction postée sur notre système. Vous avez la possibilité d effectuer une interrogation de type méthode GET, ou de type méthode POST. Le fonctionnement est le même pour les deux, le deuxième vous retournant dans la page indiquée une variable (result) contenant notre réponse. Pour la méthode GET, vous pouvez utiliser des utilitaires tels que wget ou curl. Recommandé : en récupérant le mode «mini», vous pouvez récupérer uniquement le niveau de validation global dans votre Back-Office et créer un lien en connexion automatique (point précédent 5.1) pour afficher le détail de l analyse Récupération du flux en méthode GET En bref Ce script permet de récupérer directement un flux XML <result> contenant l ensemble des critères de notre analyse (mode «full») ou uniquement le niveau de validation (mode «mini»). Il existe un mode «help» qui vous permet d obtenir une explication sur certaines valeurs numériques (voir en annexe). ATTENTION : seul le mode «full» permet, dans le cas de l activation d une évaluation customisée, de récupérer aussi l évaluation «standard», qui aurait été obtenue sans customisation. V5.6.3-dispositif_technique.doc Page 25 sur 81

26 Techniquement L URL du script appelé est la suivante : &Pwd= &RefID= &Mode= &RepFT= ATTENTION : lorsque vous effectuez les tests d intégration du système, vous devez impérativement utiliser l URL de pré-production. Pendant la phase de pré-production l URL du script appelé est la suivante : &Pwd= &RefID= &Mode= &RepFT= Les paramètres d entrée sont : SiteID : Pwd : RefID : Mode : RepFT : Identifiant numérique du site fourni par FIA-NET Mot de passe utilisé pour se connecter sur le système FIA-NET (url-encodé) Référence interne du marchand pour la transaction demandée (case sensitive) Mode d appel du script - full (par défaut, tout), mini (validation seule) ou help (affichage de l aide) (optionnel) Affichage ( 1 ) ou non ( 0, par défaut) de la réponse FT (optionnel) Encodage des informations: Pour envoyer le mot de passe (Pwd), vous devez au préalable l encoder au format URL afin de ne pas avoir de problème de transmission de données. Retour du script: Le retour de ce script est un flux XML <result> qui détaille notre analyse. En cas d erreur de votre part, ou du script, ou d une transaction invalide, le flux vous donne le détail. (détail plus loin) ATTENTION : si plusieurs flux <result> sont retournés, la transaction a probablement fait l objet d une soumission doublonnée (voir valeur de l attribut count ). Ce retour multiple est significatif d'une anomalie de soumission (transactions doublonnées). Dans ce cas, la quantité de flux <result> retournés par le script get_validation.cgi est fonction du type de retour spécifié lors de l appel au script (full / mini). Les limites sont les suivantes : 15 références (ou flux <result>) maximum en cas de retour souhaité en mode full ; Exemples: 50 références (ou flux <result>) maximum en cas de retour souhaité en mode mini. Vous trouverez en annexe, des exemples d appel du script, de réponses de ce script pour les modes «full» et «mini» ainsi qu une extraction d une partie du mode «help» Récupération du flux en méthode POST En bref Ce script permet de récupérer dans une autre page (indiquée dans l appel) un flux XML <result> contenant l ensemble des critères de notre analyse (mode «full») ou uniquement le niveau de validation (mode «mini»). Il existe un mode «help» qui vous permet d obtenir une explication sur certaines valeurs numériques (voir en annexe). V5.6.3-dispositif_technique.doc Page 26 sur 81

27 Techniquement L URL du script appelé est la suivante : &Pwd= &RefID= &Mode= &RepFT= &urlback= ATTENTION : lorsque vous effectuez les tests d intégration du système, vous devez impérativement utiliser l URL de pré-production. Pendant la phase de pré-production l URL du script appelé est la suivante : &Pwd= &RefID= &Mode= &RepFT= &urlback= Les paramètres d entrée sont : SiteID : Pwd : RefID : Mode : RepFT : urlback : Identifiant numérique du site fourni par FIA-NET Mot de passe utilisé pour se connecter sur le système FIA-NET (url-encodé) Référence interne du marchand pour la transaction demandée (case sensitive) Mode d appel du script - full (par défaut, tout), mini (validation seule) ou help (affichage de l aide) (optionnel) Affichage ( 1 ) ou non ( 0, par défaut) de la réponse FT (optionnel) URL de la page sur laquelle la réponse est redirigée. Encodage des informations: Pour envoyer le mot de passe (Pwd), vous devez au préalable l encoder au format URL afin de ne pas avoir de problème de transmission de données. Retour du script: Le retour de ce script est contenu dans la variable «result» du formulaire (POST) soumis à votre page indiquée dans urlback. Ce retour est un flux XML <result> qui détaille notre analyse. En cas d erreur de votre part, du script, ou d une transaction invalide, le flux vous donne le détail. (détail plus loin) ATTENTION : si plusieurs flux <result> sont retournés, la transaction a probablement fait l objet d une soumission doublonnée (voir valeur de l attribut count ). Ce retour multiple est significatif d'une anomalie de soumission (transactions doublonnées). Dans ce cas, la quantité de flux <result> retournés par le script get_validation.cgi est fonction du type de retour spécifié lors de l appel au script (full / mini). Les limites sont les suivantes : 15 références (ou flux <result>) maximum en cas de retour souhaité en mode full ; Exemples: 50 références (ou flux <result>) maximum en cas de retour souhaité en mode mini. Vous trouverez en annexe, des exemples d appel du script, de réponses de ce script pour les modes «full» et «mini» ainsi qu une extraction d une partie du mode «help». 5.3 Récupération de l analyse : transactions par paquets Vous pouvez récupérer l analyse de plusieurs transactions dans le même appel. Vous avez alors le choix de demander l évaluation d une liste de références ou de demander l évaluation de toutes les transactions passées dans une journée. Pour utiliser ce script, vous pouvez recourir à des outils tels que wget ou curl. Une balise <stack> </stack> englobe l ensemble des flux <result> </result> (résultat de l analyse par transaction). V5.6.3-dispositif_technique.doc Page 27 sur 81

28 5.3.1 Récupération par liste de références En bref Ce script permet de récupérer directement un flux XML <stack> contenant l ensemble des critères de notre analyse pour chaque transaction (mode «full») ou uniquement le niveau de validation (mode «mini»). Il existe un mode «help» qui vous permet d obtenir une explication sur certaines valeurs numériques (voir en annexe). Techniquement L URL du script appelé est la suivante : &Pwd= &Mode= &RepFT= &ListID= &Separ= ATTENTION : lorsque vous effectuez les tests d intégration du système, vous devez impérativement utiliser l URL de pré-production. Pendant la phase de pré-production l URL du script appelé est la suivante : &Pwd= &Mode= &RepFT= &ListID= &Separ= Les paramètres d entrée sont : SiteID : Pwd : Mode : RepFT : ListID : Separ : Identifiant numérique du site fourni par FIA-NET Mot de passe utilisé pour se connecter sur le système FIA-NET (url-encodé) Mode d appel du script - full (par défaut, tout), mini (validation seule) ou help (affichage de l aide) (optionnel) Affichage ( 1 ) ou non ( 0, par défaut) de la réponse FT (optionnel) Liste des références internes du marchand pour les transactions demandées Séparateur utilisé dans la liste des références de transactions. Encodage des informations: Pour envoyer le mot de passe (Pwd), vous devez au préalable l encoder au format URL afin de ne pas avoir de problème de transmission de données. Retour du script: Le retour de ce script est un flux XML <stack> qui regroupe l ensemble des balises <result> qui détaillent notre analyse. En cas d erreur de votre part, du script, ou d une transaction invalide, le flux vous donne le détail. (détail plus loin) ATTENTION : la quantité de flux <result> retournés par le script get_validstack.cgi est fonction du type de retour spécifié lors de l appel au script (full / mini). Les limites sont les suivantes : 15 références (ou flux <result>) maximum en cas de retour souhaité en mode full ; Exemples: 50 références (ou flux <result>) maximum en cas de retour souhaité en mode mini. Vous trouverez en annexe, des exemples d appel du script, de réponses de ce script ainsi qu une extraction d une partie du mode «help». V5.6.3-dispositif_technique.doc Page 28 sur 81

29 5.3.2 Récupération par date En bref Ce script permet de récupérer directement un flux XML <stack> contenant l ensemble des critères de notre analyse pour chaque transaction passée à la date indiquée (mode «full») ou uniquement le niveau de validation (mode «mini»). Il existe un mode «help» qui vous permet d obtenir une explication sur certaines valeurs numériques (voir en annexe). Techniquement L URL du script appelé est la suivante : &Pwd= &Mode= &RepFT= &DtStack= &Ind= ATTENTION : lorsque vous effectuez les tests d intégration du système, vous devez impérativement utiliser l URL de pré-production. Pendant la phase de pré-production l URL du script appelé est la suivante : &Pwd= &Mode= &RepFT= &DtStack= &Ind= Les paramètres d entrée sont : SiteID : Pwd : Mode : RepFT : DtStack : Ind : Identifiant numérique du site fourni par FIA-NET Mot de passe utilisé pour se connecter sur le système FIA-NET (url-encodé) Mode d appel du script - full (par défaut, tout), mini (validation seule) ou help (affichage de l aide) (optionnel) Affichage ( 1 ) ou non ( 0, par défaut) de la réponse FT (optionnel) Date pour laquelle l analyse des transactions passées est demandée (format DD/MM/YYYY) Indice de la page demandée (1 à n suivant le nombre de transactions : 50 transactions par page). Encodage des informations: Pour envoyer le mot de passe (Pwd), vous devez au préalable l encoder au format URL afin de ne pas avoir de problème de transmission de données. Retour du script: Le retour de ce script est un flux XML <stack> qui regroupe l ensemble des balises <result> qui détaillent notre analyse. En cas d erreur de votre part, du script, ou d une transaction invalide, le flux vous donne le détail. (détail plus loin) ATTENTION : la quantité de flux <result> retournés par le script get_validstack.cgi est fonction du type de retour spécifié lors de l appel au script (full / mini). Les limites sont les suivantes : 15 références (ou flux <result>) maximum en cas de retour souhaité en mode full ; Exemples: 50 références (ou flux <result>) maximum en cas de retour souhaité en mode mini. Vous trouverez en annexe, des exemples d appel du script, de réponses de ce script pour les modes «full» et «mini» ainsi qu une extraction d une partie du mode «help». V5.6.3-dispositif_technique.doc Page 29 sur 81

30 5.4 Interrogation des transactions réévaluées En bref Ce script permet de récupérer un flux XML <result> contenant l ensemble des critères de notre évaluation (mode «full») ou uniquement le niveau de validation (mode «mini») pour les transactions dont l évaluation a changé (fichiers incidents, utilisateurs certifiés, etc.) sur une période déterminée par le marchand (3 jours par défaut). Lorsque vous voulez utiliser cette méthode pour récupérer les transactions réévaluées, vous devez nous contacter pour que nous puissions activer la production de ces alertes pour votre site. Par défaut, seules les alertes consultables sur notre Back-Office sont produites pour tous les sites. Techniquement L URL du script appelé est la suivante : &Pwd= Mode= &RepFT= ATTENTION : lorsque vous effectuez les tests d intégration du système, vous devez impérativement utiliser l URL de pré-production. Pendant la phase de pré-production l URL du script appelé est la suivante : &Pwd= Mode= &RepFT= Les paramètres d entrée sont : SiteID : Pwd : Mode : Output : RepFT : Identifiant numérique du site fourni par FIA-NET Mot de passe utilisé pour se connecter sur le système FIA-NET (url-encodé) new old all Mode d appel du script suivant les informations désirées (voir ci-dessous) Mode de sortie du script full (par défaut, tout) ou mini (validation seule) (optionnel) Affichage ( 1 ) ou non ( 0, par défaut) de la réponse FT (optionnel). Le paramètre «Mode» permet de récupérer soit uniquement les nouvelles réévaluations (new), soit uniquement les réévaluations déjà vues (old), soit les nouvelles et les anciennes (all). Ce paramètre peut être très pratique pendant la phase de développement. Encodage des informations: Pour envoyer le mot de passe (Pwd), vous devez au préalable l encoder au format URL afin de ne pas avoir de problème de transmission de données. Retour du script: Le retour de ce script est un flux XML <result> qui détaille notre analyse pour chaque transaction qui a été réévaluée. En cas d erreur de votre part, ou du script, le flux vous donne le détail. (détail plus loin) Exemples: Vous trouverez en annexe, des exemples d appel du script, de réponses de ce script ainsi qu une extraction d une partie du mode «help». V5.6.3-dispositif_technique.doc Page 30 sur 81

31 5.5 Structures renvoyées Vous trouverez les exemples des différentes structures dans l annexe de ce document Structure d aide <help> La structure <help> vous permet d afficher d une part une explication des différents champs de la structure <result> et d autre part une correspondance complète entre les identifiants numériques utilisés et leur signification. Vous trouverez par exemple la liste des éléments pouvant être en fichier incident, les différentes possibilités du niveau d évaluation, les critères validant ou invalidant, Vous en trouverez une partie extraite dans l annexe de ce document. <!DOCTYPE help [ <!ELEMENT (result, tag)> Structure <stack> pour get_validstack.cgi Définition (non-exploitable directement) : <!DOCTYPE stack [ <!ELEMENT stack (result+)> <!ATTLIST stack total CDATA #REQUIRED> <!ATTLIST stack indice CDATA> Explications : Propriété «total» : Propriété «indice»: <result>: Donne le nombre de références demandées (liste) ou le nombre total de transactions de la journée indépendamment du système de pages (date) Page actuellement demandée (uniquement en mode date) Détail des analyses par transaction (une balise <result> par référence en mode liste, une seule balise <result> représentant une page en mode date) (détaillé cidessous) Structure <result> Définition (non-exploitable directement) : <!DOCTYPE result [ <!ELEMENT result (transaction *)> <!ATTLIST result version CDATA #REQUIRED> <!ATTLIST result site CDATA #REQUIRED> <!ATTLIST result refid CDATA> <!ATTLIST result date CDATA> <!ATTLIST result retour (param_error internal_error absente trouvee) #REQUIRED> <!ATTLIST result message CDATA> <!ATTLIST result count CDATA #REQUIRED ] > Explications : Propriété «version» : Version actuelle du flux (permet de suivre les évolutions) Propriété «site»: Identifiant numérique du site demandeur Propriété «refid»: Référence pour laquelle l évaluation est demandée (absent si groupé par date) Propriété «date»: Date demandée pour les transactions (présent uniquement en groupé par date) Propriété «retour»: Important, précise si la transaction a été trouvée ou non ou si une erreur est survenue Propriété «message»: Message détaillant l erreur si le cas survient (problème de connexion, ) Propriété «count»: Nombre d éléments <transaction> présents (plusieurs transactions sur la même référence, plusieurs transactions par date, plusieurs transactions réévaluées, ) <transaction>: Détail de l analyse pour chaque transaction (détaillé ci-dessous) V5.6.3-dispositif_technique.doc Page 31 sur 81

32 Comment gérer votre cinématique de flux en fonction de la propriété «retour» renvoyée pour les transactions? «param error» signifie que les paramètres que vous avez adressés au système pour récupérer l évaluation sont incorrects : vous devez corriger ce flux et le réadresser. «internal error» signifie que la transaction est bloquée dans un traitement interne à FIA-NET. Ceci peut arriver en période de maintenance nocturne (cf. périodes décrites plus haut au 5.). A l issue de cette période, la transaction devrait être correctement évaluée. Si ce n est pas le cas, pensez à le signaler à votre chargé d affaires ou à votre contact technique chez FIA-NET (coordonnées en fin du document). «absente» signifie que la transaction concernée n a pas été trouvée dans nos bases : ceci doit vous servir de déclenchement pour renvoyer le flux XML de la transaction concernée et nous réinterroger quelques minutes plus tard pour savoir si nous l avons reçue correctement. «trouvée» signifie que la transaction a bien été reçue. La balise <transaction> vous donne le détail de l analyse Format de la structure xml <transaction> : Cette structure XML donne un détail complet des différents tests effectués et de l évaluation donnée à cette transaction ainsi qu un historique des différents états de validation. Dans le cas du mode «mini», seule la balise <analyse> est présente et contient uniquement une balise <eval> contenant le niveau de validation en cours. Définition (non-exploitable directement) : <!DOCTYPE transaction [ <!ELEMENT transaction (detail, blackliste, adresse, ip, historique, histolivr?, paiement?, profil, analyse)> <!ATTLIST transaction avancement (traitee encours error) #REQUIRED> <!ATTLIST transaction cid (#PCDATA) #REQUIRED> <!ELEMENT detail (#PCDATA)> <!ELEMENT blackliste (incident?, alerte?)> <!ATTLIST blackliste valeur (oui non) #REQUIRED> <!ATTLIST blackliste incident (1 0) #REQUIRED> <!ATTLIST blackliste alerte (1 0) #REQUIRED> <!ELEMENT incident (#PCDATA)><!ELEMENT alerte (#PCDATA)> <!ELEMENT adresse (coherencecpville, facturation, livraison?)> <!ATTLIST adresse livr (1 0) #REQUIRED> <!ELEMENT coherencecpville (nc 1 0)> <!ELEMENT facturation (coherenceft, reponseft?, listeinterdit, conso?)> <!ATTLIST facturation conso (1 0) #REQUIRED> <!ELEMENT conso (j10) ><!ELEMENT j10 (1 0)><!ATTLIST j10 nb CDATA #REQUIRED> <!ATTLIST j10 mt CDATA #REQUIRED> <!ATTLIST j10 nbuser CDATA #REQUIRED> <!ATTLIST j10 nbmysite CDATA #REQUIRED> <!ATTLIST j10 mtmysite CDATA #REQUIRED> <!ELEMENT livraison (coherenceft, reponseft?, listeinterdit, conso?)> <!ATTLIST livraison conso (1 0) #REQUIRED> <!ELEMENT coherenceft (#PCDATA)> <!ELEMENT reponseft (abonne*)><!attlist reponseft nb CDATA #REQUIRED> <!ELEMENT abonne (nom, prenom, phone, rue1, ville, activite)> <!ATTLIST abonne rechtype CDATA #REQUIRED> <!ELEMENT nom (#PCDATA)><!ELEMENT prenom (#PCDATA)><!ELEMENT phone (#PCDATA)> <!ELEMENT rue1 (#PCDATA)><!ELEMENT ville (#PCDATA)><!ELEMENT activite (#PCDATA)> <!ELEMENT listeinterdit (oui non)><!attlist listeinterdit detail CDATA #REQUIRED> <!ELEMENT conso (j10) ><!ELEMENT j10 (1 0)><!ATTLIST j10 nb CDATA #REQUIRED> <!ATTLIST j10 mt CDATA #REQUIRED> <!ATTLIST j10 nbuser CDATA #REQUIRED> <!ATTLIST j10 nbmysite CDATA #REQUIRED> <!ATTLIST j10 mtmysite CDATA #REQUIRED> <!ELEMENT ip (country, conso?, nblag?)> <!ATTLIST ip granted (1 0) #REQUIRED><!ATTLIST ip valid (1 0) #REQUIRED> <!ATTLIST ip conso (1 0) #REQUIRED><!ATTLIST ip nbflag (1 0) #REQUIRED> <!ELEMENT country (#PCDATA) #REQUIRED> <!ELEMENT conso (h3) ><!ELEMENT h3 (1 0)><!ATTLIST h3 nb CDATA #REQUIRED> <!ATTLIST h3 mt CDATA #REQUIRED> <!ATTLIST h3 nbuser CDATA #REQUIRED> <!ATTLIST h3 nbmysite CDATA #REQUIRED> <!ATTLIST h3 mtmysite CDATA #REQUIRED> <!ELEMENT nbflag (detail) ><!ELEMENT detail (1 0)><!ATTLIST detail firstdate CDATA #REQUIRED> <!ATTLIST detail lastdate CDATA #REQUIRED><!ATTLIST detail delai CDATA #REQUIRED> <!ATTLIST detail nbflag CDATA #REQUIRED><!ATTLIST detail nb CDATA #REQUIRED> <!ELEMENT historique (utilisateur, ?, mobile?, cb?, consommation, consomail?, consomobil?)> <!ATTLIST historique (1 0) #REQUIRED> <!ATTLIST historique mobile (1 0) #REQUIRED > V5.6.3-dispositif_technique.doc Page 32 sur 81

33 <!ATTLIST historique cb (1 0) #REQUIRED> <!ATTLIST historique valeur CDATA #REQUIRED> <!ATTLIST historique consomail (1 0) #REQUIRED> <!ATTLIST historique consomobil (1 0) #REQUIRED> <!ELEMENT utilisateur (1 0)> <!ATTLIST utilisateur nbfix CDATA #REQUIRED> <!ATTLIST utilisateur nbmob CDATA #REQUIRED > <!ATTLIST utilisateur nbcb CDATA #REQUIRED> <!ATTLIST utilisateur nbmail CDATA #REQUIRED > <!ATTLIST utilisateur nbafact CDATA #REQUIRED ><!ATTLIST utilisateur nbalivr CDATA #REQUIRED > <!ELEMENT (1 0)><!ATTLIST nbuser CDATA #REQUIRED> <!ATTLIST nbname CDATA> <!ATTLIST nbafact CDATA #REQUIRED> <!ATTLIST nbalivr CDATA #REQUIRED> <!ELEMENT mobile (1 0)><!ATTLIST mobile nbuser CDATA #REQUIRED> <!ATTLIST mobile nbname CDATA> <!ATTLIST mobile nbafact CDATA #REQUIRED><!ATTLIST mobile nbalivr CDATA #REQUIRED > <!ELEMENT cb (1 0)> <!ATTLIST cb nbuser CDATA #REQUIRED <!ATTLIST cb nbname CDATA > <!ELEMENT consommation (h24, h48, h72, j7, j15, j30)> <!ATTLIST consommation nbtotal CDATA #REQUIRED> <!ATTLIST consommation firstconso CDATA #REQUIRED > <!ATTLIST consommation nbsite CDATA #REQUIRED> <!ATTLIST consommation nbsurcesite CDATA #REQUIRED > <!ELEMENT h24 (1 0)><!ATTLIST h24 nb CDATA #REQUIRED > <!ATTLIST h24 mt CDATA #REQUIRED> <!ATTLIST h24 nbsite CDATA #REQUIRED > <!ATTLIST h24 nbmysite CDATA #REQUIRED> <!ATTLIST h24 mtmysite CDATA #REQUIRED > <!ELEMENT h48 (1 0)><!ATTLIST h48 nb CDATA #REQUIRED > <!ATTLIST h48 mt CDATA #REQUIRED> <!ATTLIST h48 nbsite CDATA #REQUIRED > <!ATTLIST h48 nbmysite CDATA #REQUIRED> <!ATTLIST h48 mtmysite CDATA #REQUIRED > <!ELEMENT h72 (1 0)><!ATTLIST h72 nb CDATA #REQUIRED > <!ATTLIST h72 mt CDATA #REQUIRED ><!ATTLIST h72 nbsite CDATA #REQUIRED > <!ATTLIST h72 nbmysite CDATA #REQUIRED> <!ATTLIST h72 mtmysite CDATA #REQUIRED > <!ELEMENT j7 (1 0)><!ATTLIST j7 nb CDATA #REQUIRED > <!ATTLIST j7 mt CDATA #REQUIRED> <!ATTLIST j7 nbsite CDATA #REQUIRED > <!ATTLIST j7 nbmysite CDATA #REQUIRED> <!ATTLIST j7 mtmysite CDATA #REQUIRED > <!ELEMENT j15 (1 0)><!ATTLIST j15 nb CDATA #REQUIRED > <!ATTLIST j15 mt CDATA #REQUIRED> <!ATTLIST j15 nbsite CDATA #REQUIRED > <!ATTLIST j15 nbmysite CDATA #REQUIRED> <!ATTLIST j15 mtmysite CDATA #REQUIRED > <!ELEMENT j30 (1 0)><!ATTLIST j30 nb CDATA #REQUIRED > <!ATTLIST j30 mt CDATA #REQUIRED> <!ATTLIST j30 nbsite CDATA #REQUIRED > <!ATTLIST j30 nbmysite CDATA #REQUIRED> <!ATTLIST j30 mtmysite CDATA #REQUIRED > <!ELEMENT consomail (h24, h48, h72, j7, j15, j30)> <!ELEMENT h24 (1 0)><!ATTLIST h24 nb CDATA #REQUIRED > <!ATTLIST h24 mt CDATA #REQUIRED> <!ATTLIST h24 nbuser CDATA #REQUIRED > <!ATTLIST h24 nbmysite CDATA #REQUIRED> <!ATTLIST h24 mtmysite CDATA #REQUIRED > <!ELEMENT h48 (1 0)><!ATTLIST h48 nb CDATA #REQUIRED > <!ATTLIST h48 mt CDATA #REQUIRED> <!ATTLIST h48 nbuser CDATA #REQUIRED > <!ATTLIST h48 nbmysite CDATA #REQUIRED> <!ATTLIST h48 mtmysite CDATA #REQUIRED > <!ELEMENT h72 (1 0)><!ATTLIST h72 nb CDATA #REQUIRED > <!ATTLIST h72 mt CDATA #REQUIRED ><!ATTLIST h72 nbuser CDATA #REQUIRED > <!ATTLIST h72 nbmysite CDATA #REQUIRED> <!ATTLIST h72 mtmysite CDATA #REQUIRED > <!ELEMENT j7 (1 0)><!ATTLIST j7 nb CDATA #REQUIRED > <!ATTLIST j7 mt CDATA #REQUIRED> <!ATTLIST j7 nbuser CDATA #REQUIRED > <!ATTLIST j7 nbmysite CDATA #REQUIRED> <!ATTLIST j7 mtmysite CDATA #REQUIRED > <!ELEMENT j15 (1 0)><!ATTLIST j15 nb CDATA #REQUIRED > <!ATTLIST j15 mt CDATA #REQUIRED> <!ATTLIST j15 nbuser CDATA #REQUIRED > <!ATTLIST j15 nbmysite CDATA #REQUIRED> <!ATTLIST j15 mtmysite CDATA #REQUIRED > <!ELEMENT j30 (1 0)><!ATTLIST j30 nb CDATA #REQUIRED > <!ATTLIST j30 mt CDATA #REQUIRED> <!ATTLIST j30 nbuser CDATA #REQUIRED > <!ATTLIST j30 nbmysite CDATA #REQUIRED> <!ATTLIST j30 mtmysite CDATA #REQUIRED > <!ELEMENT consomobil (h24, h48, h72, j7, j15, j30)> <!ELEMENT h24 (1 0)><!ATTLIST h24 nb CDATA #REQUIRED > <!ATTLIST h24 mt CDATA #REQUIRED> <!ATTLIST h24 nbuser CDATA #REQUIRED > <!ATTLIST h24 nbmysite CDATA #REQUIRED> <!ATTLIST h24 mtmysite CDATA #REQUIRED > <!ELEMENT h48 (1 0)><!ATTLIST h48 nb CDATA #REQUIRED > <!ATTLIST h48 mt CDATA #REQUIRED> <!ATTLIST h48 nbuser CDATA #REQUIRED > <!ATTLIST h48 nbmysite CDATA #REQUIRED> <!ATTLIST h48 mtmysite CDATA #REQUIRED > <!ELEMENT h72 (1 0)><!ATTLIST h72 nb CDATA #REQUIRED > <!ATTLIST h72 mt CDATA #REQUIRED ><!ATTLIST h72 nbuser CDATA #REQUIRED > <!ATTLIST h72 nbmysite CDATA #REQUIRED> <!ATTLIST h72 mtmysite CDATA #REQUIRED > <!ELEMENT j7 (1 0)><!ATTLIST j7 nb CDATA #REQUIRED > <!ATTLIST j7 mt CDATA #REQUIRED> <!ATTLIST j7 nbuser CDATA #REQUIRED > <!ATTLIST j7 nbmysite CDATA #REQUIRED> <!ATTLIST j7 mtmysite CDATA #REQUIRED > <!ELEMENT j15 (1 0)><!ATTLIST j15 nb CDATA #REQUIRED > <!ATTLIST j15 mt CDATA #REQUIRED> <!ATTLIST j15 nbuser CDATA #REQUIRED > <!ATTLIST j15 nbmysite CDATA #REQUIRED> <!ATTLIST j15 mtmysite CDATA #REQUIRED > <!ELEMENT j30 (1 0)><!ATTLIST j30 nb CDATA #REQUIRED > <!ATTLIST j30 mt CDATA #REQUIRED> <!ATTLIST j30 nbuser CDATA #REQUIRED > <!ATTLIST j30 nbmysite CDATA #REQUIRED> <!ATTLIST j30 mtmysite CDATA #REQUIRED > <!ELEMENT histolivr (utilisateur, ?, mobile?, consommation, consomail?, consomobil?)> V5.6.3-dispositif_technique.doc Page 33 sur 81

34 <!ATTLIST histolivr (1 0) #REQUIRED> <!ATTLIST historique mobile (1 0) #REQUIRED > <!ATTLIST historique valeur CDATA #REQUIRED> <!ATTLIST histolivr consomail (1 0) #REQUIRED> <!ATTLIST historique consomobil (1 0) #REQUIRED> <!ELEMENT utilisateur (1 0)> <!ATTLIST utilisateur nbfix CDATA #REQUIRED> <!ATTLIST utilisateur nbmob CDATA #REQUIRED > <!ATTLIST utilisateur nbcb CDATA #REQUIRED> <!ATTLIST utilisateur nbmail CDATA #REQUIRED > <!ATTLIST utilisateur nbafact CDATA #REQUIRED ><!ATTLIST utilisateur nbalivr CDATA #REQUIRED > <!ELEMENT (1 0)><!ATTLIST nbuser CDATA #REQUIRED> <!ATTLIST nbname CDATA> <!ATTLIST nbafact CDATA #REQUIRED> <!ATTLIST nbalivr CDATA #REQUIRED> <!ELEMENT mobile (1 0)><!ATTLIST mobile nbuser CDATA #REQUIRED> <!ATTLIST mobile nbname CDATA> <!ATTLIST mobile nbafact CDATA #REQUIRED><!ATTLIST mobile nbalivr CDATA #REQUIRED > <!ELEMENT consommation (h24, h48, h72, j7, j15, j30)> <!ATTLIST consommation nbtotal CDATA #REQUIRED> <!ATTLIST consommation firstconso CDATA #REQUIRED > <!ATTLIST consommation nbsite CDATA #REQUIRED> <!ATTLIST consommation nbsurcesite CDATA #REQUIRED > <!ELEMENT h24 (1 0)><!ATTLIST h24 nb CDATA #REQUIRED > <!ATTLIST h24 mt CDATA #REQUIRED> <!ATTLIST h24 nbsite CDATA #REQUIRED > <!ATTLIST h24 nbmysite CDATA #REQUIRED> <!ATTLIST h24 mtmysite CDATA #REQUIRED > <!ELEMENT h48 (1 0)><!ATTLIST h48 nb CDATA #REQUIRED > <!ATTLIST h48 mt CDATA #REQUIRED> <!ATTLIST h48 nbsite CDATA #REQUIRED > <!ATTLIST h48 nbmysite CDATA #REQUIRED> <!ATTLIST h48 mtmysite CDATA #REQUIRED > <!ELEMENT h72 (1 0)><!ATTLIST h72 nb CDATA #REQUIRED > <!ATTLIST h72 mt CDATA #REQUIRED ><!ATTLIST h72 nbsite CDATA #REQUIRED > <!ATTLIST h72 nbmysite CDATA #REQUIRED> <!ATTLIST h72 mtmysite CDATA #REQUIRED > <!ELEMENT j7 (1 0)><!ATTLIST j7 nb CDATA #REQUIRED > <!ATTLIST j7 mt CDATA #REQUIRED> <!ATTLIST j7 nbsite CDATA #REQUIRED > <!ATTLIST j7 nbmysite CDATA #REQUIRED> <!ATTLIST j7 mtmysite CDATA #REQUIRED > <!ELEMENT j15 (1 0)><!ATTLIST j15 nb CDATA #REQUIRED > <!ATTLIST j15 mt CDATA #REQUIRED> <!ATTLIST j15 nbsite CDATA #REQUIRED > <!ATTLIST j15 nbmysite CDATA #REQUIRED> <!ATTLIST j15 mtmysite CDATA #REQUIRED > <!ELEMENT j30 (1 0)><!ATTLIST j30 nb CDATA #REQUIRED > <!ATTLIST j30 mt CDATA #REQUIRED> <!ATTLIST j30 nbsite CDATA #REQUIRED > <!ATTLIST j30 nbmysite CDATA #REQUIRED> <!ATTLIST j30 mtmysite CDATA #REQUIRED > <!ELEMENT consomail (h24, h48, h72, j7, j15, j30)> <!ELEMENT h24 (1 0)><!ATTLIST h24 nb CDATA #REQUIRED > <!ATTLIST h24 mt CDATA #REQUIRED> <!ATTLIST h24 nbuser CDATA #REQUIRED > <!ATTLIST h24 nbmysite CDATA #REQUIRED> <!ATTLIST h24 mtmysite CDATA #REQUIRED > <!ELEMENT h48 (1 0)><!ATTLIST h48 nb CDATA #REQUIRED > <!ATTLIST h48 mt CDATA #REQUIRED> <!ATTLIST h48 nbuser CDATA #REQUIRED > <!ATTLIST h48 nbmysite CDATA #REQUIRED> <!ATTLIST h48 mtmysite CDATA #REQUIRED > <!ELEMENT h72 (1 0)><!ATTLIST h72 nb CDATA #REQUIRED > <!ATTLIST h72 mt CDATA #REQUIRED ><!ATTLIST h72 nbuser CDATA #REQUIRED > <!ATTLIST h72 nbmysite CDATA #REQUIRED> <!ATTLIST h72 mtmysite CDATA #REQUIRED > <!ELEMENT j7 (1 0)><!ATTLIST j7 nb CDATA #REQUIRED > <!ATTLIST j7 mt CDATA #REQUIRED> <!ATTLIST j7 nbuser CDATA #REQUIRED > <!ATTLIST j7 nbmysite CDATA #REQUIRED> <!ATTLIST j7 mtmysite CDATA #REQUIRED > <!ELEMENT j15 (1 0)><!ATTLIST j15 nb CDATA #REQUIRED > <!ATTLIST j15 mt CDATA #REQUIRED> <!ATTLIST j15 nbuser CDATA #REQUIRED > <!ATTLIST j15 nbmysite CDATA #REQUIRED> <!ATTLIST j15 mtmysite CDATA #REQUIRED > <!ELEMENT j30 (1 0)><!ATTLIST j30 nb CDATA #REQUIRED > <!ATTLIST j30 mt CDATA #REQUIRED> <!ATTLIST j30 nbuser CDATA #REQUIRED > <!ATTLIST j30 nbmysite CDATA #REQUIRED> <!ATTLIST j30 mtmysite CDATA #REQUIRED > <!ELEMENT consomobil (h24, h48, h72, j7, j15, j30)> <!ELEMENT h24 (1 0)><!ATTLIST h24 nb CDATA #REQUIRED > <!ATTLIST h24 mt CDATA #REQUIRED> <!ATTLIST h24 nbuser CDATA #REQUIRED > <!ATTLIST h24 nbmysite CDATA #REQUIRED> <!ATTLIST h24 mtmysite CDATA #REQUIRED > <!ELEMENT h48 (1 0)><!ATTLIST h48 nb CDATA #REQUIRED > <!ATTLIST h48 mt CDATA #REQUIRED> <!ATTLIST h48 nbuser CDATA #REQUIRED > <!ATTLIST h48 nbmysite CDATA #REQUIRED> <!ATTLIST h48 mtmysite CDATA #REQUIRED > <!ELEMENT h72 (1 0)><!ATTLIST h72 nb CDATA #REQUIRED > <!ATTLIST h72 mt CDATA #REQUIRED ><!ATTLIST h72 nbuser CDATA #REQUIRED > <!ATTLIST h72 nbmysite CDATA #REQUIRED> <!ATTLIST h72 mtmysite CDATA #REQUIRED > <!ELEMENT j7 (1 0)><!ATTLIST j7 nb CDATA #REQUIRED > <!ATTLIST j7 mt CDATA #REQUIRED> <!ATTLIST j7 nbuser CDATA #REQUIRED > <!ATTLIST j7 nbmysite CDATA #REQUIRED> <!ATTLIST j7 mtmysite CDATA #REQUIRED > <!ELEMENT j15 (1 0)><!ATTLIST j15 nb CDATA #REQUIRED > <!ATTLIST j15 mt CDATA #REQUIRED> <!ATTLIST j15 nbuser CDATA #REQUIRED > <!ATTLIST j15 nbmysite CDATA #REQUIRED> <!ATTLIST j15 mtmysite CDATA #REQUIRED > <!ELEMENT j30 (1 0)><!ATTLIST j30 nb CDATA #REQUIRED > <!ATTLIST j30 mt CDATA #REQUIRED> <!ATTLIST j30 nbuser CDATA #REQUIRED > <!ATTLIST j30 nbmysite CDATA #REQUIRED> <!ATTLIST j30 mtmysite CDATA #REQUIRED > <!ELEMENT paiement (bin) ><!ATTLIST paiement type CDATA #REQUIRED> V5.6.3-dispositif_technique.doc Page 34 sur 81

35 <!ELEMENT bin CDATA #REQUIRED> <!ATTLIST bin country CDATA #REQUIRED <!ELEMENT profil (certificat, scoring+)> <!ELEMENT certificat (oui non)> <!ATTLIST certificat emetteur CDATA #REQUIRED > <!ELEMENT scoring (oui non nc)> <!ATTLIST scoring bin (1 0) #REQUIRED> <!ATTLIST scoring ip (1 0) #REQUIRED> <!ATTLIST scoring retrait (1 0) #REQUIRED <!ATTLIST scoring montant (1 0) #REQUIRED> <!ELEMENT analyse (histoeval, eval, classement?, myprofildetail?, FIA-NET?)> <!ELEMENT histoeval (eval*)> <!ATTLIST histoeval nbetape CDATA #REQUIRED > <!ELEMENT eval (#PCDATA)> <!ATTLIST eval date CDATA #REQUIRED> <!ATTLIST eval critere CDATA #REQUIRED> <!ATTLIST eval validation CDATA #REQUIRED> <!ATTLIST eval info CDATA #REQUIRED > <!ELEMENT classement CDATA> <!ATTLIST classement id CDATA #REQUIRED> <!ELEMENT myprofildetail (myprofilrule *)><!ATTLIST myprofildetail matchid CDATA #REQUIRED> <!ELEMENT myprofilrule (0 1 - )><!ATTLIST myprofilrule id CDATA #REQUIRED> <!ATTLIST myprofilrule type (0 1) #REQUIRED> <!ATTLIST myprofilrule info CDATA #REQUIRED> <!ELEMENT FIA-NET (defaultval,myprofildetail)> <!ELEMENT defaultval (#PCDATA)> <!ATTLIST defaultval date CDATA #REQUIRED> <!ATTLIST defaultval critere CDATA #REQUIRED> <!ATTLIST defaultval validation CDATA #REQUIRED> <!ATTLIST defaultval info CDATA #REQUIRED> ]> Explications : Balise <detail> : Donne l état de traitement de la transaction Ex : en cours de traitement, absence des informations bancaires, paiement validé Comment gérer votre cinématique de flux en fonction de la propriété «transaction avancement» renvoyée pour les transactions? «traitée» signifie que la transaction a bien été évaluée. La balise <eval> vous donne le résultat du calcul d évaluation de FIA-NET. «encours» signifie que la transaction a bien été trouvée, mais est toujours en cours de calcul d évaluation. Vous devez réinterroger le système pour obtenir l évaluation définitive. Vous pouvez le faire quelques minutes plus tard lors de votre prochaine demande d évaluation de transactions. Pendant les périodes de maintenance du système, notamment nocturnes (cf. périodes décrites plus haut en 5.), il est préférable d attendre la fin de la période de maintenance avant de réinterroger le système. En effet, les calculs d évaluation sont interrompus ou fortement ralentis pendant ces périodes. «error» signifie que la transaction n a pu être évaluée, car elle est invalide (erreur sur un des paramètres adressés dans le flux XML sur la transaction). Notre Back-Office vous donne la liste de ces transactions invalides avec la raison de l erreur ayant empêché son évaluation. En vous connectant sur ce Back-Office, vous pouvez corriger manuellement cette erreur et relancer le calcul d évaluation de la transaction concernée. Balise <blackliste> : Récapitulatif du croisement avec les fichiers incidents et alertes Propriété «valeur» : Propriété «incident» : Propriété «alerte» : Balise <incident> : oui/non - savoir si la transaction possède des éléments dans le fichier incident ou dans le fichier alerte 1/0 - présence ou non de la balise incident (possède des éléments en fichier incident) 1/0 - présence ou non de la balise alerte (possède des éléments en fichier alerte) liste des identifiants des éléments présents dans le fichier incident (séparés par des - ) Balise <alerte> : liste des identifiants des éléments présents dans le fichier alerte (séparés par des - ) Le détail des identifiants est fournit en mode «help» de l appel aux cgis. V5.6.3-dispositif_technique.doc Page 35 sur 81

36 Balise <adresse> : Analyse de la ou des adresses de la transaction Propriété «livr» : 1/0 - présence ou non de la balise livraison (adr. de livraison présente) Balise <coherencecpville> : 1/0/nc - cohérence entre le code postal et la ville (cohérent / incohérent / non-calculé) Balise <facturation> ou <livraison> : résultat de l analyse de l adresse de facturation ou de livraison Propriété «conso» : 1/0 - présence ou non de la balise d historique de consommation Balise <coherenceft> : Balise <reponseft> : Propriété «nb» : -100/-50/-1/80/90/100 - taux de correspondance avec France Télécom résultat de l interrogation France Télécom (si demandé) nombre de lignes d abonnés France Télécom Balise <abonne> : détail d une ligne d abonné France Télécom Propriété «rechtype» : indique s il s agissait d une recherche inversée ou textuelle Balise <nom>, <prenom>, <phone>, <rue1>, <ville> ou <activite> : détail de chaque information renvoyée par France Télécom (les balises peuvent être vides) Balise <listeinterdit> : oui/non - présence ou non d un élément de l adresse dans la liste des adresses interdites Propriété «detail» : libellé de l élément présent dans la liste des adresses interdites (vide si nonprésence) Balise <conso> : détail de l historique de consommation à l adresse Balises <j10> : 1/0 - calcul de l historique de consommation sur 10 jours (Bon/Mauvais historique) Propriété «nb» : nombre de transactions sur la période Propriété «mt» : somme des montants des transactions sur la période (en Euro) Propriété «nbuser» : nombre d utilisateurs différents sur la période Propriété «nbmysite» : nombre de transactions sur mon site sur la période Propriété «mtmysite» : somme des montants des transactions sur mon site sur la période Balise <ip> : Analyse des propriétés de l adresse IP Propriété «granted» : 1/0 - le site poste-t-il correctement l adresse ip? Propriété «valid» : 1/0 - l adresse ip est-elle valide? Propriété «conso» : 1/0 - présence ou non de la balise d historique de consommation de l ip Propriété «nbflag» : 1/0 - présence ou non de la balise d historique de fraude sur l ip Balise <conso> : détail de l historique de consommation de l ip Balises <h3>: 1/0 - calcul de l historique de consommation sur 3 heures (Bon historique / Historique négatif) Propriété «nb» : nombre de transactions sur la période Propriété «mt» : somme des montants des transactions sur la période (en Euro) Propriété «nbuser» : nombre d utilisateurs différents sur la période Propriété «nbmysite» : nombre de transactions sur mon site sur la période Propriété «mtmysite» : somme des montants des transactions sur mon site sur la période (en Euro) Balise <nbflag> : détail de l historique de fraude de l ip sur 30 jours Balises <detail> : 1/0 - calcul de l historique de fraude de l ip Propriété «firstdate» : date de la première fraude à cette adresse ip Propriété «lastdate» : date de la dernière fraude à cette adresse ip Propriété «delai» : nombre de jours entre la première fraude et la dernière fraude sur cette ip Propriété «nbflag» : nombre de transactions fraudées sur la période sur cette ip Propriété «nb» : nombre total de transactions sur la période sur cette ip V5.6.3-dispositif_technique.doc Page 36 sur 81

37 Balise <historique> : Calcul des historiques et modes de consommation de l utilisateur de facturation Propriété « » : 1/0 - présence ou non de la balise (possède une adresse de messagerie) Propriété «mobile» : 1/0 - présence ou non de la balise mobile (possède un numéro de tel portable) Propriété «cb» : 1/0 - présence ou non de la balise cb (possède un numéro de carte bancaire) Propriété «valeur» : -1/0/50/100 résumé de l analyse de consommation (RAS / Eliminatoire / Moyen / Client Connu) Propriété «consomail» : 1/0 - présence ou non de la balise d historique de consommation de l Propriété «consomobil» : 1/0 - présence ou non de la balise d historique de consommation du mobile Balise <utilisateur> : 1/0 - calcul de l historique des informations données par l utilisateur dans ses différentes commandes (Bon historique / Historique négatif) Propriété «nbfix» : nombre de téléphones fixes personnels utilisés Propriété «nbmob» : nombre de téléphones portables utilisés Propriété «nbcb» : nombre de numéros de carte bancaire utilisés Propriété «nbafact» : nombre d adresses de facturation utilisées Propriété «nbalivr» : nombre d adresses de livraison utilisées Balise < > : Propriété «nbuser» : Propriété «nbname» : Propriété «nbafact» : Propriété «nbalivr» : 1/0 - calcul de l historique des informations associées à l adresse utilisée dans la transaction (Bon historique / Historique négatif) nombre d utilisateurs utilisant cette adresse nombre de noms de famille des utilisateurs utilisant cette adresse nombre d adresses de facturation associées à cette adresse nombre d adresses de livraison associées à cette adresse Balise <mobile> : 1/0 - calcul de l historique des informations associées au numéro de téléphone portable utilisé dans la transaction (Bon historique / Historique négatif) Propriété «nbuser» : nombre d utilisateurs utilisant ce numéro Propriété «nbname» : nombre de noms de famille des utilisateurs utilisant ce numéro Propriété «nbafact» : nombre d adresses de facturation associées à ce numéro Propriété «nbalivr» : nombre d adresses de livraison associées à ce numéro Balise <cb> : 1/0 -calcul de l historique des informations associées au numéro de carte bancaire utilisé dans la transaction (Bon historique / Historique négatif) Propriété «nbuser» : nombre d utilisateurs utilisant ce numéro de carte bancaire Propriété «nbname» : nombre de noms de famille des utilisateurs utilisant ce numéro de carte bancaire Balise <consommation> : calcul de l historique de consommation de l utilisateur de facturation Propriété «nbtotal» : nombre total de commandes effectuées par cet utilisateur (nc si non-calculé) Propriété «firstconso» : première date de consommation de cet utilisateur (nc si non-calculé) Propriété «nbsite» : nombre de sites sur lesquels l utilisateur a acheté (nc si non-calculé) Propriété «nbsurcesite» : nombre de commandes effectuées sur le site demandeur (nc si non-calculé) Ces informations permettent de se rendre compte du profil global de consommation de l utilisateur. Très utile lorsque l ensemble des informations ne nous permet pas de donner une évaluation sûre à 100 %. Balises <h24>, <h48>, <h72>, <j7>, <j15>, <j30> : 1/0 - calcul de l historique de consommation sur 24 heures, 48 heures, 72 heures, 7 jours, 15 jours, 30 jours (Bon historique / Historique négatif) Propriété «nb» : nombre de transactions sur la période Propriété «mt» : somme des montants des transactions sur la période (en Euro) Propriété «nbsite» : nombre de sites différents de consommation Propriété «nbmysite» : nombre de transactions sur mon site sur la période Propriété «mtmysite» : somme des montants des transactions sur mon site sur la période (en Euro) V5.6.3-dispositif_technique.doc Page 37 sur 81

38 Balise <consomail> : détail de l historique de consommation à l adresse Balises <h24>, <h48>, <h72>, <j7>, <j15>, <j30> : 1/0 - calcul de l historique de consommation sur 24 heures, 48 heures, 72 heures, 7 jours, 15 jours, 30 jours (Bon historique / Historique négatif) Propriété «nb» : nombre de transactions sur la période Propriété «mt» : somme des montants des transactions sur la période (en Euro) Propriété «nbuser» : nombre d utilisateurs différents Propriété «nbmysite» : nombre de transactions sur mon site sur la période Propriété «mtmysite» : somme des montants des transactions sur mon site sur la période (en Euro) Balise <consomobil> : détail de l historique de consommation à l adresse Balises <h24>, <h48>, <h72>, <j7>, <j15>, <j30> : 1/0 - calcul de l historique de consommation sur 24 heures, 48 heures, 72 heures, 7 jours, 15 jours, 30 jours (Bon historique / Historique négatif) Propriété «nb» : nombre de transactions sur la période Propriété «mt» : somme des montants des transactions sur la période (en Euro) Propriété «nbuser» : nombre d utilisateurs différents Propriété «nbmysite» : nombre de transactions sur mon site sur la période Propriété «mtmysite» : somme des montants des transactions sur mon site sur la période (en Euro) Balise <histolivr> : Calcul des historiques et modes de consommation de l utilisateur de livraison Propriété « » : 1/0 - présence ou non de la balise (possède une adresse de messagerie) Propriété «mobile» : 1/0 - présence ou non de la balise mobile (possède un numéro de tel portable) Propriété «valeur» : -1/0/50/100 résumé de l analyse de consommation (RAS / Eliminatoire / Moyen / Client Connu) Propriété «consomail» : 1/0 - présence ou non de la balise d historique de consommation de l Propriété «consomobil» : 1/0 - présence ou non de la balise d historique de consommation du mobil Balise <utilisateur> : 1/0 - calcul de l historique des informations données par l utilisateur dans ses différentes commandes (Bon historique / Historique négatif) Propriété «nbfix» : nombre de téléphones fixes personnels utilisés Propriété «nbmob» : nombre de téléphones portables utilisés Propriété «nbcb» : nombre de numéros de carte bancaire utilisés Propriété «nbafact» : nombre d adresses de facturation utilisées Propriété «nbalivr» : nombre d adresses de livraison utilisées Balise < > : Propriété «nbuser» : Propriété «nbname» : Propriété «nbafact» : Propriété «nbalivr» : 1/0 - calcul de l historique des informations associées à l adresse utilisée dans la transaction (Bon historique / Historique négatif) nombre d utilisateurs utilisant cette adresse nombre de noms de famille des utilisateurs utilisant cette adresse nombre d adresses de facturation associées à cette adresse nombre d adresses de livraison associées à cette adresse Balise <mobile> : 1/0 - calcul de l historique des informations associées au numéro de téléphone portable utilisé dans la transaction (Bon historique / Historique négatif) Propriété «nbuser» : nombre d utilisateurs utilisant ce numéro Propriété «nbname» : nombre de noms de famille des utilisateurs utilisant ce numéro Propriété «nbafact» : nombre d adresses de facturation associées à ce numéro Propriété «nbalivr» : nombre d adresses de livraison associées à ce numéro Balise <consommation> : calcul de l historique de consommation de l utilisateur de facturation Propriété «nbtotal» : nombre total de commandes effectuées par cet utilisateur (nc si non-calculé) Propriété «firstconso» : première date de consommation de cet utilisateur (nc si non-calculé) Propriété «nbsite» : nombre de sites sur lesquels l utilisateur a acheté (nc si non-calculé) Propriété «nbsurcesite» : nombre de commandes effectuées sur le site demandeur (nc si non-calculé) Ces informations permettent de se rendre compte du profil global de consommation de l utilisateur. Très utile lorsque l ensemble des informations ne nous permet pas de donner une évaluation sûre à 100%! V5.6.3-dispositif_technique.doc Page 38 sur 81

39 Balises <h24>, <h48>, <h72>, <j7>, <j15>, <j30> : 1/0 - calcul de l historique de consommation sur 24 heures, 48 heures, 72 heures, 7 jours, 15 jours, 30 jours (Bon historique / Historique négatif) Propriété «nb» : nombre de transactions sur la période Propriété «mt» : somme des montants des transactions sur la période (en Euro) Propriété «nbsite» : nombre de sites différents de consommation Propriété «nbmysite» : nombre de transactions sur mon site sur la période Propriété «mtmysite» : somme des montants des transactions sur mon site sur la période (en Euro) Balise <consomail> : détail de l historique de consommation avec l adresse Balises <h24>, <h48>, <h72>, <j7>, <j15>, <j30> : 1/0 - calcul de l historique de consommation sur 24 heures, 48 heures, 72 heures, 7 jours, 15 jours, 30 jours (Bon historique / Historique négatif) Propriété «nb» : nombre de transactions sur la période Propriété «mt» : somme des montants des transactions sur la période (en Euro) Propriété «nbuser» : nombre d utilisateurs différents Propriété «nbmysite» : nombre de transactions sur mon site sur la période Propriété «mtmysite» : somme des montants des transactions sur mon site sur la période (en Euro) Balise <consomobil> : détail de l historique de consommation avec le téléphone mobile Balises <h24>, <h48>, <h72>, <j7>, <j15>, <j30> : 1/0 - calcul de l historique de consommation sur 24 heures, 48 heures, 72 heures, 7 jours, 15 jours, 30 jours (Bon historique / Historique négatif) Propriété «nb» : nombre de transactions sur la période Propriété «mt» : somme des montants des transactions sur la période (en Euro) Propriété «nbuser» : nombre d utilisateurs différents Propriété «nbmysite» : nombre de transactions sur mon site sur la période Propriété «mtmysite» : somme des montants des transactions sur mon site sur la période (en Euro) Balise <paiement> : Donne la correspondance entre le bin de la carte bancaire et la banque ATTENTION CETTE INFORMATION N EST PAS TOUJOURS DISPONIBLE Propriété «type» : carte cheque contre-remboursement virement cb en n fois indique que la transaction possède une information de paiement par carte Balise <bin> : nom de l organisme bancaire dont dépend le bin de la carte (nc si non disponible) Propriété «country» : code sur deux caractères du pays dont dépend le bin (vide si non disponible) Balise <profil> : Présentation d éléments externes ou de scoring calculés en bloc Balise <certificat> : oui/non - présence ou non d un certificat (pièces justificatives) pour l utilisateur Propriété «emetteur» : autorité ayant délivré le certificat (ex : FIA-NET) (aucun si pas de certificat) Balise <scoring> : oui/non/nc - la transaction rentre ou ne rentre pas dans le cadre d au moins un profil prédéterminé (nc si non-calculé) Propriété «ip» : 0/1 la transaction rentre ou non dans le cadre du profil «ip» prédéterminé Propriété «bin» : 0/1 la transaction rentre ou non dans le cadre du profil «bin» prédéterminé Propriété «retrait» : 0/1 la transaction rentre ou non dans le cadre du profil «retrait» prédéterminé Propriété «montant» : 0/1 la transaction rentre ou non dans le cadre du profil «montant» prédéterminé V5.6.3-dispositif_technique.doc Page 39 sur 81

40 Balise <analyse> : Donne le résultat de l analyse Balise <histoeval> : regroupe les différentes réévaluations survenues sur cette transaction. Attention, uniquement les changements d évaluations sont présents. Propriété «nbetape» : nombre d étapes de ré-évaluation Balises <eval> : -1/0/100/ - niveau d évaluation calculé (balise au nombre de «nbetape», les balises représentent chacune des étapes de réévaluation) Propriété «date» : date du changement d évaluation Propriété «critere» : identifiant du critère principal qui explique l évaluation (correspondance visibile dans l extraction du mode «help» présentée en annexe) (### signifie l application d un profil personnalisé, le libellé est visible dans la propriété «info») Propriété «validation» : correspond au niveau d analyse de la transaction (libellé clair) Propriété «info» : précise des informations supplémentaires comme le critère d analyse de la transaction ou met l accent sur notre connaissance de l utilisateur pour les transactions peu sûres (libellé clair) Balise <eval> : -1/0/100/ - niveau d évaluation calculé, présente la dernière évaluation de cette transaction (Evaluation globale) Propriété «date» : date de cette évaluation globale Propriété «critere» : identifiant du critère principal qui explique l évaluation (correspondance visible dans l extraction du mode «help» présentée en annexe)(### signifie l application d un profil personnalisé, le libellé est visible dans la propriété «info») Propriété «validation» : correspond au niveau de validation de la transaction (libellé clair) Propriété «info» : précise des informations supplémentaires comme le critère d analyse de la transaction ou met l accent sur notre connaissance de l utilisateur pour les transactions peu sûres (libellé clair) Balise <classement> : Propriété «id» : Libellé du classement actuel de la transaction (non présente si la transaction n est pas classée) identifiant numérique du classement actuel de la transaction Balise <myprofildetail> : précise le profil particulier qui s est appliqué Propriété «matchid» : -1/n indique la première règle vérifiée (-1 si aucune règle n est vérifiée) Balises <myprofilrule> : 0/1/- - indique si la règle en question est vérifiée (0 : non 1 : oui - : non-calculée) Propriété «id» : identifiant de la règle analysée Propriété «type» : 0/1 : indique si la règle est négative (0 : invalidante) ou positive (1 : validante) Propriété «info» : libellé en clair de la règle analysée Balise <FIA-NET> : contient le résultat de l évaluation sans customisation : si vous avez demandé une customisation du système, cette balise vous donne la réponse «par défaut» du système FIA-NET Balises <defaultval> Propriété «date» : date de cette évaluation globale Propriété «critere» : identifiant du critère principal qui explique l évaluation (correspondance visible dans l extraction du mode «help» présentée en annexe)(### signifie l application d un profil personnalisé, le libellé est visible dans la propriété «info») Propriété «validation» : correspond au niveau de validation de la transaction (libellé clair) Propriété «info» : précise des informations supplémentaires comme le critère d analyse de la transaction ou met l accent sur notre connaissance de l utilisateur pour les transactions peu sûres (libellé clair) V5.6.3-dispositif_technique.doc Page 40 sur 81

41 5.5.5 Liste des valeurs prises par <eval> : Chaque transaction se voit attribuer l une des trois évaluations possibles. 0 la transaction est considérée risquée et nécessite un contrôle, «assurée à 0%» ; -1 la transaction est considérée non risquée, «assurée à 90%» ; 100 la transaction est considérée sûre, «assurée à 100%» Liste des profils fixes FIA-NET : Cette liste est susceptible de changer sans préavis (en particulier rajout de nouveaux critères). Il est donc fortement recommandé de se référer à la structure <help> ou à l interface du Système d Analyse des Commandes afin de disposer du libellé exact des profils, de leur définition et de leur description. Cette liste correspond au libellé Crit-nnn où nnn est un numérique. Profils Fixes FIA-NET (Critère numérique) Numéro Libellé Descriptif 1 Fichier Incidents/Alertes Un élément personnel de l'acheteur a déjà servi à une fraude ou une tentative de fraude ou est lié à un fraudeur. Eliminatoire. 2 Hist. d information de l utilisateur de Pluralités d éléments rattachés à l utilisateur de facturation : nombre de téléphones fixes, mobiles, cb, , adresses de facturation/livraison. Eliminatoire. facturation 3 Historique CB Pluralités d éléments rattachés à la carte bancaire : nombre d utilisateurs, de noms de 4 Hist. consommation de l utilisateur de facturation 4 Historique parfait FIA- NET 5 Hist. de l de facturation 7 Hist. d information de l utilisateur de livraison 9 Hist. consommation de l utilisateur de livraison famille. Eliminatoire. Si l évaluation est à 0 ; Montant d'achat cumulé de l'utilisateur sur une période donnée sur l ensemble des sites FIA-NET sur 24, 48, 72 heures et 7, 15 et 30 jours. Eliminatoire. Si l évaluation est à 100 ; Acheteur présent en base depuis plus de 120 jours et consommant régulièrement sur un ou plusieurs sites FIA-NET sans anomalie.. Pluralités d éléments rattachés à l de facturation : nombre d utilisateurs, de noms de famille, adresses de facturation/livraison. Eliminatoire. Pluralités d éléments rattachés à l utilisateur de livraison : nombre de téléphones fixes, mobiles, cb, , adresses de facturation/livraison. Eliminatoire. Montant d'achat cumulé de l'utilisateur sur une période donnée sur l ensemble des sites FIA-NET sur 24, 48, 72 heures et 7, 15 et 30 jours. Eliminatoire. 10 Hist. de l de livraison Pluralités d éléments rattachés à l de livraison : nombre d utilisateurs, de noms de famille, adresses de facturation/livraison. Eliminatoire. 14 Hist. du mobile de facturation Pluralités d éléments rattachés au mobile de facturation : nombre d utilisateurs, de noms de famille, adresses de facturation/livraison. Eliminatoire. 15 Hist. du mobile de livraison Pluralités d éléments rattachés au mobile de livraison : nombre d utilisateurs, de noms de famille, adresses de facturation/livraison. Eliminatoire. 16 Certificat FIA-NET Client ayant fourni des justificatifs d'identité bancaire ou ayant été contrôlé par un opérateur FIA-NET 18 Incohérence Global CP/Ville Incohérence entre le code postal et la ville du bon de commande par rapport au fichier de La Poste. Eliminatoire. 28 Hist. consommation de l adresse de livraison Montant d'achat cumulé sur l adresse du bon de commande sur l ensemble des sites FIA- NET sur 10 jours. Eliminatoire. 32 Hist. consommation de l IP Montant d'achat cumulé de l'adresse IP du bon de commande sur l ensemble des sites FIA-NET sur 3 heures. Eliminatoire. 34 Profil client sûr Client en base depuis plus de 120 jours, possédant un payant, et commandant pour moins de 1,4 fois votre panier moyen. V5.6.3-dispositif_technique.doc Page 41 sur 81

42 Profils Fixes FIA-NET (Critère numérique) Numéro Libellé Descriptif 35 Hist. consommation de l de facturation Montant d'achat cumulé de l de facturation du bon de commande sur l ensemble des sites FIA-NET et sur 24, 48, 72 heures et 7, 15 et 30 jours. Eliminatoire. 36 Hist. consommation de l de livraison Montant d'achat cumulé de l de livraison du bon de commande sur l ensemble des sites FIA-NET et sur 24, 48, 72 heures et 7, 15 et 30 jours. Eliminatoire. 37 Hist. consommation du mobile de facturation Montant d'achat cumulé du mobile de facturation du bon de commande sur l ensemble des sites FIA-NET et sur 24, 48, 72 heures et 7, 15 et 30 jours. Eliminatoire. 38 Hist. consommation du mobile de livraison Montant d'achat cumulé du mobile de livraison du bon de commande sur l ensemble des sites FIA-NET et sur 24, 48, 72 heures et 7, 15 et 30 jours. Eliminatoire. 39 Historique de l'ip sur 30 jours L adresse IP du bon de commande est particulièrement fraudée sur les 30 derniers jours. Eliminatoire. 40 Transaction Certifiée Transaction ayant été contrôlée et validée par un opérateur FIA-NET. 101 Profil IP L'adresse IP de l'acheteur appartient à une liste de pays à risque et le montant est supérieur à un seuil de risque. Eliminatoire. 102 Profil BIN Le BIN de l'acheteur est différent du pays de la transaction et le montant est supérieur à un seuil de risque. Eliminatoire. 103 Profil acheteur retrait L'acheteur n'est pas "historique parfait FIA-NET", son appartient à une liste gratuite, le montant est supérieur à 1,2 fois votre panier moyen et le retrait de la marchandise se fait sur un réseau à risque. Eliminatoire. 104 Profil achat inconnu L'acheteur n'est pas "historique parfait FIA-NET", son appartient à une liste gratuite et le montant est supérieur à 1,4 fois votre panier moyen. Eliminatoire Liste des profils dynamiques : Cette liste est susceptible de changer sans préavis (en particulier rajout de nouveaux critères). Il est donc fortement recommandé de se référer à la structure <help> ou à l interface du Système d Analyse des Commandes afin de disposer du libellé exact des profils, de leur définition et de leur description. Cette liste correspond au libellé Crit-### Profils Personnalisés (Critère ###) Numéro Libellé Descriptif 0 Profil type d'adresse à risque Adresse dont le type d'activité professionnelle présente un risque car il ne permet pas d'identifier qui y habite. 1 Profil libellé d'adresse à risque Liste des adresses dont le libellé présente un risque, car il est difficile d'identifier qui reçoit le colis 2 Coordonnées de livraison fiables + mail payant Acheteur dont les coordonnées de livraison ont été vérifiées et qui commande avec un e- mail peu risqué ou souscrit par abonnement payant. Il est présent sur les bases FIA-NET depuis 120 jours ou plus. 3 Risques d'usurpation d'identité 1 Commandes qui présentent de forts risques d'usurpation d'identité : l'acheteur commande de la téléphonie pour + de 150 euros. Ses coordonnées sont présentes dans les annuaires, dans un code postal à risque. Il a moins de 120 jours d'ancienneté. 4 Profil acheteur livraison express L'acheteur a un mail gratuit, se fait livrer en express, pour un montant supérieur à 1,2 fois la panier moyen du site 5 Profil acheteur transporteur express L'acheteur a un mail gratuit, se fait livrer par un transporteur express (type UPS, Chronopost), pour un montant supérieur à 1,2 fois le panier moyen du site 6 Profil à risque type L'acheteur a un mail gratuit, des chiffres ou www dans son , se fait livrer pour un montant supérieur à 1,2 fois le panier moyen du site dans des codes postaux à risque V5.6.3-dispositif_technique.doc Page 42 sur 81

43 Profils Personnalisés (Critère ###) Numéro Libellé Descriptif 7 gratuit + pointretrait Le client est titulaire d'un gratuit et se fait livrer en point-retrait 8 Mail gratuit + chiffres L' du client présente plusieurs caractéristiques de risque dans son ou 'www' dans le mail 9 Mail gratuit + codes postaux à risque Le client présente un mail à risque et se fait livrer dans une zone de livraison où les fraudes sont importantes 10 Mail gratuit + téléphonie mobile L'acheteur présente un mail à risque et achète une catégorie de produit fortement fraudée (téléphonie) 11 Mail gratuit + rapidité express L'acheteur présente un mail à risque et se fait livrer avec une rapidité express (24 heures ou moins) 12 gratuit + libellé L'acheteur présente un mail à risque et se fait livrer par un transporteur express du transporteur express 13 payant L'acheteur présente un mail peu risqué 14 Téléphone fixe de location L'acheteur a donné un numéro de téléphone fixe qui se loue temporairement et qui ne correspond pas à sa véritable adresse. 15 Montant faible Le montant est inférieur à 30% du panier moyen du site 16 Risques d'usurpation d'identité 2 L'acheteur se fait livrer dans des codes postaux à risque, pour plus de 300 euros, a un e- mail gratuit, une cohérence parfaite de ses coordonnées dans l'annuaire. Il est présent depuis moins de 120 jours dans la base FIA-NET. 17 Coordonnées de Personnes dont les coordonnées sont présentes dans l'annuaire livraison fiables 18 Coordonnées fiables Les coordonnées de l'utilisateur sont présentes dans les annuaires télématiques. 19 Mail payant L'acheteur emploie un à très faible risque lié à un abonnement payant ou à une société 20 Risques d'usurpation d'identité 3 21 Risques d'usurpation d'identité 4 22 Code postal avec usurpations d'identité 23 Acheteur très récent + CP risqué L'acheteur utilise un mail à fort risque (Yahoo), se fait livrer dans des communes à risque, pour plus de 300 euros et utilise des coordonnées présentes dans les annuaires. Il est présent en base depuis moins de 120 jours. Livraison dans un code postal précis avec des usurpations d'identité en série, coordonnées fiables dans l'annuaire, montant supérieur à 280 euros Le lieu de livraison se trouve dans un code postal précis où des usurpations d'identité en série ont lieu. L'acheteur est présent depuis moins de 30 jours en base et se fait livrer dans des codes postaux à risque. V5.6.3-dispositif_technique.doc Page 43 sur 81

44 5.5.8 Conclusion Résumé : schéma général de récupération des évaluations Nous vous proposons, à titre purement informatif et non exhaustif, une méthodologie type pour analyser correctement nos différents retours d évaluation. Attention, les cas et vérifications indiqués ci-dessous sont donnés à titre indicatif et ne sont pas totalement exhaustifs. // ####################################### // ##### CHECKS LOGIQUES SAC BOF ##### // ####################################### // Début des traitements : récupération d'une évaluation... // ICI VOTRE REQUETE SUR L'EVALUATION D'UNE REFERENCE // (mode GET ou POST - cf Dispositif Technique et 5.2.3) if (retour=="trouvee"){ // transaction effectivement réceptionnée par FIA-NET if (avancement=="traitee"){ // transaction évaluée et donc balise eval disponible if (count=="1"){ // ici cas normal : transaction soumise 1 seule fois (référence non doublonnée)... // insérer votre script actuel ici ou vérifier avec les 3 types de retours d'eval possibles ci-dessous : if (eval=="0"){ // eval strictement égale à zéro : transaction évaluée 'rouge 0%' // voir exemple 4 de retour de flux // il s'agit, ici, des transactions qui théoriquement passent en 'Contrôle Expert' chez FIA-NET (cf retours-types et traitements spécifiques possibles en 5.5.9) } // fin de if (eval=="0") else if (eval>"0"){ // eval strictement supérieure à zéro : transaction évaluée 'vert foncé 100%' // voir exemple 4 de retour de flux } // fin de else if (eval>"0") else (eval<"0"){ // eval strictement inférieure à zéro : transaction évaluée 'vert clair 90%' // voir exemple 4 de retour de flux } // fin de else (eval<"0") } // fin de if (count=="1") else { // attention : transaction soumise plus d'une fois : nous disposons de plusieurs retours d'eval, éventuellement différents pour une même référence! // récupérer 'la' bonne eval... // voir exemple 3 de retour de flux } // fin de else (count >1) } // fin de if (avancement=="traitee") else if (avancement=="encours"){ // transaction en cours de traitement : l'évaluation n'est pas encore disponible // attention : votre requête d'évaluation est prématurée (évaluation du flux non terminée) : impératif : ne jamais resoumettre le flux! // Patienter quelques minutes avant de réinterroger le système. } // fin de else if (avancement=="encours") else { // transaction non traitée : avancement=="error" // attention : gérer une transaction en erreur (invalide : récupérer le motif dans balise detail pour correction) (<detail>champ telhome : format incorrect</detail>) // voir exemple 1 de retour de flux } // fin de else (avancement=="error") } // fin de if (retour=="trouvee") else { // transaction absente (non trouvee : non reçue par FIA-NET donc ni evaluee, ni invalide...) // attention : gérer une transaction absente (retour=="absente" et donc normalement count=="0") // voir exemple 2 de retour de flux } // fin de else (retour=="absente") // fin des traitements // ####################################### // ##### CHECKS LOGIQUES SAC EOF ##### // ####################################### V5.6.3-dispositif_technique.doc Page 44 sur 81

45 Voici, pour information, quelques exemples des retours de flux type possibles de la solution pour chacun des cas ci-dessus : Exemple 1 : Retour d'évaluation de transaction en 'invalide' (évaluation indisponible car impossible sans correction préalable) : <?xml version="1.0" encoding="iso "?> Erreur! Référence de lien hypertexte non valide.<result version="3.1" site="xxxx" refid="673426" retour="trouvee" count="1"> <transaction avancement="error" cid=" "> <detail>champ telhome : format incorrect</detail> </transaction> </result> Exemple 2 : Retour d'évaluation de transaction en 'absente' (transaction non trouvée car non reçue par le système) : <?xml version="1.0" encoding="iso "?> <result version="3.1" site="xxxx" refid="67srfgtgh6" retour="absente" count="0" /> Exemple 3 : Retour d'évaluation de transaction en 'doublon' (plusieurs flux reçus avec la même référence de commande) : <?xml version="1.0" encoding="iso "?> <result version="3.1" site="xxxx" refid="breferencedoublonee9" retour="trouvee" count="4"> <transaction avancement="traitee" cid=" "> <detail>paiement validé</detail> <analyse> <eval date="16/10/ :06:38" critere="###" validation="acheteur connu" info="coordonnées OK + Mail=IP">100</eval> <classement id="15">transactions traitées/validées/automatiquement</classement> </analyse> </transaction> <transaction avancement="traitee" cid=" "> <detail>paiement validé</detail> <analyse> <eval date="16/10/ :06:38" critere="###" validation="acheteur connu" info="coordonnées OK + Mail=IP">100</eval> <classement id="15">transactions traitées/validées/automatiquement</classement> </analyse> </transaction> <transaction avancement="traitee" cid=" "> <detail>paiement validé</detail> <analyse> <eval date="16/10/ :08:16" critere="###" validation="acheteur connu" info="coordonnées OK + Mail=IP">100</eval> <classement id="15">transactions traitées/validées/automatiquement</classement> </analyse> </transaction> <transaction avancement="traitee" cid=" "> <detail>paiement validé</detail> <analyse> <eval date="16/10/ :08:16" critere="###" validation="acheteur connu" info="coordonnées OK + Mail=IP">100</eval> <classement id="15">transactions traitées/validées/automatiquement</classement> </analyse> </transaction> </result> V5.6.3-dispositif_technique.doc Page 45 sur 81

46 Exemple 4 : Retour d'évaluation de transaction trouvée et évaluée 'correctement' : <?xml version="1.0" encoding="iso "?> <result version="3.1" site="xxxx" refid="673466" retour="trouvee" count="1"> <transaction avancement="traitee" cid=" "> <detail>paiement validé</detail> <analyse> <eval date="23/11/ :16:34" critere="###" validation="assuré à 100 %" info="mail payant">100</eval> <classement id="15">transactions traitées/validées/automatiquement</classement> </analyse> </transaction> </result> Conclusion Résumé : complément spécifique pour les transactions en «Contrôle Expert» Lorsque vous avez souscrit à notre option Contrôle Expert, et que vous souhaitez récupérer les traitements effectués par nos opérateurs sur les transactions concernées, vous pouvez prendre en compte ces informations complémentaires. Ces traitements peuvent être pris en compte au sein de la méthodologie de récupération présentée en du présent Dispositif Technique, lorsque la valeur récupérée pour la balise eval est strictement égale au chiffre zéro (transaction initialement non-assurée et à risque, normalement prise en charge par le Contrôle Expert sans action spécifique de votre part). if (eval=="0"){ // eval strictement égale à zéro : transaction évaluée 'rouge 0%' // il vous faut ici récupérer le 'classement' de la transaction pour connaître son niveau de traitement par le Contrôle Expert chez FIA- NET : 1/ Les ClassementID pour les transactions 'rouges' en cours de contrôle par le Contrôle Expert sont : >> 22 FIA-NET/Contrôle Expert/En cours (eval reste rouge) >> 23 FIA-NET/Contrôle Expert/Appel (eval reste rouge) >> 24 FIA-NET/Contrôle Expert/Demande de justificatifs (eval reste rouge) Pour ces transactions, la réévaluation peut toutefois intervenir après un délai de 5 jours, si l'internaute se manifeste 'hors délai'. 2/ L'issue du Contrôle Expert, lorsque celui-ci a abouti, retourne les classements suivants, normalement dans les 5 jours ouvrés : >> 25 Transactions traitées/validées/contrôle expert (eval verte) >> 26 Transactions traitées/rejetées/contrôle expert (eval reste rouge) 3/ Si reclassées (sorties du Contrôle Expert qui n'a pas abouti : absence de réponse ou de retour conforme des pièces) au bout de 5 jours : >> 0 Transactions à traiter/nouvelles (eval reste rouge) >> 1 Transactions à traiter/nouvelles/contrôle visuel (eval reste rouge) >> 2 Transactions à traiter/nouvelles/contrôle téléphonique (eval reste rouge) >> 3 Transactions à traiter/nouvelles/demande de justificatifs (eval reste rouge) } // fin de if (eval=="0") V5.6.3-dispositif_technique.doc Page 46 sur 81

47 6 Envoi de l information livraison (Obligatoire) Lorsque la décision de livraison ou de non-livraison du client a été prise, vous devez nous le faire savoir. Vous restez toujours décisionnaire sur la livraison. Ainsi, certaines transactions non assurées/risque élevé pourront être livrées, d'autres assurées à 90 %/risque faible pourront ne pas l'être. Grâce à ce retour d information supplémentaire, le système prend de la valeur en s enrichissant de l expérience de nos marchands. Ces informations nous permettent un retour statistique sur la pertinence des réponses du système. Ensuite, des correctifs pourront être apportés sur des critères non percutants. Vous pouvez nous faire connaître cette information en vous connectant directement sur notre Back-Office, en nous envoyant manuellement un fichier récapitulatif ou en appelant automatiquement un script de notre système. En utilisant l appel au script, il n y a besoin d aucune manipulation humaine et l information est transmise de façon transparente à notre système (recommandé pour des volumes de transactions importants). Une transaction peut passer par 6 états différents : 1 : Commande expédiée et livrée 2 : Commande non expédiée pour suspicion de fraude 3 : Commande non expédiée pour autre cause 4 : Commande expédiée mais perdue 5 : Commande expédiée mais retour livreur 6 : Commande expédiée mais retour client 6.1 Communication des informations en mode manuel Vous vous rendez sur la page de détail de la transaction soit en passant par notre Back-Office soit en utilisant un lien en «auto-login» à partir de votre propre Back-Office. A partir de cette page, vous pouvez nous informer de votre décision. Qui plus est, en cas de fortes présomptions, vous pouvez nous signaler une transaction particulièrement suspecte. Une équipe évaluera la transaction afin de la mettre ou non dans le fichier alerte. Merci de bien vouloir motiver votre demande à partir d éléments objectifs. 6.2 Communication des informations par fichier Vous nous transmettez un fichier (CSV, TEXT, XLS, etc.), exploitable informatiquement, contenant une liste des références des transactions déjà envoyées au Système d Analyse des Commandes. L'avantage est de vous épargner un développement supplémentaire, une extraction étant juste à réaliser périodiquement. Nous acceptons trois catégories de fichiers (Minimum, Standard et Complet) : Minimum : Liste simple de la référence de toutes les transactions livrées. Exemple 1 : REF_0001 REF_0015 REF_0120 Exemple 2 : REF_001,REF_0015,REF_0120 Standard : Liste des références et états des transactions livrées (1) ou non livrées pour autre cause (3) ou de suspicion de fraude (2). Exemple 1 : REF_ REF_ REF_ Complet : Liste des références et états des transactions pour tous les états pré-cités. Exemple 1 : REF_0101;6 REF_0103;5 REF_0105;4 REF_0120;1 V5.6.3-dispositif_technique.doc Page 47 sur 81

48 6.3 Communication des informations par appel à un script En bref Cette méthode est recommandée pour des volumes de transactions importants. Ceci s'inscrit dans votre chaîne de traitement logistique. En premier lieu, vous nous envoyez les données, vous récupérez les informations de livraison, vous prenez votre décision et enfin, vous nous communiquez cette décision. Pour chaque transaction vous faîtes appel à ce script en indiquant sa référence et son état. Techniquement L URL du script appelé est la suivante : &Pwd= &RefID= &Status= ATTENTION : lorsque vous effectuez les tests d intégration du système, vous devez impérativement utiliser l URL de pré-production. Pendant la phase de pré-production l URL du script appelé est la suivante : &Pwd= &RefID= &Status= Les paramètres d entrée sont : SiteID : Pwd : RefID : Status : Identifiant numérique du site fourni par FIA-NET Mot de passe utilisé pour se connecter sur le système FIA-NET (url-encodé) Référence interne du marchand pour la transaction Etat de livraison (1, 2, 3, 4, 5 ou 6) de la transaction Statuts possibles : 1 : Commande expédiée et livrée 2 : Commande non expédiée pour suspicion de fraude 3 : Commande non expédiée pour autre cause 4 : Commande expédiée mais perdue 5 : Commande expédiée mais retour livreur 6 : Commande expédiée mais retour client Encodage des informations: Pour envoyer le mot de passe (Pwd), vous devez au préalable l encoder au format URL afin de ne pas avoir de problème de transmission de données. Retour du script: Le retour de ce script est un flux XML <result> indiquant uniquement si la mise à jour de l information a eu lieu ou non. Exemples: Vous trouverez en annexe, des exemples d appel et de réponses de ce script. V5.6.3-dispositif_technique.doc Page 48 sur 81

49 7 Envoi de l information sur les fraudes (Obligatoire) Lorsque vous recevez une fraude (avis de débit de votre banque), vous nous envoyez cette information. Grâce à ce retour d information supplémentaire, le système prend de la valeur en s enrichissant de l expérience des vrais cas de fraude. Vous pouvez nous faire connaître cette information vous connectant directement sur notre Back-Office, ou en nous envoyant manuellement un fichier récapitulatif. Lors de la déclaration d une fraude nous avons besoin des informations suivantes : Date de livraison du produit (obligatoire) Date de l avis de débit impayé (obligatoire) Description de l objet (facultatif) Remarque de votre part susceptible de nous aider (facultatif) 7.1 Déclaration de fraude en mode manuel Vous vous rendez sur la page de détail de la transaction soit en passant par notre Back-Office soit en utilisant un lien en «auto-login» à partir de votre propre Back-Office. A partir de cette page, vous pouvez nous déclarer la fraude que vous avez subi sur cette transaction en cliquant sur le petit logo «ambulance» situé à côté du niveau de validation de la transaction. Dans la page suivante, vous serez amené à nous donner les informations nécessaires. 7.2 Déclaration de fraude par fichier Vous nous transmettez un fichier (CSV, TEXT, XLS, etc.), exploitable informatiquement, contenant une liste des références des transactions déjà envoyées au Système d Analyse des Commandes. L'avantage est de vous épargner un développement supplémentaire, une extraction étant juste à réaliser périodiquement. Attention, nous devons pouvoir identifier de façon unique chaque transaction déclarée fraudée. Dans le cas contraire, nous ne pourrons nous permettre de déclarer une fraude sur toutes les transactions ayant ces références. Nous acceptons deux catégories de fichiers (Standard et Complet) : Standard : Liste des références, dates de livraison, dates d ADI. Exemple 1 : REF_0010,10/07/2004,15/10/2004 REF_0003,05/07/2004,01/10/2004 REF_0120,04/08/2004,01/10/2004 Complète : Liste des références, dates de livraison, dates d ADI, descriptions, remarques Exemple 1 : REF_0101;06/05/2004;08/09/2004;dvd;remarque aaa REF_0103;25/05/2004;12/09/2004;cd;remarque bbb REF_0105;20/05/2004;08/09/2004;livre;remarque ccc REF_0120;25/05/2004;06/09/2004;dvd;remarque ddd V5.6.3-dispositif_technique.doc Page 49 sur 81

50 PARTIE III PRE-PRODUCTION / PERIODE DE TESTS V5.6.3-dispositif_technique.doc Page 50 sur 81

51 8 Protocole de tests 8.1 Pourquoi un système test Afin de vous offrir la possibilité de tester votre intégration vis-à-vis de notre système ou d avoir une plateforme de test chez vous «branchée» à notre système, nous possédons un environnement de test complet. Nos algorithmes et outils qui existent sur la production sont aussi testés sur notre pré-production (système test) maintenant celui-ci toujours à jour. En revanche, l intégralité de la base de données n étant pas disponible sur l interface de pré-production, les résultats de l analyse ne seront pas pertinents avant votre passage en production. Il est très important de ne jamais soumettre de transaction tests sur le système en production car cela perturbe son fonctionnement et pollue sa base. En revanche, vous pouvez envoyer des informations et tester votre intégration sur notre système de pré-production. De plus, il est obligatoire d effectuer des tests avant la mise en production afin que vous soyez sûr d envoyer toutes les données dont vous disposez et que leur format soit correct. L intégralité des informations fournies par l internaute lors de sa commande sur le site du marchand doit être envoyée au SAC en vue de leur analyse. Nous vous rappelons que l absence de l une de ces informations entraînera de plein droit la non-garantie de la transaction (Intercalaire «Commerçant Adhérent» Article «Transactions incomplètes»). Les balises <utilisateur>, <adresse> <infocommande> et <paiement> comportent des balises obligatoires qui doivent être impérativement transmises pour permettre l analyse d une transaction. Les transactions transmises par le marchand ne comportant pas ces balises obligatoires seront systématiquement considérées par le SAC comme des transactions invalides. Nous vous rappelons que toute transaction définie par le «Système d Analyse des Commandes» comme «Transaction Invalide» ne pourra ouvrir droit à une quelconque indemnisation (Intercalaire «Commerçant Adhérent» Article «Transactions invalides»). 8.2 Système en test Pendant la première phase et à chaque fois que vous voulez tester la liaison entre nos systèmes et/ou le format des informations envoyées, vous devez utiliser notre système de pré-production qui se à l URL suivante : Attention, en pré-production comme en production, si vous décidez d utiliser le script «stacking.cgi» ou le script «stackfast.cgi», vous devez nous contacter au préalable pour que nous vous autorisions à faire des envois par paquets. Lorsque le site bascule en production, la zone de test reste ouverte pour le cas où des développements ultérieurs seraient envisagés (interface incluse dans le BO, meilleure intégration, reprise sur erreur, etc.) Les données inscrites dans la zone de test sont régulièrement purgées. L évaluation des commandes n est pas à prendre en compte dans la mesure où la zone de test ne comporte pas l ensemble des données mutualisées. La bascule en production, une fois la période de test effectuée, est obligatoire afin d obtenir une réelle évaluation des transactions. Une transaction existant uniquement sur le système en pré-production ne peut obtenir aucune garantie de notre part. V5.6.3-dispositif_technique.doc Page 51 sur 81

52 8.3 Type de structure XML à tester Afin de valider l interfaçage avec le Système d Analyse des Commandes, le site marchand devra tester les différents cas de figures ci-dessous. Dans le cas où le site marchand ne dispose pas de toutes les informations, le test faisant appel à cette ou ces informations ne sera naturellement pas effectué. Cependant, il faut garder à l esprit deux points importants : la multiplicité des critères transmis au FraudScreener maximalise l efficacité du système ; la non transmission d une information entraîne la nullité de la garantie d assurance. Cas minimaliste Pas d , pas de téléphone, pas de prénom <?xml version="1.0" encoding="iso "?> <control> <utilisateur type="facturation" qualite="2"> <nom>albert</nom> </utilisateur> <adresse type="facturation"> <rue1>14 rue d avant</rue1> <cpostal>75015</cpostal> <ville>paris</ville> </adresse> <infocommande> <siteid>112</siteid> <refid>cmde-004</refid> <montant devise="eur">88</montant> </infocommande> </control> </control> Cas standard Un téléphone et sont fournis. L adresse de facturation est identique à l adresse de livraison et l utilisateur de facturation est identique à l utilisateur de livraison. <?xml version="1.0" encoding="iso "?> <control> <utilisateur type="facturation" qualite="2"> <nom>albert</nom> <prenom>pierre-jean</prenom> <telhome> </telhome> < >[email protected]</ > </utilisateur> <adresse type="facturation"> <rue1>14 rue d avant</rue1> <cpostal>75015</cpostal> <ville>paris</ville> </adresse> <infocommande> <siteid>112</siteid> <refid>cmde-004</refid> <montant devise="eur">88</montant> </infocommande> Cas d une entreprise Le nom comprend du numérique mais la qualité étant 1 (entreprise), le champ est accepté. Un est indiqué. <?xml version="1.0" encoding="iso "?> <control> <utilisateur type="facturation" qualite="1"> <nom>entreprise Toto 123</nom> < > [email protected]</ > </utilisateur> <adresse type="facturation"> <rue1>14 rue d avant</rue1> <cpostal>75015</cpostal> <ville>paris</ville> </adresse> <infocommande> <siteid>112</siteid> <refid>cmde-004</refid> <montant devise="eur">88</montant> </infocommande> </control> Cas complet L internaute a fourni un maximum d information sur lui-même et sur son lieu de résidence. L adresse de facturation est identique à l adresse de livraison et l utilisateur de facturation est identique à l utilisateur de livraison. <?xml version="1.0" encoding="iso "?> <control> <utilisateur type="facturation" qualite="2"> <nom>albert</nom> <prenom>pierre-jean</prenom> <telhome> </telhome> <telmobile> </telmobile> <teloffice> </teloffice> < > [email protected]</ > </utilisateur> <adresse type="facturation"> <rue1>14 rue d avant</rue1> <rue2>résidence les Miroirs</rue2> <cpostal>75015</cpostal> <ville>paris</ville> <appartement> <etage>5</etage> <nporte>6</nporte> </appartement> </adresse> <infocommande> <siteid>112</siteid> <refid>cmde-004</refid> <montant devise="eur">88</montant> </infocommande> </control> V5.6.3-dispositif_technique.doc Page 52 sur 81

53 Cas utilisateur livraison L internaute livre à une autre personne à la même adresse. Le site marchand nous a transmis l adresse IP relevée au moment de la commande. <?xml version="1.0" encoding="iso "?> <control> <utilisateur type="facturation" qualite="2"> <nom titre="m">albert</nom> <prenom>jean</prenom> <telmobile> </telmobile> < > [email protected]</ > </utilisateur> <adresse type="facturation"> <rue1>14 rue d avant</rue1> <cpostal>75015</cpostal> <ville>paris</ville> </adresse> <utilisateur type="livraison" qualite="2"> <nom titre="m">toto</nom> <prenom>jean</prenom> </utilisateur> <infocommande> <ip timestamp=" :14:57"> </ip> <siteid>112</siteid> <refid>cmde-004</refid> <montant devise="eur">88</montant> </infocommande> </control> Cas adresse livraison L internaute se fait livrer à une adresse différente de son adresse de facturation. <?xml version="1.0" encoding="iso "?> <control> <utilisateur type="facturation" qualite="2"> <nom>albert</nom> <telmobile> </telmobile> <telmobile> </telmobile> <teloffice> </teloffice> < > [email protected]</ > </utilisateur> <adresse type="facturation"> <rue1>14 rue d avant</rue1> <cpostal>75015</cpostal> <ville>paris</ville> </adresse> <adresse type="livraison"> <rue1>14 rue d après</rue1> <cpostal>75015</cpostal> <ville>paris</ville> </adresse> <infocommande> <siteid>112</siteid> <refid>cmde-004</refid> <montant devise="eur">88</montant> </infocommande> </control> V5.6.3-dispositif_technique.doc Page 53 sur 81

54 Cas complet livraison L internaute livre à une autre personne à une adresse différente. Le site marchand nous a transmis l adresse IP relevée au moment de la commande. <?xml version="1.0" encoding="iso "?> <control> <utilisateur type="facturation" qualite="2"> <nom titre="m">albert</nom> <prenom>pierre-jean</prenom> <telhome> </telhome> <telmobile> </telmobile> <teloffice> </teloffice> < > [email protected]</ > </utilisateur> <adresse type="facturation"> <rue1>14 rue d avant</rue1> <rue2>résidence les Miroirs</rue2> <cpostal>75015</cpostal> <ville>paris</ville> </adresse> <utilisateur type="livraison" qualite="2"> <nom titre="m"> TOTO</nom> < > [email protected]</ > </utilisateur> <adresse type="livraison"> <rue1>14 rue d après</rue1> <cpostal>75015</cpostal> <ville>paris</ville> <appartement> <etage>5</etage> <nporte>6</nporte> </appartement> </adresse> <infocommande> <ip timestamp=" :14:57"> </ip> <siteid>112</siteid> <refid>cmde-004</refid> <montant devise="eur">88</montant> </infocommande> </control> Cas produits et transport Le marchand fournit les informations de produits et de transport. <?xml version="1.0" encoding="iso "?> <control> <utilisateur type="facturation" qualite="2"> <nom>albert</nom> </utilisateur> <adresse type="facturation"> <rue1>14 rue d avant</rue1> <cpostal>75015</cpostal> <ville>paris</ville> </adresse> <infocommande> <transport> <type>1</type> <nom>chronoposte</nom> <rapidite>2</rapidite> </transport> <list nbproduit="1"> <produit type="8" ref="ggxc4">ventilateur</produit> </list> <siteid>112</siteid> <refid>cmde-004</refid> <montant devise="eur">88</montant> </infocommande> </control> V5.6.3-dispositif_technique.doc Page 54 sur 81

55 8.4 Outil d analyse de flux XML Il s agit d un outil de vérification, d analyse et d optimisation des flux générés par votre solution. Il vous permet de vérifier et tester ces flux, repérer les erreurs de formatage et plus globalement fournir un diagnostic sur la qualité des flux retournés. Un clic sur chaque balise permettra d afficher les détails techniques et pratiques sur l usage de la balise concernée. Un score global est alors décliné à l issue de l analyse et vous permet d évaluer le niveau de finesse de votre intégration. Cet outil vous permet donc : - de tester en totale autonomie la validité des flux XML générés et identifier les balises ou valeurs défaillantes ; - d évaluer la qualité de votre intégration au regard de l ensemble des éléments analysables par le SAC. ATTENTION : l analyse issue de cet outil est purement indicative. A l issue de vos tests, si l outil délivre un score a priori suffisant pour permettre une bascule en production, nous vous invitons à contacter votre chargé de suivi technique. Lui seul est à même d interpréter la qualité réelle de vos flux : il procèdera si nécessaire aux dernières vérifications manuelles, afin d aboutir à l ouverture effective en production en cas de succès. L outil d analyse de flux XML du Système d Analyse des Commandes est accessible : - dans le Back-Office, section Transactions / Transactions invalides, lien «Analyse de flux XML» - dans le Back-Office, dans la rubrique «Support, lien «Analyse de flux XML» dans le menu de gauche. - en URL directe : - en mettant en œuvre un formulaire de soumission (POST ou GET) retournant les 3 valeurs suivantes : siteid, pwd et xmldata Les paramètres d entrée sont : Siteid : identifiant numérique du site fourni par FIA-NET Pwd : mot de passe utilisé pour se connecter sur le système FIA-NET (URLencodé) Xmldata : flux XML testé contenant l ensemble des informations pour l analyse V5.6.3-dispositif_technique.doc Page 55 sur 81

56 Fonctionnement global : L outil affiche l ensemble des balises et attributs attendus, qu ils soient facultatifs ou obligatoires. Une colonne «Diagnostic» détaille l origine du problème. Le fonctionnement de l analyseur est simple : Il suffit de copier/coller le contenu du flux testé (déclaration XML et encoding suivie de la balise <control> </control>) dans la zone de texte et de cliquer sur le bouton «Analyser». La page retourne un rapport sous la forme de tableau, et indique si le flux est valide ou non avec un diagnostic pour chaque balise analysée (indique les valeurs et attributs manquants/incorrects). Ce check ne permet toutefois pas de diagnostiquer les erreurs de syntaxe XML (un flux XML non valide ne sera simplement pas analysé). Tout retour XML invalide (non parsable) empêche l analyse et la délivrance d un score et la validation de votre flux. Résultat de l analyse: Les lignes à fond vert clair indiquent la présence de balises dont le format est valide (attributs compris) ; Les lignes à fond gris indiquent l absence, non bloquante, dans votre flux de balises ou attributs optionnels ; Les lignes à fond orange indiquent l absence, bloquante, dans votre flux de balises ou attributs obligatoires ou d erreurs de format de données ; Attribution de points et délivrance d un score global : Le renseignement correct des «balises minimales» attendues permet d obtenir un score minimum ; Seules les balises renseignées avec tous leurs attributs obligatoires permettent d obtenir des points, pour arriver à 100% si toutes les balises facultatives sont retournées ; Les balises qui ont une valeur correcte mais un attribut obligatoire absent sont déclarées invalides et n apportent aucun point dans le score total ; Les points attribués à une balise ne dépendent pas de la présence des attributs optionnels. V5.6.3-dispositif_technique.doc Page 56 sur 81

57 8.5 Bascule en Production Une fois les principaux tests effectués, le marchand reprendra contact avec l équipe technique pour la bascule en production. Cette bascule se fait rapidement dans la mesure où les éléments ont été validés au préalable par l équipe technique. Le texte pages suivante doit être retourné complet par fax au V5.6.3-dispositif_technique.doc Page 57 sur 81

58 Demande de passage en production sur SiteID : Login : Date : / /2010 Nom du Responsable: Balises attendues Mise en place du Système d Analyse des Commandes et Engagements Retour OBLIGATOIRE / IMPORTANT Valeur retournée (OUI/NON) ( ref SPECIMEN ) Balise <?xml version="1.0" encoding="iso > OBLIGATOIRE OUI NON Balise <control> : OBLIGATOIRE OUI NON Balise <utilisateur type="facturation"> : OBLIGATOIRE OUI NON Propriété «type» : OBLIGATOIRE OUI NON Propriété «qualite» : IMPORTANT (1) OUI NON Balises <nom> + <prenom> + «titre» : OBLIGATOIRE OUI NON <societe> : IMPORTANT (2) OUI NON Balises <telhome> et/ou <teloffice> et/ou <telmobile> OBLIGATOIRE OUI NON Contrôles de formatage effectués sur les champs tél & IMPORTANT (3) OUI NON <telfax> : IMPORTANT (4) OUI NON < > : OBLIGATOIRE OUI NON Balise <utilisateur type="livraison"> retournée : (obligatoire si présent dans formulaire) IMPORTANT (5) OUI NON Balise <adresse type="facturation"> : OBLIGATOIRE OUI NON Propriétés <format> + <type> : OBLIGATOIRE OUI NON Balises <rue1> et/ou <rue2> : OBLIGATOIRE OUI NON Balises <cpostal> + <ville> + <pays> : OBLIGATOIRE OUI NON Balise <adresse type="livraison"> retournée : (obligatoire si présent dans formulaire) IMPORTANT (6) OUI NON Balise <appartement>: IMPORTANT (7) OUI NON Balise <infocommande> : OBLIGATOIRE OUI NON Balises <siteid> + <refid> : OBLIGATOIRE OUI NON Balises <montant> + «devise» : OBLIGATOIRE OUI NON Balises <ip> (propre à l'internaute) + «timestamp» : OBLIGATOIRE OUI NON Balise <transport> : (OBLIGATOIRE si assurance) IMPORTANT (8) OUI NON Balises <type> + <nom> + <rapidité> : (OBLIGATOIRE si assurance) IMPORTANT (9) OUI NON Balise <list> : (OBLIGATOIRE si assurance) IMPORTANT (10) OUI NON propriété «nbproduit» de <list> : (OBLIGATOIRE si assurance) IMPORTANT (11) OUI NON Balises <produit> + «type» : (OBLIGATOIRE si assurance) IMPORTANT (12) OUI NON propriété «ref» de <produit> : IMPORTANT (13) OUI NON propriété «nb» de <produit> : IMPORTANT (14) OUI NON Balise <paiement> : OBLIGATOIRE OUI NON <type> : ( cb en n fois impérativement indiqué si proposé : voir page 2/2 du présent document de bascule) OBLIGATOIRE OUI NON <numcb> : (obligatoire si disponible) IMPORTANT (15) OUI NON <dateval> : (obligatoire si disponible) IMPORTANT (16) OUI NON <bin> : IMPORTANT (17) OUI NON Informations Techniques : L'envoi des informations a-t-il lieu après paiement effectif de l'internaute ou autorisation délivrée par la banque? IMPORTANT (18) OUI NON Informez-vous vos clients de la transmission de leurs informations personnelles à Fia Net pour analyse, au sein de vos Conditions Générales de Vente? OBLIGATOIRE OUI NON Méthode d'envoi des informations de livraison des commandes : Manuel Envoi périodique d'un fichier Script Non retournée Comment avez-vous prévu de déclarer les fraudes subies à Fia Net? Manuel dans le BO Fia Net Envoi périodique d'un fichier Courrier Fax V5.6.3-dispositif_technique.doc Page 58 sur 81

59 IMPORTANT : Mise en garde sur l Optimisation des Analyses retournées par FIA-NET : En première page du présent document de bascule, des données marquées IMPORTANTES vous ont éventuellement été signalées comme non-retournées à notre système. Vous trouverez donc ci-dessous les mises en garde correspondantes au non-renseignement de ces valeurs signalées IMPORTANTES (cases cochées) pour mener à bien nos analyses : (1) Propriété «qualite» : Madame/Monsieur/Mademoiselle ou équivalent étranger (2) Balise <societe> : permet la facturation ou la livraison à une société (12 % des transactions environ). La présence de la balise permet de mieux repérer ces cas et d éviter des évaluations «risquées» non justifiées. (3) (4) Contrôles de formatage effectués sur les champs tél & & telfax : permet une optimisation des recherches sur les annuaires télématiques et évite des temps de traitements post-commande qui ralentissent le traitement ( s ou téléphones invalides à 6 ou 11 chiffres, ou avec des lettres). Ce type d erreurs génère 12 % de transactions invalides environ. (5) (6) Balises <utilisateur type="livraison"> et <adresse type="livraison"> : 23 % des internautes vivant dans une grande ville préfèrent une livraison sur leur lieu de travail, ou souhaitent offrir et livrer un(e) ami(e). Permet de lier un internaute à plusieurs adresses différentes et d éviter des évaluations «risquées» non justifiées. (7) Balise <appartement>: permet de préciser le lieu de livraison, notamment lorsque plusieurs internautes habitent le même immeuble/bâtiment, voire le même étage. Evite les blocages évaluations «risquées» pour consommation excessive à une même adresse (11 % des transactions à risque environ). (8) (9) (10) (11) (12) (13) (14) Balises <transport>, <list>, propriétés «ref» et «nb» de <produit> : permettent de qualifier les commandes et analyser les habitudes de consommation chez un marchand, éventuellement en suivant les consommations de l internaute sur un site et une période donnée. Le renseignement de l ensemble de ces balises est impératif en cas de souscription à l assurance FIA-NET. (15) (16) (17) Balises <numcb> + <dateval> + <bin> : permet de vérifier la provenance géographique de la carte bancaire utilisée pour le paiement et de repérer les fraudeurs utilisant plusieurs cartes bancaires ou le même n. (18) Envoi après paiement effectif de l internaute : évite de scorer des internautes qui ne finaliseraient pas leur commande sur le site marchand (11% des tentatives de commande). En outre, cela évite au marchand d être facturé sur un CA soumis mais ne rentrant pas dans le CA effectivement réalisé. ================================================================================================= PAIEMENT PAR CB EN PLUSIEURS FOIS : l indication cb en N fois est impérative si le site le propose. pas de paiement en N fois paiement en N fois indiqué dans balise type de paiement ================================================================================================= Attention : Les valeurs signalées "OBLIGATOIRE" doivent être retournées IMPERATIVEMENT par le marchand pour bénéficier d'une bascule en production. Les valeurs signalées "IMPORTANT" (points cochés 1 à 18) qui ne sont volontairement pas retournées dans le flux altèrent largement nos évaluations, ce qui peut augmenter les transactions refusées et dans certains cas entraîner une déchéance de garantie. Ces risques IMPORTANTS vous étant notifiés (cases cochées indiquant une information non transmise ou erronée), la bascule en production ne pourra intervenir qu'après la signature du présent document de décharge, qui vous informe clairement des risques encourus suite au non-renseignement de ces valeurs. En signant ce document, vous reconnaissez avoir été informé des risques liés à la non-transmission de l intégralité des informations requises, et en assumez l entière responsabilité. Je reconnais avoir pris connaissance de l intégralité du présent dispositif technique concernant les différentes modalités et règles à respecter dans le cadre de la transmission d informations depuis mon site Internet vers le SAC développé par FIA- NET. Conformément à ce dispositif, un plan de test complet («Type de structure XML à tester») a été effectué. Ces tests ont été validés en l état par l équipe technique de FIA-NET, sous réserve de la transmission complète des informations de notre bon de commande. Je m engage à respecter le présent dispositif et opte pour la méthode de transmission des informations suivante : (Cochez la case en face de la méthode choisie) Méthode «on-line» POST (redirect.cgi) Méthode «on-line» GET (singet.cgi) Méthode «off-line» UNE PAR UNE POST (redirect.cgi) Méthode «off-line» UNE PAR UNE GET (singet.cgi) Méthode «off-line» GROUPEES (stacking.cgi ou stackfast.cgi) Méthode Manuelle Date, signature et cachet de la société V5.6.3-dispositif_technique.doc Page 59 sur 81

60 PARTIE IV ANNEXES V5.6.3-dispositif_technique.doc Page 60 sur 81

61 9 Annexe 1 : Exemples 9.1 Flux XML <control> simple <?xml version="1.0" encoding="iso "?> <control> <adresse type="facturation" format="1"> <rue1>39 rue Saint-Lazare</rue1> <cpostal>75009</cpostal> <ville>paris</ville> <pays>france</pays> </adresse> <utilisateur type="facturation" qualite="1">??? <nom titre="monsieur">albert</nom> <prenom>pierre-jean</prenom> < >[email protected]</ > </utilisateur> <infocommande> <siteid>1</siteid> <refid>mm858</refid> <montant devise="eur"> </montant> <ip timestamp=" :11:56"> </ip> <transport> <type>4</type> <nom>la Poste</nom> <rapidite>2</rapidite> </transport> <list nbproduit="1"> <produit type="8" ref="pbg4-001">powerbook G4 867 Mhz</produit> </list> </infocommande> <paiement> <type>carte</type> <bin>459004</bin> </paiement> </control> V5.6.3-dispositif_technique.doc Page 61 sur 81

62 9.2 Flux XML <control> avec adresse de facturation et adresse de livraison <?xml version="1.0" encoding="iso "?> <control> <utilisateur type="facturation" qualite="1">??? <nom titre="monsieur">albert</nom> <prenom>pierre-jean</prenom> <telhome> </telhome> <teloffice> </teloffice> </utilisateur> <adresse type="facturation" format="1"> <rue1>39 rue Saint-Lazare</rue1> <cpostal>75009</cpostal> <ville>paris</ville> <pays>france</pays> <appartement> <digicode1>1234</digicode1> <etage>5</etage> <nporte>6</nporte> </appartement> </adresse> <adresse type="livraison" format="1"> <rue1>saint Herbot</rue1> <cpostal>29510</cpostal> <ville>loquefret</ville> <pays>france</pays> </adresse> <infocommande> <siteid>1</siteid> <refid>mm858</refid> <montant devise="eur"> </montant> <ip timestamp=" :11:56"> </ip> <transport> <type>2</type> <nom>coliposte</nom> <rapidite>2</rapidite> </transport> <list nbproduit="2"> <produit type="7" ref="xy-001">fleurs bouquetx12</produit> <produit type="7" ref="xy-004">vase</produit> </list> </infocommande> <paiement> <type>carte</type> <numcb>1a2b3c4d1a2b3c4d1a2b3c4d1a2b3c4d</numcb> <dateval>1a2b3c4d1a2b3c4d1a2b3c4d1a2b3c4d</dateval> <bin>459004</bin> </paiement> </control> V5.6.3-dispositif_technique.doc Page 62 sur 81

63 9.3 Flux XML <stack> pour stacking.cgi ou stackfast.cgi <?xml version="1.0" encoding="iso "?> <stack> <control> <utilisateur type="facturation" qualite="1">??? <nom titre="monsieur">albert</nom> <prenom>pierre-jean</prenom> </utilisateur> <adresse type="facturation" format="1"> <rue1>39 rue Saint-Lazare</rue1> <cpostal>75009</cpostal> <ville>paris</ville> <pays>france</pays> </adresse> <infocommande> <siteid>1</siteid> <refid>mm858</refid> <montant devise="eur"> </montant> <ip timestamp=" :11:56"> </ip> <transport> <type>4</type> <nom>la Poste</nom> <rapidite>2</rapidite> </transport> <list nbproduit="1"> <produit type="8" ref="pbg4-001">powerbook G4 867 Mhz</produit> </list> </infocommande> <paiement> <type>carte</type> <bin>459004</bin> </paiement> </control> <control> <utilisateur type="facturation" qualite="1">??? <nom titre="monsieur">albert</nom> <prenom>pierre-jean</prenom> </utilisateur> <adresse type="facturation" format="1"> <rue1>39 rue Saint-Lazare</rue1> <cpostal>75009</cpostal> <ville>paris</ville> <pays>france</pays> </adresse> <infocommande> <siteid>1</siteid> <refid>mm858</refid> <montant devise="eur">799.00</montant> <ip timestamp=" :11:56"> </ip> <transport> <type>4</type> <nom>la Poste</nom> <rapidite>2</rapidite> </transport> <list nbproduit="1"> <produit type="8" ref="mmg4-001">mac mini G4 867 Mhz</produit> </list> </infocommande> <paiement> <type>carte</type> <bin>459004</bin> </paiement> </control> </stack> V5.6.3-dispositif_technique.doc Page 63 sur 81

64 9.4 Intégration en méthode GET avec tag <img> <html><head>...</head> <body> <img src=" controlcallback=%3ccontrol%3e%3cutilisateur%3e...%3c%2futilisateur%3e%3cadresse% 3E...%3C%2Fadresse%3E%3Cinfocommande%3E...%3C%2Finfocommande%3E%3C%2Fcontrol%3E" border="0"> </body> </html> La chaîne passée en argument controlcallback correspond au flux XML, mais url-encodée, d une transaction : <control> <utilisateur>...</utilisateur> <adresse>...</adresse> <infocommande>...</infocommande> </control> V5.6.3-dispositif_technique.doc Page 64 sur 81

65 9.5 Intégration en méthode POST en PHP La page codée est une page intermédiaire après le formulaire de saisie, qui formate le flux <control>, prépare un formulaire pour envoyer les données à notre système et soumet automatiquement ce formulaire. Cet exemple n est pas utilisable en l état et doit d abord être adapté à vos pages. <html> <head></head> <body> <? $XControl = "<control><utilisateur type='facturation' qualite='2'>"; $XControl.= "<nom titre='".$ufacttitre."'>".$ufactnom."</nom>< >". $UFact ."</ >"; if ($UFactPrenom!= '') $XControl.= "<prenom>".$ufactprenom."</prenom>"; if ($UFactSociete!= '') $XControl.= "<societe>".$ufactsociete."</societe>"; if ($UFactPhone!= '') $XControl.= "<telhome>".$ufactphone."</telhome>"; if ($UFactMobile!= '') $XControl.= "<telmobile>".$ufactmobile."</telmobile>"; if ($UFactEntreprise!= '') $XControl.= "<teloffice>".$ufactentreprise."</teloffice>"; $XControl.= "</utilisateur><adresse type='facturation' format='1'><rue1>". $AFactRue1."</rue1>"; if ($AFactRue2!= '') $XControl.= "<rue2>".$afactrue2."</rue2>"; $XControl.= "<cpostal>".$afactcpostal."</cpostal><ville>".$afactville. "</ville><pays>france</pays>"; if (($AFactDCode1!= '') ($AFactDCode2!= '') ($AFactBatiment!= '') ($AFactEscalier!= '') ($AFactEtage!= '') ($AFactNPorte!='')){ $XControl.= "<appartement>"; if ($AFactDCode1!= '') $XControl.= "<digicode1>".$afactdcode1."</digicode1>"; if ($AFactDCode2!= '') $XControl.= "<digicode2>".$afactdcode2."</digicode2>"; if ($AFactBatiment!= '') $XControl.= "<batiment>".$afactbatiment."</batiment>"; if ($AFactEscalier!= '') $XControl.= "<escalier>".$afactescalier."</escalier>"; if ($AFactEtage!= '') $XControl.= "<etage>".$afactetage."</etage>"; if ($AFactNPorte!= '') $XControl.= "<nporte>".$afactnporte."</nporte>"; $XControl.= "</appartement>"; } $XControl.= "</adresse>"; $XControl.= "<infocommande>"; $XControl.= "<refid>".$commanderef."</refid>"; $XControl.= "<siteid>".$siteid."</siteid>"; $XControl.= "<montant devise='eur'>".$commandeprix."</montant>"; $XControl.= "</infocommande>"; $XControl.= "</control>"; $XControl = trim($xcontrol); $XControl = str_replace("\\'","'",$xcontrol); $XControl = str_replace("\\\"","\"",$xcontrol); $XControl = str_replace("\\\\","\\",$xcontrol); $XControl = str_replace("\t","",$xcontrol); $XControl = str_replace("\n","",$xcontrol); $XControl = str_replace("\r","",$xcontrol);?> <form name="formulaire" method="post" action=" <input type="hidden" name="siteid" value="<? echo $SiteID?>"> <input type="hidden" name="urlcallback" value=" <input type="hidden" name="controlcallback" value="<? echo $XControl?>"> </form> <script language= javascript >document.formulaire.submit();</script> </body> </html> V5.6.3-dispositif_technique.doc Page 65 sur 81

66 9.6 Intégration en méthode POST en ASP La page codée est une page intermédiaire après le formulaire de saisie, qui formate le flux <control>, prépare un formulaire pour envoyer les données à notre système et soumet automatiquement ce formulaire. Cet exemple n est pas utilisable en l état et doit d abord être adapté à vos pages. <%@ Language=VBScript %> <% Option Explicit %> <html> <head></head> <body> <% dim fluxxml,montant,name,firstname dim phone,phone2,fax,street,zip,city,state Montant = request("montant") name = request("name") firstname = request("firstname") societe = request("societe") phone = request("phone") phone2 = request("phone2") fax = request("fax") street = request("street") zip = request("zip") city = request("city") state = request("state") state = ucase(state) fluxxml = "<control><utilisateur type='facturation' qualite='2'>" if (name <> "") then fluxxml = fluxxml & "<nom>" & name & "</nom>" if (firstname <> "") then fluxxml = fluxxml & "<prenom>" & firstname & "</prenom>" if (societe <> "") then fluxxml = fluxxml & "<societe>" & societe & "</societe>" if (phone <> "") then fluxxml = fluxxml & "<telhome>" & phone & "</telhome>" if (phone2 <> "") then fluxxml = fluxxml & "<telmobile>" & phone2 & "</telmobile>" if (fax <> "") then fluxxml = fluxxml & "<fax>" & fax & "</fax>" fluxxml = fluxxml & "</utilisateur>" fluxxml = fluxxml & "<adresse type='facturation' format='1'>" if (street <> "") then fluxxml = fluxxml & "<rue1>" & street & "</rue1>" if (zip <> "") then fluxxml = fluxxml & "<cpostal>" & zip & "</cpostal>" if (city <> "") then fluxxml = fluxxml & "<ville>" & city & "</ville>" if (state <> "") then fluxxml = fluxxml & "<pays>" & state & "</pays>" else fluxxml = fluxxml & "<pays>france</pays>" end if fluxxml = fluxxml & "</adresse><infocommande>" fluxxml = fluxxml & "<refid>000-xxxx</refid><siteid>678</siteid>" fluxxml = fluxxml & "<montant devise='eur'>" & Montant & "</montant>" fluxxml = fluxxml & "</infocommande></control>" %> <form name="formulaire" method="post" action=" <input type="hidden" name="siteid" value="<%= siteid %>"> <input type="hidden" name="urlcallback" value=" <input type="hidden" name="controlcallback" value="<%= fluxxml %>"> <input type="hidden" name="paracallback" value="<paramcback><obj><name>mt</name><value><%= Montant%></value></obj></ParamCBack>"> </form> <script>document.formulaire.submit();</script> </body> </html> V5.6.3-dispositif_technique.doc Page 66 sur 81

67 9.7 Intégration en méthode POST en javascript La page codée représente votre formulaire de saisie, y est ajouté le formatage du flux <control> et l envoi des données à notre système par l intermédiaire d un formulaire. Cet exemple n est pas utilisable en l état et doit d abord être adapté à vos pages. <html><head> <script language= javascript > function Verif(){ if (document.paiement.last_name.value == "") { alert("n'oubliez pas d'indiquer votre nom"); return false; } if (document.paiement.first_name.value == "") { alert("n'oubliez pas d'indiquer votre prénom"); return false; } if (document.paiement. .value == "") { alert("veuillez indiquer votre "); return false; } if (document.paiement.ship_to_address1.value == "") { alert("n'oubliez pas d'indiquer votre adresse"); return false; } if (document.paiement.ship_to_address3.value == "") { alert("n'oubliez pas d'indiquer votre code postal"); return false; } if (document.paiement.ship_to_address4.value == "") { alert("n'oubliez pas d'indiquer votre ville"); return false; } return true; } function getxml(){ ret=verif(); if (ret){ XControl = '<control><utilisateur type=\'facturation\' qualite\'2\'>'; XControl += '<nom titre=\''+ document.paiement.civilite.options[document.paiement.civilite.selectedindex].value + '\'>'+document.paiement.last_name.value+'</nom>'; XControl += '<prenom>'+document.paiement.first_name.value+'</prenom>'; XControl += '<societe>'+document.paiement.societe.value+'</societe>'; XControl += '< >'+document.paiement. .value+'</ >'; XControl += '<telhome>'+document.paiement.telephone.value+'</telhome>'; XControl += '<telmobile>'+document.paiement.portable.value+'</telmobile>'; XControl += '</utilisateur><adresse type=\'facturation\' format=\'1\'>'; XControl += '<rue1>'+document.paiement.ship_to_address1.value+'</rue1>'; XControl += '<rue2>'+document.paiement.ship_to_address2.value+'</rue2>'; XControl += '<cpostal>'+document.paiement.ship_to_address3.value+'</cpostal>'; XControl += '<ville>'+document.paiement.ship_to_address4.value+'</ville>'; XControl += '<pays>france</pays>'; if ((document.paiement.codeporte.value!="") (document.paiement.etage.value!="") (document.paiement.appt.value!="")){ XControl += '<appartement>'; if (document.paiement.codeporte.value!="") XControl += '<digicode1>'+document.paiement.codeporte.value+'</digicode1>'; if (document.paiement.etage.value!="") XControl += '<etage>'+document.paiement.etage.value+'</etage>'; if (document.paiement.appt.value!="") XControl += '<nporte>'+document.paiement.appt.value+'</nporte>'; XControl += '</appartement>'; } XControl += '</adresse><infocommande><refid>ref-001</refid><siteid>225</siteid>'; XControl += '<montant devise=\'eur\'>230.60</montant></infocommande></control>'; document.sform.controlcallback.value=xcontrol; document.sform.submit(); } return ret; } </script> <body> <form name="sform" method="post" action=" <input type="hidden" name="siteid" value="xxxx"> <input type="hidden" name="urlcallback" value=" <input type="hidden" name="controlcallback" value="<control></control>"> </form> <!-- suite de la page du marchand avec formulaire PAIEMENT apparent --> </body> </html> V5.6.3-dispositif_technique.doc Page 67 sur 81

68 9.8 Envoi «off-line» multiple en méthode POST Le marchand envoi régulièrement (ex : toutes les heures) les dernières transactions validées. La page envoie une transaction vers notre système et demande une redirection vers elle-même pour envoyer la transaction suivante, jusqu à ce qu il n y ait plus de transaction. Cet exemple n est pas utilisable en l état et doit d abord être adapté à votre système. Les parties propres à votre système ne sont pas codées mais juste indiquées. <html> <head></head> <body> <? ******** Requête pour savoir si encore des transactions à envoyer ******* if ($NbReqEnvoi!= 0){ ************* On estime que les différentes variables (UfactNom, CommandePrix, ) sont renseignées par la précédente requête **************************** $XControl = "<control><utilisateur type='facturation' qualite='2'>"; $XControl.= "<nom titre='".$ufacttitre."'>".$ufactnom."</nom>< >". $UFact ."</ >"; if ($UFactPrenom!= '') $XControl.= "<prenom>".$ufactprenom."</prenom>"; if ($UFactSociete!= '') $XControl.= "<societe>".$ufactsociete."</societe>"; if ($UFactPhone!= '') $XControl.= "<telhome>".$ufactphone."</telhome>"; if ($UFactMobile!= '') $XControl.= "<telmobile>".$ufactmobile."</telmobile>"; if ($UFactEntreprise!= '') $XControl.= "<teloffice>".$ufactentreprise."</teloffice>"; $XControl.= "</utilisateur><adresse type='facturation' format='1'><rue1>". $AFactRue1."</rue1>"; if ($AFactRue2!= '') $XControl.= "<rue2>".$afactrue2."</rue2>"; $XControl.= "<cpostal>".$afactcpostal."</cpostal><ville>".$afactville. "</ville><pays>france</pays>"; if (($AFactDCode1!= '') ($AFactDCode2!= '') ($AFactBatiment!= '') ($AFactEscalier!= '') ($AFactEtage!= '') ($AFactNPorte!='')){ $XControl.= "<appartement>"; if ($AFactDCode1!= '') $XControl.= "<digicode1>".$afactdcode1."</digicode1>"; if ($AFactDCode2!= '') $XControl.= "<digicode2>".$afactdcode2."</digicode2>"; if ($AFactBatiment!= '') $XControl.= "<batiment>".$afactbatiment."</batiment>"; if ($AFactEscalier!= '') $XControl.= "<escalier>".$afactescalier."</escalier>"; if ($AFactEtage!= '') $XControl.= "<etage>".$afactetage."</etage>"; if ($AFactNPorte!= '') $XControl.= "<nporte>".$afactnporte."</nporte>"; $XControl.= "</appartement>"; } $XControl.= "</adresse><infocommande><refid>".$commanderef."</refid>"; $XControl.= "<siteid>".$siteid."</siteid>"; $XControl.= "<montant devise='eur'>".$commandeprix."</montant>"; $XControl.= "</infocommande></control>"; $XControl = trim($xcontrol); $XControl = str_replace("\\'","'",$xcontrol); $XControl = str_replace("\\\"","\"",$xcontrol); $XControl = str_replace("\\\\","\\",$xcontrol);$xcontrol = str_replace("\t","",$xcontrol); $XControl = str_replace("\n","",$xcontrol); $XControl = str_replace("\r","",$xcontrol);?> <form name="formulaire" method="post" action=" <input type="hidden" name="siteid" value="<? echo $SiteID?>"> <input type="hidden" name="urlcallback" value=" <input type="hidden" name="controlcallback" value="<? echo $XControl?>"> </form> <script>document.formulaire.submit();</script> <? }else{?> Script terminé : plus de transactions à envoyer. <? }?> </body></html> V5.6.3-dispositif_technique.doc Page 68 sur 81

69 9.9 Lien au Back-Office FIA-NET en «auto-login» Appels à get_validation.cgi Pour obtenir une réponse standard sur la référence REF001 sans résultat France Télécom : NET.com/fscreener/engine/get_validation.cgi?SiteID=XXX&Pwd=pass&RefID=REF001&RepFT=0 Pour obtenir le mode «help» : Appel à redirect_validation.cgi NET.com/fscreener/engine/redirect_validation.cgi?SiteID=XXX&Pwd=pass&RefID=REF002&RepFT=0&urlB ack= V5.6.3-dispositif_technique.doc Page 69 sur 81

70 9.12 Flux <result> (mode «full») en réponse à get_validation.cgi Exemple A avec historique de l IP : <?xml version="1.0" encoding="iso "?> <result version="3.1" site="678" refid=" xgf1z" retour="trouvee" count="2"> <transaction avancement="traitee" cid=" "> <detail>absence des informations bancaires</detail> <blackliste valeur="non" incident="0" alerte="0" /> <adresse> </adresse> <ip granted="1" valid="1" conso="1" nbflag="1"> <country>fra</country> <conso> <h3 nb="3" mt="476" nbuser="1" nbmysite="3" mtmysite="476">1</h3> </conso> <nbflag> <detail firstdate="2005/09/30" lastdate="2005/10/21" delai="21" nbflag="10" nb="16">0</detail> </nbflag> </ip> <historique ="1" mobile="1" cb="1" valeur="-1" consomail="1" consomobil="1"> </historique> <profil> </profil> <analyse> </analyse> </transaction> <transaction avancement="traitee" cid=" "> <detail>absence des informations bancaires</detail> <blackliste valeur="non" incident="0" alerte="0" /> <adresse> </adresse> <ip granted="1" valid="1" conso="1" nbflag="1"> <country>fra</ country > <conso> <h3 nb="3" mt="476" nbuser="1" nbmysite="3" mtmysite="476">1</h3> </conso> <nbflag> <detail firstdate="2005/09/30" lastdate="2005/10/21" delai="21" nbflag="10" nb="16">0</detail> </nbflag> </ip> <historique ="1" mobile="1" cb="1" valeur="-1" consomail="1" consomobil="1"> </historique> <profil> </profil> <analyse> </analyse> </transaction> </result> V5.6.3-dispositif_technique.doc Page 70 sur 81

71 Exemple Abis avec historique de l IP dans le cas d une custo: <?xml version="1.0" encoding="iso "?> <result version="3.1" site="678" refid=" xgf1z" retour="trouvee" count="2"> <transaction avancement="traitee" cid=" "> <detail>absence des informations bancaires</detail> <blackliste valeur="non" incident="0" alerte="0" /> <adresse> </adresse> <ip granted="1" valid="1" conso="1" nbflag="1"> <country>fra</country> <conso> <h3 nb="3" mt="476" nbuser="1" nbmysite="3" mtmysite="476">1</h3> </conso> <nbflag> <detail firstdate="2005/09/30" lastdate="2005/10/21" delai="21" nbflag="10" nb="16">0</detail> </nbflag> </ip> <historique ="1" mobile="1" cb="1" valeur="-1" consomail="1" consomobil="1"> </historique> <profil> </profil> <analyse> </analyse> </transaction> <transaction avancement="traitee" cid=" "> <detail>absence des informations bancaires</detail> <blackliste valeur="non" incident="0" alerte="0" /> <adresse> </adresse> <ip granted="1" valid="1" conso="1" nbflag="1"> <country>fra</country> <conso> <h3 nb="3" mt="476" nbuser="1" nbmysite="3" mtmysite="476">1</h3> </conso> <nbflag> <detail firstdate="2005/09/30" lastdate="2005/10/21" delai="21" nbflag="10" nb="16">0</detail> </nbflag> </ip> <historique ="1" mobile="1" cb="1" valeur="-1" consomail="1" consomobil="1"> </historique> <profil> </profil> <analyse> </analyse> </transaction> </result> V5.6.3-dispositif_technique.doc Page 71 sur 81

72 Exemple B avec historique de livraison : <?xml version="1.0" encoding="iso "?> <result version="3.1" site="678" refid="1zwfx" retour="trouvee" count="1"> <transaction avancement="traitee" cid=" "> <detail>paiement validé</detail> <blackliste valeur="oui" incident="1" alerte="0" /> <incident> </incident> </blackliste> <adresse livr="1"> <coherencecpville>0</coherencecpville> <facturation conso="0"> <coherenceft>0</coherenceft> <listeinterdit detail="">non</listeinterdit> </facturation> <livraison conso="0"> <coherenceft>80</coherenceft> <listeinterdit detail="">non</listeinterdit> </livraison> <conso> <j10 nb="3" mt="680" nbuser="1" nbmysite="2" mtmysite="680">1</j10> </conso> </adresse> <ip granted="1" valid="0" conso="0" nbflag="0"> <country>---</country> </ip> <historique ="1" mobile="1" cb="1" valeur="0" consomail="0" consomobil="0"> <utilisateur nbfix="1" nbmob="1" nbcb="0" nbmail="1" nbafact="1" nbalivr="0">1</utilisateur> < nbuser="1" nbname="1" nbafact="1" nbalivr="0">1</ > <mobile nbuser="1" nbname="1" nbafact="1" nbalivr="0">1</mobile> <consommation nbtotal="1" firstconso="20/02/ :00:36" nbsite="1" nbsurcesite="1"> <h24 nb="1" mt="440" nbuser="1" nbmysite="1" mtmysite="440">1</h24> <h48 nb="1" mt="440" nbuser="1" nbmysite="1" mtmysite="440">1</h48> <h72 nb="1" mt="440" nbuser="1" nbmysite="1" mtmysite="440">1</h72> <j7 nb="1" mt="440" nbuser="1" nbmysite="1" mtmysite="440">1</j7> <j15 nb="1" mt="440" nbuser="1" nbmysite="2" mtmysite="440">1</j15> <j30 nb="1" mt="440" nbuser="1" nbmysite="2" mtmysite="440">1</j30> </consommation> </historique> <histolivr ="1" mobile="1" consomail="0" consomobil="0"> <utilisateur nbfix="3" nbmob="2" nbcb="0" nbmail="3" nbafact="4" nbalivr="2">0</utilisateur> < nbuser="4" nbname="2" nbafact="5" nbalivr="3">0</ > <mobile nbuser="4" nbname="3" nbafact="4" nbalivr="2">0</mobile> <consommation nbtotal="1" firstconso="20/02/ :00:36" nbsite="1" nbsurcesite="1"> <h24 nb="2" mt="680" nbuser="1" nbmysite="2" mtmysite="680">1</h24> <h48 nb="2" mt="680" nbuser="1" nbmysite="2" mtmysite="680">1</h48> <h72 nb="2" mt="680" nbuser="1" nbmysite="2" mtmysite="680">1</h72> <j7 nb="2" mt="680" nbuser="1" nbmysite="2" mtmysite="680">1</j7> <j15 nb="2" mt="680" nbuser="1" nbmysite="2" mtmysite="680">1</j15> <j30 nb="2" mt="680" nbuser="1" nbmysite="2" mtmysite="680">1</j30> </consommation> </histolivr> <profil> <certificat emetteur="aucun" incident="1">non</certificat> <scoring ip="0" bin="0" retrait="0" montant="1">oui</scoring> </profil> <analyse> <eval date="20/02/ :17:12" critere="1" validation="risque élevé" info="fichier incidents">0</eval> <classement id="22">fia-net/contrôle Expert/En cours</classement> <myprofildetail matchid="-1" /> </analyse> </transaction> </result> V5.6.3-dispositif_technique.doc Page 72 sur 81

73 9.13 Flux <result> (mode «mini») en réponse à get_validation.cgi <?xml version="1.0" encoding="iso "?> <result version="3.1" site="678" refid=" xgf1z" retour="trouvee" count="1"> <transaction avancement="traitee" cid=" "> <detail>paiement validé</detail> <analyse> <eval date="02/02/ :13 :58" critere="32" validation="risque élevé" info="profil cumul achat IP">0</eval> <classement id="22">fia-net/contrôle Expert/En cours</classement> </analyse> </transaction> </result> 9.14 Appel à get_validstack.cgi Demande des résultats par liste de transactions : NET.com/engine/get_validstack.cgi?SiteID=XXX&Pwd=pass&ListID=1,2,3&Separ=,&RepFT=0 Demande des résultats par date : NET.com/engine/get_validstack.cgi?SiteID=XXX&Pwd=pass&DtStack=15/10/2002&Ind= Flux <stack> en réponse à get_validstack.cgi par liste <?xml version="1.0" encoding="iso "?> <stack total="202" /> <result version="2.0" site="678" refid="27" retour="absente" count="0"/> <result version="2.0" site="678" refid="28" retour="absente" count="3"> <transaction avancement="traitee" cid=" "> </transaction> <transaction avancement="error" cid=" "> <detail>champ format incorrect</detail> </transaction> <transaction avancement="encours" cid=" "> <detail>en cours de traitement</detail> </transaction> </result> </stack> 9.16 Flux <stack> en réponse à get_validstack.cgi par date <?xml version="1.0" encoding="iso "?> <stack indice="5" total="202" /> <result version="2.0" site="678" date="05/06/2003" retour="trouvee" count="2"> <transaction avancement="traitee" cid=" " refid="8145"> </transaction> <transaction avancement="error" cid=" " refid="320123"> <detail>champ telhome : valeur invalide</detail> </transaction> </result> </stack> 9.17 Erreurs sur les scripts de récupération <?xml version="1.0" encoding="iso "?> <result version="2.0" site="678" refid="275033" retour="param_error" message="erreur authentification" count="0" /> <?xml version="1.0" encoding="iso "?> <result version="2.0" site="678" refid="275033" retour="absente" count="0" /> <?xml version="1.0" encoding="iso "?> <stack total="0" /> <result version="2.0" site="678" retour="param_error" message="erreur authentification" count="0" /> </stack> V5.6.3-dispositif_technique.doc Page 73 sur 81

74 9.18 Extraction d une partie du mode «help» de get_validation.cgi Exemple A : <?xml version="1.0" encoding="iso "?> <help version="3.1" site="678" avancement="ok" count="1"> <result version="version actuelle du flux" site="identifiant numérique du site demandeur" refid="référence pour laquelle l évaluation est demandée" retour="précise si la transaction a été trouvée ou non ou si une erreur est survenue" message="message détaillant l erreur si le cas survient" count="nombre d éléments transaction présents"> </result> <tag> <blackliste> </blackliste> <adresse> </adresse> <ip> </ip> <historique> </historique> <histolivr> </historlivr> <profil> </profil> <analyse> <eval> <critere> <cas value="1">fichier Incidents/Alertes</cas> <cas value="2">historique d information de l utilisateur de facturation</cas> <cas value="3">historique CB</cas> <cas value="4">historique consommation de l utilisateur de facturation</cas> <cas value="5">historique de l de facturation</cas> <cas value="7">historique d information de l utilisateur de livraison</cas> <cas value="9">historique consommation de l utilisateur de livraison</cas> <cas value="10">historique de l de livraison</cas> <cas value="14">historique du mobile de facturation</cas> <cas value="15">historique du mobile de livraison</cas> <cas value="16">certificat Fia-Net</cas> <cas value="18">incohérence Global CP/Ville</cas> <cas value="28">historique consommation de l adresse de livraison</cas> <cas value="32">historique consommation de l IP</cas> <cas value="34">profil client sûr</cas> <cas value="35">historique consommation de l de facturation</cas> <cas value="36">historique consommation de l de livraison</cas> <cas value="37">historique consommation du mobile de facturation</cas> <cas value="38">historique consommation du mobile de livraison</cas> <cas value="39">historique de l IP sur 30 jours</cas> <cas value="40">transaction Certifiée</cas> <cas value="101">profil IP</cas> <cas value="102">profil BIN</cas> <cas value="103">profil acheteur retrait</cas> <cas value="104">profil achat inconnu</cas> <cas value="004">historique parfait Fia-Net</cas> </critere> <cas value="-1">evaluation par défaut : voir info pour nouvel acheteur, </cas> <cas value="0">non validé (0 %)</cas> <cas value="100">validé à 100 %</cas> </eval> <myprofildetail> <cas value="0">profil type d adresse à risque</cas> <cas value="1">profil libellé d adresse à risque</cas> <cas value="2">coordonnées de livraison fiables + mail payant</cas> <cas value="3">risques d usurpation d identité 1</cas> <cas value="4">profil acheteur livraison express</cas> <cas value="5">profil acheteur transporteur express</cas> <cas value="6">profil à risque type</cas> <cas value="7"> gratuit + point-retrait</cas> <cas value="8">mail gratuit + chiffres ou www dans le mail</cas> <cas value="9">mail gratuit + codes postaux à risque</cas> <cas value="11">mail gratuit + téléphonie mobile</cas> <cas value="12">mail gratuit + rapidité express</cas> <cas value="13"> gratuit + libellé du transporteur express</cas> <cas value="14"> payant</cas> <cas value="15">téléphone fix de location</cas> <cas value="16">montant faible</cas> <cas value="17">risques d usurpation d identité 2</cas> <cas value="18">coordonnées de livraison fiables</cas> V5.6.3-dispositif_technique.doc Page 74 sur 81

75 <cas value="19">coordonnées fiables</cas> <cas value="20">risques d usurpation d identité 3</cas> <cas value="21">rêgle de validation spéciale</cas> </myprofildetail> </analyse> </tag> </help> Exemple B : <?xml version="1.0" encoding="iso "?> <help version="3.1" site="678" avancement="ok" count="1"> <result version="version actuelle du flux" site="identifiant numérique du site demandeur" refid="référence pour laquelle l évaluation est demandée" retour="précise si la transaction a été trouvée ou non ou si une erreur est survenue" message="message détaillant l erreur si le cas survient" count="nombre d éléments transaction présents"> <transaction> <detail>donne l état de traitement de la transaction</detail> <blackliste valeur="savoir si la transaction possède des elements dans le fichier incident ou alerte" incident="présence ou non de la balise incident" alerte="présence ou non de la balise alerte"> </blackliste> <adresse livr="indique la presence de la balise livraison"> </adresse> <ip granted="indique si le site est autorisé à poster l IP" valid="indique la validité de l adresse IP" conso="indique s il existe un historique de consommation à cette adresse IP" nbflag="indique s il existe des fraudes à cette adresse IP"> </ip> <historique ="présence ou non de la balise " mobile="présence ou non de la balise mobile" cb=" présence ou non de la balise cb" valeur="résumé de l analyse de consommation" consomail=" présence ou non de la balise consomail" consomobil=" présence ou non de la balise consomobil"> </historique> <histolivr ="présence ou non de la balise " mobile="présence ou non de la balise mobile" cb=" présence ou non de la balise cb" valeur="résumé de l analyse de consommation" consomail=" présence ou non de la balise consomail" consomobil=" présence ou non de la balise consomobil"> </historlivr> <paiement type="indique si la transaction possède une information de paiement par carte"> </paiement> <profil> </profil> <analyse> <histoeval nbetape="nombre d étapes de ré-évaluation"> <eval date="date du changement d évaluation" critere="identifiant du critère principal qui explique l évaluation" validation="correspond au niveau de validation de la transaction" info="précise des informations supplémentaires comme le critère d analyse de la transaction ou mets l accent sur notre connaissance de l utilisateur pour les transactions peu sûres">regroupe les différentes réévaluations survenues sur cette transaction. attention, uniquement les changements d évaluations sont présents</eval> </histoeval> <eval date="date de cette évaluation globale" critere="identifiant du critère principal qui explique l évaluation" validation="correspond au niveau de validation de la transaction" info="précise des informations supplémentaires comme le critère d analyse de la transaction ou mets l accent sur notre connaissance de l utilisateur pour les transactions peu sûres">niveau d évaluation calculé, présente la dernière évaluation de cette transaction</eval> <classement id="identifiant numérique du classement actuel de la transaction">libellé du classement actuel de la transaction</classement> <myprofildetail matchid="indique la première règle vérifiée"> <myprofilrule id="identifiant de la règle analysée" type="indique si la règle est négative ou positive" info="libellé en clair de la règle analysée">indique si la règle en question est vérifiée</myprofilrule> </myprofildetail> </analyse> </transaction> </result> 9.19 Appels et retours du script delivery.cgi Appel : Retour OK : <?xml version="1.0" encoding="iso "?> <result>intégration effectuée</result> Retours Erreur : <?xml version="1.0" encoding="iso "?> <result>erreur authentification</result> <?xml version="1.0" encoding="iso "?> <result>transaction absente</result> V5.6.3-dispositif_technique.doc Page 75 sur 81

76 10 Annexe 2 : Format général des champs pour tous les pays Voici un bref descriptif du formatage des champs par pays pour l envoi des informations à notre système. Vous pouvez étudier celui-ci plus en détail en analysant le flux présent à cette URL : docs/dtd.fianet.zip nom 127 caractères Non numériques si qualité 2 (particulier) Alpha-numériques si qualité 1 (entreprise) prenom 127 caractères Non numériques si qualité 2 (particulier) Alpha-numériques si qualité 1 (entreprise) societe 127 caractères alpha-numériques Format standard d adresse mail (ex : [email protected]) rue1/rue2 ville pays 127 caractères alpha-numériques 127 caractères alpha-numériques (sans ponctuation) 56 caractères alpha-numériques (Attention à la reconnaissance des pays traités par le système) (cf. section 1.1 pour la liste des pays disponibles). digicode1/digicode2 32 caractères compris dans [A-Za-z0-9] (sans accent, sans ponctuation) escalier/etage/nporte 32 caractères compris dans [A-Za-z0-9] (sans accent, sans ponctuation) batiment 32 caractères compris dans [A-Za-z0-9 ] (sans accent, sans ponctuation, espacesautorisés) siteid numérique refid 20 caractères alpha-numériques montant numérique avec séparateur décimal «.» ou «,» devise EUR ou USD ip [0-255].[0-255].[0-255].[0-255] timestamp YYYY-MM-DD HH:MM[:SS] (les secondes sont facultatives) nom de transporteur 127 caractères alpha-numériques type de transporteur rapidite transporteur 1 2 intitule de produit 255 caractères alpha-numériques reference de produit 64 caractères alpha-numériques type de produit numérique nombre de produit numérique numcb dateval bin type 32 caractères résultants d un algorithme de hashage MD5 (sans séparateur avant hashage) 32 caractères résultants d un algorithme de hashage MD5 (format MM/YYYY avant hashage) 6 caractères numériques cheque contre-remboursement virement cb en n fois V5.6.3-dispositif_technique.doc Page 76 sur 81

77 11 Annexe 3 : Format spécifique des champs par pays Rappel : Vous pouvez étudier le formatage des champs par pays plus en détail en analysant le flux présent à cette URL : docs/dtd.fianet.zip (cf. section 1.1 pour la liste des pays disponibles) Préambule relatif à l interprétation des caractères non latins L'ouverture du SAC à de nouveaux pays européens provoque un problème de représentation des caractères propres à certains pays : la Grèce, Chypre, la Bulgarie et les pays de l'europe de l'est, par exemple, utilisent des caractères spécifiques. Nos bases de données étant prévues pour stocker des informations en caractères latins (ISO ), FIA-NET utilise un système de conversion ( romanisation ou translitération ) pour récupérer des caractères latins à partir des informations non latines reçues. ATTENTION : le système n'acceptant que les flux XML encodés en UTF-8 ou ISO , les transactions provenant de pays étrangers à caractères non latins doivent impérativement nous être soumises au format UTF Allemagne pays DE Germany Deutschland Allemagne titre/civilité m. mr m mme mde mrs mlle melle mle miss monsieur madame mademoiselle hr. hr fr. fr frl. frl téléphones de 9 à 12 caractères numériques précédés ou non du format international (+49 ou 0049 ou (49) ou 49(0)) (possibilité de séparateurs) cpostal 5 caractères numériques (possibilité de séparateur «.» ou ) 11.3 Autriche pays Autriche Austria Österreich Osterreich At titre/civilité m. mr m mme mde mrs mlle melle mle miss monsieur madame mademoiselle hr. hr fr. fr frl. frl téléphones 9 à 12 caractères numériques précédés ou non du format international (+43 ou 0043 ou (43) ou 43(0)) cpostal 4 caractères numériques 11.4 Belgique (francophone) pays BE Belgique Belgium titre/civilité m. mr m mme mde mrs mlle melle mle miss monsieur madame mademoiselle téléphones de 7 à 10 caractères numériques précédés ou non du format international (+32 ou 0032 ou (32) ou 32(0)) (possibilité de séparateurs) cpostal 4 caractères numériques (possibilité de séparateur «.» ou ) 11.5 Bulgarie pays Bulgarie Bulgaria Balgariya Bg titre/civilité monsieur madame mademoiselle m. mr m gospodin mme mde mrs gospozha melle mlle mle miss gospozhitsa téléphones 7 à 9 caractères numériques précédés ou non du format international (+359 ou ou (359) ou 359(0)) cpostal 4 caractères numériques V5.6.3-dispositif_technique.doc Page 77 sur 81

78 11.6 Chypre pays Chypre Cyprus Kypros Cy titre/civilité monsieur madame mademoiselle m. mr m mme mde mrs melle mlle mle miss kyrie kyria despoinis k ka dis téléphones 5 à 8 caractères numériques précédés ou non du format international (+357 ou ou (357) ou 357(0)) cpostal 4 caractères numériques 11.7 Danemark pays Danemark Denmark Danmark Dk titre/civilité monsieur madame mademoiselle m. mr m mme mde mrs melle mlle mle miss herre hr. hr frue fru fr. fr frøken frk. frk téléphones 8 caractères numériques précédés ou non du format international (+45 ou 0045 ou (45) ou 45(0)) cpostal 4 caractères numériques 11.8 Espagne pays ES SP Spain Espana Espagne titre/civilité m. mr m mme mde mrs mlle melle mle miss monsieur madame mademoiselle senor sr. sr senora sra. sra senorita srta. srta téléphones 9 caractères numériques précédés ou non du format international (+34 ou 0034 ou (34) ou 34(0)) (possibilité de séparateurs) cpostal 5 caractères numériques (possibilité de séparateur «.» ou ) 11.9 Estonie pays Estonie Estonia Eesti Ee titre/civilité monsieur madame mademoiselle m. mr m mme mde mrs melle mlle mle miss harra härra hr. hr proua pr. pr preili prl. prl téléphones 7 à 8 caractères numériques précédés ou non du format international (+372 ou ou (372) ou 372(0)) cpostal 5 caractères numériques Finlande pays Finlande Finland Suomi Fi titre/civilité monsieur madame mademoiselle m. mr m herra herr hr. hr mme mde mrs rouva rva. rva fru fr. fr melle mlle mle miss neiti nti. nti fröken froken frk. frk téléphones 7 à 12 caractères numériques précédés ou non du format international (+358 ou ou (358) ou 358(0)) cpostal 5 caractères numériques France pays France France métropolitain France metropolitan FR titre/civilité m. mr m mme mde mrs mlle melle mle miss monsieur madame mademoiselle téléphones 10 caractères numériques ou 9 caractères numériques précédés du format international (+33 ou 0033 ou (33) ou 33(0)) (possibilité de séparateurs) cpostal 5 caractères numériques (possibilité de séparateur «.» ou ) V5.6.3-dispositif_technique.doc Page 78 sur 81

79 11.12 Grèce pays Grèce Greece Ellada Gr titre/civilité monsieur madame mademoiselle m. mr m mme mde mrs melle mlle mle miss kyrie kyria despoinis téléphones 10 caractères numériques précédés ou non du format international (+30 ou 0030 ou (30) ou 30(0)) cpostal 5 caractères numériques Hollande et les Pays-Bas pays Pays-Bas Hollande Holland Paysbas Netherlands Netherland Nl titre/civilité monsieur madame mademoiselle m. mr mr. mo mme mde mrs mrs. ms ms. mell mlle mle miss téléphones 10 caractères numériques précédés ou non du format international (+31 ou 0031 ou (31) ou 31(0)) cpostal CCCCLL ou CCCC LL ou CCCC-LL (C=chiffre[0-9], L=lettre [A-Z]) Hongrie pays Hongrie Hungary Magyarország Magyarorszag Hu titre/civilité monsieur madame mademoiselle m. mr m mme mde mrs melle mlle mle miss téléphones 8 à 10 caractères numériques précédés ou non du format international (+36 ou 0036 ou (36) ou 36(0)) cpostal 4 caractères numériques Irlande pays Irlande Eire Éire Ireland Irl Ie titre/civilité monsieur madame mademoiselle m. mr m mme mde mrs mlle melle mle miss monsieur madame mademoiselle mister madam téléphones 6 à 10 caractères numériques précédés ou non du format international (+353 ou ou (353) ou 353(0)) cpostal aucun Italie pays IT Italia Italy Italie titre/civilité m. mr m mme mde mrs mlle melle mle miss monsieur madame mademoiselle signore sig. sig signora sig.ra sigra signorina sig.na signa téléphones 8, 9 ou 10 caractères numériques précédés ou non du format international (+39 ou 0039 ou (39) ou 39(0)) (possibilité de séparateurs) cpostal 5 caractères numériques (possibilité de séparateur «.» ou ) Lettonie pays Lettonie Latvia Latvija Latvijas Lv titre/civilité monsieur madame mademoiselle m. mr m mme mde mrs melle mlle mle miss kungs kundze jaunkundze téléphones 7 ou 8 caractères numériques précédés ou non du format international (+371 ou ou (371) ou 371(0)) cpostal 4 caractères numériques Lituanie pays Lituanie Lithuania Lietuva Lt titre/civilité monsieur madame mademoiselle m. mr m mme mde mrs melle mlle mle miss pone ponia panele téléphones 8 caractères numériques précédés ou non du format international (+370 ou ou (370) ou 370(0)) cpostal 5 caractères numériques V5.6.3-dispositif_technique.doc Page 79 sur 81

80 11.19 Luxembourg pays Luxembourg Luxemburg Lëtzebuerg Letzebuerg Lu titre/civilité monsieur madame mademoiselle m. mr m mme mde mrs melle mlle mle miss här har madamm joffer herr hr. hr frau fr. fr fräulein fraulein frl. frl téléphones 6 à 9 caractères numériques précédés ou non du format international (+352 ou ou (352) ou 352(0)) cpostal 4 caractères numériques Malte pays Malte Malta MT titre/civilité monsieur madame mademoiselle m. mr m mme mde mrs melle mlle mle miss sinjur sur sinjura sinj sinjorina téléphones 8 caractères numériques précédés ou non du format international (+356 ou ou (356) ou 356(0)) cpostal LLL CCCC ou LLLCCCC ou LLL-CCCC (L=Lettre [A-Z], C=chiffre [0-9]) Monaco pays MC Monaco titre/civilité m. mr m mme mde mrs mlle melle mle miss monsieur madame mademoiselle téléphones 8, 9 ou 10 caractères numériques précédés ou non du format international (+377 ou ou (377) ou 377(0)) (possibilité de séparateurs) cpostal 5 caractères numériques (possibilité de séparateur «.» ou ) Pologne pays Pologne Poland Polska Pl titre/civilité monsieur madame mademoiselle m. mr m mme mde mrs melle mlle mle miss pan p. p pani panna téléphones 8 à 9 caractères numériques précédés ou non du format international (+48 ou 0048 ou (48) ou 48(0)) cpostal 5 caractères numériques Portugal pays PT Portugal titre/civilité m. mr m mme mde mrs mlle melle mle miss monsieur madame mademoiselle senhor sr. sr senhora sra. sra senhorita srta. srta téléphones 9 caractères numériques précédés ou non du format international (+351 ou ou (351) ou 351(0)) (possibilité de séparateurs) cpostal ou (5 est un chiffre dans [0-9]) Royaume-Uni pays UK Royaume-Uni United Kingdom Wales Scotland GB England Grande-Bretagne Angleterre Irlande du Nord Galles Ecosse Northern Ireland titre/civilité m. mr m mme mde mrs mlle melle mle miss monsieur madame mademoiselle mister madam téléphones 11 caractères numériques ou 10 caractères numériques précédés du format international (+44 ou 0044 ou (44) ou 44(0)) (possibilité de séparateurs) cpostal CC5 5CC ou CC55 5CC ou C55 5CC ou CC55C 5CC (C est un caractère dans [A-Z] et 5 est un chiffre dans [0-9]) Slovaquie pays Slovaquie Slovakia Slovensko Sk titre/civilité monsieur madame mademoiselle pan paní pani slecna téléphones 10 caractères numériques précédés ou non du format international (+421 ou ou (421) ou 421(0)) cpostal 5 caractères numériques V5.6.3-dispositif_technique.doc Page 80 sur 81

81 11.26 Slovénie pays Slovénie Slovenia Republika Slovenija Slovenija Si titre/civilité monsieur madame mademoiselle m. mr m mme mde mrs melle mlle mle miss gospod gospa gospodicna téléphones 8 ou 9 caractères numériques précédés ou non du format international (+386 ou ou (386) ou 386(0)) cpostal 4 caractères numériques Suède pays Suède Sverige Sweden Se titre/civilité monsieur madame mademoiselle m. mr m herr hr. hr mme mde mrs fru fr. fr melle mlle mle miss fröken froken frk. frk téléphones 7 à 10 caractères numériques précédés ou non du format international (+46 ou 0046 ou (46) ou 46(0)) cpostal 5 caractères numériques Suisse (francophone) pays SW CH Suisse Switzerland titre/civilité m. mr m mme mde mrs mlle melle mle miss monsieur madame mademoiselle téléphones de 10 caractères numériques précédés ou non du format international (+41 ou 0041 ou (41) ou 41(0)) (possibilité de séparateurs) cpostal 4 caractères numériques (possibilité de séparateur «.» ou ) République Tchèque pays Republique Tcheque Tchequie Czech Republic Czechia Ceská Republika Ceska Republika Cesko Cz titre/civilité monsieur madame mademoiselle pan paní pani slecna téléphones 0 caractères numériques précédés ou non du format international (+420 ou ou (420) ou 420(0)) cpostal 5 caractères numériques Roumanie Pays Roumanie România Romania Ro titre/civilité monsieur madame mademoiselle m. mr m mme mde mrs melle mlle mle miss domn doamna domnisoara téléphones 10 caractères numériques précédés ou non du format international (+40 ou 0040 ou (40) ou 40(0)) cpostal 6 caractères numériques 12 Annexe 4 : Contacts techniques En cas de problème, vous pouvez contacter : Romuald CAUFFET Tél. : [email protected] Suivi de production [email protected] Aide à l'intégration Tél. : [email protected] Veuillez nous prévenir dès la mise en production du code afin que nous validions ensemble le bon fonctionnement du Système d Analyse des Commandes. V5.6.3-dispositif_technique.doc Page 81 sur 81