Spécifications Techniques

Transcription

1 Paiement sécurisé sur Internet Service TPE Virtuel (sécurisé par le protocole SSL) Spécifications Techniques d intégration compatibles option PLUS version 1.2open - décembre 2003

2 Sommaire : 11 MM II SSEE EE NN PPLL AA CC EE DD UU SSEE RR VV II CC EE ««TT PPEE VV II RR TT UU EE LL VV II AA II NN TT EE RR NN EE TT»» OO pp ee nn KK i it ss : ee xx ee mm pp l lee l ss dd i inn i t éé gg r aa t i ioo nn OO pp ee nn TT oo oo l lss l : pp r i iss i ee ee nn cc hh aa r gg ee dd ee ss pp aa r aa mm èè t r ee ss, pp ee r ss oo nn nn aa l l i iss i aa t i ioo nn CC l léé dd ee ss éé cc uu r i it éé cc oo mm mm ee r çç aa nn t SS PPEE CC II FF II CC AA TT II OO NN SS DDEE SS MM EE SS SSAA GG EE SS EE CC HH AA NN GG EE SS AA cc t i ioo i nn ss dd ee l l l i inn i t ee r nn aa uu t ee, dd uu ss i it ee cc oo mm mm ee r çç aa nn t ee t dd uu ss i it ee bb aa nn cc aa i ir ee e r r Pr P r oo gg r aa mm mm ee dd i inn i t ee r f aa çç aa gg ee : ««CC GG II 11»» n d Pr P r oo gg r aa mm mm ee dd i inn i t ee r f aa çç aa gg ee : ««CC GG II 22»» PPhh aa ss ee aa l ll l ee r dd uu pp aa i iee mm ee nn t : ««CC GG II 11»» 55 FF oo nn cc t i ioo nn nn aa l l i it éé ««cc r éé ee r f oo r mm uu l laa l i ir ee»» 55 EE xx ee mm pp l lee l dd ee f oo r mm uu l laa l i ir ee dd ee pp aa i iee i mm ee nn t 66 MM ee ss ss aa gg ee ss dd ee r r ee uu r dd uu ss ee r vv ee uu r dd ee pp aa i iee i mm ee nn t ss uu i it ee àà ee nn vvoo i i dd uu f oo r mm uu l laa i ir ee PPhh aa ss ee cc oo nn f i ir ir mm aa t i ioo i nn dd uu pp aa i iee mm ee nn t : ««CC GG II 22»» 99 PPaa r aa mm èè t r ee ss r ee nn vv oo yy éé ss pp aa r l laa BB aa nn qq uu ee 99 RR éé pp oo nn ss ee dd uu ss ee r vv ee uu r cc oo mm mm ee r çç aa nn t 99 EE xx ee mm pp l lee l ss FF oo nn cc t i ioo nn nn aa l l i it it éé ««t ee ss t ee r HH MM AA CC»» RR éé ss uu l lt lt aa t dd uu pp aa i iee i mm ee nn t : ccooddee--rreettoouurr CCoomppl lléémeenntt CC yy bb ee r MM UU TT PP@@ i iee i mm ee nn t oo pp t i ioo nn ««PP LL UU SS»» : r ee t oo uu r PPLL UU SS FF oo nn cc t i ioo nn nn aa l l i it it éé ««cc r éé ee r aa cc cc uu ss éé dd ee r éé cc ee pp t i ioo i nn»» SSpp éé cc i if if i icc i aa t i ioo i nn ss dd ee ss f oo r mm aa t ss CC oo nn t r aa i inn i t ee gg éé nn éé r aa l lee dd ee cc oo dd aa gg ee HH TT MM LL dd ee ss cc hh aa mm pp ss CC oo nn t r aa i inn i t ee ss pp aa r t i icc i uu l li l i èè r ee ss ss ee l loo nn l lee l cc hh aa mm pp UU RR LL SS DDEE SS SS EE RR VV EE UU RR SS BB AA NN CC AA II RR EE SS UU RR LL ss dd ee ss ss ee r vvee uu r ss dd ee t ee ss t UU RR LL ss dd ee ss ss ee r vvee uu r ss dd ee pp r oo dd uu cc t i ioo i nn /13

3 1 Mise en place du service «TPE Virtuel via Internet» Les éléments nécessaires à la mise en place du paiement sécurisé sur votre Terminal de Paiement Electronique Virtuel («TPEV») vous seront fournis par le centre de support «CentreCom sous forme de liens de téléchargement sur le site sécurisé de votre banque. Vous recevrez ces informations par lors des différentes phases d installation et de test. Vous devrez utiliser la documentation fournie pour créer les deux programmes d interface : «CGI1» : génération du formulaire de demande de paiement «CGI2» : réception de la confirmation du paiement. Ces programmes sont appelés par commodité CGI1 et CGI2 mais ne sont pas nécessairement cgi : aspx, php, etc. Le travail à réaliser nécessite des compétences de base en programmation : recevoir et contrôler des paramètres en méthode «POST» manipuler des chaînes de caractères utiliser une fonction ou une classe conforme à la RFC2104 implémentant le HMAC SHA1 ou MD5 sauvegarder le contexte de paiement en fichier ou base de données suivre le déroulement pas à pas d un programme dans un «debugger» ou en programmant des traces. 1.1 Open Kits : exemples d intégration A titre d information, des exemples en PHP, ASPX, ASP, Python, Java et C de chacun des deux programmes à interfacer avec notre solution vous sont fournis avec la documentation. Vous pourrez utiliser ces exemples comme point de départ et vous devrez les modifier selon les spécificités de votre environnement et de votre application. En particulier le stockage des clés devra être revu pour exploiter les meilleurs outils de confidentialité disponibles dans votre environnement. Les exemples proposent un stockage en base de données ou en 2 fichiers textes complémentaires de manière à ce que la compromission accidentelle d un seul fichier ne compromette pas la clé. 1.2 Open Tools : prise en charge des paramètres, personnalisation Cet outil s exécute en local et génère à partir des paramètres du terminal tels que clé, N de TPE, code société, «Urls», etc., les fichiers ou les sections de code de personnalisation correspondant à chacun des exemples proposés. Ceci vous permet de parcourir en quelques minutes le cycle complet du paiement. Les blocs de code générés sont à revoir, comme il a été dit plus haut, pour exploiter au mieux les outils de sécurisation de données dont vous disposez pour protéger les secrets et, de façon générale, pour exploiter au mieux les possibilités de votre environnement. 1.3 Clé de sécurité commerçant Une clé de sécurité, propre au terminal, destinée à certifier les données échangées entre le serveur du commerçant et le serveur de paiement sécurisé de la banque, est attribuée par la banque à chaque TPE virtuel. Cette clé, associée au TPE virtuel du commerçant, est indispensable pour utiliser le service de paiement par carte bancaire. Un lien de téléchargement sécurisé (lien codé, protocole SSL, authentification du souscripteur de contrat par son identifiant/mot de passe) est envoyé par le support «CentreCom». Le commerçant, après authentification, téléchargera la «matière» de cette clé sous forme d un fichier texte scellé de 4 lignes à conserver sur un support externe. Le nom proposé au téléchargement est <N detpe.key> (ex : « key»), mais il n y a pas de contraintes de nom. Le commerçant peut demander la régénération d une nouvelle clé, périodiquement ou à l occasion d évènements tels que : mise en production, changement d hébergeur, changement de prestataire. Il est de la responsabilité du commerçant de conserver cette clé de façon sûre et confidentielle en exploitant les meilleurs outils disponibles dans son environnement. La valeur de clé utilisée dans les fonctions de HMAC est une chaîne de 20 octets représentée de façon externe par 40 chiffres hexadécimaux, exemple : ABCDEF ABCDEF Cette représentation externe doit être convertie («0x», «Pack») en une chaîne de 20 octets. L outil «Open Tools» construit les différentes représentations opérationnelles de la clé, selon les langages et les met en situation dans les exemples, à partir du fichier «matière» unique. 3 /13

4 2 Spécifications des messages échangés 2.1 Actions de l internaute, du site commerçant et du site bancaire Site commerçant «boutique» Le serveur commerçant obtient l accord de l internaute sur «la chose et le prix». 1 er Programme d interfaçage : «CGI1» Le serveur du commerçant rassemble les données du paiement à effectuer. Le serveur du commerçant crée le formulaire de paiement scellé : fonction «créer formulaire». Ensuite il met en page ce formulaire de paiement à destination de l internaute. Serveur bancaire de paiement Internet L internaute clique sur le bouton correspondant au formulaire de paiement et accède au serveur de paiement. Le serveur bancaire vérifie la validité du sceau et entame le dialogue de paiement avec l internaute. L internaute dialogue avec le serveur bancaire et paye (ou ne paye pas) par carte bancaire. Le serveur bancaire renvoie un résultat de paiement scellé au serveur du commerçant. 2 nd Programme d interfaçage : «CGI2» Le serveur du commerçant vérifie la validité du sceau : fonction «tester HMAC». Le serveur du commerçant prend en compte le résultat de paiement. Enfin il répond au serveur bancaire : fonction «créer accusé de réception». Serveur bancaire de paiement Internet Le serveur affiche le résultat du paiement (avec le N d autorisation si autorisation). L internaute peut imprimer (ou sauvegarder) cette page «ticket». Le serveur propose à l internaute de revenir sur le site du commerçant via un lien hypertexte. S il suit ce lien, l internaute quitte le serveur de paiement et revient sur le site du commerçant. Site commerçant «boutique» Le serveur du commerçant adapte son dialogue en fonction du résultat de paiement reçu (ou non reçu) et sauvegardé par le «CGI2». 4 /13

5 2.2 Phase aller du paiement : «CGI1» Fonctionnalité «créer formulaire» Cette fonction met en forme les paramètres du terminal et les données de la commande en un formulaire HTML scellé afin de transmettre la demande de paiement au serveur de la banque via le navigateur du client. Champs Description Remarques ACTION Url du service de Paiement de la Banque Url de Test ou de Production version Version du système de paiement de la banque Version actuelle : 1.2open TPE date montant reference TPE virtuel du commerçant fourni par la banque sous forme d une chaîne numérique de 7 caractères Date de la commande au format : JJ/MM/AAAA:HH:MM:SS Montant TTC de la commande formaté de la façon suivante : un nombre entier un point décimal (optionnel) un nombre entier (optionnel) une devise sur 3 caractères alphabétiques ISO 4217 (EUR, USD, GBP, CHF, etc.) Référence unique de la commande sur exactement 12 caractères alpha-numériques (A Z, a z, 0 9) permettant d identifier la commande (par exemple, un numéro séquentiel incrémenté à chaque commande) Ex : Ex : 08/11/2003:11:25:43 Ex : 65.25EUR 10GBP Ex : AZERTYP00145 Texte-libre Zone de texte libre (Taille raisonnable 100 caractères, maximale 3200 après codage, voir les contraintes de codage en fin de document) Il peut contenir un numéro de panier ou toute autre référence de gestion «longue» imposée par la solution de commerce. Lgue Code langue (Majuscules) Ex : FR ou EN, DE, IT, ES Societe Code à usage interne uniquement qui permet à un commerçant d utiliser le même TPE virtuel pour des sites différents (paramètres différents). Ex : Site1 url_retour url_retour_ok url_retour_err URL de retour pour l acheteur : retour sur la page d accueil de la boutique URL de retour pour l acheteur : page de retour sur le site commerçant après un paiement accepté (attention : à ne pas confondre avec l URL de confirmation des paiements sur laquelle sera placée le CGI2) URL de retour pour l acheteur : page de retour sur le site commerçant après un paiement refusé Bouton Texte du bouton de paiement Ex : Paiement CB Information de certification des données (sceau MAC) : MAC Sceau résultant de la certification des données HMAC-SHA1(stringDatas, 20byteKey) stringdatas := TPE. "*". date. "*". montant. "*". reference. "*". texte-libre. "*". version. "*". lgue. "*". societe. "*" On note ici en pseudo-code «HMAC-SHA1(stringDatas, 20byteKey)» la fonction d authentification conforme à la RFC2104 présente sur votre environnement, avec : stringdatas : une chaîne obtenue par concaténation d informations essentielles du message et de délimiteurs «.» : l opérateur de concaténation de chaînes La notation équivalente en représentant la concaténation par une fonction StringConcat() serait : StringConcat( TPE, "*", date, "*", montant, "*", reference, "*", texte-libre, "*", version, "*", lgue, "*", societe, "*" ) 20byteKey : votre clé de sécurité (160 bits, 40 chiffres hexadécimaux). 5 /13

6 Exemple de formulaire de paiement Comme vous le voyez, les champs de ce formulaire sont TOUS codés en HTML. Les spécifications d encodage sont décrites en fin de document. <form method= post name= FormulaireEncodeConforme target= _top action= > <input type= hidden name= version value= 1.2open > <input type= hidden name= TPE value= > <input type= hidden name= date value= 11/12/2003:16:27:45 > <input type= hidden name= montant value= EUR > <input type= hidden name= reference value= votrerf12345 > <input type= hidden name= MAC value= 78bc376c5b192f1c cbdb0050f156b9a2 > <input type= hidden name= url_retour value= > <input type= hidden name= url_retour_ok value = > <input type= hidden name= url_retour_err value = > <input type= hidden name= lgue value= FR > <input type= hidden name= societe value= votresociete > <input type= hidden name= texte-libre value= bla bla > <input type= submit name= bouton value= Paiement CB - Card Payment > </form> dont la seule partie visible serait ici : Paiement CB - Card Payment 6 /13

7 Messages d erreur du serveur de paiement suite à envoi du formulaire "Le site de votre commerçant n'a pas été identifié par notre serveur. Nous ne sommes pas en mesure de traiter la demande de paiement relative à votre commande." Les informations transmises par le «CGI1» ne sont pas reconnues par le serveur de la banque : Vérifiez que vous avez bien répondu aux questions qui sont posées dans le mail de fourniture de la clé. Vérifiez que les paramètres suivants, transmis par le «CGI1», correspondent aux informations que vous nous avez envoyées ou confirmées par mail : Numéro de TPE ; Code société (importance de la casse) ; Langue "Les informations transmises par votre commerçant ont une signature non valide : le niveau de sécurité exigé n'est pas atteint. Notre serveur n'est pas en mesure de traiter la demande de paiement relative à votre commande." Le champ MAC transmis par le «CGI1» n'est pas valide ou n'a pas pu être calculé : Affichez le code source du formulaire généré et vérifiez que le champ caché "MAC" est valorisé par une suite de chiffres hexadécimaux. Vérifiez que vous avez bien intégré la clé. Les exemples fournis fournissent et affichent un champ de contrôle à comparer avec le champ de contrôle affiché dans l outil de prise en charge de clé. Vérifiez que vous avez la bonne clé : transmettez le champ de contrôle produit par l outil de prise en charge de clé au support «CentreCom». Ne transmettez que ce champ et non la clé elle-même. Rq : si vous avez le moindre doute sur une action ou un oubli de votre part qui pourrait avoir porté la clé à la connaissance de personnes non autorisées, contactez le support «CentreCom» pour la génération d une nouvelle clé. "Votre commande a déjà été traitée." Ce message signifie que vous passez une commande sur une référence de commande déjà utilisée. "La date de validité de votre commande est dépassée." La référence de commande est en instance de paiement depuis un délai trop important (typiquement plus d une heure) : Testez un formulaire mis à jour avec une nouvelle référence de commande. Le formulaire de commande a été créé depuis un délai trop important, typiquement plus de 12 heures : Testez un nouveau formulaire. Vérifiez la date système de votre machine. 7 /13

8 Notez bien que le formulaire suivant, dont les valeurs de champs ne sont pas codées en HTML, n est pas conforme à nos spécifications. Cet encodage est préconisé pour la sécurité du site commerçant. En effet le code qui doit réaliser la fonction «créer formulaire» recevra dans la pratique l essentiel des valeurs de ces champs depuis un programme distinct, appartenant à la solution de commerce. Or, il est de bonne pratique de coder en HTML tout champ à afficher provenant d une source tierce, à commencer bien entendu par les champs saisis par les utilisateurs. Le code «créer formulaire» n a pas d informations sur l origine première de ces champs, il doit donc les encoder tous. <FORM METHOD="post" TARGET="_top" NAME="FormulaireNonEncodeHtml_NonConforme" ACTION=" <INPUT TYPE="hidden" NAME="version" VALUE="1.2open"> <INPUT TYPE="hidden" NAME="TPE" VALUE=" "> <INPUT TYPE="hidden" NAME="date" VALUE="11/12/2003:17:06:15"> <INPUT TYPE="hidden" NAME="montant" VALUE="123.45EUR"> <INPUT TYPE="hidden" NAME="reference" VALUE="XXXXXXX99999"> <INPUT TYPE="hidden" NAME="MAC" VALUE="9ee8217f179931a5fb e76e394e45db9d"> <INPUT TYPE="hidden" NAME="url_retour" VALUE=" <INPUT TYPE="hidden" NAME="url_retour_ok" VALUE=" <INPUT TYPE="hidden" NAME="url_retour_err" VALUE=" <INPUT TYPE="hidden" NAME="lgue" VALUE="EN"> <INPUT TYPE="hidden" NAME="societe" VALUE="Site1"> <INPUT TYPE="hidden" NAME="texte-libre" VALUE="Alpha&Num"> <INPUT TYPE="submit" NAME="bouton" VALUE="Paiement CB - Card Payment"> </FORM> 8 /13

9 2.3 Phase confirmation du paiement : «CGI2» Après avoir traité la demande de paiement, en dialogue avec l internaute payant par carte, le serveur de la banque informe directement le serveur du commerçant du résultat de la demande de paiement en émettant une requête HTTP on-line, contenant le résultat de la demande de paiement, sur l URL de confirmation des paiements. Cette URL correspond à l URL du «CGI2», URL que vous devez nous indiquer au moment de la mise en place du système. Le «CGI2» est chargé de recevoir cette requête de confirmation du paiement, d en extraire les différentes informations, dont le résultat du paiement, de mettre à jour l état de la commande dans les bases commerçant, et de répondre par un accusé de réception. Pour cela il doit implémenter les fonctionnalités «tester HMAC» (prise en compte des aspects de sécurisation des échanges) et «créer accusé de réception» (génération de l accusé de réception à renvoyer au serveur de la banque). Le «CGI2» sera appelé par le serveur de la banque avec la méthode POST. Paramètres renvoyés par la Banque Champs Description Remarques MAC TPE Date Sceau calculé sur les données renvoyées, à vérifier avant de prendre en compte le résultat du paiement : HMAC-SHA1(stringDatas, 20byteKey) TPE virtuel du commerçant fourni par la banque chaîne numérique de 7 caractères Date de la commande au format : JJ/MM/AAAA_a_HH:MM:SS montant m montant TTC de la commande, formaté stringdatas := retourplus. TPE. "+". date. "+". montant. "+". reference. "+". texte-libre. "+". "1.2open". "+". code-retour. "+" Ex : Ex : 06/06/1996_a_17:30:42 Ex : 65.25EUR 10GBP reference référence de la commande Ex : texte-libre zone de texte libre Reçu par le serveur bancaire en phase «aller» code-retour résultat du paiement ( A-Z a-z 0-9 ) payetest paiement Annulation (sur le serveur de test uniquement) (sur le serveur de production uniquement) retourplus informations optionnelles séparées par 2 tirets -- ( A-Z a-z 0-9 _-.) --optiona--optionb (CyberMUT P@iement PLUS) On note ici en pseudo-code «HMAC-SHA1(stringDatas, 20byteKey)» la fonction d authentification conforme à la RFC2104 présente sur votre environnement avec : stringdatas : une chaîne obtenue par concaténation d informations essentielles du message et de délimiteurs «.» : l opérateur de concaténation de chaînes La notation équivalente en représentant la concaténation par une fonction StringConcat() serait : StringConcat( retourplus, TPE, "+", date, "+", montant, "+", reference, "+", texte-libre, "+", "1.2open", "+", code-retour, "+" ) 20byteKey : votre clé de sécurité (160 bits, 40 chiffres hexadécimaux). Réponse du serveur commerçant Accusé de réception à rendre au serveur de la Banque en fonction de la vérification du sceau MAC. Sceau reçu == Sceau calculé Sceau reçu!= Sceau calculé Pragma: no-cache<lf> Content-type : text/plain<lf> Version: 1 <LF> OK<LF> Pragma: no-cache<lf> Content-type : text/plain<lf> Version: 1 <LF> Document falsifie<lf> 9 /13

10 Exemples La «Query String» reçue par le «CGI2» est de la forme suivante : "TPE=<numero_TPE>&date=<date>&montant=<montant>&reference=<reference> &MAC=<code_MAC>&texte-libre=<texte_libre>&code-retour=<code_retour>&r etourplus=<options>" par exemple : "TPE= &date=09%2f10%2f1996%5fa%5f15%3a51%3a46&montant=10%2e75EU R&reference=AZERTYP12345&MAC=e4359a2c18d86cf2e4b0e646016c202e89947b04 &texte-libre=reference+commande+tres+tres+longue&code-retour=paiement &retourplus=--optionaxyz--optionb123" Fonctionnalité «tester HMAC» Cette fonction doit être implémentée dans le «CGI2» pour s assurer qu il n y a pas eu de falsification des données contenues dans le message de confirmation du paiement reçu. Le message de confirmation reçu est «scellé» par un sceau MAC qui a été calculé par le serveur de paiement de la banque à l aide de la clé de sécurité commerçant attribuée à votre terminal de paiement. L objet de la fonctionnalité «tester HMAC» est de recalculer le code MAC associé au message et de le comparer à celui transmis dans le message : si les deux codes MAC sont identiques, l information reçue est fiable (intégrité des informations et authentification de l émetteur). Le serveur commerçant peut alors exploiter le message : Rechercher la commande en attente de paiement qui correspond à la référence et au montant Mettre à jour les informations relatives à cette commande et, dans le cas de code-retour «paiement», en tenant compte des informations complémentaires [--options] de retourplus, lancer le processus de livraison, typiquement envoyer un à l internaute et informer le commerçant. Se préparer au retour de l internaute sur le site du commerçant. Résultat du paiement : code-retour Le champ code-retour doit être égal à une de ces 3 valeurs : payetest paiement Annulation : si la carte bancaire est acceptée sur le serveur de test : si la carte bancaire est acceptée sur le serveur de production : si la carte bancaire est refusée 10 /13

11 Complément CyberMUT 2004 option «PLUS» : retourplus C est un tableau de données délimitées par 2 tirets -- avant chaque valeur. La liste des données fournies dépendra des options CyberMUT P@iement 2004 souscrites, parmi les champs prévus : --hpan : hachage irréversible (HMAC-SHA1) de la carte (identifiant de manière unique une carte pour un commerçant donné) --vld : date de validité de la carte (https exigé) --bin : code BIN banque de la carte (https exigé) --cvx : oui (--cvxoui) ou non (--cvxnon) selon que le code de contrôle cvv2/cvc2 a été saisi (le cvv2/cvc2 est obligatoire pour les cartes Visa/MasterCard) --aut : numéro d autorisation --gar : garantie de paiement ( Verified by Visa, Ucaf MasterCard, CartaFacile, etc.) par exemple : "retourplus=--cvxoui--hpan1a2b3c4d5e6f a2b3c4d5e6f " NB : L annexe CyberMUT P@iement 2004 option «PLUS» paraîtra prochainement. Fonctionnalité «créer accusé de réception» La réponse renvoyée par le «CGI2» dans le flux de retour doit être un des 2 messages d accusé de réception présentés dans le tableau «Réponse du serveur commerçant», dépendant seulement de la vérification du sceau MAC reçu, sans tenir compte de la valeur du code-retour de paiement, dès lors que cette valeur fait partie de la liste des valeurs énumérées pour le champ code-retour. Lorsque le serveur de la banque ne reçoit pas d accusé de réception «OK» (time out, erreur, ), il envoie un d alerte sur une boîte aux lettres électronique de surveillance indiquée par le commerçant et refait une seconde tentative. Pour cela, dès la phase de test, le commerçant doit nous fournir l adresse d une boîte aux lettres électronique régulièrement relevée. Pour passer en production, le serveur commerçant doit avoir fait au moins un test complet avec accusé de réception «OK». Une confirmation par fax peut être mise en place. C'est une option payante (0.76 EUR HT/fax au 1/12/2003). Cette confirmation ne remplace pas la confirmation «CGI2» on-line à laquelle le serveur commerçant doit obligatoirement répondre. 11 /13

12 2.4 Spécifications des formats Contrainte générale de codage HTML des champs Tous les champs de formulaire «CGI1» doivent être codés en HTML immédiatement avant la mise en forme dans le formulaire (c est à dire immédiatement après le calcul du MAC). Les caractères à coder impérativement sont les codes ASCII<=127 «non safe» : "&" sera remplacé par "&" "<" sera remplacé par "<" ">" sera remplacé par ">" double quote (") par """ ou "&#x22 ;" simple quote ( ) par "&#x27;" Les fonctions de type «HTML_ENCODE» des langages conviennent parfaitement, elles encodent beaucoup plus de caractères, typiquement tout ce qui n est pas : "ABCDEFGHIJKLMNOPQRSTUVWXYZ", "abcdefghijklmnopqrstuvwxyz", " ", "_.-" (blanc souligné, point, tiret) Note importante : pour éviter tout problème de calcul du sceau MAC si vous utilisez dans le champ texte-libre des caractères hors de la plage ascii commune imprimable (31<ascii<127), vous devez coder ce champ («url encode» ou «base64» ou tout autre codage dont le résultat ne comporte que des caractères «31<ascii<127» ) avant tout traitement relatif au paiement (donc avant le calcul du sceau MAC). Contraintes particulières selon le champ Champs Contenu/Format avant codage HTML Taille maxi après codage HTML TPE 07 version 1.2open Fixe date 40 montant 20 reference A-Z a-z MAC 0-9 A-F a-f 40 lgue 2 societe 20 texte-libre Base code-retour A-Z a-z retourplus A-Z a-z 0-9 _ URLs /13

13 3 URLs des serveurs bancaires 3.1 URLs des serveurs de test Le rôle de notre serveur de test est de vous permettre de tester et de valider vos développements. Sur ce serveur de paiement de test, le seul contrôle effectué est un contrôle de structure du numéro de carte (contrôle de clé de Luhn). Il n'y a pas d'autres contrôles effectués : date d'expiration, contrôle du fichier des cartes en opposition, etc., comme cela existe sur notre serveur de paiement de production. Bien sûr, aucun paiement accepté par notre serveur de paiement de test ne donne lieu à une mise en recouvrement. Afin de tester les différents codes de retour du serveur bancaire, vous avez la possibilité d utiliser plusieurs cartes de tests dont les coordonnées sont affichables en cliquant sur l icône «Carte de Test» de la page de paiement bancaire. Les environnements de test sont disponibles aux adresses suivantes : Pour les banques et fédérations du Crédit Mutuel Pour les banques du Groupe CIC Pour la banque OBC Pour la banque CAIXA URLs des serveurs de production Après avoir validé vos développements, vous pourrez vous adresser au serveur de production, disponible à l adresse suivante : Pour les banques et fédérations du Crédit Mutuel Pour les banques du Groupe CIC Pour la banque OBC Pour la banque CAIXA Nous attirons votre attention sur le fait que les formulaires de paiement adressés au serveur de production seront des paiements réels. 13 /13