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