Release 24.5

aller directement au contenu

Rechercher par mots clés

Intégration CACF_3X CACF_4X

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

Sherlock's 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 des moyens de paiement CACF_3X et CACF_4X dans Sherlock's.

Ce document a pour objectif de vous aider à implémenter les moyens de paiement CACF_3X et CACF_4X 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 Sherlock's, nous vous conseillons de consulter les documents suivants :

  • Présentation fonctionnelle
  • Guide de configuration des fonctionnalités

Le moyen de paiement CACF est un moyen de paiement privatif proposé par des grandes enseignes de la distribution, ayant pour acquéreur exclusif le Crédit Agricole en France.

Les moyens de paiement CACF_3X et CACF_4X sont des moyens de paiement de crédit en plusieurs fois, avec ou sans frais.

A l'issu d'un paiement de ce type, vous êtes crédité du montant en une fois, et le porteur sera débité en 3 ou 4 fois (suivant le moyen de paiement choisi).

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 X
Paiement en fin de journée V
Paiement différé V
Paiement à l'expédition V
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

Le client sélectionne l'un des moyens de paiement entre CACF_3X, CACF_4X, CACF_3XSANSFRAIS ou CACF_4XSANSFRAIS.

Il est ensuite redirigé vers la page de la saisie des informations requises :


Capture d'écran montrant les champs de saisie des données personnelles

Capture d'écran montrant les champs de saisie des données personnelles telles que la date de naissance ou le numéro de mobile ainsi qu'un récapitulatif de paiement avec le détail des échéances choisies. Cette page contient un bouton Valider pour passer à l'étape suivante.


Capture d'écran montrant les champs de saisie pour les données de paiement

Capture d'écran montrant les champs de saisie pour les données de paiement contenant le numéro de carte, la date de validité et le cryptogramme visuel.Cette page contient un bouton Valider pour passer à l'étape suivante ainsi qu'un bouton Annulation pour arreter le paiement.

Le ticket de paiement s’affiche, puis le client retourne sur votre site Web :


page de validation des conditions precontractuelles

Capture d'écran de la page de validation des conditions precontractuelles. Le récapitulatif de paiement y est aussi affiché.

Afin de proposer le moyen de paiement CACF_3X et CACF_4X sur votre site Web, vous devez souscrire un contrat d'acceptation auprès de Crédit Agricole Consumer Finance. Vous nous transmettez par la suite le numéro de contrat afin de l’enregistrer dans notre système d’information.

Sherlock's vous offre deux solutions pour intégrer CACF_3X et CACF_4X :

  • Sherlock’s Paypage qui assure l’interface de paiement directement avec le client via son navigateur Web.
  • Sherlock’s 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 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.

Le diagramme ci-dessous explique les différents états par lesquels peuvent passer les transactions selon le mode de capture choisi :


Diagramme du processus de paiement.

La transaction est passée en mode Validation avec un capture_mode Validation ou un mode Annulation avec un capture_mode Author_capture. Avec un response_code 00, on recupère un statut To Validate en mode Validation ou un statut To capture en mode Annulation. Avec un response_code 17, le statut est Aborted. Pour tous les autres codes, le statut est Refused.

La cinématique de paiement pour Sherlock’s Paypage est décrite ci-dessous :


Cinématique de paiement avec Paypage

1- Le client procède au paiement (finalisation de la commande) 2- Redirection du client vers la page de paiement 3- Redirection vers la page du moyen de paiement 4- Retour du client vers Sips (finalisation du paiement) 5- Le client est redirigé vers le site marchand (réponse manuelle) 6- Le moteur Sips envoie une réponse automatique vers le site marchand

Les champs suivants ont un comportement particulier :

Nom du champ Remarque / règles
captureDay La valeur envoyée dans la requête doit être de 8 au maximum.
Une valeur supérieure sera forcée à 8.
customerLanguage Permet de choisir la langue utilisée sur les pages Sherlock's et CACF.
orderId Obligatoire
customerId Obligatoire
amount Obligatoire
deliveryData.deliveryMethod Facultatif (Se rapprocher de Thunes pour obtenir la liste exhaustive des valeurs.)
customerContact Pour plus de détails, voir les tableaux ci-dessous
billingContact Pour plus de détails, voir les tableaux ci-dessous
billingAddress Pour plus de détails, voir les tableaux ci-dessous
deliveryAddress Pour plus de détails, voir les tableaux ci-dessous
shoppingCartDetail Pour plus de détails, voir les tableaux ci-dessous
CustomerAccountHistoric Pour plus de détails, voir les tableaux ci-dessous
CustomerData Pour plus de détails, voir les tableaux ci-dessous
Nom du champ Remarque / règles
customerContact.email Obligatoire
customerContact.title Facultatif
customerContact.firstname Obligatoire
customerContact.lasttname Obligatoire
customerContact.mobile Facultatif
customerContact.phone Facultatif
Nom du champ Remarque / règles
billingContact.title Obligatoire {0,4} ANS (exemple : MR / MME / MLLE …)
billingContact.firstname Obligatoire
billingContact.lastname Obligatoire
billingContact.mobile Obligatoire
billingContact.phone Obligatoire
Nom du champ Remarque / règles
billingAddress.street Obligatoire
billingAddress.streetNumber Obligatoire
billingAddress.zipCode Obligatoire
billingAddress.city Obligatoire
billingAddress.country Obligatoire
billingAddress.addressAdditional1 Obligatoire
Nom du champ Remarque / règles
deliveryAddress.street Facultatif
deliveryAddress.addressAdditional1 Facultatif
deliveryAddress.city Facultatif
deliveryAddress.zipCode Facultatif
Nom du champ Remarque / règles
shoppingCartDetails.shoppingCartItemList.itemX.productCategory Facultatif
shoppingCartDetails.shoppingCartItemList.itemX.productName Facultatif
shoppingCartDetails.shoppingCartItemList.itemX.productQuantity Facultatif
shoppingCartDetails.shoppingCartItemList.itemX.productUnitAmount Facultatif
Nom du champ Remarque / règles
customerAccountHistoric.numberOfPurchase Facultatif
customerAccountHistoric.creationDate Facultatif
customerAccountHistoric.lastPurchaseDate Facultatif
customerAccountHistoric.numberOfUncancelledPurchase Facultatif
customerAccountHistoric.numberOfScoringCancelledPurchase Facultatif
Nom du champ Remarque / règles
customerData.loyaltyIndicator Facultatif

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 = CACF_3X ou CACF_4X
paymentMeanType = ONELINE_CREDIT
responseCode = 00
Vous pouvez livrer la commande.
Transaction en attente acquirerResponseCode = (voir le Dictionnaire des données).
responseCode = 60
Vous devez attendre de recevoir la seconde réponse automatique pour cette transaction afin de connaître son statut final et savoir si vous pouvez expédier la marchandise. Si vous ne recevez pas la réponse automatique, vous devrez consulter régulièrement les journaux des transactions.
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.

Le processus de paiement pour Sherlock’s Office est décrit ci-dessous :


Cinématique de paiement avec Office

1- Le client procède au paiement (finalisation de la commande) 2- Le commerçant initialise le paiement (PaymentProviderInitialize) 3- Le commerçant redirige le client (redirectionUrl) 4- Le client est redirigé vers le site du commerçant (merchantReturnUrl) 5- Le commerçant finalie le paiement (PaymentProviderFinalize) 6- Le commerçant affiche le résultat du paiement

L’initialisation d'un paiement CACF_3X et CACF_4X est effectuée en appelant la méthode PaymentProviderInitialize.

Les champs génériques suivants sont définis dans le cas d’une initialisation de paiement:

Nom du champ Remarques / règles
merchantReturnUrl URL de retour du commerçant.
paymentMeanBrand Doit être valorisé avec CACF_3X ou CACF_4X.

Vous devez valoriser les champs spécifiques suivants dans la requête d'initialisation pour un paiement CACF_3X ou CACF_4X :

Nom du champ Remarque / règles
orderId Obligatoire
customerId Obligatoire
customerContact.email Obligatoire
customerLanguage Permet de choisir la langue utilisée sur les pages Sherlock's et CACF.
billingContact.title Obligatoire {0,4} ANS (exemple : MR / MME / MLLE …)
billingContact.firstname Obligatoire
billingContact.lastname Obligatoire
billingContact.mobile Obligatoire
billingContact.phone Obligatoire
billingAddress.street Obligatoire
billingAddress.streetNumber Obligatoire
billingAddress.zipCode Obligatoire
billingAddress.city Obligatoire
billingAddress.country Obligatoire

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 = 00
messageVersion = version du message récupérée en réponse à l’initialisation du paiement.
responseCode = 00
redirectionData = 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.

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

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.

Tip: vous pouvez, en réponse à votre requête paymentProviderFinalize, obtenir un code 24 « Opération impossible ». Ce code signifie que cette requête a déjà été envoyée et traitée pour la transaction concernée. Si vous ne pouvez identifier ce traitement, nous vous invitons à utiliser la fonction GetTransactionData du service diagnostic : cette opération permet de récupérer des informations relatives à une transaction créée préalablement à l'aide de Sherlock's.

Vous devez fournir les champs spécifiques suivants dans la requête de finalisation pour un paiement CACF_3X ou CACF_4X.

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

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 = CACF_3X ou CACF_4X
responseCode = 00
transactionStatus = (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.

Les opérations suivantes sont disponibles sur les transactions CACF_3X et CACF_4X :

Gestion de caisse
Annulation V
Validation V
Remboursement V
Duplication 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é :


Diagramme décrivant les opérations de caisse possibles sur les transactions.

Pour une transaciton en statut To Validate, soit elle expire soit on la valide et elle passe à To Capture. Quand la transaction est à To Capture, on peut faire une annulation partielle et le restant à débiter reste au statut To Capture. On peut aussi annuler totalement et la trasanction passe au statut Cancelled. Sans action sur la transaction elle passe au statut Captured. Dès lors qu'elle est au statut Captured, on peut rembourser partiellement et la transaction reste au statut Captured; on peut aussi la rembourser totalement et la transaction passe au statut Credited.

Les journaux mis à disposition par Sherlock's 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 CACF_3X et CACF_4X 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 V
Journal de rapprochement des impayés V
Note: pour les transactions CACF_3X et CACF_4X, le champ paymentMeanBrand est renseigné avec les CACF_3X ou CACF_4X.

Vous pouvez consulter vos transactions CACF_3X et CACF_4X et effectuer différentes opérations de gestion de caisse grâce à Sherlock's Gestion.

Voici le détail d'une transaction CACF_3X :


détail de la transaction

Capture du détail de la transaction indiquant que dans le champ Moyen de paiement on récupère CACF 3X ou CACF 4X
Retourner en haut de page Besoin d'aide ?

Besoin d'aide ?

Fermer

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

Paramètres