Introduction

Ce document est un guide de configuration des fonctionnalités de WL 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 WL 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 et Business Score ,
  • Implémentation des moyens de paiement,
  • Personnalisation des pages de paiement,
  • Paiement OneClick ,
  • Paiement par abonnement .

Disponibilité des moyens de paiement par interface

Interfaces
Moyens de paiement
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
AcceptGiro oui non non non oui
Bancontact oui oui non oui oui
Bancontact mobile oui oui non oui non
BCACB_3X oui non non non non
BCACB_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 Casino BCACUP non oui non non non
Carte Oney oui oui oui non oui
Carte Cadeau Oney oui oui non non non
Cetelem CPay (anciennement Cetelem Aurore) oui non non non non
Cetelem 3X 4X CB oui non non non oui
Cetelem Presto oui non non non non
Chèque-Vacances Connect oui oui non non non
Cofidis 1euro.com oui non non non non
Cofidis 3xCB oui non non non non
Cofidis 4XCB oui non non non non
Cofinoga oui oui oui non non
Cofinoga 3XCB oui non non non non
Titres Restaurants Dématérialisés - Conecs oui oui non non non
China Union Pay oui non non non non
Diners oui non non non non
e-Chèques Vacances oui oui non non non
Facily Pay oui non non non non
Franfinance 3XWEB oui non non non non
Franfinance 4XWEB oui non non non non
Giropay oui non non non non
iDEAL (anciens contrats) oui oui non non non
iDEAL (nouveaux contrats) oui non non non non
Illicado oui oui non non non
Incasso oui non non non non
Japan Credit Bureau oui non non non non
Lepotcommun oui oui non non non
Lydia oui oui non non non
Lyf Pay oui non non non non
Masterpass
(pour usage futur)
oui oui non non non
Oney 3x 4x oui non non non non
Paybutton ING oui non non non non
Paybutton KBC/CBC Online oui non non non non
Paylib oui oui non non non
PayPal oui oui non non oui
Paytrail oui non non non non
Passcadeau oui oui non non non
Rembours oui non non non non
SEPA Direct Debit (SDD) oui oui oui non non
Sofortüberweisung oui oui non non non
Spiritofcadeau oui oui non non non
Visa Checkout oui oui non oui non

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

Mise en œuvre des fonctionnalités

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

  • Configuration WL Sips : l’activation ou la désactivation de la fonctionnalité nécessite un changement de configuration sur la plateforme WL 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.

Gestion de la clé secrète

Fonctionnement

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 WL 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 .

Expiration de la clé secrète

Afin d'assurer la conformité avec la norme PCI DSS, un système d'alerting est mis en place afin de vous avertir que votre clé secrète arrive à expiration et ainsi la renouveler via l'interface Sips Download . Cet alerting se fait en 3 étapes par l'envoi de 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 mails d'alerte. Pour cela, merci de contacter notre support technique.

Ce process d'alerting 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é.

Mode d’identification des transactions

Deux modes d’identification des transactions sont disponibles sur WL 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 WL Sips le générer automatiquement et vous le récupérez dans la réponse
Note: 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.

Identification à la création

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

Différents cas sont possibles :

Table 1. Boutique en mode TransactionReference - Le commerçant se connecte à WL 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 WL 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 WL Sips s10TransactionId s10TransactionIdDate s10TransactionId s10TransactionIdDate s10TransactionId s10TransactionIdDate
Contenu réponse s10TransactionId s10TransactionIdDate transactionReference s10TransactionId s10TransactionIdDate transactionReference
Table 2. Boutique en mode TransactionReference - Le commerçant se connecte à WL Sips sans transactionReference (Tref auto)
Données Création de transaction via :
Sips Paypage Sips Office Sips Office Extranet
transactionReference généré par WL Sips Traitement standard N/A généré par WL 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 WL Sips transactionReference s10TransactionId s10TransactionIdDate transactionReference s10TransactionId s10TransactionIdDate
Contenu réponse s10TransactionId s10TransactionIdDate transactionReference
Table 3. Boutique en mode TransactionId - Le commerçant se connecte à WL 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 WL 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 WL Sips transactionReference transactionReference transactionReference
Contenu réponse s10TransactionId s10TransactionIdDate transactionReference s10TransactionId s10TransactionIdDate transactionReference
Table 4. Boutique en mode TransactionId - Le commerçant se connecte à WL Sips sans transactionId (Tid auto)
Données Création de transaction via :
Sips Paypage Sips Office Sips Office Extranet
transactionId généré par WL Sips Traitement standard N/A généré par WL 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 WL Sips s10TransactionId s10TransactionIdDate TransactionReference s10TransactionId s10TransactionIdDate TransactionReference
Contenu réponse s10TransactionId s10TransactionIdDate transactionReference

Identification en gestion de caisse

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.

Table 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, recyclage et crédit porteur ) Voir Tableau de création des transactions ci-dessus
Table 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, recyclage et crédit porteur ) Voir Tableau de création des transactions ci-dessus

Identification dans le reporting

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 les opérations de duplication et de recyclage, la transaction d’origine est identifiable via les champs s10FromTransactionId, s10FromTransactionIdDate et fromTransactionReference du journal des transactions.

Gestion des paypages

Personnalisation des pages

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

Affichage des moyens de paiement

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

Note: l'affichage de la page de sélection des moyens de paiement WL 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.

WL 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é, WL 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 WL 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

Affichage du ticket par WL Sips

La page de confirmation du paiement, appelée « ticket de paiement », est affichée par défaut par WL 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 WL Sips .

Table 8. En résumé
Connecteur disponible Sips Paypage
Configuration WL Sips OUI Affichage du ticket WL 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.

Nombre de tentatives de 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 :

Table 9. En résumé
Connecteurs disponibles Sips Paypage , Sips Walletpage
Configuration WL 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

Nouvelle tentative de paiement

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.

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

Notification en cas d’erreur

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 WL Sips OUI
Vérification acquéreur NON
Paramètre dans la requête de paiement NON

Durée de présence sur les pages de paiement

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 WL Sips . Le point de départ de ce délai débute à l’arrivée du client sur la page de paiement WL Sips .

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

Affichage du nom de la boutique

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

Table 13. En résumé
Connecteurs disponibles Sips Paypage , Sips Walletpage
Configuration WL 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

Saisie du numéro de carte en blocs séparés

La saisie du numéro de carte peut être divisée par bloc de 4 numéros. Dans le cas d’Amex et 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 WL 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

Saisie du nom du titulaire de la carte

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 WL 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

Affichage de la page d’erreur lors de l’initialisation

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).

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 WL 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 WL 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.

Masquage de la saisie d’informations sensibles

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 WL 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

Affichage du message d’attente

Un message d’attente peut être intégré à la procédure de paiement après la validation du paiement par l’acheteur.

Table 19. En résumé
Connecteur disponible Sips Paypage
Configuration WL Sips OUI Affichage du message d’attente non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête de paiement NON

Balise iFrame

Les pages de paiement WL 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 WL Sips . Pour plus d’informations, veuillez consulter le guide d’utilisation Sips Paypage iFrame.

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

Canal de paiement

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.

Internet

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

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

OUI orderChannel : INTERNET

MOTO

Dans le cas du canal MOTO (Mail Order 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.

Table 22. En résumé
Connecteurs disponibles Sips Paypage , Sips Office , Sips Office Batch
Configuration WL 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

SVI (Serveur Vocal Intéractif)

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 23. En résumé
Connecteurs disponibles Sips Office , Sips Office Batch
Configuration WL 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

Application mobile

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 24. En résumé
Connecteur disponible Sips In-App
Configuration WL Sips OUI
Vérification acquéreur NON Assimilé au canal Internet
Paramètre dans la requête de paiement OUI orderChannel : INAPP

Modalités de remise en paiement

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.

Paiement en fin de journée

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, WL 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 25. En résumé
Connecteurs disponibles Sips Paypage , Sips Office , Sips Office Batch , Sips In-App
Configuration WL 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)

Paiement différé

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 et 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 3D Secure : pour bénéficier du transfert de responsabilité lors d'une transaction 3D 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, WL 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, WL 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, WL 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, WL 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, WL Sips surcharge le champ captureDay.

Table 26. En résumé
Connecteurs disponibles Sips Paypage , Sips Office , Sips Office Batch , Sips In-App
Configuration WL 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)
Note: la demande de renseignement est une évolution réglementaire de CB, VISA et MASTERCARD qui remplace la prise d'empreinte. Cette fonctionnalité est soumise à la conformité de l’acquéreur.

Paiement à l’expédition

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, WL Sips le surcharge avec la modalité de paiement par défaut.

Table 27. En résumé
Connecteurs disponibles Sips Paypage , Sips Office , Sips Office Batch , Sips In-App
Configuration WL 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)

Paiement en plusieurs fois

Vous disposez de 2 techniques pour mettre en oeuvre le paiement en plusieurs fois :

  • via une requête de paiement vers l'interface Sips Paypage
  • via plusieurs requêtes de duplication

  1. Paiement en plusieurs fois via Sips Paypage

    Les informations détaillées sur les échéances doivent être renseignées dans la requête de paiement.

    Règles et conseils de mise en oeuvre

    • les champs captureMode et captureDay ne sont pas pris en considération dans le cadre du paiement en plusieurs fois;
    • les transactions des échéances (rang 1 à N) sont remisées automatiquement en fin de journée lors de l'expiration des échéances;
    • si votre contrat acquéreur et votre boutique sont configurés avec le 3-D Secure, alors le premier paiement bénéficie de la garantie de paiement. Ce paiement est garanti 6 jours . Si la première échéance indiquée dans le champ instalmentDate.datesList va au-delà du 6ème jour après la collecte des coordonnées de paiement, celle-ci sera automatiquement ramenée à 6 jours afin que vous puissiez bénéficier de la garantie de paiement. Les échéances suivantes (rang 2 à N) ne sont pas soumises à cette règle et ne bénéficient donc pas de la garantie de paiement;
    • le premier élément du champ instalmentData.transactionReferencesList doit être égal au champ transactionReference de la requête;
    • la somme des montants des échéances (champ instalmentData.amountList ) doit être égale au montant de la requête (champ amount );
    • les dates de chaque échéance doivent être uniques;
    • la période entre la première et dernière échéance ne peut pas dépasser la durée légale du paiement sans frais, imposée par l'offre distributeur;
    • les dates de l'échéancier D1, D2, DN doivent être transmises dans l'ordre chronologique;
    • vous avez la possibilité de représenter une échéance refusée via l'opération de duplication.

    Pages de paiement

    Si vous transmettez une requête de type "paiement en plusieurs fois ", seuls les moyens de paiement compatibles avec le paiement en plusieurs fois sont proposés au client (par exemple, si vous acceptez le moyen de paiement Ideal et que vous transmettez une requête de type "paiement en plusieurs fois " , le moyen de paiement Ideal ne sera pas proposé au client).

    La page de saisie des informations du moyen de paiement contient les détails du paiement selon le nombre d’échéances :

    • affichage de chaque date et montant, si moins de 5 échéances :

    • affichage du nombre d'échéances, des dates de début et fin des opérations, si plus de 5 échéances

    À la fin du processus, le ticket le détail des échéances

    Journaux

    Les Journaux reprennent toutes les échéances associées aux transactions après l’acceptation de la 1ère échéance :

    • Les N transactions sont présentées dans le journal des transactions,
    • Les demandes d’autorisation soumises au moment des échéances sont présentées dans le journal des opérations,
    • Si les transactions sont rapprochées avec le flux d’acquisition, elles apparaissent dans le journal de rapprochement des transactions et/ou dans le journal de rapprochement des impayés

    Contrôles effectués

    Le moyen de paiement doit être valide à la date de la dernière échéance (par exemple, dans le cas des cartes, la date d’expiration doit être postérieure à la dernière échéance). Dans le cas contraire, le paiement est refusé.

    Table 28. En résumé
    Connecteurs disponibles Sips Paypage
    Configuration WL Sips OUI
    Vérification acquéreur NON
    Paramètres dans la requête de paiement OUI
    • paymentPattern : INSTALMENT
    • instalmentData.number : Nombre d’échéances (>=2)
    • instalmentData.datesList : Liste des échéances
    • instalmentData.transactionReferencesList : Liste des références des transactions
    • instalmentData.amountsList : Liste des montants correspondant aux échéances

  2. Paiement en plusieurs fois avec la duplication

    L'échéancier de paiement doit nécessairement être affiché sur les pages de votre site E-Commerce, juste avant de rediriger le client sur Sips Paypage pour le paiement de la première échéance.

    La première échéance est payée via Sips Paypage , le champ paymentPattern doit être valorisé à RECURRING_1 ou ONE_SHOT* (valeur par défaut), le champ amount avec le montant de la prémière échéance.

    A chaque échéance ultérieure, vous dupliquez la transaction de la première échéance.

    Table 29. En résumé
    Connecteurs disponibles Sips Office , Sips Office Batch , Sips Office Extranet
    Configuration WL Sips OUI
    Vérification acquéreur NON
    Paramètres dans la requête de paiement OUI
    • amount : montant de l'échéance

    (*) Néanmoins, comme à ce jour il n’existe pas de contrôle par les serveurs d’autorisation émetteur, la transaction initiale n’a pas obligation à être de type RECURRING_1.

Paiement immédiat

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, WL 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 :

  • Carte Cadeau Oney
  • Bancontact
  • Cetelem 3X 4X CB
  • Cetelem Presto
  • Cofinoga 3XCB
  • Giropay
  • iDEAL
  • Paybutton ING
  • Paybutton KBC/CBC Online
  • PayPal
  • Paytrail
  • Sofortüberweisung
Table 30. En résumé
Connecteurs disponibles Sips Paypage , Sips Office , Sips Office Batch , Sips In-App
Configuration WL Sips NON
Vérification acquéreur NON
Paramètre dans la requête de paiement OUI
  • captureMode : IMMEDIATE
  • captureDay : 0

Paiement par fichier

Le paiement par fichier est un échange d’informations en temps différé (en mode fichier) entre vous et WL 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é WL Sips .

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

Mode fichier :

  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é WL Sips  ;
  3. WL 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 à WL Sips  ;
  5. WL 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é WL Sips  ;
  6. Vous récupérez le fichier « réponse » via votre compte FTP sécurisé WL 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 31. En résumé
Connecteurs disponibles Sips Office Batch
Configuration WL Sips OUI
Vérification acquéreur NON
Paramètre dans la requête de paiement N/A

Durée de validité de l’autorisation

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 32. En résumé
Connecteurs disponibles Sips Paypage , Sips Office , Sips Office Batch , Sips In-App
Configuration WL 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

Paiement en devises

Acceptation multidevise

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 WL 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 33. En résumé
Connecteurs disponibles Sips Paypage , Sips Office , Sips Office Batch , Sips In-App
Configuration WL Sips OUI Les devises acceptées doivent être définies dans la configuration WL 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.

Règlement en devise

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.

Note: pour la mise en œuvre de cette fonctionnalité avancée, veuillez contacter l’assistance technique.
Table 34. En résumé
Connecteurs disponibles Sips Paypage , Sips Office , Sips Office Batch , Sips In-App
Configuration WL Sips OUI Les devises acceptées doivent être définies dans la configuration WL 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.

Conversion dynamique des devises (DCC)

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 WL Sips
Note: pour la mise en œuvre de cette fonctionnalité avancée, veuillez contacter l’assistance technique.
Table 35. En résumé
Connecteur disponible Sips Paypage
Configuration WL Sips OUI Les devises acceptées doivent être définies dans la configuration WL 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

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 et AMEX.

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

Authentification 3-D Secure du client dissociée du paiement

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

Deux cas d’usages sont possibles :

  • Vous transmettez votre requête d’authentification vers WL 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 WL 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

Sécurisation SafeDebit SDD

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

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é.

Note: 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 36. En résumé
Connecteurs disponibles Sips Paypage , Sips Office Extranet , Sips Office et Sips Walletpage
Configuration WL 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

Paiement récurrent

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 et SDD.

Sécurisation 3DS des paiements récurrents carte

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

Traiter les paiements récurrents en respectant les exigences PCI

La solution WL 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é…)

Paiement récurrent via duplication

Lors du 1er paiement , vous indiquez dans la requête qu’il s’agit du 1er paiement d’une récurrence.

Table 37. En résumé
Connecteurs disponibles Sips Paypage , Sips Office , Sips Office Batch , Sips In-App , Sips Office Extranet
Configuration WL Sips OUI Non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête de paiement OUI paymentPattern : RECURRING_1 pour le 1er paiement ou ONE_SHOT* (valeur par défaut)
Reporting

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

(*) Néanmoins, comme à ce jour il n’existe pas de contrôle par les serveurs d’autorisation émetteur, la transaction initiale n’a pas obligation à être de type RECURRING_1.

Pour les Nème paiements , vous dupliquez la transaction initiale via son identifiant transactionId ou transactionReference.

Table 38. En résumé
Connecteurs disponibles Sips Office , Sips Office Batch , Sips Office Extranet
Configuration WL Sips OUI Non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête de paiement NON
Reporting

  • Journal des transactions : OUI
  • Journal des opérations : NON
  • Sips Office Extranet : OUI
Note: la transaction initiale est échue au bout de 18 mois il faut donc toujours utiliser la référence (transactionId ou transactionReference) la plus récente. Vous devez aussi être attentif à la date de validité de la carte associée à la transaction initiale.

Paiement récurrent via wallet

Le paiement récurrent via Wallet est la solution WL 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 de la carte dans le wallet lors d’un paiement Sips Paypage

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

Table 39. En résumé
Connecteur disponible Sips Paypage
Configuration WL 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 pour le 1er paiement ou ONE_SHOT* (valeur par défaut)
Reporting

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

(*) Néanmoins, comme à ce jour il n’existe pas de contrôle par les serveurs d’autorisation émetteur, la transaction initiale n’a pas obligation à être de type RECURRING_1.

Enregistrement de la carte dans le wallet via Sips Walletpage hors contexte de paiement

Via l’interface Walletpage, vous pouvez demander à votre client de créer un wallet par l’ajout de son numéro de carte ou de son identifiant de mandat.

Table 40. En résumé
Connecteur disponible Sips Walletpage
Configuration WL 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 : Liste des moyens de paiements parmi CB, VISA, MASTERCARD et SEPA_DIRECT_DEBIT
Reporting

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

Enregistrement de la carte dans le wallet via la méthode addCard de Sips Office hors contexte paiement

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

Table 41. En résumé
Connecteurs disponibles Sips Office ,
Configuration WL Sips OUI Option wallet
Vérification acquéreur OUI Option recurring
Paramètre dans la requête OUI
  • merchantWalletID : identifiant du wallet
  • cardNumber : Numéro de carte
  • cardExpirayDate : Date d’expiration de la carte
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 42. En résumé
Connecteurs disponibles Sips Office ,
Configuration WL 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

En fonction du moyen de paiement stocké dans le wallet, WL Sips va générer un paiement carte ou un paiement SDD.

Table 43. En résumé
Connecteurs disponibles Sips Office , Sips Office Batch
Configuration WL Sips OUI Non activé par défaut
Vérification acquéreur OUI Option recurring
Paramètre dans la requête OUI
  • paymentPattern : RECURRING_N
  • merchantWalletID : identifiant du wallet dans lequel est stocké le PAN ou le mandat
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.

Paiement récurrent via token

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 WL Sips . En réponse vous recevez un token que vous utiliserez pour les paiements récurrents futurs.

Table 44. En résumé
Connecteurs disponibles Sips Paypage , Sips Office , Sips Office Batch , Sips In-App , Sips Office Extranet
Configuration WL Sips OUI Option Token
Vérification acquéreur OUI Option recurring
Paramètre dans la requête de paiement OUI paymentPattern : RECURRING_1 pour le 1er paiement ou ONE_SHOT* (valeur par défaut)
Reporting

  

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

(*) Néanmoins, comme à ce jour il n’existe pas de contrôle par les serveurs d’autorisation émetteur, la transaction initiale n’a pas obligation à être de type RECURRING_1.

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

Table 45. En résumé
Connecteurs disponibles Sips Office , Sips Office Batch
Configuration WL Sips OUI Option Token
Vérification acquéreur OUI Option recurring
Paramètre dans la requête

paymentPattern

OUI
  • 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
Reporting

  

  • Journal des transactions : OUI
  • Journal des opérations : NON
  • Sips Office Extranet : OUI
Note: 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.

Paiement OneClick

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 .

Gestion de caisse

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.

Annulation

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 sera 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 46. En résumé
Connecteurs disponibles Sips Office , Sips Office Batch , Sips Office Extranet
Configuration WL 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

Validation

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 « à remiser » ( transactionStatus = TO_CAPTURE), à l’état « en attente d’une validation avec demande d’autorisation » ( transactionStatus = TO_REPLAY) ou à 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é;
  • 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 47. En résumé
Connecteurs disponibles Sips Office , Sips Office Batch , Sips Office Extranet
Configuration WL 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.

Remboursement

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é.
Note: vous retrouvez l’ensemble des codes réponse dans le dictionnaire des données ici .
Table 48. En résumé
Connecteurs disponibles Sips Office , Sips Office Batch , Sips Office Extranet
Configuration WL 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

Remboursement déplafonné

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 49. En résumé
Connecteurs disponibles Sips Office , Sips Office Batch , Sips Office Extranet
Configuration WL 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

Duplication

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 WL 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.
Note: vous retrouvez l’ensemble des codes réponse dans le dictionnaire des données ici .
Table 50. En résumé
Connecteurs disponibles Sips Office , Sips Office Batch , Sips Office Extranet
Configuration WL 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

Duplication étendue

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 WL 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 51. En résumé
Connecteurs disponibles Sips Office , Sips Office Batch ,
Configuration WL 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

Recyclage

Cette fonctionnalité vous permet de générer plusieurs remises en paiement d’une même transaction autorisée. Cette fonction permet notamment de gérer l’envoi en plusieurs lots d’une même commande en ne facturant le client que lors de l’expédition de chaque produit.

Comme pour la duplication, vous créez une transaction à partir d’une transaction existante mais il y a une différence essentielle entre recyclage et duplication :

  • Pour le recyclage, le montant est limité au montant résiduel (non encore envoyé en paiement) de la transaction initiale,

Dans le cas où la demande d’autorisation de la transaction initiale n’est plus valide (délai dépassé), alors la transaction est dupliquée avec une nouvelle demande d’autorisation (comme pour la duplication standard), mais cette duplication n’est possible que dans les limites du montant qui restait à percevoir.

Vous pouvez recycler une transaction plusieurs fois, tant que le montant initial non réglé n’est pas atteint. Il n’est pas possible de recycler une transaction recyclée.

Les contrôles suivants sont effectués :

  • Vous disposez du droit de recyclage. 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 est compatible et permet le recyclage. Dans le cas contraire, un responseCode 24 est retourné ;
  • Le statut de la transaction sur laquelle est effectuée l’opération est au statut « CAPTURED ». Dans le cas contraire, un code refus 24 est retourné ;
  • Le montant à recycler est inférieur ou égale à ce qui est autorisé. Dans le cas contraire un responseCode 51 est retourné ;
  • La demande d'autorisation est acceptée pas l’acquéreur et un responseCode 00 a été obtenu.
Note: vous retrouvez l’ensemble des codes réponse dans le dictionnaire des données ici .
Table 52. En résumé
Connecteurs disponibles Sips Office , Sips Office Batch , Sips Office Extranet
Configuration WL Sips OUI Non activé par défaut
Vérification acquéreur NON
Reporting

  

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

Crédit porteur

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, WL Sips la traduit en un refus pour carte ou compte invalide et renvoie un responseCode 14. Dans le cas d'une réponse positive, WL Sips envoie la demande d’autorisation avec le montant réel du crédit.
Table 53. En résumé
Connecteurs disponibles
  • creditHolder : Sips Office , Sips Office Batch , Sips Office Extranet
  • walletCreditHolder : Sips Office , Sips Office Batch
Configuration WL 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)

Reporting en ligne

Diagnostic

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 54. En résumé
Connecteur disponible Sips Office
Configuration WL 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

Réponse manuelle

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 55. En résumé
Connecteurs disponibles Sips Paypage , Sips Walletpage
Configuration WL Sips NON
Vérification acquéreur NON
Paramètre dans la requête

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

Réponse automatique

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 56. En résumé
Connecteurs disponibles Sips Paypage , Sips In-App , Sips Walletpage ,
Configuration WL 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)

Confirmation de fin de transaction vers le client

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.

Note: pour la mise en œuvre de cette fonctionnalité avancée (notification par SMS), veuillez contacter l’assistance technique.
Table 57. En résumé
Connecteurs disponibles Sips Paypage , Sips Office , Sips Office Batch , Sips In-App
Configuration WL 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

Reporting fichier

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 58. En résumé
Connecteurs disponibles Sips Paypage , Sips Office , Sips Office Batch , Sips In-App , Sips Walletpage
Configuration WL 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.

Tokenisation

Le token est un numéro partagé par le commerçant et WL 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.
Note: pour la mise en œuvre de cette fonctionnalité avancée, veuillez contacter l’assistance technique.

Renvoi du token

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.

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

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

Blocage de la transaction en cas d’erreur de tokenisation

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

Table 60. En résumé
Connecteurs disponibles Sips Paypage , Sips Office
Configuration WL 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.

Tokenisation de numéro de carte

Cette fonctionnalité crypte 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.

Table 61. En résumé
Connecteurs disponibles Sips Office , Sips Office Batch
Configuration WL 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

Tokenisation de transaction

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 62. En résumé
Connecteurs disponibles Sips Office , Sips Office Batch
Configuration WL 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

Détokenisation

Cette fonctionnalité décrypte 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.

Table 63. En résumé
Connecteurs disponibles Sips Office
Configuration WL 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 : Numéro de carte à convertir en token

Paiement à partir d’un 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 .

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 64. En résumé
Connecteurs disponibles Sips Office , Sips Office Batch
Configuration WL 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

Crédit porteur à partir d’un token

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 65. En résumé
Connecteurs disponibles Sips Office , Sips Office Batch
Configuration WL 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

Renvoi du PAN hashé

À 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) hashé (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 hashage.

WL 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 66. En résumé
Connecteurs disponibles Sips Paypage
Configuration WL 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

Fraude

Détection de la fraude avant remise

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 67. En résumé
Connecteurs disponibles Sips Paypage , Sips Office , Sips Office Batch , Sips In-App
Configuration WL Sips OUI Non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête NON

Gestion du résultat du scoring

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.

acceptChallenge

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 68. En résumé
Connecteurs disponibles Sips Office , Sips Office Batch , Sips Office Extranet , MEX
Configuration WL Sips OUI Non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête OUI transactionReference ou s10TransactionId + s10 TransactionIdDate

refuseChallenge

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 69. En résumé
Connecteurs disponibles Sips Office , Sips Office Batch , Sips Office Extranet , MEX
Configuration WL Sips OUI Non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête OUI transactionReference ou s10TransactionId + s10 TransactionIdDate

Diagnostic fraude

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 70. En résumé
Connecteur disponible Sips Office
Configuration WL 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

Contrôles de fraude en ligne

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 MEX .

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 .

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

Intermediate Service Provider (ISP)

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

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

ISP est une entité habilitée à se connecter à WL 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 WL 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.

Note: pour la mise en œuvre de cette fonctionnalité avancée, veuillez contacter l’assistance technique.
Table 71. En résumé
Connecteurs disponibles Sips Paypage , Sips Office , Sips In-App , Sips Walletpage
Configuration WL 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.

Spécificités pays

France

Sélection de la marque (MIF)

La solution WL 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.

Grande Bretagne

Service de vérification d’adresse (AVS)

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 indiquer 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 WL Sips . Dans ce cas, une opération de redressement (Reversal) automatique sera envoyée à l’acquéreur par WL 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.

Surcharge de frais

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 WL 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 à WL Sips contient la surcharge.

Account Updater Service

L’objectif du service Account Updater & Stop Service, qui a été lancé par les émetteurs et acquéreurs est de répondre au problème suivant : les cartes physiques sont régulièrement réémises et il est facile pour un commerçant de perdre la trace des informations des porteurs de carte.

Ce service :

  • Fournira aux commerçants un moyen automatique de mettre à jour les informations carte de leurs clients, leur permettant ainsi d’améliorer les autorisations et règlements de leur paiements récurrents,
  • Aidera à minimiser les risques d’impayés,
  • Permettra aux porteurs de demander un ‘stop payments’ via les émetteurs.

Pour bénéficier de ce service vous devez :

  • Souscrire au service fourni par WL Sips si votre acquéreur est compatible,
  • Mettre en œuvre une connexion FTP avec WL Sips pour le transfert de fichier,
  • Envoyer les requêtes appropriées aux « schemes » via WL Sips avant d’effectuer des transactions récurrentes,
  • Effectuer des demandes d’autorisation pour toutes vos transactions récurrentes,
  • Effectuer la transaction initiale dans un environnement sécurisé (c’est-à-dire avec CVV2 ou code PIN).

Pour plus d’informations, veuillez consulter le document Account updater service.

Belgique

Programme ARP

ARP est l’appellation employée dans WL Sips pour les solutions MARP ( Mastercard Advanced Registration Program ) et MUPP ( Mastercard Utility Payment Program ) de Mastercard.

L’objectif de cette fonction est de proposer le contournement automatique du processus 3D-Secure si la carte a déjà passé le premier contrôle de sécurité 3D (dans le cadre du même contrat avec l’acquéreur). Ainsi, le parcours de paiement est simplifié pour les titulaires de confiance.

Le processus 3D-Secure est déclenché lors du premier paiement avec la carte. Le paiement suivant avec la même carte (dans le cadre du même contrat) sera identifié comme une transaction ARP et le processus 3D Secure ne s’affichera pas.

Dans le cas d’un paiement où l’authentification 3D est contourné par l’ARP, le champ “HolderAuthentProgram” est valorisé à ARP dans les réponses.

Les conditions d’utilisation d’ARP sont les suivantes :

  • Vous devez souscrire au programme 3D Secure,
  • L’option ARP doit être activée dans WL Sips ,
  • Il doit s’agir d’une carte MasterCard ou Maestro,
  • Votre acquéreur est conforme ARP.
Table 72. En résumé
Connecteurs disponibles Sips Paypage
Configuration WL Sips OUI Non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête de paiement NON

ANNEXES

Annexe 1 : Tableau récapitulatif des fonctionnalités disponibles par interface

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 WL 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
3D Secure
3D Secure oui oui non oui oui
débrayage dynamique du 3-D Secure oui non non non oui
débrayage dynamique du 3-D Secure pour les paiements OneClick oui non non non non
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
Forçage non non non non non
Recyclage 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
Programme ARP (Advance registration program) oui non non non non

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

Annexe 2 : Tableau de validité de la demande d’autorisation et des fonctions autorisées par moyen de paiement

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*
AcceptGiro Oui Non Non Non Non Paiement différé
Bancontact Oui Non Non Oui Non Paiement immédiat
Bancontact mobile Oui Non Non Non Non Paiement immédiat
BCACB_3X Oui Non Oui Oui Non Paiement immédiat
BCACB_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 Casino BCACUP Oui Oui Oui Oui Oui 20 jours
Carte Oney Oui Oui Oui Oui Oui Paiement différé
Carte Cadeau Oney Oui Non Non Oui Oui Paiement immédiat
Cetelem CPay (anciennement Cetelem Aurore) Oui Oui Oui Conditionnel Oui 60 jours
Cetelem 3X 4X CB Oui Non Non Oui Non Paiement immédiat
Cetelem Presto Oui Conditionnel Non Non Non Paiement immédiat
Chèque-Vacances Connect Oui Non Non Conditionnel Non Paiement immédiat
Cofidis 1euro.com Oui Oui Oui Oui Non 99 jours
Cofidis 3xCB Oui Oui Oui Oui Non 8 jours
Cofidis 4xCB Oui Oui Oui Oui Non 8 jours
Cofinoga Oui Oui Oui Oui Oui 15 jours
Cofinoga 3xCB Oui Non Non Oui Non Paiement immédiat
Titres Restaurants Dématérialisés - Conecs Oui Non Non Conditionnel Non Paiement immédiat
China Union Pay Oui Non Non Oui Non Paiement immédiat
Diners Oui Non Non Oui Non Paiement immédiat
e-Chèques Vacances Oui Non Non Conditionnel Non Paiement immédiat
Facily Pay Oui Oui Conditionnel Conditionnel Non 30 jours
Franfinance 3xWEB Oui Oui Oui Oui Non 99 jours
Franfinance 4xWEB Oui Oui Oui Oui Non 99 jours
Giropay Oui Non Non Non Non Paiement immédiat
iDeal Oui Non Non Oui Non Paiement immédiat
Illicado Oui Non Non Conditionnel Non Paiement immédiat
Incasso Oui Non Non Non Non Paiement différé
Japan Credit Bureau Oui Non Non Oui Non Paiement immédiat
Lepotcommun Oui Non Non Conditionnel Non Paiement immédiat
Lydia Oui Non Non Oui Non Paiement immédiat
Lyf Pay Oui Oui Oui Oui Non 30 jours
Masterpass Oui Oui Oui Oui Oui 6 jours
Oney 3x 4x Oui Oui Oui Oui Non 30 jours
Paybutton ING Oui Non Non Non Non Paiement immédiat
Paybutton KBC/CBC Online Oui Non Non Non Non Paiement immédiat
Paylib Oui Oui Oui Oui Conditionnel 6 jours
Paypal Oui Oui Oui Oui Oui 29 jours
Paytrail Oui Non Non Non Non Paiement immédiat
Passcadeau Oui Non Non Conditionnel Non Paiement immédiat
Rembours Oui Non Non Non Non Paiement différé
SEPA Direct Debit (SDD) Oui Oui Oui Conditionnel Oui Paiement différé
Sofortüberweisung Oui Non Non Conditionnel Non Paiement immédiat
Spiritofcadeau Oui Non Non Conditionnel Non Paiement immédiat
Visa Checkout Oui Oui Oui Oui Oui 6 jours*

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

Annexe 3 : Tableau récapitulatif des heures de remise par acquéreur / privatif

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
Cofinoga 22h00
Diners 22h00
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).