Introduction

Sips est une solution de paiement de commerce électronique multicanale sécurisée conforme à la norme PCI DSS. Elle vous permet d’accepter et de gérer des transactions de paiement en prenant en compte les règles métiers liées à votre activité (paiement à la livraison, paiement différé, paiement récurrent, paiement en plusieurs fois , …).

L’objectif du présent document est d’expliquer la migration vers Sips 2.0.

A qui s’adresse ce document

Ce document est à destination des commerçants disposant de l’offre Sips 1.0.

Il a pour but de faciliter la migration vers Sips 2.0.

Contacter l'assistance

Pour toute question technique ou demande d'assistance, nos services sont disponibles :

  • par téléphone au : +33 (0) 811 10 70 33 ;
  • par e-mail : sips@worldline.com.

Pour faciliter le traitement de vos demandes, veuillez communiquer votre identifiant de commerçant : merchantId (numéro à 15 chiffres).

Etapes de migration

Timing

Nous avons identifié une liste d’étapes indispensables à la bonne réalisation de la migration de Sips 1.0 vers Sips 2.0. Ces étapes peuvent être schématisées de la manière suivante :

Etape Acteurs Description
1 Client Demande client
2 Worldline Etat des lieux du profil commerçant, cartographie, présentation de migration et remise de la trousse.
3 Client Choix de migration
4 Client/ Worldline Validation Design + planning + choix technique
5 Client Développements client pour se connecter à 2.0 et adapter la personnalisation des pages.
6 Worldline Inscription boutique en recette
7 Client Recette fonctionnelle 2.0
8 Worldline Inscription boutique production et migration des données
9 Client PV de recette. Date de migration
10 Worldline Suivi des flux suite au démarrage
11 Client/ Worldline Suppression des références à Sips 1.0 sur le site commerçant/Suppression des accès.

Le calendrier précis de migration est défini à l’étape 4, une fois le choix technique effectué par le client avec l’assistance de Worldline .

Processus de migration

Ce processus de migration décrit les étapes successives nécessaires que vous devrez suivre afin de réaliser avec succès votre migration vers Sips 2.0.

Etat initial

Vous disposez d’une boutique en 1.0, vous avez donc un merchantId qui permet de vous identifiez. Toutes vos transactions sont réalisées avec ce merchantId et vous bénéficiez de journaux consolidés et d’une visualisation de toutes vos transactions sur l’extranet ( Sips Office Extranet ) tous moyens de paiement confondus.

Passage des flux en 2.0

Vous pilotez la migration. Après avoir émis votre PV de recette, la décision de la date et de l’heure de migration est prise conjointement entre vous et Worldline . Un suivi attentif des premiers flux est opéré de la part de vous et de Worldline pour vous assurer du bon déroulement de la bascule en 2.0.

Procédure de retour

Dans le cas où vous détectez une anomalie (problème non identifié lors de la phase de recette de vos développements internes), il est possible de rebasculer les flux sur Sips 1.0 via les API.

Cette solution reste possible tant que vous et Sips maintenez les identifiants de connexion 1.0 valides. La suppression des accès 1.0 est réalisée lors de la dernière étape (11).

Accompagnement

Un dispositif d’accompagnement facilite la migration pour vous et garantit le succès de celle-ci :

  • Présenter
  • Conseiller
  • Supporter

L’équipe commerciale Worldline est en charge de la présentation de la solution Sips 2.0. Elle pourra vous expliquer les apports techniques et fonctionnels de l’évolution de notre solution.

Les ASM (Account Support Manager) Worldline qui sont quotidiennement à votre contact ont une bonne connaissance de votre fonctionnement global et de l’utilisation de notre produit. Ils sont chargés d’effectuer une cartographie (profil d’utilisation) afin de couvrir la totalité du périmètre fonctionnel et technique.

Suite à cette étude, l’équipe commerciale présente le processus de migration ainsi que sa trousse d’accompagnement (présentation générale, guides de correspondances, guides d’implémentation).

Quand vous (équipe technique ou sous-traitant) avez pris connaissance de la documentation mise à votre disposition et défini sa solution, un rendez-vous technique avec Worldline permet de valider le design de la solution.

L’étape de création de la boutique de recette est prise en charge par l’équipe des technico-commerciaux.

Vous (ou votre prestataire) pouvez alors démarrer la phase de développement et (éventuellement) de personnalisation des pages de paiement. Les équipes techniques et fonctionnelles de Worldline sont présentes pour accompagner et fournir toutes les précisions nécessaires à la bonne réalisation.

Lorsque les développements client sont réalisés, la recette fonctionnelle 2.0 peut démarrer et une assistance particulière est mise en place par Worldline afin de faciliter celle-ci (aide au paramétrage de la fraude, nouveaux code réponse, ...).

Une fois que les tests sont finalisés, la boutique est inscrite en production, les données sont migrées par Worldline et un suivi particulier est effectué lors du démarrage et des semaines suivantes afin de vérifier le bon déroulement de la bascule sur Sips 2.0.

Principes de migration vers Sips 2.0

Ce qui est disponible en 2.0

Fonctionnalités

Interface (mode) Fonctionnalité Payment 1.0 Sips Paypage 2.0 Sips Office 1.0 Sips Office 2.0 Sips Office Batch 2.0 Sips In-App Sus cription Sips Walletpage 2.0
Gestion des paypages sécurisées
Personnalisation des pages V V X X X X V V
Affichage de la sélection des moyens de paiement V V X X X X V V
Affichage du ticket par Sips V V X X X X V X
Nombre de tentatives de paiement V V X X X X V V
Nouvelle tentative de paiement X V X X X X X X
Durée de présence sur les pages de paiement V V X X X X V X
Affichage du nom de la boutique V V X X X X X V
Saisie du numéro de carte en blocs séparés X V X X X X X V
Saisie du nom du titulaire de la carte X V X X X X X V
Affichage optionnel de la page d’erreur X V X X X X X X
Masquage de la saisie d’informations sensibles X V X X X X X V
Affichage du message d’attente X V X X X X X X
Balise iframe V V X X X X V V
Canal de paiement
INTERNET V V V V V X V V
MOTO V V V V V X V X
In App mobile X X X X X V X X
Modalités de remise en paiement
Paiement à la fin de la journée V V V V V V V X
Paiement différé V V V V V V V X
Paiement à l’expédition V V V V V V V X
Paiement en plusieurs fois V V X X X X X X
Paiement immédiat V V V V V V X X
Période de validité de l’autorisation V V V V V V V X
Paiement en devises
Acceptation multidevises V V V V V V V X
Règlement en devises V V V V V V V X
Conversion dynamique des devises V V X X X X X X
3-D Secure
3-D Secure (VISA/MC/AMEX) V V V V X V X V
Débrayage dynamique du 3-D Secure V V X X X X X X
Débrayage du 3-D Secure pour les paiements OneClick V V X X X X X X
Refus des transactions erreur 3D V V V V X V X V
OneClick - gestion du wallet commerçant
Inscription et paiement V V X X X V X X
Paiement V V V V V V X X
Création du wallet hors paiement X X V V V X X V
Lecture des données wallet X X V V V X X V
Lecture des données moyen de paiement X X V V V V X V
Ajout d’un moyen de paiement hors cinématique de paiement V X V V V X X V
Mise à jour d’un moyen de paiement hors cinématique de paiement V X V V V X X V
Suppression d’un moyen de paiement V V V V V X X V
Suppression du wallet X X V V V X X V
Paiement récurrent
1er paiement récurrent V V V V V V V X
Nème paiement X X V V V V X X
Règlement de facture
Paiement standard X V X X X X X X
Paiement OneClick X V X X X X X X
Gestion de caisse
Annulation X X V V V X X X
Validation X X V V V X X X
Remboursement X X V V V X X X
Remboursement déplafonné X X X V V X X X
Duplication X X V V V X X X
Duplication étendue X X V V V X X X
Forçage (arrêté en 2.0 pour répondre aux contraintes réglementaires PCI) X X V X X X X X
Recyclage X X X V V X X X
Crédit Porteur X X V V V X X X
Reporting en ligne
Diagnostic X X V X X X X X
Réponse automatique V V X X V V V V
Réponse manuelle V V X X X V V V
Confirmation fin de transaction vers le client V V X V X X X X
Reporting fichier
Journal des transactions V V V V V V V X
Journal des opérations V V V V V V V X
Journal de rapprochement des transactions V V V V V V V X
Journal de rapprochement des impayés V V V V V V V X
Journal des cartes échues V V V V V V X X
Tokenisation
Renvoi du token X V X V X X X X
Renvoi du PAN hashé X V X X X X X X
Tokenisation de numéros de carte X X X V V X X X
Détokenisation de numéro de carte X X X V X X X X
Tokenisation de transaction X X X V V X X X
Paiement à partir d’un token X X X V V X X X
Crédit porteur à partir d’un token X X X V V X X X
Entité agissant pour un commerçant
Intermediate Service Provider (ISP) X V X V X V X V
Spécificité pays
Sélection de la marque (MIF) X V X V V V X X
Service de vérification d’adresse (AVS) X V X V V X X X
Surcharge de frais X V X X X X X X
ARP (Advance registration program) X V X X X X X X

Moyens de paiement

Interface (mode) Moyens de paiement Payment 1.0 Sips Paypage Sips Office 1.0 Sips Office Sips Office Batch Sips In-App Sips Walletpage
CB V V V V V V V
Visa V V V V V V V
MasterCard V V V V V V V
American Express V V V V V V V
VPay X V X V V V V
Maestro V V V V V V V
Visa Electron V V V V V V V
Airplus SNCF X X V X X X X
Bancontact V V V V X V V
Buybox V X V V X X X
Carte Casino BCACUP X X V V X X X
Carte Oney V V X V X X V
Carte Oney Cadeau V V X V X X X
Carte Cpay (ex-Aurore Visa Cetelem) V V X X X X X
Cetelem Presto V V X X X X X
Cofidis 1euro.com V V X X X X X
Cofidis 3X V V V X X X X
Cofidis 4 étoiles V X V X X X X
Cofinoga V X V X X X X
Cofinoga 3XCB V V V X X X X
Delta V use visa V use visa use visa use visa use visa
Diners V X V X X X X
ELV V V V V X X X
Facilypay (Accord 3X4) V V X X X X X
Finaref privatives V X V X X X X
Franfinance 3XWEB V V X X X X X
Franfinance privatives V X V X X X X
Franfinance Solution Sprint Secure V X X X X X X
iDEAL V V X V X X X
JCB V X V X X X X
Masterpass V V V V X X X
Paylib V V X V X X X
PayPal V V V V X X V
S2P CBPASS V X X X X X X
S2P PASS V X X X X X X
S2P PASS2 V X X X X X X
S2P Visa PASS Belgique V X X X X X X
SEPA Direct Debit V V V V V X X
Sofortüber weisung V V X V X X X
Switch V use MC V use MC use MC use MC use MC

Ce qui change en 2.0

Connecteurs

  • Nouveaux connecteurs non intrusifs en remplacement des API,
  • Nouvelle clé secrète par boutique qui remplace le certificat Sips 1.0.

Merci de vous référer à la documentation :

  • Guide de migration Payment 1.0
  • Guide de migration Sips Office 1.0 .

Moyens de paiement

  • Nouveaux moyens de paiement internationaux,
  • Moyens de paiement existants 1.0 non encore reportés.

Merci de vous référer à la documentation :

  • Liste des moyens de paiement disponibles et le calendrier de lancement (§ 3.1.2),
  • Guides d’implémentation des différents moyens de paiement.

Identification des transactions

Rappel de l’existant 1.0

Sur Sips 1.0, le système d’identification des transactions est assuré par l’assemblage des 4 champs suivants :

  • MerchantId (N15) : valeur fixe donnée par Sips ,
  • MerchantCountry (A2) : valeur fixe donnée par Sips ,
  • TransactionDate (YYYYMMDD) : valeur variable donnée par Sips (en fuseau local Français) au moment de l’acceptation du paiement,
  • TransactionId (N6) : valeur variable attribuée par vous ou par Sips en votre délégation au moment de la demande de paiement (c'est-à-dire avant la demande d’autorisation). Il doit être unique pour la combinaison des 3 champs précédents.

Les opérations associées à une transaction sont identifiées par un quintuplé, les 4 champs précédents complétés d’un operation_sequence.

Génération de l’identification des transactions

Comme sur Sips 1.0, le mode par défaut de génération de l’identifiant de la transaction est la génération faites par vous-même. Ce mode est préconisé car il vous permet de stocker le contexte et de préparer le rapprochement de votre transaction avant l’envoi de la requête.

Le mode de génération automatique est une facilité d’intégration qui n’est pas recommandé si vous générez des flux importants car il présente quelques inconvénients :

  • Le contrôle de doublon de transaction est effectué par Sips sur cet identifiant que vous avez envoyé. Donc dans le cas de l’auto-génération de l’identifiant, ce contrôle ne peut pas être effectué.
  • L’absence de TransactionId ou TtransactionReference dans la requête vous oblige à utiliser d’autres données (customer, orderId, amount) pour rapprocher la réponse et la requête.
  • Il n’est pas possible d’interroger Sips avec la méthode Diag en cas de dysfonctionnement (exemple : Réponse non reçue par vous, …)

Le TransactionReference

Sur Sips 2.0, l’identification standard de la transaction se fait grâce à un nouvel identifiant : le TransactionReference .

Ce nouvel identifiant présente l’avantage d’être au format ANS35 ce qui permet :

  • de garder cet identifiant unique de manière illimitée (sur la période d’existence de la transaction dans Sips : 15 mois) au lieu d’une journée pour le TransactionId ,
  • d'utiliser des caractères alphanumériques dans la référence, format ouvert facilitant la génération par vous,
  • de se rendre indépendant des fuseaux horaires (internationalisation).

La compatibilité

Afin de minimiser les impacts tout en restant sur 1.0, l’utilisation du TransactionId est maintenue dans Sips 2.0.

Sur Sips 2.0, vous devez être dans un des deux modes suivants :

  • Mode TransactionReference (mode par défaut),
  • Mode TransactionId .

Si vous souhaitez rester en mode transactionId vous devez en faire la demande à Sips lors de l’inscription de votre identifiant commerçant à l’offre Sips 2.0.

Toutes les transactions sur Sips 2.0 sont à la fois liées à un TransactionId + TransactionIdDate et à un TransactionReference .

Les TransactionId , TransactionIdDate et TransactionReference sont stockés, restitués et affichés pour toutes les transactions.

Dans les interfaces 2.0, les champs transactionId et TtransactionIdDate ont été nommés s10TransactionId et s10TransactionIdDate afin de vous permettre d’identifier directement et simplement la référence à Sips 1.0.

En résumé,

  • TransactionReference est le moyen par défaut d’identifier une transaction,
  • s10TransactionId permet d’identifier une transaction en restant compatible avec Sips 1.0,
  • le couple s10TransactionId + s10TransactionIdDate assure l’unicité de la transaction.

Les cas d’utilisation

Création des transactions

Lors d’une création de transaction, et en fonction du mode choisi, Sips accepte ou rejette la création et génère des identifiants complémentaires. Le tableau ci-après récapitule les différents cas possibles.

Création de transaction via
Cas d’utilisation Données Sips Paypage Sips Office Sips Office Extranet
Boutique en mode TransactionReference
Vous vous connectez à Sips avec un Transaction Reference que vous avez généré. Transaction Reference fourni par vous. cas d'usage cas d'usage Proposé par Sips , modifiable et affiché en rouge.
TransactionId fourni par vous.

Rejet

Rejet Code = 12

Rejet

Code = 12

N/A
TransactionId absent. OK OK N/A
Transaction Reference absent.

Rejet

Code = 12

Rejet

Code = 12

Rejet

Code = 12

Référence complémentaire générée par Sips .

s10Transaction Id

s10TransactionId Date

s10Transaction Id

s10Transaction Id Date

s10Transaction Id

s10Transaction IdDate

Contenu réponse

s10Transaction Id

s10Transaction IdDate

Transaction Reference

s10Transaction Id

s10Transaction IdDate

Transaction Reference

Vous vous connectez à Sips sans Transaction Reference (Tref auto). Transaction Reference généré par Sips . cas d'usage N/A Généré par Sips et affiché en rouge.
TransactionId fourni par vous.

Rejet

Code = 12

N/A
TransactionId absent. OK N/A
Transaction Reference fourni par vous.

Rejet

Code = 12

N/A
Référence complémentaire générée par Sips .

Transaction Reference

s10Transaction Id

s10Transaction IdDate

Transaction Reference

s10Transaction Id

s10Transaction IdDate

Contenu réponse

s10Transaction Id

s10Transaction IdDate

Transaction Reference

Boutique en mode TransactionId
Vous vous connectez à Sips avec un TransactionId que vous avez généré. TransactionId fourni par vous. cas d'usage cas d'usage Proposé par Sips , modifiable et affiché en rouge.
TransactionId absent.

Rejet

Code = 12

Rejet

Code = 12

Rejet

Code = 12

Transaction Reference fourni par vous.

Rejet

Code = 12

Rejet

Code = 12

N/A
Transaction Reference absent. OK OK N/A
Référence complémentaire générée par Sips . Transaction Reference Transaction Reference Transaction Reference
Contenu réponse

s10Transaction Id

s10Transaction IdDate

Transaction Reference

s10Transaction Id

s10Transaction IdDate

Transaction Reference

Vous vous connectez à Sips sans TransactionId (Tid auto). TransactionId généré par Sips . cas d'usage N/A Généré par Sips et affiché en rouge.
TransactionId fourni par vous.

Rejet

Code = 12

N/A
Transaction Reference fourni par vous.

Rejet

Code = 12

N/A
Transaction Reference absent. OK N/A
Référence complémentaire générée par Sips .

s10Transaction Id

s10Transaction IdDate

Transaction Reference

s10Transaction Id

s10Transaction IdDate

Transaction Reference

Contenu réponse

s10Transaction Id

s10Transaction IdDate

Transaction Reference

Opérations de caisse

Pour les opérations de caisse, l’identification d’une transaction n’est pas limitée au mode choisi.

Le tableau ci-dessous reprend les différentes possibilités.

Cas d’utilisation Données Gestion de caisse
Boutique en mode TransactionReference
Transaction d'origine générée avec un TransactionReference : TransactionId fourni par vous. OK
TransactionReference fourni par vous. OK
TransactionReference et TransactionId cohérents fournis par vous. OK
TransactionReference et TransactionId ne référençant pas la même transaction fournis par vous.

Rejet

Code = 12

Nouvelle transaction (duplication, recyclage et crédit porteur). Voir Tableau de création des transactions ci-dessus.
Boutique en mode TransactionId
Transaction d'origine générée avec un TransactionId . TransactionId fourni par vous. OK
TransactionReference fourni par vous. OK
TransactionReference et TransactionId cohérents fournis par vous. OK
TransactionReference et TransactionId ne référençant pas la même transaction fournis par vous.

Rejet

Code = 12

Nouvelle transaction (duplication, recyclage et crédit porteur). Voir Tableau de création des transactions ci-dessus.
Le paiement en N fois (via paypages)
  • Mode transactionId

Pour effectuer un paiement en plusieurs fois en mode TransactionId , vous devez transmettre une liste de TransactionId et une liste de TransactionIdDate dans la requête de paiement. Sips génère automatiquement une TransactionReference pour chaque transaction.

Si la liste de TransactionId n’est pas envoyée, la transaction est rejetée avec un responseCode = 12.

  • Mode TransactionReference

Pour effectuer un paiement en plusieurs fois en mode transactionReference , vous devez transmettre une liste de TransactionReference et la date de chacune des échéances dans la requête de paiement. Sips génère automatiquement un TransactionId pour chaque transaction.

Si la liste de TransactionReference n’est pas envoyée, la transaction est rejetée avec un responseCode = 12.

Le paiement en N fois n’est pas compatible avec le mode de génération automatique de la référence de transaction par Sips .

Reporting
  • Journaux

Les champs s10TransactionId , s10TransactionIdDate et TransactionReference sont présents dans les journaux de rapprochement des transactions, des opérations, de rapprochement des transactions et de rapprochement des impayés 2.0, indépendamment du mode d’identification de transaction activé.

Pour les opérations de duplication et de recyclage, la transaction d’origine est identifiable via les champs s10FromTransactionId , s10FromTransactionIdDate et fromTransactionReference du journal des transactions.

  • Sips Office Extranet

La recherche d’une transaction dans Sips Office Extranet peut se faire indifféremment avec un TransactionId ou un TransactionReference .

Si vous avez opté pour le TransactionReference , les deux colonnes seront systématiquement présentes dans Sips Office Extranet dans les écrans suivants :

  • liste des transactions suite à une recherche,
  • détail d’une transaction.
La fraude – Alimentation des listes

L’ajout de PAN sur des listes grises via la référence de la transaction est possible via l’utilisation du TransactionId ou du TransactionReference .

Données et formats

  • Possibilité pour vous de conserver le transactionId et de garder les journaux au format 1.0,
  • Nouveau format des requêtes et des réponses automatiques et manuelles.

Merci de vous référer à la documentation :

  • Guide de migration Payment 1.0 ,
  • Guide de migration Sips Office 1.0 .

Nouveau format de vos journaux.

Merci de vous référer à la documentation :

  • Guide de correspondance des journaux 1.0 / 2.0,
  • Description des journaux.

URLs

  • Nouvelle URL pour la partie Paiement,
  • Nouvelle URL pour la partie Office.

Merci de vous référer à la documentation :

  • Guide de migration Payment 1.0 ,
  • Guide de migration Sips Office 1.0 .

Fraude

En 1.0 les contrôles sont réalisés sur l’outil de contrôle de fraude 1.0.

En 2.0, vous utilisez le nouveau moteur de fraude 2.0.

Sur Sips 1.0, pour débrayer un ou plusieurs contrôles complémentaires, il faut notifier le mot-clé correspondant au contrôle dans le champ DATA de l’API. Sur Sips 2.0, il faut renseigner les valeurs des champs bypassCtrlList et bypassInfoList .

La correspondance des mots clé de débrayage est décrite dans le document Guide de correspondance des données 1.0 / 2.0.

Les contrôles non liés au moyen de paiement (ex. encours client, liste grise, … ) ne sont pas partagés entre 1.0 et 2.0.

  • La migration des listes grises 1.0 en 2.0 est prise en charge par le processus de migration.

Les principales caractéristiques de la gestion de la fraude 2.0 sont les suivantes :

  • Mode Go-No-Go (correspond à Sips 1.0),
  • Mode Go-No-Go +,
  • Contrôles de lutte contre la fraude 1.0 (Go-No-Go),
  • Contrôles de lutte contre la fraude 2.0 (Go-No-Go +),
  • Profils par défaut,
  • GUI RMS (Risk Management system) : visualisation / mise à jour de la configuration.

Paypages

  • Nouvelles pages de paiement,
  • Web réactivité.

Merci de vous référer à la documentation :

  • Guide de migration Payment 1.0,
  • Guide de migration Sips Office 1.0,
  • Guide de migration de la personnalisation des pages de paiement.

Ce que doit faire le commerçant

Les différentes étapes se réfèrent au la partie Timing .

  • Choisir les modalités de migration (Étape 3)
    • Choix des connecteurs en fonction du mode de fonctionnement du commerçant,
    • Décision de rester en TransactionId ou de passer en TransactionReference .
  • Installer les connecteurs (Étape 5)

    • Transposition des données 1.0 / 2.0 (journaux, fraude, …).
  • Personnaliser les pages de paiement si choix du mode paypage (Etape 5)

    • Test en local avec un outil fourni par Worldline ,
    • Envoi des CSS à Sips .
  • Utiliser l’environnement de recette client pour tester les applications Sips Paypage et Sips Office avec la boutique de recette mise à disposition (Étape 7)

    • Récupération des identifiants de recette,
    • Tests en recette,
    • Vérification des tests effectués,
    • Envoi d’un PV de recette à Worldline (Étape 9).
  • Démarrer en production (Étapes 9 & 10)

    • Vérification de la configuration de la boutique en production,
    • Envoi de la demande de démarrage en production,
    • Intégration des identifiants de la boutique de production,
    • Activation de la bascule de la boutique vers Sips 2.0,
    • Surveillance du démarrage de la bascule.
  • Supprimer les références à Sips 1.0 sur le site commerçant : certificat, fichiers paramètres, fichiers exécutables … (Étape 11).

Description des uses Case commerçants

UC1 - Commerçant 1.0 qui ouvre une nouvelle boutique en 2.0

Le premier scénario décrit ici consiste à ouvrir une nouvelle boutique en 2.0.

Ce scénario peut convenir au cas où vous souhaitez pouvoir rapidement mettre en œuvre un nouveau moyen de paiement pour une boutique sans avoir à migrer tous vos flux, ou vous utilisez des moyens de paiement non encore disponibles en 2.0.

Vous disposerez donc de deux boutiques, une Sips 1.0 pour vos moyens de paiement actuels, et une seconde Sips 2.0 pour un ou plusieurs nouveaux moyens de paiement.

Les 2 boutiques sont rattachées au même client, mais vous aurez 2 merchantId .

Enregistrement commerçant

Il convient d’utiliser la procédure classique d’enregistrement d’une nouvelle boutique 2.0.

Gestion de caisse

Vous accédez et manipulez les transactions dans les environnements/interfaces 1.0 ou 2.0 dans lesquels vous les avez créées.

La duplication étendue vous permet de créer une transaction à partir d’une transaction existante initialisée par une autre boutique. Vous pouvez donc utiliser cette fonctionnalité pour dupliquer une transaction de votre boutique 1.0 à partir de votre nouvelle boutique 2.0.

Pour ce faire, les deux boutiques doivent partager le même clientId .

Vous devez notamment renseigner dans votre requête de paiement les identifiants de la boutique d’origine et de la transaction d’origine :

  • fromMerchantId ,
  • fromMerchantId ,
  • s10FromTransactionIdDate .

Les coordonnées du moyen de paiement sont récupérées de la transaction initiale par Sips . Toutefois, vous pouvez modifier les données métier (numéro de commande, modalité d’envoi en banque, …).

Les transactions dupliquées sont traitées comme une nouvelle transaction en mode récurrent (champ paymentPattern est fixé à RECURRING_N).

Les contrôles effectués sont les suivants :

  • Vous n'avez pas le droit de duplication étendue (code refus 03).
  • La boutique d’origine n’est pas rattachée à vous (code refus 40).
  • La transaction à dupliquer n’existe pas (code refus 25).
  • La transaction initiale ne peut pas être dupliquée car le moyen paiement ne le permet pas (code refus 24).
  • La date d’expiration du moyen de paiement a été dépassée (code refus 24).
  • Demande d’autorisation refusée par l’acquéreur.

La transaction créée moyennant la duplication est reprise dans le Journal sur les transactions et affichée dans l’Extranet.

Reporting

Journaux : Vous recevez vos journaux par boutique, les journaux 1.0 et 2.0 ne sont pas consolidés. Les journaux 2.0 isolent les flux relatifs aux transactions effectuées sur Sips 2.0.

Ce scénario vous permet de bénéficier du nouveau format de journaux 2.0 pour votre seconde boutique. Néanmoins, cette option n’est pas obligatoire, vous pouvez garder le format 1.0 si vous voulez garder le traitement existant des journaux dans votre Back Office. Ceci est valable pour les types de journaux : journal des transactions, journal des opérations, journal de rapprochement des transactions et journal de rapprochement des impayés.

Alerte : Si vous souhaitez conserver les journaux au format 1.0, vous ne récupérez pas les données purement 2.0. Les impacts sont à mesurer en fonction des fonctionnalités et moyens de paiement que vous avez retenus.

Extranet : Vous pouvez garder la même URL et vos login/mot de passe existants grâce à l’utilisation de la fonctionnalité de super-user.

Néanmoins, vous n’avez pas accès à un historique consolidé de vos transactions 1.0 et 2.0 puisque vous gardez votre identifiant existant pour votre boutique 1.0, et utilisez un nouvel identifiant pour votre nouvelle boutique 2.0.

Fraude

En 1.0 les contrôles sont réalisés sur l’outil de contrôle de fraude 1.0.

En 2.0, vous utilisez le moteur de fraude 2.0.

Les contrôles non liés au moyen de paiement (ex. encours client, liste grise …) ne sont pas partagés entre 1.0 et 2.0.

La création des listes en 2.0 est prise en charge par le processus de migration.

Facturation

Il y a une coexistence des items de facturation 1.0 et 2.0.

Les deux boutiques sont rattachées au même client facturé avec le même modèle de facturation.

Limites

  • Etanchéité entre la fraude 1.0 et la fraude 2.0.
  • Ne pas utiliser un même moyen de paiement en 1.0 ET en 2.0 avec un seul et même contrat VAD car la réconciliation ne fonctionne pas correctement quand plusieurs boutiques d’un même commerçant ont un même contrat d’acquisition.

UC2 – Commerçant qui utilise Subscription

Si vous utilisez l’API Subscription vous disposez des fonctions de wallet en 2.0 grâce au connecteur Sips Walletpage .

Vous pouvez également réaliser des paiements hors ligne sans manipuler de données sensibles en utilisant Sips Office Batch avec le service office et la fonction walletOrder de ce service, et gérer votre wallet avec le service wallet et toutes les fonctions de ce service. Le document Sips Office Batch décrit cette possibilité.

Il existe quelques différences fonctionnelles entre Sips Walletpage et Subscription :

  • L’offre Sips Walletpage ne permet pas de stocker les données personnelles du porteur :

    • Pas de nom, prénom, d’adresse,
    • Pas de mot de passe.
  • L’interface Sips Walletpage ne permet pas le paiement à l’enrôlement

    • Le paiement avec enrôlement est déjà disponible via Sips Paypage ,
    • Si vous pensez proposer un paiement à l’enrôlement vous devrez donc utiliser Sips Paypage .
  • Dans le cas où il y a plusieurs moyens de paiement dans le wallet, vous ne pouvez pas utiliser le walletID seul pour faire un paiement récurrent. Vous devez dans ce cas préciser le walletID et le paymentMeanID. Cette obligation n’existe pas dans le cas où le wallet est mono-moyen de paiement.
  • Il n’y a pas de réponse automatique lors d’une cinématique de gestion du Wallet car la cinématique permet au client de réaliser plusieurs actions.

Comparaison Sips Payment / Sips Office

Le tableau comparatif suivant vous permet de comparer les avantages des différentes interfaces :

Critère Interface Sips Paypage Interface Sips Office
Périmètre fonctionnel

Création de transactions uniquement

Création de transaction et gestion de caisse.

Note: vous pouvez utiliser Sips Paypage pour le paiement et Sips Office pour la gestion de caisse.
PCI/DSS

Bénéficie de la certification PCI car la cinématique de paiement est externalisée sur les serveurs Sips .

Vous ne connaissez pas le PAN du client.

Dans la création de transaction, la gestion des pages de paiement est faite par vous, celui-ci est donc soumis à la certification PCI-DSS.
Note: vous pouvez limiter votre périmètre en ne stockant aucune information PAN dans votre système d’information (exemple en remplaçant PAN par un token ou un identifiant de Wallet ou un hashPan).
La solution de tokeniser fait partie du tableau de fonctionnalités (§ 3.1.1) et peut vous être présentée par les équipes Worldline .
3-D Secure Processus 3-D Secure réalisé par Sips et transparent pour vous.
Vous pilotez le processus d’authentification 3-D Secure.
Note: vous avez la possibilité d’utiliser le MPI Sips pour gérer les échanges avec les directory server Visa/MC.
Effort d’intégration Solution Plug & Play facile à intégrer Solution nécessitant plus de développement : paiement embarqué côté commerçant avec la gestion des pages de paiement…
Ajout d’un moyen de paiement

Sans effort de développement pour vous dans la plupart des cas.

Note: vous devez parfois renseigner des champs spécifiques dans la requête de paiement pour bénéficier des options du moyen de paiement (exemple PayPal).
Effort de développement côté commerçant pour intégrer le moyen de paiement (gestion cinématique, gestion des pages, …)
Parcours client Rupture limitée entre votre site Web et le serveur de paiement grâce à la personnalisation des pages de paiement que vous pouvez faire (CSS, URL). Aucune rupture entre votre site Web et le serveur de paiement
Intégration dans votre SI S’interface avec votre boutique. S’interface avec votre Boutique ou Back Office.
Reporting Reporting homogène

Annexe 1 - FAQ Migration 122

Pourquoi migrer sur 2.0 ?

Worldline s’est doté d’une nouvelle plateforme Sips , vous permettant :

  • de simplifier l’intégration de Sips et standardiser les méthodes de connexion : nouveaux connecteurs Sips à l’état de l’art.
  • d'optimiser le parcours client : nouvelles fonctionnalités et nouvelle ergonomie des interfaces client (application InApp, webresponsive, …).
  • d'avoir plus d’autonomie dans la gestion de ses transactions et de ses paramètres commerçant: nouvelle interface Extranet.
  • de faciliter votre déploiement sur le marché international : nouveaux moyens de paiement
  • de bénéficier de fonctionnalités avancées : Lutter efficacement contre la fraude, tableau de bord, …

Peut-on garder en 2.0 le même MerchantID 1.0 ?

Si vous avez créé une nouvelle boutique en 2.0 vous aurez deux merchantId distincts.

Peut-on visualiser en 2.0 les transactions créées en 1.0 ?

Depuis les interfaces 2.0, vous ne pouvez pas accéder et manipuler les transactions créées en Sips 1.0 (validation, annulation, remboursement, duplication) puisque vous gardez l'identifiant existant pour votre boutique 1.0, et utilisez un nouvel identifiant pour votre nouvelle boutique 2.0.

Peut-on en 2.0 valider une transaction 1.0 ?

Depuis les interfaces 2.0, vous ne pouvez pas accéder et manipuler les transactions créées en Sips 1.0 (validation, annulation, remboursement, duplication) puisque vous gardez l'identifiant existant pour votre boutique 1.0, et utilisez un nouvel identifiant pour votre nouvelle boutique 2.0.

Peut-on en 2.0 annuler une transaction 1.0 ?

Depuis les interfaces 2.0, vous ne pouvez pas accéder et manipuler les transactions créées en Sips 1.0 (validation, annulation, remboursement, duplication) puisque vous gardez l'identifiant existant pour votre boutique 1.0, et utilisez un nouvel identifiant pour votre nouvelle boutique 2.0.

Peut-on en 2.0 rembourser une transaction 1.0 ?

Depuis les interfaces 2.0, vous ne pouvez pas accéder et manipuler les transactions créées en Sips 1.0 (validation, annulation, remboursement, duplication) puisque vous gardez l'identifiant existant pour votre boutique 1.0, et utilisez un nouvel identifiant pour votre nouvelle boutique 2.0.

Peut-on en 2.0 dupliquer une transaction 1.0 ?

Depuis les interfaces 2.0, vous ne pouvez pas accéder et manipuler les transactions créées en Sips 1.0 (validation, annulation, remboursement, duplication) puisque vous gardez l'identifiant existant pour votre boutique 1.0, et utilisez un nouvel identifiant pour votre nouvelle boutique 2.0.

Néanmoins, vous pouvez utiliser la fonctionnalité de duplication étendue qui permet à partir d’une boutique 2.0 de dupliquer une transaction provenant d’une autre boutique, même si celle-ci est en 1.0.

Peut-on continuer de recevoir les journaux au format 1.0 ?

Dans le cas où vous conservez l’identification par le TransactionId , vous avez la possibilité de conserver vos journaux à l’ancien format 1.0 ou de bénéficier du nouveau format de journaux 2.0 à votre convenance.

Néanmoins, seuls les journaux 2.0 évoluent et bénéficient des nouveaux champs ajoutés. Si vous restez sur le format 1.0, vous ne bénéficierez pas des mises à jour (ex. ajout dans les journaux de données additionnelles liés à un moyen de paiement).

Quels sont les apports du TransactionReference par rapport au TransactionId ?

Ce nouvel identifiant présente l’avantage d’être au format ANS35 ce qui permet :

  • de garder cet identifiant unique de manière illimitée (sur la période d’existence de la transaction dans Sips : 15 mois) au lieu d’une journée pour le TransactionId ,
  • d'utiliser des caractères alphanumériques dans la référence, format ouvert facilitant la génération par vous,
  • se rendre indépendant des fuseaux horaires (internationalisation).

Peut-on migrer en 2.0 sans personnaliser ses pages de paiement ?

La personnalisation des pages de paiements reste une étape facultative pour démarrer en 2.0. Sips propose une personnalisation par défaut.

Peut-on garder la même personnalisation des pages de paiement ?

Il n’y a pas d’outil de migration qui reproduit la personnalisation des pages de paiement 1.0.Nous déconseillons les tentatives de reproduire exactement le visuel des pages de paiement 1.0 sur les pages de paiement 2.0. En effet, il est dommage de se priver des nouvelles possibilités qu'offrent les pages de paiement 2.0, notamment sur l’aspect adaptabilité à la taille des écrans.

Peut-on changer la personnalisation des pages de paiement ?

Il est conseillé de changer la personnalisation des pages de paiement afin de bénéficier des atouts des pages de paiement 2.0.

Un guide de personnalisation des pages est mis à votre disposition.

Peut-on utiliser la base wallet existante 1.0 ?

La base Wallet est partagée entre Sips 1.0 et 2.0.

La base des abonnés SUBSCRIPTION est déjà migrée dans la base Wallet.

Quels sont les moyens de paiement disponibles en 2.0 ?

La liste des moyens de paiement disponibles en 2.0 est fournie dans le § 3.1.2 du présent guide.

Quels sont les contrôles de fraude disponibles en 2.0 ?

Les contrôles de fraude disponibles en 2.0 sont détaillés dans le guide « Gestion de la lutte contre la fraude ».

Quels sont les devises acceptées en 2.0 ?

Les devises acceptées dépendent du contrat acquéreur. Les devises prévues pour le schème Visa / MC, Amex sont les suivantes :

EUR,USD,CHF,GBP,CAD,JPY,MXN,TRY,AUD,NZD,NOK,BRL,ARS,KHR,TWD,SEK,DKK,KRW,SGD,XPF,XOF.

Quels sont les acquéreurs français disponibles en 2.0 ?

  • La Banque Postale
  • Banque Populaire
  • BNP Paribas
  • Caisse d’Epargne
  • Crédit Agricole
  • Crédit Du Nord
  • Crédit Mutuel Centre Est Europe
  • CIC
  • Crédit Mutuel de Bretagne
  • HSBC
  • Le Crédit Lyonnais
  • Société Générale

Comment valider que ma migration est OK ?

Worldline met à votre disposition une boutique de recette qui vous permet de valider vos développements internes.

Lorsque vous avez terminé votre recette, vous établissez un PV de recette et déterminez en accord avec Worldline la date et l’heure de votre migration.

Suite à cette migration, un suivi attentif des premiers flux est opéré.