Introduction
Worldline Sips est une solution de paiement de commerce électronique multicanale sécurisée conforme à la norme PCI DSS. Elle vous permet d’accepter et de gérer des transactions de paiement en prenant en compte les règles métier liées à votre activité (paiement à la livraison, paiement différé, paiement récurrent, paiement en plusieurs fois…).
L’objectif du présent document est d’expliquer l'intégration du moyen de paiement Conecs dans Worldline Sips.
À qui s’adresse ce document ?
Ce document a pour objectif de vous aider à implémenter le moyen de paiement Conecs sur votre site de commerce électronique.
Il comprend :
- des informations fonctionnelles à votre attention ;
- des instructions d'implémentation à destination de votre équipe technique.
Pour avoir une vue d’ensemble de la solution Worldline Sips, nous vous conseillons de consulter les documents suivants :
- Présentation fonctionnelle
- Guide de configuration des fonctionnalités
Comprendre les paiements Conecs avec Worldline Sips
Principes généraux
Worldline Sips propose le moyen de paiement prépayé Conecs.
Pour payer avec Conecs :
- le client renseigne les données de son titre restaurant dématérialisé ;
- si le titre ne couvre pas la totalité du montant du panier, le client paie le complément avec sa carte bancaire.
Le paiement CB complémentaire suit nécessairement une cinématique 3-D Secure. Si le complément carte n’est pas accepté ou que l'authentification 3-D Secure n'est pas réussie, la totalité de la transaction est annulée, et la somme du titre restaurant n’est pas consommée.
Règles d’acceptation
Fonctionnalités disponibles
Canaux de paiement | ||
---|---|---|
Internet | V | Canal de paiement par défaut |
MOTO | X | |
Télécopie | X | |
SVI | X |
Typologies de paiement | ||
---|---|---|
Paiement immédiat | V | |
Paiement en fin de journée | V | Méthode par défaut |
Paiement différé | V | Limité à 6 jours. |
Paiement à l'expédition | V | Limité à 6 jours. |
Paiement en plusieurs fois | X | |
Paiement par abonnement | X | |
Paiement par fichier | X | |
Paiement OneClick | X |
Gestion des devises | ||
---|---|---|
Acceptation multidevise | X | |
Règlement en devise | X | |
Conversion dynamique des devises | X |
Pages de paiement
Le client sélectionne le moyen de paiement Conecs.
Il est ensuite redirigé vers la page de saisie des informations de son titre restaurant dématérialisé :
Si le montant de son titre restaurant n'est pas suffisant, un complément CB est demandé.
Le ticket de paiement s’affiche, puis le client retourne vers votre site Web.
Vérification de paiement
Au cours de la cinématique de paiement, il est possible que nous ne recevions pas le retour escompté (timeout), l'état de la transaction est :
- TO_CONFIRM_CAPTURE (lors d'un paiement en mode IMMEDIATE)
- TO_CONFIRM_CREDIT
Un traitement par fichier est exécuté quotidiennement pour mettre à jour ces transactions vers des états finaux :
- REFUSED
- CAPTURED
- CREDITED
Le diagramme du paragraphe Effectuer un paiement Conecs schématise ces états ainsi que les transitions.
Le statut final apparaîtra dans vos journaux des transactions pour vous permettre de continuer le traitement de la commande.
Ouvrir votre contrat d'acceptation Conecs
Afin de proposer le moyen de paiement Conecs sur votre site Web, vous devez souscrire un contrat d'acceptation auprès de Conecs. Vous nous transmettez par la suite le numéro de contrat afin de l’enregistrer dans notre système d’information.
Afin que le complément CB soit proposé au client, vous devez aussi nous transmettre votre numéro de contrat CB VADS souscrit avec votre banque.
Effectuer un paiement Conecs
Worldline Sips vous offre deux solutions pour intégrer les moyens de paiement Conecs :
- Sips Paypage qui assure l’interface de paiement directement avec le client via son navigateur Web.
- Sips Office qui vous laisse la possibilité d’afficher vous-même vos pages de paiement et qui fonctionne par un dialogue de serveur à serveur.
Les modes de remise disponibles pour une transaction Conecs sont les suivants :
- Mode annulation : mode par défaut, il permet de remiser la transaction à une date prédéfinie, appelée délai de capture. Lorsque ce délai de capture est atteint, la remise est automatiquement envoyée. Ce délai est paramétré via le champ captureDay, sa valeur par défaut est 0 (paiement en fin de journée).
- Mode validation : vous devez valider la transaction pour déclencher la remise. Un délai de capture doit aussi être défini. Lorsque ce délai de capture est atteint ou dépassé, vous ne pourrez plus valider la transaction, celle-ci expire donc automatiquement.
- Mode immédiat : l'autorisation et la remise sont exécutées en ligne simultanément.
Le diagramme ci-dessous explique les différents états par lesquels peuvent passer les transactions selon le mode de capture choisi :
Effectuer un paiement Conecs avec Sips Paypage
Le processus de paiement pour Sips Paypage est décrit ci-dessous :
Paramétrer la requête de paiement
Les champs suivants ont un comportement particulier :
Nom du champ | Remarques / règles |
---|---|
amount | minimum 100 (1€) |
captureDay | La valeur envoyée dans la requête doit être de 6 au
maximum. Une valeur supérieure sera forcée à 6. |
paymentPattern | La valeur envoyée dans la requête est ignorée. Le type
de paiement est forcé à ONE_SHOT. |
orderId | Obligatoire |
customerContact.email | Obligatoire |
Analyser la réponse
Le tableau suivant récapitule les différents cas de réponse à traiter :
État | Champs de la réponse | Action à réaliser |
---|---|---|
Paiement accepté | acquirerResponseCode = 00
authorisationId = (voir le
Dictionnaire des données).paymentMeanBrand = CONECSpaymentMeanType =
VOUCHERresponseCode =
00 |
Vous pouvez livrer la commande. |
Transaction en attente | acquirerResponseCode = (voir
le Dictionnaire des données).responseCode =
60 |
La transaction est toujours en cours de
traitement. Vous recevrez une nouvelle réponse avec un statut
définitif dans 30 minutes. |
Refus acquéreur | acquirerResponseCode = (voir
le Dictionnaire des données).responseCode =
05 |
L’autorisation est refusée pour un motif non lié à la
fraude. Si vous n’avez pas opté pour l’option « nouvelle
tentative de paiement » (pour plus de détails veuillez consulter
le Guide de configuration des
fonctionnalités), vous pouvez proposer à votre
client de payer avec un autre moyen de paiement en générant une
nouvelle requête. |
Refus nombre max essais atteint | responseCode = 75 |
Le client a fait plusieurs tentatives qui ont toutes échoué. |
Refus suite problème technique | acquirerResponseCode = 90-98
responseCode = 90, 99
|
Problème technique temporaire lors du traitement de la transaction. Proposez à votre client de refaire un paiement ultérieurement. |
Pour connaître l'intégralité des codes réponses (responseCode
) et codes réponses
acquéreur (acquirerResponseCode
), veuillez vous
référer au Dictionnaire des
données.
Effectuer un paiement Conecs avec Sips Office
Le processus de paiement pour Sips Office est décrit ci-dessous :
Initialiser un paiement (paymentProviderInitialize)
L’initialisation d’un paiement est effectuée en appelant la méthode paymentProviderInitialize.
Requête d’initialisation du paiement
Vous devez valoriser les champs spécifiques suivants dans la requête d'initialisation pour un paiement Conecs :
Nom du champ | Remarques / règles |
---|---|
merchantReturnUrl | URL de retour du commerçant. |
paymentMeanBrand | Doit être valorisé avec CONECS. |
Les champs spécifiques Conecs qui doivent être transmis sont les suivants :
Nom du champ | Remarques / règles |
---|---|
captureDay | La valeur envoyée dans la requête doit être de 6 au
maximum. Une valeur supérieure sera forcée à 6. |
paymentPattern | La valeur envoyée dans la requête est ignorée. Le type
de paiement est forcé à ONE_SHOT. |
orderId | Obligatoire |
customerContact.email | Obligatoire |
Réponse d’initialisation du paiement
Le tableau suivant récapitule les différents cas de réponse à traiter :
État | Champs de la réponse | Action à réaliser |
---|---|---|
Initialisation de paiement acceptée | acquirerNativeResponseCode =
00messageVersion = version du
message récupérée en réponse à l’initialisation du
paiement.responseCode =
00redirectionData = données de
redirection récupérées en réponse à l’initialisation du
paiement.redirectionUrl = URL de
redirection vers le site Web du moyen de paiement. |
Redirigez le client vers redirectionUrl . |
Initialisation de paiement rejetée | responseCode <>
00 |
Consultez le champ errorFieldName , puis corrigez
la requête.En cas d’erreur persistante, contactez
l'assistance technique. |
Refus acquéreur | acquirerResponseCode = (voir
le Dictionnaire des données).responseCode =
05 |
L’autorisation est refusée pour un motif non lié à la fraude, vous pouvez proposer à votre client de payer avec un autre moyen de paiement en générant une nouvelle requête. |
Refus suite problème technique | acquirerResponseCode = 90-98
responseCode = 90, 99
|
Problème technique temporaire lors du traitement de la transaction. Proposez à votre client de refaire un paiement ultérieurement. |
Pour connaître l'intégralité des codes réponses (responseCode
) et codes réponses
acquéreur (acquirerResponseCode
), veuillez vous
référer au Dictionnaire des
données.
Rediriger le client vers le site Web du moyen de paiement
Le client doit être redirigé vers l’URL redirectionUrl fournie en réponse de la méthode paymentProviderInitialize. Cette redirection consiste à effectuer un appel POST sur l’URL redirectionUrl obtenue dans la réponse à l’initialisation de paiement. Les paramètres POST à transmettre sont redirectionData et messageVersion obtenus également dans la réponse à l’initialisation de paiement.
A la fin de la cinématique de paiement, le client est redirigé sur l’URL fournie dans la requête d’initialisation, merchantReturnUrl. Les champs suivants sont transmis en POST et doivent être récupérés pour finaliser le paiement :
Nom du champ | Remarques / règles |
---|---|
responseCode | Code réponse du processus |
redirectionData | Données de redirection récupérées en réponse à l’initialisation du paiement. |
messageVersion | Version du message récupérée en réponse à l’initialisation du paiement. |
amount | Montant de la transaction en centimes |
merchantId | Identifiant de la boutique |
transactionReference | Référence de la transaction |
transactionId | Identifiant de la transaction |
transactionDate | Date de la transaction |
Finaliser un paiement (PaymentProviderFinalize)
Cette dernière étape vous permet d’obtenir le statut du paiement. Les paramètres obtenus lors de la redirection après la cinématique de paiement sur le site Web du moyen de paiement sont à transmettre lors de cet appel. La méthode utilisée pour finaliser un paiement est paymentProviderFinalize.
Requête de finalisation du paiement
Vous devez fournir les champs spécifiques suivants dans la requête de finalisation pour un paiement CONECS.
Nom du champ | Remarques / règles |
---|---|
redirectionData | Données de redirection récupérées au retour du client vers votre site Web (voir Rediriger le client vers le site Web du moyen de paiement). |
messageVersion | Version du message récupérée au retour du client vers votre site Web (voir Rediriger le client vers le site Web du moyen de paiement). |
Réponse de finalisation du paiement
The following table summarises the different response cases to be processed:
État | Champs de la réponse | Action à réaliser |
---|---|---|
Paiement accepté | acquirerResponseCode =
00authorisationId = (voir le
Dictionnaire des données).acquirerResponseMessage =
informations sur les montants payés par chacun des moyens de
paiement.Format = champ1:champ2:[...]champ7 champ1
= SPLIT champ2 = nom du moyen de paiement
prépayé champ3 = référence partenaire du paiement
prépayé champ4 = montant payé avec le moyen de paiement
prépayé champ5 = moyen de paiement
complémentaire champ6 = PAN masqué champ7 =
montant payé avec le moyen de paiement
complémentaire paymentMeanBrand = CONECSresponseCode =
00transactionStatus = (voir le
Dictionnaire des données). |
Vous pouvez livrer la commande. |
Refus acquéreur | acquirerResponseCode = (voir
le Dictionnaire des données).responseCode =
05 |
L’autorisation est refusée pour un motif non lié à la fraude, vous pouvez proposer à votre client de payer avec un autre moyen de paiement en générant une nouvelle requête. |
Refus suite problème technique | acquirerResponseCode = 90-98
responseCode = 90, 99
|
Problème technique temporaire lors du traitement de la transaction. Proposez à votre client de refaire un paiement ultérieurement. |
Pour connaître l'intégralité des codes réponses (responseCode
) et codes réponses
acquéreur (acquirerResponseCode
), veuillez vous
référer au Dictionnaire des
données.
Gérer vos transactions
Opérations de caisse disponibles
Les opérations suivantes sont disponibles sur les transactions Conecs :
Gestion de caisse | ||
---|---|---|
Annulation | V | |
Validation | V | Validation possible sur le montant partiel de la transaction. |
Remboursement | V | Remboursement possible uniquement sur la partie CB sur le montant partiel de la transaction et sur les montants supérieurs au montant initial (remboursement illimité). |
Duplication | X | |
Crédit | X |
Le diagramme ci-dessous vous permet de savoir quelle opération de gestion de caisse est disponible lorsqu’une transaction est dans un état donné :
Consulter vos transactions
Journaux
Les journaux mis à disposition par Worldline Sips vous permettent d’avoir une vision exhaustive et consolidée de vos transactions, opérations de caisse, situation comptable et impayés. Vous pouvez utiliser ces informations pour enrichir votre système d’information.
La disponibilité des transactions Conecs pour chaque type de journal est récapitulée dans le tableau ci-dessous :
Disponibilité des journaux | |
---|---|
Journal des transactions | V |
Journal des opérations | V |
Journal de rapprochement des transactions | X |
Journal de rapprochement des impayés | X |
Sips Office Extranet
Vous pouvez consulter le détail de vos transactions Conecs et effectuer différentes opérations de gestion de caisse grâce à Sips Office Extranet.