WL SIPS DOCS

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

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

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

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

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

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

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

Différents cas sont possibles :

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.

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

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

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

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

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

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

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

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

et

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

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

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

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

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 :

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.

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.

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

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

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

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

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.

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 :

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

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.

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

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

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

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.

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.

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

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

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

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

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

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

    • La première demande d’autorisation d'un petit montant, appelée l’empreinte, pour vérifier la carte lors de l’acceptation en ligne.
    • La deuxième demande d’autorisation pour le montant réel avant la remise en paiement.

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

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

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

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

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

Les moyens de paiement supportant ce mode sont les suivants :

• Bancontact
• Bancontact mobile
• BCACB 3X 4X
• Cadhoc
• Cadocarte
• Carte Cadeau Oney
• Cetelem 3X 4X CB
• Cetelem Presto
• Chèque-Vacances Connect
• CONECS
• iDEAL
• Illicado
• Lepotcommun
• Lydia
• Paybutton ING
• Spiritofcadeau

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

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

Mode fichier :

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

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

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.

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

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

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

1. vous devez gérer le prix de vos ventes en ligne en plusieurs devises ;
2. lorsque vous soumettez la transaction au serveur Worldline Sips, vous renseignez la devise que vous désirez dans le champ currencyCode ;
3. la transaction est envoyée pour autorisation et pour la remise du paiement avec le même code de devise ;
4. lors de l’acquisition du paiement, l’acquéreur convertit la transaction dans votre devise de règlement.

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.

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

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

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

• souscrire un contrat d’acquisition avec l’option DCC ;
• souscrire à un service de taux de change ;
• demander l’option DCC lors de l’inscription au service Worldline Sips.

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

Deux cas d’usages sont possibles :

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

Les contrôles suivants sont effectués :

• vous disposez du droit d’annulation. Dans le cas contraire un responsCode 40 est retourné ;
• la transaction existe dans notre base de données. Dans le cas contraire un responseCode 25 est retourné ;
• la transaction est au statut "TO_CAPTURE" ou "TO_VALIDATE" ou "TO_AUTHORIZE" ou "TO_CHALLENGE". Dans le cas contraire un responseCode 24 est retourné. Vous pouvez consulter les heures de remise par acquéreur / privatif en Annexe 3 ;
• le montant à annuler est égal ou inférieur au montant de la transaction. Dans le cas contraire un responseCode 51 est retourné ;
• aucune opération de caisse n'est déjà en cours sur la transaction. Dans le cas contraire, un responseCode 24 est retourné.

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

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

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

Les contrôles suivants sont effectués :

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

• aucune opération de caisse n'est déjà en cours sur la transaction. Dans le cas contraire, un responseCode 24 est retourné.

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 .

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.

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

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

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

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

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

Les contrôles suivants sont effectués :

• vous disposez du droit de duplication. Dans le cas contraire un responseCode 40 est retourné;
• la transaction existe dans notre base de données. Dans le cas contraire un responseCode 25 est retourné;
• le moyen de paiement utilisé est compatible et permet la duplication. Dans le cas contraire, un responseCode 24 est retourné ;
• la date d’expiration du moyen de paiement est toujours valide. Dans le cas contraire, un responseCode 14 est retourné ;
• la demande d’autorisation est acceptée pas l’acquéreur et un responseCode 00 a été obtenu.

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

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

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

Les contrôles suivants sont effectués :

• contrôles identiques que ceux effectués pour une duplication standard ;
• la boutique effectuant la duplication est paramétrée avec le droit de duplication étendue. Dans le cas contraire, un responseCode 40 est retourné.

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.

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.

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

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.

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.

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

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

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

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

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

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

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

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.

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

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

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

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

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.

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

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

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

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

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

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.

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.

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.

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

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

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