SIPS (Secure Internet Payment Services) est un service de paiement à distance de la société Atos Worldline, qui a remporté en 2007 le prix Sesame Award pour ce service utilisé en Europe. Fonctionnalités : Ce système de paiement peut s'intégrer quel que soit le canal de vente à distance : Internet, Internet mobile, Serveur vocal interactif, télévision numérique, centre d'appel, etc.

Son principe est de concentrer en une caisse virtuelle unique une fonction de paiement sécurisée, un outil de gestion des transactions et de suivi de leur envoi en banque et permet d'obtenir des relevés détaillés de l'activité.

L'utilisation de SIPS permet au commerçant d'accepter des moyens de paiement internationaux ainsi que locaux. Les commerçants peuvent donc exercer leurs activités dans l'ensemble de l'Union européenne avec une seule solution de paiement. Cette solution est utilisée entre autres par la banque nationale d'Australie

Le paiement sur Internet :
SIPS assure la sécurisation du paiement sur les serveurs sécurisés d'Atos Worldline. Lorsque le client internaute a constitué son panier, il confie à SIPS le soin de réaliser le paiement avec son client (obtention d'un numéro de carte, d'un numéro de compte, d'un identifiant de porte-monnaie virtuel, etc). Le serveur SIPS lui donnera le résultat de l'opération en temps réel afin que l'expédition de sa commande puisse avoir lieu.

Avec l'Interface de programmation Server, le commerçant peut choisir de gérer lui-même cette étape de capture des informations et de les confier en communiquant avec SIPS de serveur à serveur. Cela permet au commerçant de conserver la maîtrise de l'ensemble du processus, paiement compris, sans que l'internaute ne quitte son site.

Les plateformes et les langages de programmation :
Du côté du commerçant/hébergeur, le service est multi plateformes. Le serveur du commerçant est équipé d'une interface (API, fournie par Atos Worldline), élaborée soit à partir d'une librairie de fonctions écrites en C ou en Java soit à partir d'un plug-in exécutable. Ce logiciel (compatible POSIX) est compatible avec les serveurs acceptant les modules CGI ainsi qu'avec une multitude de systèmes d'exploitation.

L'API SIPS Payment avec laquelle le serveur du commerçant communique est disponible, en fonction des plateformes utilisées, pour les langages de programmation tels que le C, le Java ou encore par des langages scripts comme Perl, PHP, ASP, Shell.

Les moyens de paiement :

L'internaute a la possibilité de payer le commerçant avec :

• Les cartes de paiement (CB, VISA ou EUROCARD/MASTERCARD),
• Les cartes de accréditives et corporate (American Express, Diner's club),
• Les cartes privatives et d'enseignes (Cetelem, Finaref, etc)
• Les chèques cadeaux (Promonetic)
• Le téléphone portable (Bouygues Telecom / Cetelem)

Le paiement sur Internet: le flux:

Le parcours d'une transaction varie en fonction des moyens de paiement utilisés. La cinématique d'une transaction carte est décrite ci-après.

Le paiement traditionnel

• 1. L'internaute navigue sur le serveur commerçant et remplit son caddie.
• 2. L'internaute souhaitant passer à la caisse, le serveur commerçant utilise l'API pour afficher tous les moyens de paiement acceptés.
• 3. En cliquant sur un de ces moyens de paiement, l'internaute se connecte au serveur de paiement SIPS. Le serveur SIPS affiche le formulaire approprié pour obtenir ses coordonnées bancaires.
• 4. Le serveur SIPS effectue une demande d'autorisation auprès d'une institution financière impliquée dans le paiement sélectionné.
• 5. et 5'. Après réception de la réponse d'autorisation, SIPS envoie la réponse de la demande d'autorisation au serveur commerçant et affiche un ticket de caisse sur l'écran de l'internaute.
• 6. A partir de ce ticket, l'internaute peut cliquer sur un bouton pour retourner sur le serveur commerçant, qui reçoit ainsi toutes les informations concernant la transaction (identique à 5').
• 7. Atos Worldline envoie la transaction pour remise en banque (crédit commerçant et débit internaute)

Le paiement 3D-Secure

Le paiement 3D-Secure mettant en jeu d'autres acteurs et connexions permettant d'authentifier directement l'acheteur, il est plus complexe.


Une transaction de paiement sur le site d'un commerçant inscrit au programme 3D-Secure implique l'authentification du porteur, et met ainsi en œuvre des flux supplémentaires en direction du réseau cartes (Visa / Mastercard) ainsi que de la banque de l'Internaute.

La cinématique du paiement diffère du paiement traditionnel après la troisième étape (cf. page précédente).

• 4 et 5. Le serveur SIPS transfère les coordonnées carte de l'internaute vers le réseau Visa ou Mastercard, qui à son tour contacte la banque émettrice, qui détermine si le porteur est ou non inscrit 3D Secure (et donc dispose d'un mot de passe).
• 6 et 7. Si le porteur est effectivement inscrit (ou « enrôlé »), SIPS met le porteur en relation avec la banque émettrice (6). Celle-ci affiche un formulaire pour saisie du mot de passe. Atos Worldline est destinataire (7) de la vérification du mot de passe par la banque, via le poste de l'internaute. Si le porteur n'est pas inscrit, il passe directement au point 8.
• 8 et 9. La transaction prend le circuit traditionnel et est envoyée pour demande d'autorisation vers la banque du commerçant. Après réception de la réponse d'autorisation, SIPS envoie la réponse de la demande d'autorisation au serveur commerçant (9') et affiche un ticket de caisse sur l'écran de l'internaute (9).
• 10. A partir de ce ticket, l'internaute peut cliquer sur un bouton pour retourner sur le serveur commerçant, qui reçoit ainsi toutes les informations concernant la transaction (identique à 9').
• 11. Atos Worldline envoie la transaction pour remise en banque (crédit commerçant et débit internaute)

Le cycle de vie d'une transaction

CyberMUT P@iement est une solution qui permet à vos clients de vous régler par carte bancaire, sur votre site internet. Véritable terminal de paiement électronique (TPE) virtuel, il s'adapte aussi facilement à un petit commerce en ligne qu'à un site d'e-commerce international travaillant en plusieurs langues et devises. Ce service, opérationnel depuis 1996, décharge votre site de toute la phase de paiement ; en effet cette dernière a lieu directement sur le serveur de paiement sécurisé de la banque. Le serveur de paiement effectue la vérification de la validité de la carte bancaire de l'acheteur avant d'accorder l'autorisation de paiement et confirme automatiquement le résultat de la demande de paiement au serveur du commerçant.

Les éléments de sécurisation des échanges mis en oeuvre dans le cadre du service de paiement sécurisé sont les suivants :

• intégrité des données échangées entre le serveur du commerçant et le serveur de la banque assurée par une méthode de scellement,
• authentification du commerçant émetteur de la demande de paiement,
• confidentialité des données échangées entre l'acheteur et le serveur de paiement de la banque (numéro, date de validité et cryptogramme visuel de la carte bancaire) assurée par chiffrement TLS,
• saisie directe des coordonnées Carte Bancaire sur le site sécurisé de la banque, garantissant que ni le commerçant, ni aucun intermédiaire technique, n'auront connaissance des informations concernant la carte bancaire,
• intégration native de la fonctionnalité Visa 3D Secure / MasterCard Secure Code, qui permet à la banque de garantir le paiement dans les pays où la solution est déployée.

Notre solution de paiement offre depuis son introduction la meilleure sécurisation possible ; cette sécurisation est garantie par des audits réguliers réalisés par des sociétés indépendantes.

De plus, l'utilisation d'une solution "Open Source" vous permet une maîtrise complète et transparente. Vous pourrez donc mettre en oeuvre selon vos propres préférences et constater par vous-même et en toute transparence le niveau de sécurité de notre solution. Ceci vous permettra également d'être en permanence à jour en incluant dans votre solution les dernières mises à jour de sécurité disponibles.

Principe

La solution Monetico Paiement s'intègre facilement dans votre site internet, quelle que soit sa configuration. Les paiements par carte bancaire de vos clients transitent alors par votre banque, qui enregistre pour vous les transactions.



Les contrôles portent notamment sur :

• la validité du numéro de carte
• le cryptogramme visuel
• la date de validité de la carte
• le fichier des oppositions
• l'encours carte
• l'identité du porteur

Vous bénéficiez d'un retour d'information immédiat sur votre serveur suite à chaque paiement effectué sur notre plate-forme, vous notifiant du succès ou de l'échec du paiement. En complément, nous pouvons également vous notifier par courriel du résultat de ces paiements.

Technique et échanges

Le schéma et le paragraphe suivants présentent la cinématique des échanges intervenant lors d'un paiement, entre l'acheteur, le serveur Web du commerçant et le serveur sécurisé de la banque.

L'interfaçage du serveur du commerçant avec le serveur de paiement de la banque s'effectue par l'intermédiaire de deux programmes, situés sur le serveur marchand. Nous les appellerons ici interface "Aller" et interface "Retour" ; ils interviennent respectivement dans les phases (3) et (7).

Un paiement se passe de la façon suivante :

• (1) L'acheteur parcourt le catalogue des produits et remplit son caddie virtuel
• (2) Le serveur du commerçant affiche un résumé de la commande
• (3) Préparation de la phase aller du paiement : génération du formulaire de demande de paiement Le serveur du commerçant propose à l'acheteur un bouton "Paiement par carte bancaire". Ce bouton va agir comme charnière entre la phase de commande et la phase de paiement : lorsque l'acheteur cliquera sur ce bouton, il sera dirigé vers le serveur de paiement sécurisé de la banque. Ce bouton est en réalité la seule partie visible d'un formulaire HTML contenant toutes les informations relatives à la commande qu'il est nécessaire de transmettre au serveur de la banque (le montant de la commande, sa référence, le numéro du TPE virtuel du commerçant, etc.). En cliquant sur ce bouton, l'acheteur arrive sur le site de paiement sécurisé de la banque en ayant apporté avec lui ces informations. L'interface "Aller" est chargée de générer ce formulaire HTML. Le développement de ce lien entre boutique et serveur de paiement reste sous l'entière responsabilité du marchand (ou de ses prestataires de développement/intégration).
• (4) Lorsque l'acheteur clique sur le bouton "Paiement par carte bancaire", il arrive sur le serveur sécurisé de la banque, accompagné des informations de la commande nécessaires au paiement.
• (5) Le serveur de la banque propose à l'acheteur un formulaire de saisie du numéro, de la date de validité et du cryptogramme visuel de sa carte bancaire.
• (6) L'acheteur valide le paiement. La banque vérifie la validité de la carte bancaire. Différents niveaux de vérification sont effectués selon le mode de fonctionnement du TPE (mode tel que décrit plus haut).
• (7) Phase retour du paiement Le serveur de la banque informe directement le système informatique du commerçant du résultat de la demande de paiement en émettant une requête http(s) sur l'adresse de confirmation des paiements (en d'autres termes, le serveur de la banque appelle l'interface "Retour" placée sur la machine du commerçant). Vous devez nous indiquer cette adresse URL au moment de la mise en place du système et en cas de changement (modification de nom de domaine ou de répertoire).
• (8) Le système informatique du commerçant accuse réception de la confirmation du paiement. En pratique, l'interface "Retour" est chargée de recevoir la requête de confirmation du paiement, d'en extraire les différentes informations et de répondre au serveur bancaire par un accusé de réception. Les informations reçues par l'interface "Retour" permettent de déterminer la commande concernée, ainsi que le résultat de la demande de paiement. Cela permet au serveur du commerçant d'effectuer des traitements spécifiques :
  - Vérifier que le montant et la référence correspondent au règlement d'une commande enregistrée en attente de paiement
  - Mettre à jour le statut de la commande dans les bases de données
  - Envoyer un courriel de confirmation au commerçant et/ou à l'acheteur
  - Etc.
  Attention : la commande doit être persistante dans le système commerçant (fichier, base de données) dès le début du processus et ne doit pas être détruite même après un premier avis de refus de paiement. En effet, un refus peut être suivi d'un accord (l'interface "Retour" peut donc être appelée plusieurs fois pour une même commande), par exemple en cas d'erreur de saisie ou de plafond CB atteint ; l'acheteur peut donc vouloir utiliser une autre carte pour effectuer son paiement.
• (9) Le serveur de la banque affiche à l'acheteur le résultat du paiement et propose sur cet écran un lien hypertexte lui permettant de retourner sur le site du commerçant. Les points (8)

RSA Security est une entreprise inscrite au NASDAQ appartenant à EMC depuis le 14 septembre 2006. Son siège social est à Bedford, au Massachusetts, et la société a des bureaux en Irlande, au Royaume-Uni, à Singapour et au Japon. RSA Security organise la conférence annuelle RSA Conference. Ses produits les mieux connus sont les bibliothèques cryptographiques B-SAFE et le ticket d'authentification SecurID. RSA est un sigle formé à partir des noms de ses fondateurs : Ronald Rivest, Adi Shamir et Leonard Adleman. Ce sont les co-inventeurs du cryptosystème à clé publique du même nom : le chiffrement RSA.