WL SIPS DOCS

Release 24.5

aller directement au contenu

Rechercher par mots clés

Guide de configuration des fonctionnalités

Pour rechercher dans la page utiliser Ctrl+F sur votre clavier

Worldline 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, …).

Ce document est un guide de configuration des fonctionnalités de Worldline Sips. Il vous explique comment utiliser les fonctionnalités disponibles dans les différentes interfaces de paiement (Sips Paypage, Sips Office). Il présente également un résumé de la disponibilité des fonctionnalités dans chacune des interfaces et fournit des renseignements détaillés sur l’impact éventuel sur votre configuration Worldline Sips et/ou sur votre configuration acquéreur (nécessitant une vérification auprès de ce dernier).

La mise en œuvre de certaines fonctionnalités fait l’objet de guides spécifiques :

  • Gestion de la lutte contre la fraude : GoNoGo, Business Score ;
  • Implémentation des moyens de paiement ;
  • Personnalisation des pages de paiement ;
  • Paiement OneClick ;
  • Paiement par abonnement.

Ce tableau indique, pour chaque moyen de paiement, quels connecteurs il est possible d'utiliser pour créer un paiement. Il ne traite pas de la gestion de caisse. Les connecteurs compatibles pour la gestion de caisse sont détaillés dans la partie "Gestion de caisse" et les opérations possibles par moyen de paiement sont récapitulées en annexe.

Moyens de paiements Sips Paypage Sips Office Sips Office Batch Sips In-App Sips Walletpage
CB oui oui oui oui oui
Visa oui oui oui oui oui
MasterCard oui oui oui oui oui
American Express oui oui oui oui oui
VPay oui oui oui oui oui
Maestro oui oui oui oui oui
Visa Electron oui oui oui oui oui
Apple Pay oui oui non non non
Bancontact oui oui non oui oui
Bancontact mobile oui oui non oui non
Floa Bank CB 3X oui non non non non
Floa Bank CB 4X oui non non non non
CACF oui non non non non
CACF 3X oui oui non non non
CACF 4X oui oui non non non
Cadhoc oui oui non non non
Cadocarte oui oui non non non
Carte CUP par Floa Bank non oui non non non
Cetelem CPay (anciennement Cetelem Aurore) oui non non non non
Cetelem 3X 4X CB oui non non non oui
Chèque-Vacances Connect oui oui non non non
Cofidis Pay 5x10x20x oui non non non non
Cofidis 3xCB oui non non non non
Cofidis 4XCB oui non non non non
Titres Restaurants Dématérialisés - Conecs oui oui non non non
Franfinance 3XWEB oui non non non non
Franfinance 4XWEB oui non non non non
Google Pay oui oui non non non
Illicado oui oui non non non
Lepotcommun oui oui non non non
Lydia oui oui non non non
Oney 3x 4x oui non non non non
PayPal oui oui non non oui
Samsung Pay oui oui non non non
SEPA Direct Debit (SDD) oui oui oui non non
Spiritofcadeau oui oui non non non
Oney Paylater oui non non non non

Moyen de paiement disponible (oui) / Moyen de paiement indisponible (non).

L’activation des fonctionnalités peut nécessiter une configuration côté Worldline Sips et/ou une vérification côté acquéreur.

  • Configuration Worldline Sips : l’activation ou la désactivation de la fonctionnalité nécessite un changement de configuration sur la plateforme Worldline Sips et entraîne, éventuellement, une modification du contrat d’acceptation.
  • Vérification acquéreur : l’activation ou la désactivation de la fonctionnalité peut engendrer une modification du contrat d’acquisition. Vous devez vous renseigner auprès de votre acquéreur.

L’utilisation d’une fonctionnalité peut aussi entraîner l’ajout de certains paramètres dans la requête de paiement ainsi qu’un éventuel changement de connecteurs.

Lors de votre inscription, Worldline met à disposition sur Sips Download, une clé secrète qui permet de sécuriser les échanges entre votre site et le serveur Worldline Sips. La compromission de la clé secrète et son utilisation par un tiers malveillant perturberait le fonctionnement normal de votre boutique, et pourrait notamment générer des transactions et des opérations de caisse injustifiées (des remboursements par exemple). En cas de compromission d’une clé secrète, vous êtes tenu d’en demander au plus vite la révocation puis le renouvellement via Sips Download.

Afin d'assurer la conformité avec la norme PCI DSS, un système d'alerte est mis en place afin de vous avertir que votre clé secrète arrive à expiration et ainsi la renouveler via l'interface Sips Download. Cette alerte se fait en 3 étapes par l'envoi de e-mails informatifs qui sont paramétrés par défaut comme suit :

  • 1ère alerte 90 jours avant la date d'expiration de la clé - destinataires principaux : vos contacts Administrateur et Technique ;
  • 2ème alerte 45 jours avant la date d'expiration de la clé - destinataires principaux : vos contacts Administrateur et Technique ; destinataire secondaire : votre chargé de clientèle ;
  • 3ème alerte 20 jours avant la date d'expiration de la clé - destinataires principaux : vos contacts Administrateur et Technique ; destinataire secondaire : votre chargé de clientèle.

Il vous est possible de demander à ce que soient paramétrés des seuils différents pour l'envoi des e-mails d'alerte. Pour cela, merci de contacter notre support technique.

Ce processus d'alertage prend fin pour une clé donnée si celle-ci est désactivée avant la date d'expiration ou si la date d'expiration est dépassée.

Cette gestion de vos clés secrètes vous permet d'être autonome dans la gestion de vos clés en validant vous-même les actions, tout en assumant la responsabilité.

Deux modes d’identification des transactions sont disponibles sur Worldline Sips 2.0 : le mode transactionReference et le mode transactionId. La différence entre les 2 modes est la portée de l’identifiant, le transactionReference doit être unique durant toute la vie de la boutique alors que le transactionId doit être unique sur la journée.

Une option permet également de choisir le mode de génération :

  • vous fournissez l’identifiant de la transaction dans la requête de paiement ou
  • vous laissez Worldline Sips le générer automatiquement et vous le récupérez dans la réponse.
Remarque : le transactionReference est le mode d’identification par défaut, le transactionId 1.0 a été reconduit en 2.0 pour faciliter la migration des commerçants 1.0 vers 2.0.

Lors d’une création de transaction, et en fonction du mode choisi, Worldline Sips accepte ou rejette la création et génère des identifiants complémentaires.

Différents cas sont possibles :

Tableau 1. Boutique en mode TransactionReference - Le commerçant se connecte à Worldline Sips avec un transactionReference qu’il a généré
Données Création de transaction via :
Sips Paypage Sips Office Sips Office Extranet
transactionReference fourni par le commerçant Traitement standard Traitement standard proposé par Worldline Sips, modifiable et affiché en rouge
transactionId fourni par le commerçant Rejet Code = 12 Rejet Code = 12 N/A
transactionId absent OK OK N/A
transactionReference absent Rejet Code = 12 Rejet Code = 12 Rejet Code = 12
Référence complémentaire générée par Worldline Sips s10TransactionId s10TransactionIdDate s10TransactionId s10TransactionIdDate s10TransactionId s10TransactionIdDate
Contenu réponse s10TransactionId s10TransactionIdDate transactionReference s10TransactionId s10TransactionIdDate transactionReference
Tableau 2. Boutique en mode TransactionReference - Le commerçant se connecte à Worldline Sips sans transactionReference (Tref auto)
Données Création de transaction via :
Sips Paypage Sips Office Sips Office Extranet
transactionReference généré par Worldline Sips Traitement standard N/A généré par Worldline Sips et affiché en rouge
transactionId fourni par le commerçant Rejet Code = 12 N/A
transactionId absent OK N/A
transactionReference fourni par le commerçant Rejet Code = 12 Rejet Code = 12
Référence complémentaire générée par Worldline Sips transactionReference s10TransactionId s10TransactionIdDate transactionReference s10TransactionId s10TransactionIdDate
Contenu réponse s10TransactionId s10TransactionIdDate transactionReference
Tableau 3. Boutique en mode TransactionId - Le commerçant se connecte à Worldline Sips avec un transactionId qu’il a généré
Données Création de transaction via :
Sips Paypage Sips Office Sips Office Extranet
transactionId fourni par le commerçant Traitement standard Traitement standard proposé par Worldline Sips, modifiable et affiché en rouge
transactionId absent Rejet Code = 12 Rejet Code = 12 Rejet Code = 12
transactionReference fourni par le commerçant Rejet Code = 12 Rejet Code = 12 N/A
transactionReference absent OK OK N/A
Référence complémentaire générée par Worldline Sips transactionReference transactionReference transactionReference
Contenu réponse s10TransactionId s10TransactionIdDate transactionReference s10TransactionId s10TransactionIdDate transactionReference
Tableau 4. Boutique en mode TransactionId - Le commerçant se connecte à Worldline Sips sans transactionId (Tid auto)
Données Création de transaction via :
Sips Paypage Sips Office Sips Office Extranet
transactionId généré par Worldline Sips Traitement standard N/A généré par Worldline Sips et affiché en rouge
transactionId fourni par le commerçant Rejet Code = 12 N/A
transactionReference fourni par le commerçant Rejet Code = 12 N/A
transactionReference absent OK N/A
Référence complémentaire générée par Worldline Sips s10TransactionId s10TransactionIdDate TransactionReference s10TransactionId s10TransactionIdDate TransactionReference
Contenu réponse s10TransactionId s10TransactionIdDate transactionReference

Pour les opérations de caisse, le mode d’identification d’une transaction n’est pas limité au mode choisi lors de la création.

Les tableaux ci-dessous reprennent les différentes possibilités.

Tableau 5. Boutique en mode transactionReference - Transaction d'origine générée avec un transactionReference
Données Gestion
transactionId fourni par le commerçant OK
transactionReference fourni par le commerçant OK
transactionReference et TransactionId cohérents fournis par le commerçant OK
transactionReference et transactionId ne référençant pas la même transaction fournie par le commerçant Rejet Code = 12
Nouvelle transaction (duplication et crédit porteur) Voir Tableau de création des transactions ci-dessus
Tableau 6. Boutique en mode transactionId - Transaction d'origine générée avec un transactionId
Données Gestion
transactionId fourni par le commerçant OK
transactionReference fourni par le commerçant OK
transactionReference et transactionId cohérents fournis par le commerçant OK
transactionReference et transactionId ne référençant pas la même transaction fournie par le commerçant Rejet Code = 12
Nouvelle transaction (duplication et crédit porteur) Voir Tableau de création des transactions ci-dessus

Les champs s10TransactionId, s10TransactionIdDate et transactionReference sont présents dans les journaux de transactions, d’opérations, de rapprochements et d’impayés, quel que soit le mode d’identification de transaction.

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

Pour plus de détails veuillez consulter les guides de personnalisation de Sips Paypage.

La page de sélection des moyens de paiement Worldline Sips n’est pas affichée automatiquement. Elle peut être gérée soit sur votre site marchand soit par Worldline Sips. Une option permet d’afficher systématiquement cette page par Worldline Sips.

Attention: l'affichage de la page de sélection des moyens de paiement Worldline Sips est inutile dans le cas où l'option de la sélection de la marque (MIF) est activée sur votre boutique et si vous ne proposez que les moyens de paiement CB, VISA et Mastercard.

Néanmoins, dans le cas où les moyens de paiement ne sont pas du même type (carte et Paypal par exemple), la page de sélection s’affiche systématiquement. Quand plusieurs moyens de paiement sont configurés dans votre contrat, vous pouvez filtrer ceux qui s’afficheront dans la page de sélection des moyens de paiement grâce au champ paymentMeanBrandList :

  • un seul moyen de paiement : la page de sélection des moyens de paiement ne s’affiche pas ;
  • une liste de moyens de paiement : l’affichage des moyens de paiement se fait dans l’ordre d’alimentation du champ ;
  • champ non renseigné : tous les moyens de paiement configurés s’affichent.

Worldline Sips affiche les moyens de paiement qui correspondent à la fois

  • à la liste des moyens de paiement prévus dans votre configuration

et

  • aux données de la transaction (contrôle de la devise de la transaction par exemple).

Si aucun moyen de paiement compatible n’est trouvé, Worldline Sips refuse la transaction.

Exemple d’affichage de la page de sélection du moyen de paiement :



Table 7. En résumé
Connecteur disponible Sips Paypage
Configuration Worldline Sips OUI Pas d’affichage de la page de sélection des moyens de paiement par défaut
Vérification acquéreur NON
Paramètre dans la requête de paiement OUI paymentMeanBrandList : optionnel, choix des moyens de paiement à afficher. Les valeurs possibles sont listées dans le dictionnaire des données

La page de confirmation du paiement, appelée « ticket de paiement », est affichée par défaut par Worldline Sips. Néanmoins, vous pouvez choisir de l’afficher vous-même sur votre site en utilisant les éléments fournis dans le message de réponse envoyé à l’URL de réponse (normalReturnUrl). Vous pouvez également décider dynamiquement, en fonction du contexte de la transaction, de ne pas afficher le ticket produit par Worldline Sips.

Table 8. En résumé
Connecteur disponible Sips Paypage
Configuration Worldline Sips OUI Affichage du ticket Worldline Sips par défaut
Vérification acquéreur NON
Paramètre dans la requête de paiement OUI paypageData.bypassReceiptPage : Indicateur permettant de cacher la page du ticket lors du paiement.

Vous pouvez décider du nombre de tentatives maximum de saisie du PAN

  • quand un client accède à la page de saisie des informations de paiement ;
  • ou qu’un utilisateur saisit via Sips Office Extranet.

Au-delà de cette limite, la transaction est refusée et le message suivant s’affiche :


image avec le message : vous avez atteint le nombre maximum de tentatives de paiement autorisés

Table 9. En résumé
Connecteurs disponibles Sips Paypage, Sips Walletpage
Configuration Worldline Sips OUI 3 tentatives par défaut sur les pages de paiement et dans Sips Office Extranet
Vérification acquéreur NON
Paramètre dans la requête de paiement NON

Habituellement, une nouvelle tentative de paiement est proposée au client uniquement en cas de saisie de PAN invalide. Cette option supplémentaire permet d’étendre les nouvelles tentatives de paiements sur d’autres types de refus :

  • refus de l’acquéreur, non typé fraude ;
  • authentification 3DS échouée ;
  • refus de l’outil de lutte contre la fraude, non typé fraude.

Le nombre de tentatives de paiement est paramétrable dans votre configuration commerçant (voir paragraphe précédent « Nombre de tentatives de paiement »).

Le message suivant est affiché à votre client.


image avec le message : votre tentative de paiement a échoué, veuillez réessayer

Attention: si le paiement renvoie un code acquéreur 03 (accepteur invalide), alors les moyens de paiements rattachés à ce même contrat acquéreur ne seront pas proposés lors de la nouvelle tentative de paiement.

Exemple de moyens de paiement rattachés à un même contrat acquéreur : CB, Visa, Mastercard.
Si aucun autre moyen de paiement ne peut être proposé, alors le paiement sera définitivement refusé sans nouvelle tentative possible.

Table 10. En résumé
Connecteur disponible Sips Paypage
Configuration Worldline Sips OUI
Vérification acquéreur NON
Paramètre dans la requête de paiement NON

Vous pouvez choisir de faire envoyer une notification automatique à votre site en cas d’erreur technique. Ce type d’erreur intervient de manière exceptionnelle.

Table 11. En résumé
Connecteur disponible Sips Paypage
Configuration Worldline Sips OUI
Vérification acquéreur NON
Paramètre dans la requête de paiement NON

Un délai de 15 minutes d’inactivité est accordé au client pour lui permettre de réaliser son paiement. Au-delà de ce temps imparti, la session utilisateur expire, et il n’est plus possible pour le client de finaliser son achat. Ce délai est fixé à 15 minutes, conformément à la réglementation PCI DSS (condition 8.1.7).

En complément de cette limitation réglementaire, vous avez la possibilité de proposer un délai de présence maximum sur les pages de paiement Worldline Sips. Le point de départ de ce délai débute à l’arrivée du client sur la page de paiement Worldline Sips.

Table 12. En résumé
Connecteur disponible Sips Paypage
Configuration Worldline Sips OUI
Vérification acquéreur NON
Paramètre dans la requête de paiement NON

Le nom de la boutique configuré dans Worldline Sips peut être affiché dans le bandeau de la page de paiement.



Table 13. En résumé
Connecteurs disponibles Sips Paypage, Sips Walletpage
Configuration Worldline Sips OUI Affichage du nom de la boutique non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête de paiement NON

La saisie du numéro de carte peut être divisée par bloc de 4 numéros. Dans le cas d’Amex et de BCMC, cette option est adaptée à la longueur du numéro de carte.



Table 14. En résumé
Connecteurs disponibles Sips Paypage, Sips Walletpage
Configuration Worldline Sips OUI Saisie du numéro de carte en blocs séparés non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête de paiement NON

Afin de sécuriser la validité de la saisie, une option permet l'affichage d'un champ obligatoire en dessous de la zone de saisie des informations carte, demandant au titulaire de la carte de saisir son nom.

Cette option est disponible uniquement pour le paiement par carte.

Cette donnée est envoyée à certains acquéreurs dans la demande d’autorisation (principalement les acquéreurs anglais). Cependant, cette saisie peut être utilisée pour dissuader d’éventuels fraudeurs.



Table 15. En résumé
Connecteurs disponibles Sips Paypage, Sips Walletpage
Configuration Worldline Sips OUI Saisie du nom du titulaire de la carte non activé par défaut.
Vérification acquéreur NON
Paramètre dans la requête de paiement NON

Cette page s’affiche en cas d’une erreur à l’initialisation de paiement uniquement via le connecteur POST (requête mal formatée par exemple).


image avec le message suivant : une erreur s'est produite. Veuillez contacter votre commerçant

Le bouton de redirection permet de rediriger l’internaute vers le site du commerçant (avec la réponse manuelle). L’affichage du bouton de redirection est configurable :

Table 16. En résumé
Connecteur disponible Sips Paypage (POST)
Configuration Worldline Sips OUI Paramètre « Afficher la page d’erreur »
Vérification acquéreur NON
Paramètre dans la requête de paiement OUI manualErrorResponseInitPOST : URL du commerçant pour le retour à la boutique en cas d’erreur sur l’initialisation du paiement.

En parallèle, une réponse automatique peut être envoyée. L’envoi de cette réponse automatique est configurable :

Table 17. En résumé
Connecteur disponible Sips Paypage (POST)
Configuration Worldline Sips OUI Paramètre « Notifier les erreurs »
Vérification acquéreur NON
Paramètre dans la requête de paiement OUI automaticErrorResponseInitPOST : URL du commerçant pour recevoir la réponse automatique en cas d’erreur sur l’initialisation du paiement.

Dans la page de saisie des informations du moyen de paiement, les données sensibles (numéro de carte et CVV) peuvent être masquées.





Si cette fonctionnalité est activée, alors le masquage de la saisie de données sensibles sera également effective lors de la création d'une transaction avec une carte de paiement dans l'interface Sips Office Extranet.



Table 18. En résumé
Connecteurs disponibles Sips Paypage,Sips Office Extranet,
Configuration Worldline Sips OUI Masquage de la saisie d’informations sensibles non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête de paiement NON

Les pages de paiement Worldline Sips peuvent être intégrées à une page de la boutique. Cela n’a aucun impact sur vos pages et vous pouvez utiliser cette fonction sans configuration Worldline Sips. Pour plus d’informations, veuillez consulter le guide d’utilisation Sips Paypage iFrame.

Table 19. En résumé
Connecteurs disponibles Sips Paypage, Sips Walletpage
Configuration Worldline Sips NON
Vérification acquéreur NON
Paramètre dans la requête de paiement NON

Pour choisir votre canal de paiement, vous devez remplir le champ orderChannel dans la requête de paiement. Cette information est importante car elle conditionne les règles d’acceptation et d’acquisition du traitement de la transaction.

Pour utiliser le canal Internet, vous devez souscrire un contrat VADS (vente à distance sécurisée) avec l’acquéreur.

Table 20. En résumé
Connecteurs disponibles Sips Paypage, Sips Office, Sips Office Batch
Configuration Worldline Sips OUI
Vérification acquéreur OUI contrat VADS obligatoire
Paramètre dans la requête de paiement OUI orderChannel : INTERNET

Dans le cas des canaux MOTO, MAIL_ORDER ou TELEPHONE_ORDER, la transaction est traitée en acceptation vente à distance. Vous devez souscrire un contrat VAD (vente à distance) acceptant le canal MOTO avec l’acquéreur.

Tip: au niveau des connecteurs, il est conseillé de différencier le canal MAIL_ORDER et TELEPHONE_ORDER, au lieu d'utiliser directement le canal MOTO.
Table 21. En résumé
Connecteurs disponibles Sips Paypage, Sips Office, Sips Office Batch
Configuration Worldline Sips OUI
Vérification acquéreur OUI contrat VAD supportant le MOTO obligatoire
Paramètre dans la requête de paiement OUI orderChannel :


MOTO
TELEPHONE_ORDER
MAIL_ORDER
FAX

Le canal SVI (Serveur Vocal Intéractif ou encore Interactive Voice Response en anglais) est assimilé au canal MOTO. Vous devez donc souscrire un contrat VAD (vente à distance) acceptant le MOTO avec l'acquéreur.

Table 22. En résumé
Connecteurs disponibles Sips Office, Sips Office Batch
Configuration Worldline Sips OUI (configuration du canal MOTO)
Vérification acquéreur OUI contrat VAD supportant le MOTO obligatoire
Paramètre dans la requête de paiement OUI orderChannel : IVR

L’utilisation du canal application mobile ne nécessite pas de configuration acquéreur. Pour en savoir plus sur ce connecteur, veuillez consulter le document Sips In-App JSON.

Table 23. En résumé
Connecteur disponible Sips In-App
Configuration Worldline Sips OUI
Vérification acquéreur NON Assimilé au canal Internet
Paramètre dans la requête de paiement OUI orderChannel : INAPP

Les champs paymentPattern, captureMode et captureDay permettent de fixer les modalités de remise en paiement.

Pour en savoir plus sur la disponibilité de ces modalités pour chaque moyen de paiement, veuillez consulter leurs guides d’intégration.

Dans le cas du paiement en fin de journée, toutes les transactions acceptées durant la journée sont envoyées en remise en paiement le soir. Ce mode s’applique aux moyens de paiement fonctionnant dans le mode de « message double » souvent appelé « dual message » (un message pour l’autorisation et un message pour la remise).

Si cette modalité n’est pas supportée par le moyen de paiement,Worldline Sips surcharge le paramètre captureMode avec la valeur par défaut du moyen de paiement concerné (pour plus de renseignements, veuillez consulter les guides d’intégration des moyens de paiement).

Table 24. En résumé
Connecteurs disponibles Sips Paypage, Sips Office, Sips Office Batch, Sips In-App
Configuration Worldline Sips NON
Vérification acquéreur NON
Paramètre dans la requête de paiement OUI
  • captureMode : AUTHOR_CAPTURE
  • captureDay : 0 (0 jour de différé, remise le soir)

Dans le cas du paiement différé, la remise en paiement de la transaction est effectuée N jours après l’acceptation en ligne.

La durée de validité des autorisations du moyen de paiement est fixée dans le contrat conclu entre vous et l’acquéreur (par défaut 6 jours pour CB, VISA et Mastercard).

En fonction de la durée de validité de l’autorisation, le nombre de jours de différé de remise communiqué dans la requête de paiement peut avoir une incidence sur le cycle de vie de la transaction :

  • 1er cas : Le différé de paiement est inférieur ou égal à la durée de validité de l’autorisation. L’autorisation donnée par l’acquéreur est toujours valable pour le montant total de la transaction initiale. Si la transaction n’est pas annulée, elle est payée à la date de la transaction +N jours.
  • Cas particulier 3-D Secure : pour bénéficier du transfert de responsabilité lors d'une transaction 3-D Secure, le différé de paiement ne peut pas être supérieur à la durée maximale de validité de l’autorisation donné par l'acquéreur. Si nécessaire, Worldline Sips surcharge ce différé de paiement si la valeur que vous renseignez est supérieure.
  • 2ème cas : Le différé de paiement est supérieur à la durée de validité de l’autorisation. L’autorisation donnée lors de l’achat en ligne par l’acquéreur n’est plus valable lors du paiement. En fonction de l’acquéreur, Worldline Sips choisit entre l’un des scénarios suivants :
    • Acquéreur conforme avec la fonctionnalité « Demande de renseignement » : Une demande de renseignement est envoyée à l’acquéreur dans le but de vérifier le numéro de carte de la transaction avant de réaliser une autorisation. Si la réponse est positive, Worldline Sips envoie la demande d’autorisation avec le montant réel de la transaction à J+N. En cas d’accord, la transaction est envoyée en remise.
    • Acquéreur non conforme avec la fonctionnalité « Demande de renseignement » : La procédure est identique mais la demande de renseignement faite en ligne est remplacée par une prise d'empreinte (demande d’autorisation d'un petit montant).
      Par conséquent,Worldline Sips fait deux demandes d’autorisation :
      • La première demande d’autorisation d'un petit montant, appelée l’empreinte, pour vérifier la carte lors de l’acceptation en ligne.
      • La deuxième demande d’autorisation pour le montant réel avant la remise en paiement.

Si le moyen de paiement est incompatible avec le différé demandé par vous, Worldline Sips surcharge le champ captureDay.

Table 25. En résumé
Connecteurs disponibles Sips Paypage, Sips Office, Sips Office Batch, Sips In-App
Configuration Worldline Sips NON
Vérification acquéreur NON
Paramètre dans la requête de paiement OUI
  • captureMode : AUTHOR_CAPTURE
  • captureDay : N (Nombre de jours de différé de paiement)
Attention: la demande de renseignement est une évolution réglementaire de CB, VISA, MASTERCARD et AMEX qui remplace la prise d'empreinte. Cette fonctionnalité est soumise à la conformité de l’acquéreur.

Dans le cas du paiement à l’expédition, la transaction est envoyée en remise en paiement suite à votre validation. Vous indiquez dans le champ captureDay la durée de validité de votre transaction. Si vous ne validez pas une transaction donnée avant que ce délai ne prenne fin, cette transaction expire. Si vous oubliez de valider dans les délais, vous pouvez représenter la transaction grâce à l’opération de duplication. Vous pouvez valider tout ou partie du montant de la transaction mais il est impossible de valider un montant supérieur au montant initial de la transaction.

Si le mode VALIDATION n’est pas supporté par le moyen de paiement, Worldline Sips le surcharge avec la modalité de paiement par défaut.

Table 26. En résumé
Connecteurs disponibles Sips Paypage, Sips Office, Sips Office Batch, Sips In-App
Configuration Worldline Sips OUI Option de VALIDATION à activer
Vérification acquéreur NON
Paramètre dans la requête de paiement OUI
  • captureMode : VALIDATION
  • captureDay : N (période de validité avant la validation)
Note: Pour les paiements 3-D Secure, si vous souhaitez valider la transactions plus de 6 jours après sa création ou que vous envoyez la commande en plusieurs fois, veuillez-vous référer à la page paiement multiple à l'expédition.

Le paiement en plusieurs fois s’adresse aux commerçants qui souhaitent offrir des facilités de paiement à leurs clients.

Pour avoir une description fonctionnelle et les modalités d’implémentation du paiement en plusieurs fois, veuillez consulter le guide du paiement en plusieurs fois.

Dans le cas du paiement immédiat, la transaction est remisée lors de l’autorisation en ligne. Cette modalité de paiement est plus rarement utilisée, et uniquement pour les moyens de paiement supportant le mode « message unique » appelé aussi « single message » (un seul message pour l’autorisation et le paiement).

Si cette modalité n’est pas supportée par le moyen de paiement, Worldline Sips surcharge le paramètre captureMode avec la valeur par défaut correspondant au moyen de de paiement concerné (pour plus de renseignements, consultez les guides d’intégration des moyens de paiement).

Les moyens de paiement supportant ce mode sont les suivants :

  • Bancontact
  • Bancontact mobile
  • BCACB 3X 4X
  • Cadhoc
  • Cadocarte
  • Carte Cadeau Oney
  • Cetelem 3X 4X CB
  • Cetelem Presto
  • Chèque-Vacances Connect
  • CONECS
  • iDEAL
  • Illicado
  • Lepotcommun
  • Lydia
  • Paybutton ING
  • Spiritofcadeau
Table 27. En résumé
Connecteurs disponibles Sips Paypage, Sips Office, Sips Office Batch, Sips In-App
Configuration Worldline Sips NON
Vérification acquéreur NON
Paramètre dans la requête de paiement OUI
  • captureMode : IMMEDIATE
  • captureDay : 0

Le paiement par fichier est un échange d’informations en temps différé (en mode fichier) entre vous et Worldline Sips. Il vous permet de constituer des fichiers de transactions et/ou d'opérations puis de les déposer sur un compte FTP sécurisé Worldline Sips.

Il se distingue donc d'un nombre N d'informations communiquées en temps réel (mode transactionnel).

Mode fichier :


schéma représentant la cinématique du traitement des fichiers

  1. Vous disposez d’un nombre N de transactions de paiement et/ou d'opérations indépendantes (N1, N2, N3, N4, etc) ;
  2. En vous basant sur les spécifications de Sips Office Batch, vous constituez un fichier « requête » rassemblant ces transactions et/ou opérations, que vous déposez sur votre compte FTP sécurisé Worldline Sips ;
  3. Worldline Sips effectue des contrôles de droits ainsi que de cohérence du fichier (format, taille), puis procède au traitement des informations contenues dans ce fichier et envoie les demandes d’autorisation vers les acquéreurs ;
  4. Les acquéreurs traitent les demandes d’autorisation reçues et envoient les réponses à Worldline Sips ;
  5. Worldline Sips construit le fichier « réponse » contenant les réponses aux paiements et/ou opérations et le dépose sur votre compte FTP sécurisé Worldline Sips ;
  6. Vous récupérez le fichier « réponse » via votre compte FTP sécurisé Worldline Sips puis intégrez ce fichier dans votre propre système d’information.

Le paiement par fichier s’avère particulièrement utile si vous devez traiter un très grand nombre de flux puisqu’il vous évite d’avoir à apporter une réponse en temps réel à vos clients.

Table 28. En résumé
Connecteurs disponibles Sips Office Batch
Configuration Worldline Sips OUI
Vérification acquéreur NON
Paramètre dans la requête de paiement N/A

L’autorisation de l’acquéreur demeure valide pour une certaine durée (par défaut 6 jours pour CB, VISA et Mastercard) :

  • durant ce délai, la transaction est envoyée en remise avec l’autorisation faite en ligne ;
  • au-delà de ce délai, une nouvelle demande d’autorisation est envoyée à l’acquéreur avant la remise en paiement.

La durée de validité peut dépendre du contrat d’acquisition conclu entre vous et l’acquéreur, c’est pourquoi une option permet de fixer la durée de l’autorisation associée à votre contrat d’acquisition. Cette fonctionnalité n’est disponible que pour certains moyens de paiement, pour plus d’information, veuillez consulter les guides d’implémentation.

Table 29. En résumé
Connecteurs disponibles Sips Paypage, Sips Office, Sips Office Batch, Sips In-App
Configuration Worldline Sips OUI Par défaut 6 jours pour les cartes CB / Visa / Mastercard.
Vérification acquéreur OUI
Paramètre dans la requête de paiement NON

Dans le cas des transactions multidevises, l’acceptation porte sur la devise du client mais le paiement est réglé dans votre devise.

Vous devez souscrire cette option auprès de l’acquéreur.

Les étapes de l’acceptation des transactions multidevises sont les suivantes :

  1. vous devez gérer le prix de vos ventes en ligne en plusieurs devises ;
  2. lorsque vous soumettez la transaction au serveur Worldline Sips, vous renseignez la devise que vous désirez dans le champ currencyCode ;
  3. la transaction est envoyée pour autorisation et pour la remise du paiement avec le même code de devise ;
  4. lors de l’acquisition du paiement, l’acquéreur convertit la transaction dans votre devise de règlement.
Table 30. En résumé
Connecteurs disponibles Sips Paypage, Sips Office, Sips Office Batch, Sips In-App
Configuration Worldline Sips OUI Les devises acceptées doivent être définies dans la configuration Worldline Sips
Vérification acquéreur OUI
Paramètre dans la requête de paiement OUI currencyCode : Code devise de la transaction. Les valeurs possibles sont listées dans document Dictionnaire des données.

Dans le cas du règlement en devise, l’acceptation et le règlement sont effectués dans la même devise.

Vous indiquez le code de la devise utilisée par le client dans la requête de paiement. Vous devez disposer d’un contrat d’acquisition et d’un compte bancaire dans les devises concernées.

Tip: pour la mise en œuvre de cette fonctionnalité avancée, veuillez contacter l’assistance technique.
Table 31. En résumé
Connecteurs disponibles Sips Paypage, Sips Office, Sips Office Batch, Sips In-App
Configuration Worldline Sips OUI Les devises acceptées doivent être définies dans la configuration Worldline Sips
Vérification acquéreur OUI Contrat d’acquisition avec règlement en devises
Paramètre dans la requête de paiement OUI currencyCode : Code devise de la transaction. Les valeurs possibles sont listées dans le dictionnaire des données.


La conversion dynamique de devise (DCC – Dynamic Currency Conversion) est un service financier prévu pour les titulaires des cartes VISA et MasterCard qui permet au client de payer dans sa devise et au commerçant d’être payé dans la sienne.

Le DCC permet à la banque locale qui est l’acquéreur (celle qui prend en charge le paiement en votre nom) et à vous de profiter des frais de change ajoutés normalement à de telles transactions par VISA, MasterCard et les banques émettrices internationales. Vous recevez toujours le règlement dans votre devise de base.

Pour utiliser la conversion dynamique de devise (DCC), vous devez :

  • souscrire un contrat d’acquisition avec l’option DCC ;
  • souscrire à un service de taux de change ;
  • demander l’option DCC lors de l’inscription au service Worldline Sips.
Tip: pour la mise en œuvre de cette fonctionnalité avancée, veuillez contacter l’assistance technique.
Table 32. En résumé
Connecteur disponible Sips Paypage
Configuration Worldline Sips OUI Les devises acceptées doivent être définies dans la configuration Worldline Sips et convenues avec l’acquéreur et le changeur.
Vérification acquéreur OUI
Contrat de change OUI
Paramètre dans la requête de paiement OUI currencyCode : indiquez le code de votre devise de base. Les valeurs possibles sont listées dans le dictionnaire des données.

3-D Secure est un protocole d’authentification obligatoire destiné à réduire les risques de fraude liés au paiement sur Internet. Il a pour but de s’assurer que la carte est bien utilisée par son véritable titulaire. Outre cet aspect sécuritaire, 3-D Secure vous permet de bénéficier du transfert de responsabilité vers la banque émettrice de la carte, selon des règles édictées par les réseaux CB, VISA, MASTERCARD, AMEX et Bancontact.

Pour en avoir une description fonctionnelle détaillée et les modalités d’implémentation, veuillez consulter le Guide 3-D Secure.

Vous avez la possibilité de transmettre vos requêtes d’authentification ou vos requêtes d’autorisation à un PSP différent de Worldline Sips, via la nouvelle version du connecteur Sips Office .

Deux cas d’usages sont possibles :

  • Vous transmettez votre requête d’authentification vers Worldline Sips, en retour vous recevez les données techniques 3-D Secure. Puis, vous transmettez votre requête d’autorisation vers un autre PSP avec les données techniques 3-D Secure afin de bénéficier de la garantie de paiement ;
  • Vous transmettez votre requête d’authentification vers un autre PSP qui peut vous retourner les données techniques 3-D Secure. Puis, vous transmettez votre requête d’autorisation vers Worldline Sips avec les données techniques 3-D Secure afin de bénéficier de la garantie de paiement.

Pour plus d'information, merci de vous référez au Guide 3-D Secure

La sécurisation SafeDebit vous permet de garantir le paiement des prélèvements Sepa Direct Debit (SDD) de type BtoC . Celle-ci s'applique sur l'ensemble des échéances, pas uniquement sur le premier prélèvement . Pour cela, il vous faut souscrire un contrat auprès de SSP (Score & Secure Payment).

La prise de risque est une option à laquelle vous pouvez souscrire permettant de forcer la création d'un mandat et d'éventuels SDD associés. Les prélèvements forcés via cette option ne seront pas garantis et ne pourront donc pas être indemnisés en cas d'impayé.

Attention: un SDD non garanti sera considéré refusé si vous n'avez pas souscrit à l'option prise de risque.

Pour plus d'information, veuillez consulter le guide d'intégration SDD.

Table 33. En résumé
Connecteurs disponibles Sips Paypage,Sips Office Extranet,Sips Office et Sips Walletpage
Configuration Worldline Sips NON Activé si souscription auprès de SSP
Vérification acquéreur NON
Paramètre dans la requête de paiement NON La prise de risque se gère à votre niveau

Le paiement récurrent définit les règles et modalités du paiement d'un service sur une période donné, validées entre le commerçant et son client. Son usage est adapté pour le paiement des services liés à un abonnement.

Dans son cas d'usage, le paiement récurrent se passe en 2 phases :

  • 1ère phase : la collecte des coordonnées carte s’effectue en présence du client et est associée ou non à un paiement. Ce sont ces coordonnées cartes que vous utiliserez pour les paiements futurs selon des conditions validées par le client.
  • 2ème phase : les Nième paiements que vous soumettez sans intervention du client à partir des données cartes stockées lors de la 1ère phase.

Moyens de paiement supportés

CB, Visa, Mastercard, American Express, Bancontact et SDD.

Sécurisation 3-D Secure des paiements récurrents carte

Pour sécuriser la récurrence, il est obligatoire de dérouler la transaction initiale (1er paiement) en mode 3-D Secure pour authentifier le titulaire de la carte. Les Nème paiements se déroulent nécessairement hors contexte 3-D Secure car le porteur n’intervient pas.

Traiter les paiements récurrents en respectant les exigences PCI

La solution Worldline Sips vous permet d’utiliser les coordonnées cartes en toute sécurité sans être soumis aux exigences PCI liées au stockage des données cartes. Plusieurs possibilités pour traiter les Nème paiements :

  • duplication de la transaction initiale ;
  • paiement via Wallet (carte stockée dans le wallet) ;
  • paiement via Token (carte tokenisée).
Attention: vous devez informer vos clients du stockage de leurs coordonnées et des modalités des paiements récurrents (durée, montant, périodicité…)

La gestion des abonnements via la duplication est décrite de manière détaillée dans le guide du paiement par abonnement via duplication.

Le paiement récurrent via Wallet est la solution Worldline Sips Abonnement.

Pour avoir une description fonctionnelle et les modalités d’implémentation du paiement par abonnement, veuillez consulter le document Paiement par abonnement.

Voici en synthèse les principaux cas d’utilisation.

Enregistrement du moyen de paiement dans le wallet lors d’un paiement Sips Paypage

Via Sips Paypage, vous pouvez demander l’enregistrement automatique du moyen de paiement dans le wallet en cas de paiement accepté.

Attention: s'il s'agit d'un paiement par carte, vous devez conserver la valeur du schemeTransactionIdentifier en réponse. Vous devrez transmettre cette donnée dans le champ InitialSchemeTransactionIdentifier lors des paiements récurrents pour chaîner les chaîner avec la transaction initiale (conformité DSP2).
Table 34. En résumé
Connecteur disponible Sips Paypage
Configuration Worldline Sips OUI Option Enrôlement automatique dans le wallet lors d’un paiement Sips Paypage accepté
Vérification acquéreur NON
Paramètre dans la requête

OUI
  • merchantWalletID : identifiant du wallet
  • paymentPattern : RECURRING_1
  • challengeMode3DS : valeur forcé à CHALLENGE_MANDATE
Reporting

  • Journal des transactions : OUI
  • Journal des opérations : NON
  • Sips Office Extranet : OUI

Enregistrement du moyen de paiement dans le wallet via Sips Walletpage hors contexte de paiement

Via l’interface Walletpage, vous pouvez demander à votre client de créer un wallet en y ajoutant un moyen de paiement.

IMPORTANT: cette interface ne doit pas être utilisée pour la mise en place d'un abonnement avec une carte car vous ne disposerez pas d'un identifiant de chainage à envoyer pour chaque nouvelle récurrence. Si vous utilisez cette interface pour mettre en place un abonnement, vousne serez pas en conformité avec la DSP2.
Table 35. En résumé
Connecteur disponible Sips Walletpage
Configuration Worldline Sips OUI Option Sips Walletpage
Vérification acquéreur NON
Paramètre dans la requête

OUI
  • merchantWalletID : Identifiant dans lequel va être stocké le PAN ou le mandat
  • walletActionNameList : ADDPM pour ajout d’un moyen de paiement
  • PaymentMeanBrandList : SEPA_DIRECT_DEBIT
Reporting

  • Journal des transactions : NON
  • Journal des opérations : NON
  • Sips Office Extranet : NON

Enregistrement d’un mandat dans le wallet via la méthode addDirectDebit de Sips Office hors contexte de paiement

Via les interfaces Sips Office ou Sips Office Batch, vous pouvez créer un wallet pour votre client avec son numéro de mandat.

Table 36. En résumé
Connecteurs disponibles Sips Office,
Configuration Worldline Sips OUI Option wallet
Vérification acquéreur OUI Option recurring
Paramètre dans la requête OUI
  • merchantWalletID : Identifiant du wallet
  • mandateId : Identifiant du mandat
  • paymentMeanBrand : SEPA_DIRECT_DEBIT
Reporting

  

  • Journal des transactions : NON
  • Journal des opérations : NON
  • Sips Office Extranet : NON

Pour les Nème paiements, vous utilisez la méthode walletOrder en renseignant l’identifiant du wallet dans le champ merchantwalletID

Attention: si le moyen de paiement associé au wallet est une carte, vous devez renseigner le champ initialSchemeTransactionIdentifier avec la valeur du champ schemeTransactionIdentifier reçue lors de la mise en place de l'abonnement.
Table 37. En résumé
Connecteurs disponibles Sips Office, Sips Office Batch
Configuration Worldline Sips OUI Non activé par défaut
Vérification acquéreur OUI Option recurring, Option WIP pour Bancontact
Paramètre dans la requête OUI
  • paymentPattern : RECURRING_N
  • merchantWalletID : identifiant du wallet dans lequel est stocké le moyen de paiement
  • initialSchemeTransactionIdentifier : identifiant de chainage obtenu lors du premier paiement (uniquement pour les paiements par carte)
Reporting

  

  • Journal des transactions : OUI
  • Journal des opérations : NON
  • Sips Office Extranet : OUI
Note: le wallet est limité à 1 seul moyen de paiement pour simplifier la mise en œuvre du paiement récurrent. (1 wallet = 1 moyen de paiement)

Vous n’avez à gérer que l’identifiant du wallet et pas l’identifiant du moyen de paiement à l’intérieur du wallet.

Lors du 1er paiement, vous indiquez dans la requête qu’il s’agit du 1er paiement d’une récurrence et vous devez avoir souscrit à l’option Token de la solution Worldline Sips. En réponse vous recevez un token que vous utiliserez pour les paiements récurrents futurs. Lors d'une cinématique 3DS, le token est également retourné en réponse de la vérification d'enrôlement sur les connecteurs Sips Office et Sips In-App.

Attention: vous devez conserver la valeur du schemeTransactionIdentifier en réponse. Vous devrez transmettre cette donnée dans le champ initialSchemeTransactionIdentifier lors des paiements récurrents pour les chaîner avec la transaction initiale (conformité DSP2).
Table 38. En résumé
Connecteurs disponibles Sips Paypage, Sips Office, Sips Office Batch, Sips In-App, Sips Office Extranet
Configuration Worldline Sips OUI Option Token
Vérification acquéreur OUI Option recurring
Paramètre dans la requête de paiement OUI paymentPattern : RECURRING_1
Reporting

  

  • Journal des transactions : OUI
  • Journal des opérations : NON
  • Sips Office Extranet : OUI

Pour les Nième paiements, vous soumettez la requête en fournissant le token retourné lors de la transaction initiale.

Tip: vous devez renseigner le champ initialSchemeTransactionIdentifier avec la valeur du champ schemeTransactionIdentifier reçue lors de la mise en place de l'abonnement.
Table 39. En résumé
Connecteurs disponibles Sips Office, Sips Office Batch, Sips In-App
Configuration Worldline Sips OUI Option Token
Vérification acquéreur OUI Option recurring, Option WIP pour Bancontact
Paramètre dans la requête de paiement OUI Via connecteur Sips Office ou Sips Office Batch :
  • paymentPattern : RECURRING_N
  • panType : TOKEN_PAN
  • cardNumber : <token> valeur du token
  • cardExpiryDate : date d’expiration de la carte
  • cardEffectiveDate : si carte et acquéreur UK
  • cardSequenceNumber : si carte et acquéreur UK
Via connecteur Sips In-App (à l'initialisation de la requête de paiement) :
  • paymentPattern : RECURRING_N
  • tokenPan : <token> valeur du token
  • initialSchemeTransactionIdentifier : identifiant de chainage obtenu lors du premier paiement
Reporting

  

  • Journal des transactions : OUI
  • Journal des opérations : NON
  • Sips Office Extranet : OUI
Tip: le token est valide tant que la carte est valide. En cas de token expiré, le client devra donner ses nouvelles coordonnées carte.
Le token s’applique aux cartes CB, VISA et MASTERCARD.

Le paiement OneClick s’adresse aux commerçants qui souhaitent simplifier le paiement de leurs clients.

Ce service permet aux clients d’enregistrer leurs coordonnées de paiement dans un espace sécurisé appelé Wallet et ainsi d’éviter la ressaisie de ces informations lors de futurs paiements.

Le paiement OneClick simplifie l’acte de paiement, améliore l’expérience utilisateur notamment pour les achats effectués via mobiles et augmente donc le taux de conversion.

Pour avoir une description fonctionnelle et les modalités d’implémentation du paiement OneClick, veuillez consulter le document OneClick.

Les cycles de vie des transactions diffèrent selon les moyens de paiement, le nouvel état de la transaction peut donc lui aussi différer. Les cycles de vie détaillés sont disponibles dans les guides d’intégration des moyens de paiement.

Tip: si vous obtenez en réponse de votre opération de gestion de caisse un refus suite à une erreur technique (responseCode 90 ou 99) ou un refus lié à l'état de la transaction (responseCode 24), nous vous conseillons de retenter votre opération.

Vous pouvez annuler les transactions, non remisées, partiellement ou totalement en utilisant la fonction Annuler disponible dans les interfaces de Sips Office, Sips Office Batch et Sips Office Extranet.

Pour les moyens de paiement CB, Visa et Mastercard, l’opération d'annulation n’est plus possible sur une transaction dès l’exécution de son traitement de remise en banque.

Exemple : si une transaction (CB, Visa ou Mastercard) est effectuée à J, avec un captureDay paramétré à 2 et un captureMode AUTHOR_CAPTURE, il ne sepra plus possible de l'annuler à J+2 à partir de 22h00 CET.



Pour la majorité des autres moyens de paiement, les opérations d'annulation sont indisponibles tous les jours durant le traitement de la remise (voir Annexe 3 pour le détail des horaires), même sur les transactions non inclues dans la remise. La durée de traitement peut varier selon le nombre de transactions à remiser.

Il est possible de connaître la date de remise en paiement d'une transaction soit via Sips Office Extranet, soit les journaux, soit en utilisant la fonction GetTransactionData via Sips Office (dans le champ captureLimitDate).

Dans le cas d’une annulation totale, l’état de la transaction passe à « annulée » (transactionStatus CANCELLED), mais pour une annulation partielle, l’état reste inchangé.

Les contrôles suivants sont effectués :

  • vous disposez du droit d’annulation. Dans le cas contraire un responsCode 40 est retourné ;
  • la transaction existe dans notre base de données. Dans le cas contraire un responseCode 25 est retourné ;
  • la transaction est au statut "TO_CAPTURE" ou "TO_VALIDATE" ou "TO_AUTHORIZE" ou "TO_CHALLENGE". Dans le cas contraire un responseCode 24 est retourné. Vous pouvez consulter les heures de remise par acquéreur / privatif en Annexe 3 ;
  • le montant à annuler est égal ou inférieur au montant de la transaction. Dans le cas contraire un responseCode 51 est retourné ;
  • aucune opération de caisse n'est déjà en cours sur la transaction. Dans le cas contraire, un responseCode 24 est retourné.
Note: vous retrouvez l’ensemble des codes réponse dans le dictionnaire des données ici.
Table 40. En résumé
Connecteurs disponibles Sips Office, Sips Office Batch, Sips Office Extranet
Configuration Worldline Sips OUI Non activé par défaut
Vérification acquéreur NON
Reporting

  • Journal des transactions : NON
  • Journal des opérations : OUI, CANCEL
  • Sips Office Extranet : OUI

Les transactions créées dans le mode validation (captureMode = VALIDATION), doivent être validées partiellement ou totalement pour déclencher le paiement en utilisant la fonction Valider disponible dans les interfaces de Sips Office, Sips Office Batch et Sips Office Extranet.

La transaction passe alors à l’état « à valider » (transactionStatus = TO_VALIDATE) ou à l’état « en attente d’une validation avec demande d’autorisation » (transactionStatus = TO_REPLAY), puis à l'état « à remiser » (transactionStatus = TO_CAPTURE) ou directement à l’état « remisée » (transactionStatus = CAPTURED) en fonction des règles du moyen de paiement.

Vous ne pouvez valider une transaction qu’une seule fois. Dans le cas d’un paiement partiel, le complément peut être réalisé grâce à l’opération de duplication.

Les contrôles suivants sont effectués :

  • vous disposez du droit de validation. Dans le cas contraire un responseCode 40 est retourné ;
  • la transaction existe dans notre base de données. Dans le cas contraire un responseCode 25 est retourné ;
  • la transaction est au statut "TO_VALIDATE". Dans le cas contraire un responseCode 24 est retourné ;
  • le montant à valider est inférieur ou égale au montant de la transaction. Dans le cas contraire un responseCode 51 est retourné ;
  • la demande d'autorisation est acceptée par l’acquéreur dans le cas d'une validation avec demande d’autorisation (spécifique à quelques moyens de paiement). Dans le cas contraire un responseCode autre que 00 est retourné ;
  • aucune opération de caisse n'est déjà en cours sur la transaction. Dans le cas contraire, un responseCode 24 est retourné.

Tip: vous retrouvez l’ensemble des codes réponse dans le dictionnaire des données ici.
Table 41. En résumé
Connecteurs disponibles Sips Office, Sips Office Batch, Sips Office Extranet
Configuration Worldline Sips OUI VALIDATE
Vérification acquéreur NON
Reporting

  • Journal des transactions : NON
  • Journal des opérations : OUI, VALIDATE
  • Sips Office Extranet : OUI

Cas des validations immédiates après le paiement

Votre métier de vente sur Internet vous a peut-être contraint à implémenter vos paiements en mode validation (champ captureMode = VALIDATION), et à envoyer une requête de validation via Sips Office immédiatement après le paiement, soit au retour de votre client sur votre site marchand, soit à réception de la réponse automatique. Ce mode de fonctionnement est valable, mais vous devez prendre quelques précautions de mise en œuvre et échanger avec votre chargé de compte pour qu'il(elle) valide votre choix.

Afin d'optimiser la réussite de vos ventes sur Internet, nous utilisons un système d'écriture en base de données de type asynchrone. Grâce à ce système d'écriture asynchrone, nous restons en capacité d'accepter vos transactions de paiement en temps réel, même si notre système base de données venait à subir quelques perturbations ou à ralentir.

Toutefois, lors d'une maintenance ou en cas d'engorgement ponctuel de notre système de base de données, les transactions s'enregistrent avec un temps de décalage par rapport au traitement temps réel du paiement. Il est par conséquent nécessaire de suivre les conseils ci-dessous pour votre implémentation de validations automatisées .

Code réponse Description Causes possibles Conseils de mise en oeuvre
00 La validation est acceptée RAS RAS
25 Validation refusée, car la transaction n'est pas trouvée en base de données Cas 1 : vous avez commis une erreur dans la requête. Les données d'identification de la transaction (transactionReference ou transactionId ou transactionDate) sont fausses, ou vous tentez de valider un paiement qui ne s'est pas terminé (par exemple l'acheteur a abandonné)

Cas 2 : la transaction de paiement a bien été traitée jusqu'à sa fin , mais elle n'est pas encore enregistrée en base de données, dû à notre système asynchrone d'écriture en base de données Nous conseillons de mettre en place un batch de recyclage automatique de ces tentatives de validation échouée, et d'exécuter ce batch 30 minutes minimum après le paiement, de manière à laisser le temps nécessaire d'insertion de la transaction en base de données. Si vous recevez un nouveau code 25, nous ne sommes pas dans le cas 2, mais certainement dans le cas 1 décrit ci-contre

99 Validation échouée, car notre système de gestion de caisse est ponctuellement inaccessible Cas 1 : nous subissons un incident technique, nous mettons tout en œuvre pour rétablir la situation au plus tôt. Vous allez recevoir une communication par e-mail décrivant l'incident.

Nous conseillons de mettre en place un batch de recyclage automatique de ces tentatives de validation échouée, et d'exécuter ce batch 30 minutes minimum après le paiement, de manière à laisser le temps nécessaire au rétablissement du service. Tant que vous recevez un code 99, recyclez votre requête de validation.
Cas 2 : nous sommes en maintenance. S'il s'agit d'une maintenance programmée, un e-mail vous a été transmis quelques semaines auparavant.

Dans le cas d’un paiement déjà remisé, vous pouvez rembourser la transaction partiellement ou totalement en utilisant la fonction Rembourser disponible dans les interfaces de Sips Office, Sips Office Batch et Sips Office Extranet.

Note: tous les jours, durant le traitement de remise des transactions en banque (qui a lieu entre 22h00 et 23h00 CET pour la majorité des moyens de paiement), les opérations de remboursement sont indisponibles sur l'ensemble des transactions.

Exemple : si un transaction (CB, Visa ou Mastercard) est effectuée à J, avec un captureDay paramétré à 2, il sera possible de la rembourser en totalité ou partiellement à J+2 après la fin du traitement de la remise.



Dans le cas d’un remboursement total, la transaction passe à l’état « à rembourser » (transactionStatus = TO_CREDIT) ou à l’état « remboursée » (transactionStatus = CREDITED) en fonction des règles du moyen de paiement.

En cas de remboursement partiel, l’état de la transaction redevient « envoyée en banque » (transactionStatus = CAPTURED) après le traitement de la remise.

Les contrôles suivants sont effectués :

  • vous disposez du droit de remboursement. Dans le cas contraire un responseCode 40 est retourné ;
  • la transaction existe dans notre bas de données. Dans le cas contraire un responseCode 25 est retourné ;
  • la transaction est au statut CAPTURED ou TO_CREDIT. Dans le cas contraire un responseCode 24 est retourné. Vous pouvez consulter les heures de remise par acquéreur / privatif en Annexe 3 ;
  • le montant à rembourser doit être inférieur ou égale au montant de la transaction. Dans le cas contraire un responseCode 51 est retourné ;
  • la transaction à rembourser n'est pas en impayé. Dans le cas contraire, un responseCode 57est retourné ;
  • aucune opération de caisse n'est déjà en cours sur la transaction. Dans le cas contraire, un responseCode 24 est retourné.
Tip: vous retrouvez l’ensemble des codes réponse dans le dictionnaire des données ici.
Table 42. En résumé
Connecteurs disponibles Sips Office, Sips Office Batch, Sips Office Extranet
Configuration Worldline Sips OUI Non activé par défaut
Vérification acquéreur NON
Reporting

  

  • Journal des transactions : NON
  • Journal des opérations : OUI, REFUND
  • Sips Office Extranet : OUI

Vous pouvez effectuer un remboursement déplafonné, c'est-à-dire rembourser un montant supérieur à celui de la transaction payée.

Pour effectuer un remboursement déplafonné, vous utilisez la même fonction que dans le cas d’un remboursement standard, mais vous devez disposer d’une option supplémentaire et définir un pourcentage de dépassement autorisé par rapport au montant de la transaction d’origine.

Dans le cas d’un dépassement de plafond, le remboursement est rejeté.

Les contrôles suivants sont effectués :

  • contrôles identiques que ceux effectués pour un remboursement standard, sauf le contrôle du montant ;
  • le montant à rembourser est inférieur ou égale au dépassement autorisé. Dans le cas contraire un responseCode 51 est retourné ;
  • aucune opération de caisse n'est déjà en cours sur la transaction. Dans le cas contraire, un responseCode 24 est retourné.
Note: vous retrouvez l’ensemble des codes réponse dans le dictionnaire des données ici.
Table 43. En résumé
Connecteurs disponibles Sips Office, Sips Office Batch, Sips Office Extranet
Configuration Worldline Sips OUI Non activé par défaut
Vérification acquéreur NON
Reporting

  

  • Journal des transactions : NON
  • Journal des opérations : OUI, REFUND
  • Sips Office Extranet : OUI

Vous pouvez créer une transaction à partir d’une transaction existante en utilisant la fonction « Duplication » disponible dans les interfaces Sips Office, Sips Office Batch et Sips Office Extranet. Cette fonction permet par exemple de recréer une transaction à partir d’une transaction qui a expiré par erreur, mais également de faire du paiement en plusieurs fois.

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

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

Les contrôles suivants sont effectués :

  • vous disposez du droit de duplication. Dans le cas contraire un responseCode 40 est retourné;
  • la transaction existe dans notre base de données. Dans le cas contraire un responseCode 25 est retourné;
  • le moyen de paiement utilisé est compatible et permet la duplication. Dans le cas contraire, un responseCode 24 est retourné ;
  • la date d’expiration du moyen de paiement est toujours valide. Dans le cas contraire, un responseCode 14 est retourné ;
  • la demande d’autorisation est acceptée pas l’acquéreur et un responseCode 00 a été obtenu.
Tip: vous retrouvez l’ensemble des codes réponse dans le dictionnaire des données ici.
Table 44. En résumé
Connecteurs disponibles Sips Office, Sips Office Batch, Sips Office Extranet
Configuration Worldline Sips OUI Non activé par défaut
Vérification acquéreur NON
Reporting

  

  • Journal des transactions : OUI
  • Journal des opérations : OUI, DUPLICATE
  • Sips Office Extranet : OUI

Vous pouvez créer une transaction à partir d’une transaction existante initiée par une de vos autres boutiques, en utilisant la fonction Duplication étendue disponible dans les interfaces Sips Office et Sips Office Batch.

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

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

Les contrôles suivants sont effectués :

  • contrôles identiques que ceux effectués pour une duplication standard ;
  • la boutique effectuant la duplication est paramétrée avec le droit de duplication étendue. Dans le cas contraire, un responseCode 40 est retourné.
Note: vous retrouvez l’ensemble des codes réponse dans le dictionnaire des données ici.
Table 45. En résumé
Connecteurs disponibles Sips Office, Sips Office Batch,
Configuration Worldline Sips OUI Non activé par défaut
Vérification acquéreur NON
Reporting

  

  • Journal des transactions : OUI
  • Journal des opérations : OUI, DUPLICATE
  • Sips Office Extranet : NON

Si vous disposez des coordonnées carte ou du token (voir paragraphe Tokenisation) de la carte de votre client, vous pouvez le rembourser sans faire référence à une transaction antérieure via la fonction creditHolder des connecteurs Sips Office, Sips Office Batch et Sips Office Extranet.

Si vous avez souscrit à l’option OneClick et que la carte est sauvegardée dans le wallet, vous pouvez également réaliser un crédit porteur à partir du wallet à la place du numéro de carte original (fonctionnement conforme à PCI) via la fonction walletCreditHolder des connecteurs Sips Office et Sips Office Batch.

Note: la cinématique d'un crédit porteur est particulière ; elle consiste tout d'abord en une demande d'autorisation d'un petit montant (appelée "prise d'empreinte") ou bien d'une demande de renseignement (si supportée par l'acquéreur) dans le but de vérifier le numéro de carte. Si la réponse acquéreur est négative, Worldline Sips la traduit en un refus pour carte ou compte invalide et renvoie un responseCode 14. Dans le cas d'une réponse positive, Worldline Sips envoie la demande d’autorisation avec le montant réel du crédit.

Il n'est pas possible de demander un remboursement sur une transaction créée par un crédit porteur. Toute demande de remboursement sur ce type transaction renverra un responseCode 24 (opération impossible).

Table 46. En résumé
Connecteurs disponibles
  • creditHolder : Sips Office, Sips Office Batch, Sips Office Extranet
  • walletCreditHolder : Sips Office, Sips Office Batch
Configuration Worldline Sips OUI Non activé par défaut
Vérification acquéreur NON
Reporting

  

  • Journal des transactions : OUI
  • Journal des opérations : NON
  • Sips Office Extranet : OUI (uniquement pour la fonction creditHolder)

La fonctionnalité de diagnostic vous permet de connaître l’état détaillé d’une transaction indiquée dans votre requête via la fonction getTransactionData des interfaces Sips Office.

Table 47. En résumé
Connecteur disponible Sips Office
Configuration Worldline Sips OUI Diagnostic non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête de diagnostic OUI transactionReference ou s10TransactionId + s10TransactionIdDate

La réponse manuelle vous est envoyée lorsque le client est redirigé vers votre site une fois le paiement en ligne (connecteur Sips Paypage ) ou la gestion de wallet (connecteur Sips Walletpage) effectué. Néanmoins, vous n’avez pas de garantie de récupérer la réponse manuelle car, le client peut décider de fermer son navigateur ou ne pas cliquer sur le bouton de retour à la boutique une fois son paiement réalisé ou sa gestion de wallet terminée.

Les champs retournés dans la réponse sont variables en fonction du résultat de la transaction (refusée ou réussie).

Table 48. En résumé
Connecteurs disponibles Sips Paypage, Sips Walletpage
Configuration Worldline Sips NON
Vérification acquéreur NON
Paramètre dans la requête

OUI normalReturnUrl : <url> Adresse URL pour la réponse manuelle (obligatoire)

Pour assurer la récupération de la réponse à la requête de paiement (connecteurs Sips Paypage et Sips In-App) ou à la requête de gestion de wallet (connecteur Sips Walletpage), vous pouvez demander l’envoi de la réponse dite automatique. La réponse est envoyée indépendamment du retour boutique du client. Les champs de la réponse sont variables en fonction du résultat de la transaction (refusée ou réussie).

L’adresse URL de la réponse automatique peut être fournie dans la requête, si elle n’est pas fournie, c’est celle de la configuration marchande qui est utilisée. Si elle n’est pas fournie et qu’aucune configuration n’a été faite, la réponse automatique n’est pas envoyée.

Le résultat de l’envoi de la réponse automatique vers le commerçant est renseigné dans le champ automaticResponseStatus d’une transaction de paiement. Les valeurs de ce champ (SENT, FAILED, TIMED_OUT) sont conditionnées par le code HTTP renvoyé.

Dans le cas où l'envoi de la réponse automatique est en échec (statut FAILED ou TIMED_OUT), un renvoi est réalisé au bout de 15 minutes. En tout 5 tentatives d'envoi de la réponse automatique sont effectuées en cas d'échec.

HTTP 200 HTTP 201 HTTP 204 HTTP 205 HTTP 301 HTTP 301 HTTP 404 HTTP 408 HTTP 504 HTTP 500 HTTP 503 default
SENT X X X X X X
FAILED X X X X
TIMED

_OUT

X X
Table 49. En résumé
Connecteurs disponibles Sips Paypage, Sips In-App, Sips Walletpage,
Configuration Worldline Sips OUI Réponse automatique non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête OUI automaticResponseUrl : <url> Adresse URL pour la réponse automatique (optionnel)

Le format et la version des réponses automatiques et manuelles dépend de l'interfaceVersion précisée dans la requête.

Si l'interface version est antérieure à 3.0, le format de sortie sera de type POST et la version des réponses dépendra de la configuration de la boutique (par défaut identique à la version d'entrée).

Si l'interface version est supérieure ou égale à 3.0, le format de sortie sera de type POST si le format d'entrée est de type POST ou SOAP, et de type JSON si le format d'entrée est de type JSON. Par défaut la version de la réponse sera égale à la version de la requête.

Cependant cette version et ce format peuvent être remplacés par des versions antérieures à la version 3.0 et forcé en format POST si les champs interfaceVersionNormalResponse et interfaceVersionAutomaticResponse sont renseignés dans la requête.

Table 50. En résumé
Connecteurs disponibles Sips Paypage, Sips Walletpage, Sips In-App
Configuration Worldline Sips OUI Par défaut, à partir de l’interfaceVersion 3.0 :
  • Version de la réponse identique à la requête
  • Requête en JSON = réponse en JSON
  • Requête en POST or SOAP = réponse en POST
Vérification acquéreur NON
Paramètre dans la requête OUI Surcharge du comportement par défaut possible. Champs de la requête :
  • interfaceVersion : 3.0 ou supérieur
  • interfaceVersionNormalResponse : numéro de version souhaité pour la réponse manuelle
  • interfaceVersionAutomaticResponse : numéro de version souhaité pour la réponse automatique

Cette notification est reçue par le client à la fin du processus de la transaction. Vous pouvez en recevoir une copie par e-mail sur une adresse configurée lors de l’activation de cette option. Le contenu de la notification est variable en fonction du résultat de la transaction (refusée ou réussie).

La notification au client peut être envoyée par e-mail ou SMS, si les deux champs sont renseignés, la notification par e-mail est choisie.

Tip: pour la mise en œuvre de cette fonctionnalité avancée (notification par SMS), veuillez contacter l’assistance technique.
Table 51. En résumé
Connecteurs disponibles Sips Paypage, Sips Office, Sips Office Batch, Sips In-App
Configuration Worldline Sips OUI Confirmation non activée par défaut
Vérification acquéreur NON
Paramètre dans la requête

  

OUI
  • customerContact.email : <adresse mail du client> Pour la notification par courrier électronique
  • customerContact.mobile : <numéro de téléphone du client> Pour la notification par SMS

Les journaux suivants vous permettent de suivre l’activité de votre boutique :

  • Journal des transactions
  • Journal des opérations
  • Journal de rapprochement des transactions
  • Journal de rapprochement des impayés
  • Journal des cartes échues

Par défaut les journaux sont envoyés quotidiennement par mail sauf le journal d’expiration qui est envoyé mensuellement.

Vous pouvez choisir les journaux qui vous sont envoyés.

Table 52. En résumé
Connecteurs disponibles Sips Paypage, Sips Office, Sips Office Batch, Sips In-App, Sips Walletpage
Configuration Worldline Sips OUI Non activé par défaut
Vérification acquéreur NON/OUI Dépend de l’acquéreur ou de l’établissement financier pour les journaux de rapprochement des transactions et de rapprochements des impayés

Par défaut, les opérations de remise n’apparaissent pas dans le journal des opérations. Si vous souhaitez les inclure, vous pouvez souscrire à une option spécifique.

Par défaut, les transactions non rapprochées n’apparaissent pas dans le journal de rapprochement des transactions. Si vous souhaitez les inclure, vous pouvez souscrire à une option spécifique.

Pour plus d’information, veuillez consultez le document description des journaux.

Le token est un numéro partagé par le commerçant et Worldline Sips qui remplace le numéro de carte de crédit (PAN) et ne constitue pas une donnée sensible.

L’utilisation du token est une méthode qui contribue au respect des normes PCI/DSS

Caractéristiques du token

  • Même longueur que le PAN pour minimiser les changements dans le système d’information du commerçant.
  • Tokenisation complet du PAN (aucun digit ne reste en clair).
  • Contient au moins une lettre pour le distinguer du PAN en clair.
  • Unique pour un numéro de carte donné.
  • Irréversible (ne permettant pas de déduire le numéro de carte).
  • Libre utilisation dans le système d’information du commerçant.
  • Solution certifiée PCI-DSS.
Tip: pour la mise en œuvre de cette fonctionnalité avancée, veuillez contacter l’assistance technique.

Le numéro de la carte peut être converti en token lors du processus de paiement et retourné dans les réponses manuelles et automatiques.

Le token est également retourné en réponse de la vérification d'enrôlement lors d'une cinématique 3DS via les connecteurs Sips Office et Sips In-App.

Avec ce token, vous pourrez ensuite soumettre des paiements récurrents via les connecteurs Sips Office.

Table 53. En résumé
Connecteurs disponibles Sips Paypage, Sips Office, Sips In-App
Configuration Worldline Sips OUI Non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête NON

Dans le cas où le traitement de tokenisation ne peut aboutir, une option permet d’interrompre le processus de paiement.

Table 54. En résumé
Connecteurs disponibles Sips Paypage, Sips Office, Sips In-App
Configuration Worldline Sips OUI Non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête NON

Vous pouvez également continuer le processus de paiement, et choisir de tokeniser ensuite la transaction grâce à la fonction « Tokenisation de transaction » décrite ci-dessous.

Cette fonctionnalité chiffre un ou plusieurs numéros de carte en un ou plusieurs token. L’ordre des token n’est pas garanti (le premier numéro saisi dans le connecteur n’est pas nécessairement le premier jeton à apparaître dans la réponse). Le champ tokenPanId sert à récupérer le token associé au numéro de la carte envoyée.

Les données de sortie dans la réponse contiennent autant de token qu’il y a de paires de champs tokenPanId et tokenPan renseignées.

IMPORTANT: le nombre maximum de numéros de carte que l'on peut chiffrer avec un appel à cette fonction est limité à 256.
Table 55. En résumé
Connecteurs disponibles Sips Office, Sips Office Batch
Configuration Worldline Sips OUI Non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête OUI
  • panId : Identifiant du token dans le process de tokenisation
  • pan : Numéro de carte

Cette fonctionnalité crypte le numéro de carte d’une transaction existante à partir de sa référence en un token. Vous pouvez utiliser cette fonctionnalité en mode transactionReference ou transactionId (voir paragraphe Mode d’identification des transactions).

Vous ne pouvez envoyer qu’une seule transaction par requête.

Table 56. En résumé
Connecteurs disponibles Sips Office, Sips Office Batch
Configuration Worldline Sips OUI Non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête OUI fromTransactionReference ou s10FromTransactionId + s10From
TransactionIdDate : Identifiant de transaction

Cette fonctionnalité déchiffre un ou plusieurs token en un ou plusieurs numéros de carte. L’ordre des numéros de carte n’est pas garanti (le premier token renseigné dans le connecteur n’est pas nécessairement le premier numéro carte à apparaître dans la réponse). Le champ panId sert à récupérer le numéro de carte associé au token envoyé.

Les données de sortie dans la réponse contiennent autant de numéros de carte qu’il y a de paires de champs panId et pan renseignées.

IMPORTANT: le nombre maximum de numéros de carte que l'on peut déchiffrer avec un appel à cette fonction est limité à 256.
Table 57. En résumé
Connecteurs disponibles Sips Office
Configuration Worldline Sips OUI Non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête OUI
  • tokenPanId : identifiant du token dans le process de tokenisation
  • tokenPan : Nnuméro de carte à convertir en token

Vous pouvez envoyer une requête de paiement en précisant le token au lieu du PAN via la fonction cardOrder des connecteurs Sips Office et Sips Office Batch ou via la fonction orderInitialize du connecteur Sips In-App.

Au préalable, vous devez récupérer le token du client soit en retour d’un paiement soit via la fonction de tokenisation.

Table 58. En résumé
Connecteurs disponibles Sips Office, Sips Office Batch, Sips In-App
Configuration Worldline Sips OUI Non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête OUI Via connecteur Sips Office et Sips Office Batch :
  • panType : TOKEN
  • cardNumber : <token> valeur du token
  • cardExpiryDate : Date d’expiration de la carte
  • cardCSCValue : Code de sécurité si paiement non récurrent
  • cardEffectiveDate
  • cardSequenceNumber
Via connecteur Sips In-App :
  • tokenPan : <token> valeur du token
  • cardExpiryDate : Date d’expiration de la carte
  • cardCSCValue : Code de sécurité si paiement non récurrent

Vous pouvez rembourser un client à partir de son token. C’est la version sécurisée de la fonction crédit porteur puisque vous n’avez pas besoin de connaître le numéro de carte de votre client.

Via la fonction CreditHolder des interfaces Sips Office, vous faîtes une transaction de crédit porteur avec un token au lieu du PAN.

Au préalable vous devez récupérer le token du client soit en retour d’un paiement soit via la fonction de tokenisation.

Table 59. En résumé
Connecteurs disponibles Sips Office, Sips Office Batch
Configuration Worldline Sips OUI Non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête OUI
  • panType : TOKEN
  • cardNumber : <token> valeur du token
  • cardExpiryDate : Date d’expiration de la carte
  • cardCSCValue : Code de sécurité si paiement non récurrent
  • cardEffectiveDate
  • cardSequenceNumber

À la fin du processus de paiement, un ou deux hashPan calculés à partir du numéro de la carte peuvent être renvoyés dans les réponses automatiques et/ou manuelles.

Le PAN (Primary Account Number ou numéro de carte) haché (champ hashPan) est calculé à partir d’une fonction cryptographique non réversible (à la différence du Token). Il vous permet de vérifier la fréquence d’utilisation d’une carte en retour de paiement.

La réponse automatique et/ou manuelle contient autant de hashPan qu’il y a de champs hashSalt et hashAlgorithm renseignés dans la requête de paiement.

HashSalt sert à augmenter la complexité du hash calculé et à empêcher de retrouver le numéro de carte à l’aide d’une fonction de dictionnaire inversé de hachage.

Worldline Sips propose de retourner 2 hashPan pour vous permettre de changer d’algorithme et d’éviter une rupture des contrôles effectués en retour de paiement.

Table 60. En résumé
Connecteurs disponibles Sips Paypage
Configuration Worldline Sips OUI Non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête OUI
  • hashSalt1 : Sel pour calcul du hashPan1
  • hashSalt2 : Sel pour calcul du hashpan2
  • hashAlgorithm1 : <SHA-1, SHA-256, SHA-512> Algorithme1 utilisé pour hashPan1
  • hashAlgorithm2 : <SHA-1, SHA-256, SHA-512> Algorithme2 utilisé pour hashPan2

Le contrôle Oppotota avant remise (gestion des cartes en opposition), permet de vérifier que la carte utilisée n’a pas été mise en opposition entre la demande d’autorisation et la validation de la transaction ou sa remise en paiement.

Ce contrôle ne s’applique qu’aux transactions CB, VISA, MASTERCARD et n’est pertinent que si vos transactions sont traitées par une banque française du réseau CB.

Le fichier des cartes en opposition est alimenté en se basant sur la liste des cartes en opposition du réseau CB. La mise à jour du fichier est effectuée plusieurs fois par jour.

Table 61. En résumé
Connecteurs disponibles Sips Paypage, Sips Office,Sips Office Batch,Sips In-App
Configuration Worldline Sips OUI Non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête NON

L’option CHALLENGE vous permet de mettre en attente les transactions dont le score est ORANGE. Ceci vous permet de vérifier le risque avant de poursuivre les autres étapes d’acceptation : validation, ré autorisation ou remise en banque.

Si vous ne disposez pas de l’option CHALLENGE la transaction est acceptée.

Vous avez X jours pour mesurer le risque de la fraude et valider ou refuser la transaction. X est la valeur maximale entre la validité de l’autorisation et le délai de capture (captureDay) que vous avez défini lors du paiement.

Une fois la vérification effectuée, si vous décidez d’accepter la transaction, vous utilisez l’opération acceptChallenge.

Attention: aucune opération ne doit déjà être en cours sur la transaction. Dans le cas contraire, un responseCode 24 est retourné (Table des responseCode).
Table 62. En résumé
Connecteurs disponibles Sips Office, Sips Office Batch, Sips Office Extranet, Merchant Extranet
Configuration Worldline Sips OUI Non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête OUI transactionReference ou s10TransactionId + s10 TransactionIdDate

Une fois la vérification effectuée, si vous décidez de refuser la transaction, vous utilisez l’opération refuseChallenge.

Attention: aucune opération ne doit déjà être en cours sur la transaction. Dans le cas contraire, un responseCode 24 est retourné (Table des responseCode).
Table 63. En résumé
Connecteurs disponibles Sips Office, Sips Office Batch, Sips Office Extranet, Merchant Extranet
Configuration Worldline Sips OUI Non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête OUI transactionReference ou s10TransactionId + s10 TransactionIdDate

La fonctionnalité de diagnostic vous permet de récupérer des informations relatives au contrôle anti-fraude d'une transaction indiquée dans votre requête via la fonction getFraudData.

Table 64. En résumé
Connecteur disponible Sips Office
Configuration Worldline Sips OUI Diagnostic non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête OUI transactionReference ou s10TransactionId + s10 TransactionIdDate

Le moteur de lutte contre la fraude s’adresse à tous les commerçants qui ont souscrit à l’offre « Gestion de la lutte contre la fraude – Business Score » et souhaitent bénéficier d’un outil de lutte contre la fraude administrée par eux-mêmes sur le Merchant Extranet.

Le moteur de lutte contre la fraude s’appuie sur des profils antifraudes afin d’évaluer les transactions. Ceux-ci sont composés de règles que vous pouvez configurer.

Pour avoir une description fonctionnelle et les modalités d’implémentation du contrôle des fraudes en ligne, veuillez consulter les documents Gestion de la lutte contre la fraude Go-No-Go et Gestion de la lutte contre la fraude Business Score.

Tip: pour la mise en œuvre de cette fonctionnalité avancée, veuillez contacter l’assistance technique.

Worldline Sips supporte 2 types d’acteurs pour utiliser les connecteurs Worldline Sips :

  • le commerçant (défaut) ;
  • une entité également appelée Intermediate Service Provider.

ISP est une entité habilitée à se connecter à Worldline Sips et à agir pour le compte des commerçants. Un ISP peut être une structure qui gère un parc de boutiques (cas fréquent dans la grande distribution) ou un hébergeur / revendeur de la solution Worldline Sips.

Pour être connecté en tant qu’ISP, vous devez en faire la demande auprès du support technique qui, si votre demande est acceptée, vous attribue un identifiant ISP qui a sa propre et unique clé sécrète applicable à l’ensemble des boutiques qu’il gère.

Cet identifiant doit être envoyé dans le champ intermediateServiceProviderId de la requête en plus de l’habituel merchantId. Au niveau sécurité, la signature des messages requêtes et réponses est faite avec la clé secrète de l’IPS et non avec celle de la boutique.

Tip: pour la mise en œuvre de cette fonctionnalité avancée, veuillez contacter l’assistance technique.
Table 65. En résumé
Connecteurs disponibles Sips Paypage, Sips Office, Sips In-App, Sips Walletpage
Configuration Worldline Sips OUI
Vérification acquéreur NON
Paramètre dans la requête de paiement OUI intermediateServiceProviderId : Identifiant de l’entité agissant en tant que commerçant

Pour plus de détails veuillez consulter le document Présentation fonctionnelle.

Le filtrage des cartes permet au commerçant de sélectionner les marques et usages qu'il souhaite accepter et qui concerne les réseaux CB, Visa et Mastercard.

Par défaut, sans l'activation de cette fonctionnalité, et si le commerçant à un contrat CB/VISA/MASTERCARD, toutes les marques et usages seront acceptées.

Les marques du réseau sélectionnables sont :
  • CB
  • VISA
  • VPAY
  • ELECTRON
  • MASTERCARD
  • MAESTRO
Les usages sélectionnables sont :
  • Crédit
  • Débit
  • Prépayé
  • Commercial
Tip: pour la mise en œuvre de cette fonctionnalité avancée, veuillez contacter l’assistance technique.

La solution Worldline Sips 2.0 en tant que solution d’acceptation de paiement, est assujettie à la réglementation européenne MIF (JO EU 2015/751 L123 du 19/05/2015). Parmi ces règles, la « Sélection de la Marque » vous impose de proposer au client porteur d’une carte cobadgée le choix de la marque au moment du paiement ce qui impacte la page de paiement.

Une carte cobadgée est une carte qui supporte au moins deux marques. La plupart des cartes émises en France sont cobadgées avec CB (carte CB/VISA, CB/MASTERCARD, CB/MAESTRO, …).

Pour la mise en œuvre de la sélection de la marque, veuillez consulter le document Intégration Carte Bancaire Nationale.

L’AVS est une fonctionnalité de lutte contre la fraude, utilisée dans certains pays comme la Grande-Bretagne. L’AVS vous permet de demander l’adresse du porteur de carte (voir les champs concernés ci-dessous), de l’envoyer dans la demande d’autorisation et de laisser l’émetteur de carte comparer cette adresse avec celle qu’il connaît.

L’AVS contient des contrôles sur la rue et le code postal.

La réponse d’une autorisation et le résultat du contrôle AVS sont indépendants, c’est-à-dire qu’il est possible que l’acquéreur approuve la demande d’autorisation avec les contrôles AVS faux.

Vous devez indipquer dans la requête les modalités de vérification des données AVS lors de l’acceptation en ligne de la transaction. Si vous indiquez que le résultat du contrôle AVS conditionne l’acceptation de la transaction alors une autorisation accordée avec un contrôle AVS échoué sera refusée par Worldline Sips. Dans ce cas, une opération de redressement (Reversal) automatique sera envoyée à l’acquéreur par Worldline Sips pour remettre à jour le plafond de la carte.

Paramètres Valeurs Note
checkAVS Y/N Indique si le contrôle AVS doit être exécuté. Désactivé par défaut.
ignorePostcodeCheckResult Y/N Ignore le résultat du contrôle du code postal (inactif par défaut)
ignoreAddressCheckResult Y/N Ignore le résultat du contrôle de la rue (inactif par défaut)
holderAddress.addressAdditional1 Adresse Contient les informations sur la rue du porteur
holderAddress.addressAdditional2 Adresse
holderAddress.addressAdditional3 Adresse
holderAddress.streetNumber Numéro
holderAddress.street Rue
holderAddress.postbox Boîte postale
holderAddress.city Ville
holderAddress.state État
holderAddress.zipCode Code postal Contient les informations sur le code postal du porteur

Les transactions refusées suite à un échec de l’AVS retournent un code réponse 14 et un code réponse acquéreur 00.

Deux codes réponses dédiés à l’AVS (avsPostcodeResponseCode and avsAddressResponseCode) vous sont retournés dans la réponse de paiement (pas encore disponible sur Sips Paypage) et présents dans le journal des transactions.

Une « Surcharge de frais » est un frais supplémentaire s’ajoutant à un paiement par chèque ou carte (les paiements en espèces ne sont pas concernés) dans le but de couvrir le coût du service d’acceptation impactant le commerçant. Elle peut être interdite par les émetteurs de carte – complètement (par exemple Visa et MasterCard aux États-Unis) – ou lorsque le commerçant applique un taux interdit. La réglementation peut autoriser ou interdire la surcharge de frais. Sans surcharge signifie qu’elle est incluse dans le prix (même en cas de paiement en espèces).

Sur Sips Paypage, la surcharge est calculée par Worldline Sips lors du paiement. Vous devez vous inscrire à l’option « Surcharge » et configurer le montant de la surcharge lié au code produit de la carte. Deux types de surcharges peuvent être appliqués : un montant fixe ou un pourcentage de la transaction. Le montant de l’autorisation envoyé à l’acquéreur est égal au montant total de la transaction + la surcharge.

Pour configurer la surcharge, vous devez fournir le « Scheme » de la carte, le code produit de la carte, la devise et le montant ou le pourcentage fixé.

Sur Sips Office, la surcharge doit être calculée par vous. Le montant total dans la requête de paiement envoyée à Worldline Sips contient la surcharge.

Le service WIP s'applique aux cartes Bancontact et apporte 2 nouvelles possibilités :

  • améliorer l'expérience utilisateur des paiements OneClick en supprimant la phase d'authentification 3-D Secure ;
  • permettre d'effectuer des paiements récurrents.

Le service s'adresse aux marchands de commerce électronique à faible risque et à volume élevé, capables de maintenir leur taux de fraude en dessous d'un certain seuil. Chaque marchand doit être approuvé par le gestionnaire du système de paiement avant d'être autorisé à accéder au service WIP.

Sips Paypage Sips Office Sips Office Batch Sips In-App Sips Walletpage
Identification des transactions
Identification à la création oui oui non non oui
Identification en gestion de caisse non oui oui non non
Identification dans le reporting oui oui non non oui
Gestion des paypages sécurisées
Personnalisation des pages de paiement oui non non non oui
Affichage des moyens de paiement oui non non non non
Affichage du ticket par Worldline Sips oui non non non non
Nombre de tentatives de paiement oui non non non oui
Nouvelle tentative de paiement oui non non non non
Durée de présence sur les pages de paiement oui non non non non
Affichage du nom de la boutique oui non non non oui
Saisie du numéro de carte en blocs séparés oui non non non oui
Saisie du nom du titulaire de la carte oui non non non oui
Affichage de la page d’erreur oui non non non non
Masquage de la saisie d’informations sensibles oui non non non oui
Affichage du message d’attente oui non non non non
Balise iframe oui non non non oui
Canal de paiement
Internet oui oui oui non non
MOTO oui oui oui non non
Application mobile non non non oui non
Modalités de remise en paiement
Paiement en fin de journée oui oui oui oui non
Paiement différé oui oui oui oui non
Paiement à l’expédition oui oui oui oui non
Paiement en plusieurs fois oui non non non non
Paiement immédiat oui oui oui oui non
Période de validité de l’autorisation oui oui oui oui non
Paiement en devises
Acceptation multidevise oui oui oui oui non
Règlement en devise oui oui oui oui non
Conversion dynamique des devises oui non non non non
3-D Secure
3D Secure oui oui non oui oui
Refus des transactions erreur 3D oui oui non oui non
Blocage des transactions non garanties 3D oui oui non oui non
Sécurisation Safekey
Sécurisation Safekey oui oui non non oui
Paiement OneClick
Enrôlement OneClick avec paiement oui non non oui non
Enrôlement OneClick sans paiement non oui oui non oui
Paiement OneClick oui oui oui oui non
Paiement par abonnement
Enregistrement de l’abonné avec 1er paiement oui non non non non
Enregistrement de l’abonné sans paiement non oui oui non oui
Paiement par abonnement non oui oui non non
Gestion de caisse
Annulation non oui oui non non
Validation non oui oui non non
Remboursement non oui oui non non
Remboursement déplafonné non oui oui non non
Duplication non oui oui non non
Duplication étendue non oui oui non non
Crédit Porteur non oui oui non non
Reporting en ligne
Diagnostic non oui non non non
Réponse manuelle oui non non non oui
Réponse automatique oui non non oui oui
Confirmation de fin de transaction vers le client oui oui oui oui non
Reporting fichier
Journal des transactions oui oui oui oui non
Journal des opérations oui oui oui oui non
Journal de rapprochement des transactions oui oui oui oui non
Journal de rapprochement des impayés oui oui oui oui non
Journal des cartes échues oui oui oui oui non
Tokenisation
Renvoi du token oui oui non non non
Tokenisation de numéros de carte non oui oui non non
Tokenisation de transaction non oui oui oui non
Détokenisation de numéro de carte non oui non non non
Paiement à partir d’un token non oui oui non non
Crédit porteur à partir d’un token non oui oui non non
Renvoi du PAN hashé oui oui non non non
Fraude
Détection de la fraude avant remise (contrôle Oppotota) oui oui oui oui non
acceptChallenge non oui oui non non
refuseChallenge non oui oui non non
Diagnostic Fraude non oui non non non
Entité agissant pour un commerçant
Intermediate Service Provider (ISP) oui oui non oui oui
Spécificité pays
Sélection de la marque (MIF) oui oui oui oui non
Service de vérification d’adresse (AVS) oui oui oui non non
Surcharge de frais oui non non non non

Fonctionnalité disponible (oui) / Fonctionnalité indisponible (non).

Oui = fonctionnalité disponible

Non = fonctionnalité indisponible

Conditionnel = fonctionnalité disponible avec spécificité, se référer au guide d'intégration du moyen de paiement en question

C : Consultation A : Annulation
V : Validation R : Remboursement
D : Duplication
Cartes / Moyens de paiement Fonctions autorisées Validité demande d’autorisation
C A V R D
CB Oui Oui Oui Oui Oui 6 jours*
Visa Oui Oui Oui Oui Oui 6 jours*
Mastercard Oui Oui Oui Oui Oui 6 jours*
American Express Oui Oui Oui Oui Oui 6 jours*
Vpay Oui Oui Oui Oui Oui 6 jours*
Maestro Oui Oui Oui Oui Oui 6 jours*
Visa Electron Oui Oui Oui Oui Oui 6 jours*
Apple Pay Oui Oui Oui Oui Non 6 jours
Bancontact Oui Non Non Oui Oui Paiement immédiat
Bancontact mobile Oui Non Non Non Non Paiement immédiat
Floa Bank CB 3X Oui Non Oui Oui Non Paiement immédiat
Floa Bank CB 4X Oui Non Oui Oui Non Paiement immédiat
CACF Oui Conditionnel Oui Non Oui 21 jours
CACF 3X Oui Oui Oui Oui Non Paiement différé
CACF 4X Oui Oui Oui Oui Non Paiement différé
Cadhoc Oui Non Non Conditionnel Non Paiement immédiat
Cadocarte Oui Non Non Conditionnel Non Paiement immédiat
Carte CUP par Floa Bank Oui Oui Oui Oui Oui 20 jours
Cetelem CPay (anciennement Cetelem Aurore) Oui Oui Oui Conditionnel Oui 60 jours
Cetelem 3X 4X CB Oui Non Non Oui Non Paiement immédiat
Chèque-Vacances Connect Oui Oui Oui Conditionnel Non Paiement différé
Cofidis Pay 5x10x20x Oui Oui Oui Oui Non 99 jours
Cofidis 3xCB Oui Oui Oui Oui Non 6 jours
Cofidis 4xCB Oui Oui Oui Oui Non 6 jours
Titres Restaurants Dématérialisés - Conecs Oui Oui Oui Conditionnel Non Paiement différé
Franfinance 3xWEB Oui Oui Oui Oui Non 99 jours
Franfinance 4xWEB Oui Oui Oui Oui Non 99 jours
Google Pay Oui Oui Oui Oui Non 6 jours
Illicado Oui Non Non Conditionnel Non Paiement immédiat
Lepotcommun Oui Non Non Conditionnel Non Paiement immédiat
Lydia Oui Non Non Oui Non Paiement immédiat
Oney 3x 4x Oui Oui Oui Oui Non 30 jours
Paybutton ING Oui Non Non Non Non Paiement immédiat
Paypal Oui Oui Oui Oui Oui 29 jours
Samsung Pay Oui Oui Oui Oui Non 6 jours
SEPA Direct Debit (SDD) Oui Oui Oui Conditionnel Oui Paiement différé
Spiritofcadeau Oui Non Non Conditionnel Non Paiement immédiat
Oney Paylater Oui Oui Oui Oui Non 30 jours

*par défaut la validité de la demande d’autorisation est à 6 jours, mais elle est aussi configurable.

Ci-dessous un tableau reprenant la programmation horaire actuelle des lancements des remises par acquéreur / privatif.

Acquéreur Heure* de début du lancement de la remise
AMEX 22h00
Armoney 22h00
Banksys 22h00
Barclays 22h00
Bancontact 05h00
BNP Paribas 22h00
Crédit Agricole Consumer Finance 19h00
Caisse Centrale Banques Populaires 22h00
Crédit Commercial de France 22h00
Crédit Du Nord 22h00
Cedicam 22h00
Cetelem Crédit 22h00
Cetelem Débit 17h00
CIC 22h00
Crédit Lyonnais 22h00
Crédit Mutuel Centre Est Europe 22h00
Crédit Mutuel de Bretagne 22h00
Caisse Nationale des Caisses d'Epargne 22h00
Cofidis 05h00
Franfinance 22h00
La Banque Postale 22h00
Natwest 22h00
Paypal 17h00
Société Générale 22h00
SPS 22h00

* les heures sont indiquées sous le fuseau horaire CET (Central European Time).

Ce site utilise des traceurs pour améliorer votre expérience de navigation, effectuer des analyses et des recherches sur votre utilisation du site web de documentation WL Sips.
En fermant ce bandeau vous refusez notre utilisation des traceurs sur votre appareil.

Paramètres