Contenu
Sommaire | ||||
---|---|---|---|---|
|
Comment configurer votre compte ?
Vous devez vous rapprocher de votre responsable de compte ou d'un commercial pour la création de ce moyen de paiement.
Monext Online réalise toute la configuration.
Inclusion d'extrait | ||||||
---|---|---|---|---|---|---|
|
Une fois votre le nom de l’alias du numéro de contrat créé alors le moyen de paiement est disponible.
Vous devez réaliser des transactions 'pilote' pour valider le bon fonctionnement en production.
Le code (card_code) du moyen de paiement est : CASINO_3XCB ou CASINO_4XCB
Pour ces deux moyens de paiement, il est indispensable de renseigner 4 informations :
- Identifiant STS
- Mot de passe STS
- Identifiant commerçant
- Identifiant site commerçant
- Si le contrat souscrit est un contrat 3DS ou non
Comment proposer le paiement FLOA 3x / 4x à vos clients ?
Le mode d'intégration est disponible avec l'API WebPayment : services doWebPayment et getWebPaymentDetail.
Le mode d'intégration en API direct avec la fonction 3DS est disponible.
Les principes d’utilisation
Au moment du doWebPayment, Payline réalise une demande d'éligibilité de paiement avant de proposer le moyen de paiement 3x ou 4x.
Payline affiche les conditions de crédit : échéancier et CGV.
Payline peut remplir les champs la date de naissance, département et nom de jeune fille s'ils sont fournis par le commerçant.
Le moyen de paiement ne s'affiche pas si le score n'a pu être réalisé. L'échéancier s'affiche même en cas de données personnelles manquantes.
Les paiements FLOA 3x/4x sont éligibles au traitement par le module anti-fraude Payline, au même titre que les autres transactions.
Si une authentification 3DSecure est nécessaire, Payline gère l’affichage de la page ACS. Seul un refus banque (FICP ou acquéreur) peut conduire à un refus du paiement.
La fonction getWebPaymentDetail renvoie l’échéancier sélectionné par l'acheteur.
Le marchand a la possibilité de modifier le montant de la commande après que le paiement ait été accepté. Le montant doit être inférieur ou égal à celui de la commande initiale .
La référence commande doit être différente a chaque paiement : balise order.ref
Extrait | ||
---|---|---|
| ||
Script JavaScript : En mode widget et mode redirection, le marchand doit intégrer un .JS theatmetrix sur sa page de paiement. Il faut également vérifier : Le domaine. ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Bonjour, Suite à la PAYSUP 12879 et à la PAYLANO-4450, il y aurait quelques modifications et précisions à apporter à la documentation Casino 3/4xCB. En effet, cette partie est erronée et à modifier :
Pour ThreatMetrix, les équipes technique m'ont confirmé, que c'est le WIDGET qui se charge d'insérer le script dans la page.
Merci pour vos actions, Cordialement,
--- Script JavaScript En mode widget et mode redirection, le marchand doit intégrer un .JS theatmetrix sur sa page de paiement <script type="text/javascript" src="https://cb4x.payline.com/tags.js?org_id=b0st0pm3&pageid=1&session_id=OrderRef-ScoringToken-PaymentAttempt"> </script> <iframe src="https://cb4x.payline.com/tags.js?org_id=b0st0pm3&pageid=1&session_id=OrderRef-ScoringToken-PaymentAttempt" style="width: 100px; height: 100px; border: 0; position: absolute; top: -5000px;"> </noscript> A verifier : Les certificats SSL : pour que l'envoi de données à ThreatMetrix soit transparent, la génération d'un certificat SSL à partir du CSR fourni par CB4X devra être effectué par Payline. Une fois obtenu, il sera communiqué au processeur pour intégration sur leur loadBalancer. |
Les web services en mode Web
LesInitier le paiement
- Les services doWebPayment et getWebPaymentDetail sont disponibles.
- L'object Payment sera transmis par le commerçant avec les valeurs Action = 101 et Mode = CPT.
Récupérer le résultat
- Le
- service getWebPaymentDetail retourne l'échéancier : champ transaction.partnerAdditionalData avec
paymentSchedule
. Cette fonction implique l'utilisation d'une baliseversion
avec une valeur>= 16
.
Les web services en mode Direct
Le mode d'intégration en API direct est disponible en utilisant le webservice webservice isRegistered. Ce service vous permet de récupérer le scoring data nécessaire pour appeler le moyen de paiement Floa.
Vous récupérez un registrationToken à renvoyer dans la demande de 3D Secure verifyEnrollment puis dans la demande de paiement doAuthorization.
En entrée le commerçant indique le contrat, le montant, commande et les données personnelles.
En retour, il reçoit un l'échéancier de paiement dont les frais de dossier et le registrationToken qui le registrationToken qui permettra de réaliser le paiement.
Les étapes
:- Sur le site marchand, le consommateur valide son panier, puis le marchand appelle Payline
- avec le service isRegistered.
- Payline retourne un code 02500 - Accepter pour valider la demande et renvoie
- le registrationToken ainsi qu'une balise data contenant un objet JSON avec l'
- échéancier paymentSchedules et le montant totalAmount.
- Puis il renvoie le jeton registrationToken dans la balise payment en appelant le verifyEnrollment pour réaliser le 3D Secure
- .
- Le consommateur saisie son mot de passe reçu par mobile
- .
- Le marchand réalise la demande de
- paiement doAuthorization
- avec registrationToken dans la balise
- payment et les données 3DS
- .
- Payline réalise la requête et la réponse du l'autorisation et renvoie une notification.
Lorsque un doAuthorization ou un verifyEnrollment verifyEnrollment est réalisé avec la balise registrationToken demandé qui est absente, vide ou incorrectement valorisée.
L'erreur suivante est remontée par le service : code 02999, short_message ERROR, long_message 'Invalid registration token'.
Exemples de web services
1. Branchement de la demande de scoring : isRegistered
2. Branchement du 3DS : verifyEnrollment
3. Branchement de la demande d'autorisation : doAuthorization
Authentification 3D Secure
Les paiements sont éligibles au traitement par le module anti-fraude Payline, au même titre que les autres transactions.
Si une authentification 3DSecure est nécessaire, Payline gère l’affichage de la page ACS. Seul un refus banque (FICP ou acquéreur) peut conduire à un refus du paiement.
Les champs obligatoires
Les champs obligatoires doivent être renseignés lors de la demande de paiement, dans le cas contraire la demande sera refusée.
En complément des données obligatoires pour obtenir un paiement, vous devez transmettre les données obligatoires suivantes :
dans le tableau ci-dessous.
Les prérequis sont définis par leurs types d'utilisation :
- Mode web
doWebPayment : fonctionnement éligibilité (mode automatiquement réalisé par Monext).
- Mode direct
- doAuthorization : fonctionnement éligibilité.
isRegistered : fonctionnement pré-éligibilité.
Object | Balise | Requis Eligibilité | Requis Pré-éligibilité | Description |
---|---|---|---|---|
Order.country | Valeur FR (= FRANCE) | |||
Order.deliveryMode | Voir valeurs possibles entre 1 et 5. | |||
Order.reference | Format à respecter |
|
Order.date |
Format : dd/mm/yyyy HH24:MI | |||
Order.Amount | L'order amount est le montant global de la commande. Le |
champs order.amount doit |
être égal au payment.amount. |
currency | Valeur |
valeurs possibles. | |||
Buyer.lastname | Information de l'acheteur. | ||
Buyer.firstname | Information de l'acheteur. | ||
Buyer.email | Information de l'acheteur. | ||
Buyer.birthDate | Information de l'acheteur. | ||
Buyer.phoneType |
Information de l'acheteur. Voir |
Buyer.phone |
Information de l'acheteur. | |||
Buyer.billingAdress.title | Information de l'acheteur. Voir valeurs possibles. | ||
Buyer.billingAdress.lastname | Information de l'acheteur. | ||
Buyer.billingAdress.firstname | Information de l'acheteur. | ||
Buyer.billingAdress.street1 | Information de l'acheteur. | ||
Buyer.billingAdress.city | Information de l'acheteur. | ||
Buyer.billingAdress.zipcode | Information de l'acheteur. | ||
Buyer.billingAdress.country | Information de l'acheteur. | ||
Buyer.ip |
Doit être vide. | ||||||||||||||||||||||||||||
PrivateData |
|
Transmission des données
clientsacheteurs
Pour transmettre les données 3DS, OTA, champs libre et historique, vous devez utiliser la balise <miscData> du doWebPayment en version 18 ou supérieure.
- Cette balise prend en compte un object JSON formaté qui sera retransmis à Floa.
- Les données OTA doivent être référencées par le numéro de contrat auquel elles font référence. Ces données sont facultatives.
- Les balises <![CDATA[ ... ]]> ne sont pas obligatoires.
Le numéro de contrat contenu dans le JSON doit être un numéro de contrat présent dans les balises selectedContractList ou secondSelectedContractList du service doWebPayment appelé.
S'ils ne sont pas non présent une erreur 'Invalid contractNumber' est levée avec le code retour 02303.
Le JSON doit être bien formaté de la manière suivante :
- { "ContractNUMBER" : "Contenu JSON ..." }
avec { "CASINO_3XCB" : "{'optionalTravelDetails':{...}" , 'additionalNumericFieldList':{...}" , 'additionalTextFieldList':{...}" , 'MerchantCustomerHistory'
:{...}" , }Exemple miscData :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<
impl:miscData
>
<![CDATA[
{ "ContratVAD": :{...}" , }
Exemple de code :
miscData
>
Données de scoring Floa
Les données contenues dans le JSON correspondent aux données du service Score de Floa:
optionalTravelDetails
additionalNumericFieldList
additionalTextFieldList
MerchantCustomerHistory :
Champs | Description | Format |
---|---|---|
CanceledOrderAmount | Montant total en centimes des commandes annulées durant les 2 dernières années | Integer |
CanceledOrderCount | Nombre de commandes effectuées puis annulées par le client durant les 2 dernières années | Integer |
FirstOrderDate | Date de la première commande du client Format AAAA-MM-JJ | DateTime |
FraudAlertCount | Nombre d’alertes de fraude concernant les commandes du client durant les 2 dernières années | Integer |
LastOrderDate | Date de la dernière commande du client Format AAAA-MM-JJ | DateTime |
PaymentIncidentCount | Nombre d’incidents de paiement concernant les commandes du client durant les 2 dernières années | Integer |
RefusedManyTimesOrderCount | Nombre de commandes dont le paiement en plusieurs fois a été refusé au cours des 2 dernières années | Integer |
UnvalidatedOrderCount | Nombre de commandes refusées dans la phase de validation au cours des 2 dernières années | Integer |
ValidatedOneTimeOrderCount | Nombre de commandes ayant été réglées en 1 fois au cours des 2 dernières années | Integer |
ValidatedOrderCount | Nombre de commandes validées ces 2 dernières années. | Integer |
Comment réaliser des tests ?
Vous devez demander un compte de test ainsi que des cartes de test à Banque FLOA.
Pour pouvoir faire des tests sur l'API, vous pouvez utiliser la carte de test ci-dessous :
Numéro | 5017670000001800 |
---|---|
CVV | 000 |
Date d'expiration | > à la dernière échéance |
Les codes de retour
Inclusion d'extrait | ||||||
---|---|---|---|---|---|---|
|
Développer | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||
|
Exemples de trame
Tab Content Wrapper | ||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Pages associées
Contenu par étiquette | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...