Page tree
Skip to end of metadata
Go to start of metadata


Sommaire






Préambule : Qu'est-ce qu'un paiement complexe mixte


Un paiement complexe mixte est un cas de paiement qui s'effectue en plusieurs phases:

  • Une prise de commande avec présence de l'acheteur à l'aide de l'interface Page Web de Paiement. Nous parlons de CIT, Customer Initiated Transaction;
  • D'un ou plusieurs paiements effectués par la suite par le commerçant sur l'interface directe en l'absence de l'acheteur. Nous parlons de MIT, Merchant Initiated Transaction.


Les cas de paiement concernés sont par exemple les paiements échelonnés (NX), les paiements récurrents (REC), les précommandes et expéditions tardives, etc...


Le mode mixte permet à un marchand:

  1. de garder la maîtrise des paiements MIT ;
  2. tout en s'affranchissant des contraintes PCI-DSS, et de l'authentification pilotée par Monext.


Le commerçant

  1. initie le paiement CIT avec un doWebPayment
  2. récupère l'identifiant de regroupement de la réponse du getWebPaymentDetails
  3. récupère le token PAN du getWebPaymentDetails ou crée un wallet
  4. initie les MIT avec le wallet ou le token PAN, l'identifiant de transaction de regroupement et les paramètres spécifiques au cas de paiement.


Contrainte abonnement

Le commerçant doit être titulaire d'un abonnement lui permettant de créer des wallets ou de récupérer les tokens pan utilisés lors des paiements.

Version API web services

Ces cas de paiements requièrent d'utiliser une version d'API web service au moins égale à 28.

A partir de cette version, vous devez vous assurer que le champ order.amount contient la valeur du montant à authentifier et ce,  quel que soit le cas de paiement.



 

Généralités

Ce cas de paiement permet à un commerçant d'accepter une commande qu'il sait ne pas pouvoir honorer immédiatement.

Ce peut être le cas lorsque le commerçant:

  • ne peut effectuer l'envoi de la totalité des marchandises dans la période de garantie de paiement d'une autorisation;
  • accepte une pré-commande sans que le produit ne soit disponible.

Le scénario se déroule comme suit:

  1. Pendant la phase de commande:
    • authentification du montant total de la commande;
    • demande d'info à 0 € si aucun envoi effectué immédiatement ou demande d'autorisation du montant de l'envoi prêt à être effectué;
  2. Au gré des expéditions en dehors la présence de l'acheteur:
    • autorisation + validation du montant de l'expédition en référençant la première autorisation.


Le numéro de carte peut être saisi par l'acheteur ou récupéré d'un card on file.


Authentification ne vaut pas autorisation

Dans ce schéma, les autorisations sont effectuées au gré des expéditions.
Ces demandes d'autorisation peuvent être refusées (fond insuffisant, carte opposée, ...).

Le commerçant doit prendre en compte ces aléas dans ses traitements.

Version API web services

Ces cas de paiements requièrent d'utiliser une version d'API web service au moins égale à 28.

A partir de cette version, vous devez vous assurer que le champ order.amount contient la valeur du montant à authentifier et ce,  quel que soit le cas de paiement.


Conditions CB

Le commerçant dispose de 180 jours pour terminer sa commande (durée de validité du cryptogramme d'authentification)

Les remises effectuées dans les 30 jours après l'authentification bénéficient du transfert de responsabilité

Conditions VISA / Mastercard

Le commerçant dispose de 90 jours pour terminer sa commande (durée de validité du cryptogramme d'authentification)

Prérequis / contraintes:

  • l'acheteur initie la commande en ligne depuis du site web ou de l'application mobile du marchand;
  • la somme des montants des autorisations ne peut excéder celui de l'authentification ;
  • la validation (remise ou capture) des autorisations doit intervenir pendant la période de validation de l'autorisation accordée par l'acquéreur, généralement 7 jours.







 Valorisation de la commande


Le doWebPayment d'initialisation de la commande est valorisé comme suit

ParamètrePrésenceCommentaire
linkedTransactionID
Vide pour la demande initiale
Objet Payment
  amountO

Montant du paiement effectué en phase de commande (montant de l'acompte ou des articles de la première expédition.

Ce montant peut être nul.

  actionO

126: pour effectuer une demande d'autorisation

127: pour effectuer une demande d'autorisation et de validation

Si le montant est nul, Payline transforme la demande d'autorisation ou d'autorisation + validation en demande d'information.

modeOCPT :
Objet Order
  amountO

Montant total de la commande.

C'est ce montant qui est utilisé dans la demande d’authentification.

  expectedDeliveryDateF

Pour une pré-commande, indique la date estimée de la livraison.

Pour une expédition tardive, indique la date de la dernière livraison.

Objet ThreeDSinfo
  ChallengeIndF

Au choix du marchand en fonction de son analyse de risque.

Par défaut: No choice, c'est l'ACS qui décide du type d'authentification en fonction de sa propre analyse de risque.

O : Obligatoire ;     F: Facul tatif ;    C : Conditionnel

Le marchand récupère le tokenPan card.token, le linkedTransactionID et le authentication3DSecureretournés dans la réponse au getWebPaymentDetails

Stockage des données de paiement dans un wallet Payline.


Cette étape facultative permet de stocker les données de paiement dans un wallet Payline.

Il faut faire appel au web service createWallet en précisant:

  1. le numéro de contrat
  2. l'identifiant de wallet
  3. l'identifiant de transaction Payline donné en réponse du doAuthorization.

Valorisation des demandes de paiement subséquentes (MIT)

Les demandes de paiement des autres échéances sont initiées par le marchand hors la présence de l'acheteur, il n'y a pas d'authentification.

La demande de paiement peut être effectuée en utilisant:

  • doAuthorization;
  • doImmediateWalletPayment;
  • doScheduledWalletPayment.


Les paramètres spécifiques à ces demandes sont précisés dans le tableau ci-dessous.


ParamètrePrésenceCommentaire
linkedTransactionIDOValeur récupérée en phase de commande



Objet Payment
  amountOMontant de l'expédition
  actionO

127: pour effectuer une demande d'autorisation et de validation

  cumulatedAmountR

Somme des montants déjà autorisés.  (Fortement recommandé par CB)

O : Obligatoire ;     F: Facul tatif ;    C : Conditionnel  ;    R : Recmmandé