Contenu
Sommaire | ||
---|---|---|
|
Extrait | ||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||
Le tableau ci-dessous liste les dernières modifications effectuées sur ce document.
|
Caractéristiques principales
Contenu des fichiers
Les fichiers comportent le détail des transactions selon les options de recherche choisies par le commerçant.
Ils peuvent être générés pour tous les clients qui souscrivent à cette option.
Un fichier CSV est généré à partir du contenu du système d'information de Payline.
Format des fichiers
Le format de génération du fichier est de type CSV en encodage ISO 8859-1.
Un exemple dans le format de fichier est fourni en fin de document
La structure du fichier au format CSV se présente sous cette forme : nom des colonnes, liste détaillées des transactions.
Génération des fichiers
Dans le Centre Administration de l'application Payline, le commerçant peut créer des modèles de structure et générer le fichier d'export des transactions au format CSV dans le menu « Transactions de paiement » puis « Exporter vos transactions ».
La structure présente dans ce document décrit le format de fichier généré en automatique.
Options de recherche
Le commerçant peut sélectionner les critères suivants :
- le point de vente pour lequel il souhaite exporter les transactions parmi la liste de tous ses points de ventes visibles dans une liste déroulante du formulaire.
- la période durant laquelle ont été effectuées les transactions. Trois choix de périodes sont disponibles :
- une plage de date, choisie par le commerçant en saisissant une date de début et une date de fin, la période doit être inférieure à 31 jours.
- la semaine dernière : la semaine précédente la recherche.
- le mois dernier : le mois précédent la recherche.
- le type de transactions : autorisation + validation, autorisation, commande, validation, annulation, ré-autorisation, remboursement, crédit, débit.
- l'état de la transaction : acceptée ou refusée
- .
Vous pouvez consulter la documentation du centre administration pour réaliser un modèle d'export ou un export.
Données facultatives
Les données privées
Ce sont les informations personnelles d'un commerçant, structurées sous la forme d'un tableau de données avec une clef et sa valeur associée. La clef (KEY_N) permet de filtrer les transactions de paiement d'un commerçant et la valeur (VAL_N) est une valeur associée à la clef. Ce tableau de données peut contenir entre 0 et 100 occurrences de données privées associéeassociées à une transaction.
Les détails de la commande
Ce sont les détails d'une commande, les informations sur les articles commandés, structurés sous la forme d'un tableau pouvant contenir entre 0 et 100 occurrences. Chaque occurrence du tableau contient les éléments suivants :
- la référence de l'article
- le prix de l'article dans la plus petite unité de la devise
- la quantité d'articles
- un commentaire
Transfert des fichiers
Le fichier CSV peut-être transmis au client par l'un des moyens suivants :
- transfert de fichiers CFT, FTPS, SFTP via réseau IP (dans ce cas un lien doit être mis en place entre le client et Payline)
- transfert depuis le centre d'administration (téléchargement HTTPS)
Transfert de fichiers automatique
La diffusion par CFT, SFTP, FTPS s'effectue automatiquement vers un serveur du client, Payline supporte les modes PUSH (Payline va déposer le fichier sur le serveur du client) ou GET (Le client vient récupérer le fichier sur les serveurs de Payline).
Transfert depuis le centre d'administration
Le commerçant peut récupérer les fichiers en cliquant dans l'encart « Récapitulatif des fichiers créés » puis sélectionner le fichier voulu. Ce transfert s'effectue en HTTPS.
Le fichier d'export suit la règle de nommage suivante : « IDCOMMERCANT_DATEDEBUT-DATEFIN » où :
- IDCOMMERCANT correspond au numéro d'identifiant du point de vente.
- DATEDEBUT correspond à la date de début de la période au format JJMMAAAA.
- DATEDEBUT correspond à la date de début de la période au format JJMMAAAA.
Format des fichiers
Ce paragraphe décrit le format des fichiers liste des transactions CSV.
Règles générales du format
- fichier de type ISO 8859-1 ;
- une ligne d'entête indiquant le nom de la donnée exportée ;
- une ligne par transaction ;
- le nombre de donnée exportée par ligne dépend des options d'export choisies (données privées et/ou détail de la commande) ;
- le séparateur de champ du fichier CSV est le point-virgule (';') ;
- le caractère d'échappement pour les caractères de contrôle (ici les guillemets et le point virgule) est le back slash ('\') ;
- toutes les colonnes sont entourés de double guillemet ;
- le séparateur décimal des numériques est le point ('.').
Plage de données
exportésexportée
Par souci de performance, Seul l'export CSV de données historisées est possible. Les exports CSV pourront donc être lancés a partir des données de la veille.
De plus, on limite la plage des données recherchées à un mois. C'est-à-dire que la période des données exportées sera de 31 jours maximum (nombre de jours entre la première transaction et la dernière transaction).
Les recherches peuvent être réalisées sur les 11 derniers mois glissant.
Nommage du fichier
- La règle de nommage par défaut est : FIC_CSV=${Version_J}${DATE_FIC}${MERCHANT_ID}.csv
- Avec :
- Version_J = Numéro de version du jour
- DATE_FIC = Date au format ddmmyy
- MERCHANT_ID = merchant ID
Exemple : 100_260315_4240xxxxxxxxxx.csv
Structure du fichier CSV
La structure du fichier CSV est standard :
- le nom des colonnes est sur la 1ère ligne
- puis nous avons la liste des transactions détaillées
Chaque enregistrement correspond à une opération :
Nom de colonne |
---|
N° col
Lg max
Id | Type | Longueur | Format | Moyen de paiement |
---|
Valeur ou description | ||||||
---|---|---|---|---|---|---|
MERCHANT_ID | 1 | R | 16 | N | Identifiant commerçant. | |
CORPORATE_NAME | 2 | R | 30 | AN | Enseigne du commerçant. | |
POINT_OF_SELL_LABEL | 3 | R | 40 | AN | Libellé du point de vente. | |
CONTRACT_NUMBER | 4 | R | 20 | AN | Numéro de contrat utilisé lors de la transaction. | |
CONTRACTS_SELECTED | 5 |
C | 255 | AN | Liste des contrats proposée à l'acheteur. La liste est concaténée et chaque valeur séparée par des slashs |
'/'. | ||||||
TRANSACTION_AMOUNT | 6 | R | 12 | N | Montant de la transaction. | |
TRANSACTION_CURRENCY_CODE | 7 | R | 3 | AN |
Le code ISO-4217 (3 lettres) de la devise associée au paiement. | ||||||
ACTION | 8 | R | 30 | AN | Type de la transaction :
| |
PMODE | 9 | R | 3 | AN | Mode de |
paiement (CPT, DIF, NX ou REC).
| ||||||
DIFFERED_ACTION_DATE | 10 | C | 8 | AN | Date souhaitée de validation du paiement. | |
ORDER_REFERENCE | 11 | R | 50 | AN | Référence de la commande. | |
ORDER_ORIGIN | 12 | F | 50 | AN | Origine de la commande. | |
ORDER_COUNTRY_CODE | 13 | F | 3 | AN | Le code du pays dans lequel la commande a |
été effectuée. | ||||||
ORDER_AMOUNT | 14 | R | 12 | N | Le montant de la commande dans la plus |
petite unité de la devise. | |||
ORDER_CURRENCY_CODE | 15 | R | 3 |
AN | Le code ISO-4217 (3 lettres) de la devise |
associée à la |
commande |
ORDER_DATE | 16 | R | 18 | AN | La date de la commande chez le commerçant. | |
BUYER_LAST_NAME | 17 | F | 100 | AN | Nom de l'acheteur. | |
BUYER_FIRST_NAME | 18 | F | 100 | AN | Prénom de l'acheteur. | |
BUYER_EMAIL | 19 | F | 150 | AN | Adresse email de l'acheteur. | |
ADDRESS_NAME | 20 | F | 100 | AN | Nom |
de l' |
adresse. | ||||||
ADDRESS_STREET_1 | 21 | F | 100 | AN | Nom de rue. | |
ADDRESS_STREET_2 | 22 | F | 100 | AN | Complément du nom de rue. | |
ADDRESS_CITY_NAME | 23 | F | 40 | AN | Ville. | |
ADDRESS_ZIP_CODE | 24 | F | 20 | AN | Code postal. | |
BUYER_PHONE | 25 | F | 15 | AN | Téléphone de l'acheteur. | |
BUYER_ACCOUNT_CREATE_DATE | 26 | F | 10 | AN | Date de création du compte utilisateur | |
BUYER_ACCOUNT_AVERAGE_AMOUNT | 27 | F | 10 | N | Le montant moyen des achats de l'acheteur | |
BUYER_ACCOUNT_ORDER_COUNT | 28 | F | 10 | N | Nombre de commande passé par cet acheteur. | |
EXTERNAL_WALLET_ID | 29 | C | 50 | AN | Numéro de portefeuille associé à ce client. | |
URL_RETURN | 30 | F | 255 | AN | URL sur laquelle le navigateur de l'acheteur |
est redirigé après validation du paiement sur |
Payline. | ||||||
URL_CANCEL | 31 | F | 255 | AN | URL sur laquelle le navigateur de l'acheteur |
est redirigé s'il décide de ne pas valider le |
paiement ou que Payline ne peut pas |
autoriser le paiement de ce client. | ||||||
URL_NOTIFICATION | 32 | F | 255 | AN | URL sur laquelle Payline va demander au |
site commerçant de récupérer le résultat de |
la transaction. | ||||||
LANGUAGE | 33 | F | 100 | AN | Libellé de la langue utilisée | |
CUSTOM_PAYMENT_PAGE_CODE | 34 | F | 50 | AN | Code des pages personnalisées dans le cas d'un paiement web | |
MASKED_CARD_NUMBER | 35 | F | 19 | AN | Numéro masqué de la carte | |
PAYMENT_CARD_TYPE_CODE | 36 | F | 40 | AN | Type de carte utilisé pour la transaction |
CARD_EXPIRATION_DATE
. Il s'agit du code carte tel que défini par Mastercard, Visa ou CB. Cette information est dédiée aux utilisateurs experts | ||||||
PAYMENT_CARD_CODE | Moyen de paiement utilisé | |||||
CARD_PRODUT | Type de produit de la carte | |||||
CARD_EXPIRATION_DATE | 37 | F | 4 | N | Date d'expiration de la carte | |
CARD_OWNER_BIRTHDAY_DAY | 38 | F | 6 | N | Date d'anniversaire du porteur. | |
CARD_PASSWORD | 39 | F | 16 | AN | Mot de passe. | |
RECCURING_PAYMENT_FIRST_AMOUNT | 40 | F | 12 | N | Le montant du premier montant à effectuer. |
de la devise. | ||||||
RECCURING_PAYMENT_ | 41 | F | 12 | N | Le montant d'une échéance. Il doit être |
formulé dans la plus petite unité de la |
devise. Pour un montant de 5 €, vous devez |
mettre la valeur 500. | ||||||
BILLING_CYCLE_CODE | 42 | F | 2 | N | Le code de la fréquence des paiements. | |
BILLING_DATE | 43 | F | 10 | AN | La date de l'échéance | |
BILLING_LEFT | 44 | F | 3 | N | Nombre d'échéance | |
BILLING_DAY | 45 | F | 2 | AN | Jour où les échéances doivent être traitées. | |
FLAG_3D_SECURE | 46 | F | 1 | N | Activation de l'option 3DSecure.
| |
INITIAL_TRANSACTION_ID | 47 | F | 50 | AN | L'id de la transaction d'origine | |
USER_LOGIN | 48 | |||||
IS_DUPLICATED | 49 | F | 1 | N | 0 = Transaction unique | |
BANK_CODE | 50 | F | Code de la banque. | |||
ACCOUNT_NUMBER | 51 | F | Numéro du compte bancaire. | |||
CHEQUE_NUMBER | 52 | F | Numéro du chèque dans le cas d'une transaction scoring_chèque. | |||
SERIAL_NUMBERS | 53 | F |
Numéro de série. | ||||||
SERIAL_NUMBERS_AMOUNT | 54 | F | Montant pour le numéro de série indiqué. | |||
COL_FREE17 | 55 | F | Réservé à un usage futur. | |||
TRANS_MB_EXTERNAL_ID | 56 | F | Y | Identifiant de la transaction de MoneyBookers. | ||
EXTERNAL_RETURN_CODE | 57 | R | 5 | N | Code retour transmis à l'utilisateur. | |
SHORT_MESSAGE | 58 | F | 50 | AN | Message court du résultat. | |
LONG_MESSAGE | 59 | F | 255 | AN | Message du résultat. | |
EXTERNAL_TRANSACTION_ID | 60 | F | 50 | AN | Identifiant de la transaction. | |
TRANSACTION_DATE | 61 | F | 19 | AN | Date et heure de la transaction Payline | |
AUTORIZATION_NUMBER | 62 | F | 6 |
AN | Numéro d'autorisation délivré par le serveur | |||||
TOKEN | 63 | F | 50 | AN | Jeton horodaté de la session du paiement web. | |
TOKEN_START | 64 | F | 19 | AN | Horodatage début paiement web dd/mm/yyyy HH24:mm:ss | |
TOKEN_END | 65 | F | 19 | AN | Horodatage fin paiement web dd/mm/yyyy HH24:mm:ss | |
TOKEN_TIME | 66 | F | 16 | N | Durée paiement web. | |
TOKEN_TRY | 67 | F | 16 | N | Nombre de tentative acheteur. | |
BUYER_IP_ADDRESS | 68 | F | 15 | AN | Adresse IP de l'acheteur. | |
BUYER_BROWSER | 69 | F | 100 | AN | Caractéristique navigateur de l'acheteur. | |
PAYMENT_RECORD_ID | 70 | F | 16 | N | Numéro du dossier de paiement récurrent. | |
BILLING_RECORD_NUMBER | 71 | F | 16 | N | Numéro de l'échéance. | |
ENROLLED_3D_SECURE | 72 | F | 1 | AN | Vérifier l'éligibilité du porteur au dispositif 3dsecure.
| |
AUTHENTICATED_3D_SECURE | 73 | F | 1 | AN | Vérifier l'authentification 3dsecure
| |
SECURITY_LEVEL | 74 | F | 10 | AN | La valeur |
|
|
La valeur « CVV » correspondant à la
|
| ||||||
TRANSMITTER_COUNTRY | 75 | F | 3 | AN | Le pays de la carte de paiement utilisée | |
BUYER_IP_COUNTRY_CODE | 76 | F | 2 | AN | Le pays à partir duquel la transaction est effectuée (pays correspondant à L'IP) | |
IS_CVD | 77 | F | A | AN |
| |
PIN_TSI | 78 | F | Y | Numéro de code utilisé pour le moyen de paiement TicketSurf | ||
AMOUNT_PIN_TSI | 79 | F | Y | Montant utilisé pour le moyen de paiement TicketSurf | ||
TID_TSI | 80 | F | Y | Identifiant de la transaction utilisé pour le moyen de paiement TicketSurf | ||
CHARGE_BACK | 81 | F |
WEXPAY_REF
82
F
CARDHOLDER
83
F
NEOSURF_ID_TICKET
84
F
EXTERNAL_TRANSACTION_SIPS_ID
85
C
32
Valeurs : Yes, No, Vide. Cas de paiement à la commande (autor+capture) : Yes indique si l'opération a donné à un chargeback. Cas de paiement à l'expédition (autor, capture) : Yes indique si l'opération est un chargeback. | ||||||
WEXPAY_REF | 82 | F | Y | Référence utilisé pour le moyen de paiement WexPay. | ||
CARDHOLDER | 83 | F | Nom et prénom du porteur de la carte s'il est demandé lors du paiement. | |||
NEOSURF_ID_TICKET | 84 | F | Y | Identifiant de la transaction utilisé pour le moyen de paiement NeoSurf. | ||
EXTERNAL_TRANSACTION_SIPS_ID | 85 | C | 32 | AN | WEBPAYMENT_ID correspond à l'id de transaction chez ATOS pour les moyens de paiements 1euro.com. | |
TRANSACTION_3XCB_SIPS_ID | 86 | C | 32 | AN | WEBPAYMENT_ID correspond à l'id de transaction chez ATOS pour les moyens de paiements 3xCB. | |
KEY_N | 87 | F | 50 | AN | Données privées * Ces champs sont répétés 99 fois dans le fichier d'export si l'utilisateur a choisi de les afficher. N prend la valeur de l'itération (entre 0 et 99). | |
VAL_N | 88 | F | 50 | AN | Données privées * | |
REFERENCE_N | 89 | F | 50 | AN | Détails de la commande* Ces champs sont répétés 99 fois dans le fichier d'export si l'utilisateur a choisi de les afficher. N prend la valeur de l'itération (entre 0 et 99). | |
PRICE_N | 90 | F | 12 | N | Détails de la commande* | |
QUANTITY_N | 91 | F | 5 | N | Détails de la commande* | |
COMMENTS_N | 92 | F | 255 | AN | Détails de la commande* | |
WALLET_CONTRACT_ID | 93 | F | N | Contient le numéro de contrat utilisé pour réaliser la transaction. | ||
WALLET_TYPE | 94 | F | AN | Contient la valeur du code du moyen de paiement (APPLE PAY). |
G_YPS_EXTERNAL_INVOICE_ID | 95 | F | AN | Yandex Numéro de facture | ||
TRANSACTION_RETRY_TYPE | F | AN | L’information du type deRetry
| |||
3DS_MERCHANT_ CHOICE | 2 | AN | Le choix du challenge lors d'une authentification 3D Secure V2. | |||
3DS_AUTHENTICATION_TYPE | 2 | AN | Le type d'authentification réalisé Frictionless ou Challenge : FR ou CH | |||
3DS_TRANS_STATUS | 2 | AN | Le code du résultat de l'authentification transStatus. | |||
3DS_TRANS_STATUS_REASON | AN | La description du code du résultat de l'authentification transStatusReason. | ||||
3DS_ECI | 2 | AN | Le résultat ECI de l'authentification des réseaux du paiement par carte. | |||
CARD_TOKEN | AN | Token de la carte utilisé par le commerçant. | ||||
CARD_PANTYPE | 12 | AN | Type de carte ou token ou carte mise à jour : SCHEME TOKEN / CARD PAN / UPDATED PAN |
Légende :
R = requis, F = facultatif, C = conditionnel / AN = alphanumérique, N = numérique / Y = oui
* : données du commerçant
Valorisation des données conditionnelles
Date souhaitée de validation
Dans le cadre d'un paiement programmé, la date souhaitée de validation du paiement, «differed_action_date», est obligatoire si le mode de paiement choisi est différé (« PMODE » a pour valeur « DIF »).
Paiement Web
Un paiement Web se caractérise par des éléments qui lui sont exclusivement réservés :
- l'url de retour « URL_RETURN » est utilisée lorsque le paiement a été accepté.
- l'url d'annulation « URL_CANCEL» est utilisée lorsque le paiement a été refusé ou que votre client a annulé le paiement.
- l'url de notification « URL_NOTIFICATION »utilisée lorsque Payline vous notifie d'un paiement effectué.
- le Code des pages personnalisées dans le cas d'un paiement web «CUSTOM_PAYMENT_PAGE_CODE » a utilisé par défaut.
3-D Secure
Un paiement 3-D Secure se caractérise par des éléments qui lui sont propres :
- vérification de l'éligibilité du porteur au dispositif 3dsecure « ENROLLED_3D_SECURE » par l'appel au web service verifyEnrollment.
- vérification de l'authentification 3-D Secure « AUTHENTICATED_3D_SECURE» auprès du MPI (Merchant Plug-In) via Payline.
- vérification du statut de la transaction « STATUS_3D_SECURE »
Valorisation des données conditionnelles
Date souhaitée de validation
Dans le cadre d'un paiement programmé, la date souhaitée de validation du paiement, «differed_action_date», est obligatoire si le mode de paiement choisi est différé (« PMODE » a pour valeur « DIF »).
Paiement Web
Un paiement Web se caractérise par des éléments qui lui sont exclusivement réservés :
- l'url de retour « URL_RETURN » est utilisée lorsque le paiement a été accepté
- l'url d'annulation « URL_CANCEL» est utilisée lorsque le paiement a été refusé ou que votre client a annulé le paiement.
- l'url de notification « URL_NOTIFICATION »utilisée lorsque Payline vous notifie d'un paiement effectué
- le Code des pages personnalisées dans le cas d'un paiement web «CUSTOM_PAYMENT_PAGE_CODE » a utilisé par défaut.
3-D Secure
Un paiement 3-D Secure se caractérise par des éléments qui lui sont propres :
- vérification de l'éligibilité du porteur au dispositif 3dsecure « ENROLLED_3D_SECURE » par l'appel au web service verifyEnrollment.
- vérification de l'authentification 3-D Secure « AUTHENTICATED_3D_SECURE» auprès du MPI (Merchant Plug-In) via Payline.
- vérification du statut de la transaction « STATUS_3D_SECURE ».
Avec un peu plus de détails.
Nouveaux Moyens de Paiement
ü ApplePay, Paypal, Paylib, voir liste possible chez Payline
Ø Ok, applepay pour novembre 2016 en homologation sauf pour la récurrence. Nous serons certifiés mi-décembre.
ü Carte cadeau Carrefour
Ø Ok, en attente go carrefour mi–déc 2016. èJe n’ai pas d’informations là-dessus.
ü Paiement collaboratif (type Leetchi)
Ø Ok
Options de Paiement
ü Enregistrement des coordonnées bancaires des clients chez Payline (Pas d’hébergement Carrefour)
Ø Quel est votre besoin ?
Ø 2 solutions :
ü Wallet (PAYLINE gère l’enregistrement des cartes dans le wallet, la gestion des portefeuilles) èMoins couteuse mais plus rigide
ü token PAN(CARREFOUR gère la gestion des token PAN.) =>Plus couteuse mais plus souple
ü Paiement à la commande avec remboursements automatiques aux clients des manquants sans action manuelle
Ø Ok. Il est préférable car plus simple de fonctionner avec une autorisation globale et ne capturer que le montant correspondant à la livraison. Exemple : Je fais mes courses pour 100€, lorsque je viens les récupérer au Drive il manque 20€ d’article, on ne capture seulement 80€. + un DoReset de 20€ est à réaliser par CARREFOUR pour créditer le plafond d’autorisation du porteur.
Ø Il est possible de fonctionner en autorisaiton+validation de 100€ puis de rembourser 20€ mais le remboursement (DoRefund) sera calculé et généré à l’initiative de CARREFOUR.
ü 1-Click Payment activé au choix du client si au moins une carte bancaire est enregistrée sur le compte client
Ø Ok
ü Paiement en plusieurs fois (3*, 4*, etc…)
Ø Ok mais il faut préciser s’il s’agit de paiements avec échéances ou de moyen de paiement 3XONEY, 4XONEY, FullCB, COFIDIS. S’il s’agit de paiements avec échéances, celles-ci peuvent gérées par PAYLINE (échéancier à définir dans l’appel du web service pour chacun des paiements) ou à l’initiative de CARREFOUR via le wallet ou le token PAN (plus souple, CARREFOUR possède l’alias de la donnée carte non sensible et peut réaliser les opérations souhaitées en toute autonomie).
ü Proposer du paiement différé au client en fonction du jour de livraison ou paramétrage d’un nombre de jours pour déclencher le débit client (voir fonctionnement Payline)
Ø Ok. PAYLINE propose une validation automatique par BATCH (commun à tous les paiements sur un contrat) ou de procéder depuis l’appel web service.(configurable par transaction). PAYLINE propose également de fonctionner par fichier ; CARREFOUR envoie la liste des transactions à captuer/valider à PAYLINE que nous traitons dès réception.
ü Proposer l’abonnement avec débit hebdomadaire, mensuel pour des prélèvements de commandes récurrentes pour nos clients (ex: couches, litière, etc…) ou annuel (abonnement Premium Carrefour)
Ø OK. PAYLINE propose le mode REC ou NX celles-ci peuvent gérées par PAYLINE (échéancier) ou à l’initiative de CARREFOUR via le wallet ou le token PAN (plus souple).
Parcours client
ü Pouvoir proposer un nouveau moyen de paiement sur le site en cas de rejet sur le 1er moyen de paiement (sans devoir ressaisir sa commande complète) è Augmenter le niveau de contrôle dans ce cas (ex: forcer 3DSecure)
Ø Ok. Il s’agit de la fonctionnalité proposition du second moyen de paiement qui se configure simplement en précisant le contrat à proposer en cas d’échec sur le premier contrat (secondcontractlist)
ü Revoir le process opérationnel pour les paiements à la commande avec remboursements si manquants
Ø Décrit précédemment.
ü Revoir le process opérationnel pour les paiements KO à la livraison client
Ø A préciser, il faut détailler le risque. S’il y a un risque, nous pouvons mettre en place un contrôle OPPOTA ou envisager une ré-autorisation.
Gestion de la fraude
ü Facturer ses clients à la validation de la livraison (iso aujourd’hui) mais avec des nouvelles règles de réservation bancaire pour limiter l’impact sur le plafond des clients et réduire les rejets de paiement
Ø Ok, réaliser une annulation. èA mon avis, c’est plus compliqué que cela car ils veulent éviter de faire des réaturosiation chaque semaine donc l’annulation n’est pas une solution, à creuser.
ü Intégrer du 3D Secure intelligent en définissant des règles d’activation (ex: nouveau client, paiement refusé, etc…)
Ø Ok, le module de lutte anti-fraude PAYLINE offre de nombreuses règles de débrayages 3DSecure ainsi que des listes noires, grises, blanches, clients connus et inconnus.
ü Gestion de risques en fonction de différents critères (produits sensibles, montant article/commande, etc…)
Ø OK, grâce au module LCLF tout cela est possible, il faut seulement que CARRFOUR transmettent les informations à PAYLINE (customer_id, adresse de livraison, type de produits, etc)
Reporting
ü Report quotidien, hebdo, mensuel de toutes les transactions par points de retrait (format à définir par Carrefour)
Ø PAYLINE propose un reporting quotidien par commerçant.
Ces fichiers sont transmis par FTPS au format CSV ou XML.
2 types de fichier: fichier des transactions et fichiers des paiements.
ü Report national des transactions avec kpi type taux de commandes rejetées, etc… (format à définir par Carrefour)
Ø Payline peut créer un report BI selon les informations demandées.
ü Dashboard des transactions sur Payline pour suivre le statut des commandes en temps réel (existant Payline?)
Ø Le Centre d’Administration (Back Office PAYLINE) permet de rechercher et gérer les transactions en temps réel- .