Arborescence des pages

Comparaison des versions

Légende

  • Ces lignes ont été ajoutées. Ce mot a été ajouté.
  • Ces lignes ont été supprimées. Ce mot a été supprimé.
  • La mise en forme a été modifiée.
Commentaire: jira





Sommaire

Sommaire
maxLevel3



Extrait
hiddentrue

Jira
serverSystem JIRA
serverId50744091-840f-3ee1-b868-bceedb28d8a1
keyPAYLPRO-948



Inclure page
3DSV2 - Paiements complexes mixtes
3DSV2 - Paiements complexes mixtes



Généralités

Cette page précise les paramètres à utiliser pour l'authentification et l'autorisation des paiements

  • récurrents avec des échéances en nombre défini et de même montant;
  • autres récurrents, c'est à dire paiements récurrents de montants variables et/ou de durée indéterminée, par exemple paiement d'un abonnement dont le montant dépend de la consommation et/ou sans date de fin prédéfinie ;
  • échelonnés, aussi appelés NX ou  installments.

Ce cas d'utilisation permet à un commerçant de gérer les échéances de son côté en doWebPayment (CPT) et les échéances suivantes avec le service doAuthorization en étant conforme à la DSP2.


Valorisation de la demande de paiement de la commande (CIT)


Nous donnons dans les tableaux ci-dessous les valeurs des champs caractéristiques des différents objets à fournir au doWebPayment.


Les tableaux ci-dessous donnent les valeurs et la présence des différents champs pour le cas spécifiques des paiements NX et récurrents

ParamètrePrésenceCommentaire



Objet Payment
  amountOMontant de la première échéance.
  actionO

122 : autorisation pour un paiement récurrent de montant constant et de durée fixée

123: autorisation + validation pour un paiement récurrent de montant constant et de durée fixée

124: autorisation pour un paiement écheloné, NX, ou installment

125: autorisation + validation  pour un paiement écheloné, NX, ou installment

128: autorisation pour les autres paiements récurrents

129: autorisation + validation pour les autres paiements récurrents

  modeOCPT
  cumulatedAmountO0
Objet Order
  amountO

Contient le montant à authentifier, dépend du cas de paiement.

Objet Recurring
  firstAmountOMontant de la première échéance (prime sur payment.amount)
  amountC

Montant des échéances suivantes

Obligatoire pour les codes action (122, 123, 124, 125)

Vide pour les codes action (128, 129)

  billingCycleC

Récurrence, par exemple 40 pour une récurrence mensuelle

Obligatoire pour les codes action (122, 123, 124, 125)

Vide pour les codes action (128, 129)

  billingLeftC

Nombre d'échéances total (3 pour paiement 3 fois, ...)

Obligatoire pour les codes action (122, 123, 124, 125)

Vide pour les codes action (128, 129)

  billingRankO

1 pour la 1ère échéance

  endDateC

date de la dernière échéance (prendre une marge qui inclut  le temps nécessaire pour répéter la demande de paiement de la dernière échéance en cas d'incident)

Obligatoire pour les codes action (122, 123, 124, 125)

Vide pour les codes action (128, 129)


Objet Buyer
  ipFLaisser vide (géré par Monext)
Objet ThreeDSinfo
  ChallengeIndF

'04'

Monext force la demande de challenge à cette valeur dans la demande envoyée à l'ACS.

Il s'agit d'un aspect réglementaire.

Le commerçant n'est pas obligé de remplir ce champ.

  browserFLaisser vide (géré par Monext)
  sdkFLaisser vide (géré par Monext)

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.


Inclure page
3DSV2 - Paiements récurrents subséquents
3DSV2 - Paiements récurrents subséquents



Pages associées

Contenu par étiquette
showLabelsfalse
showSpacefalse
sorttitle
cqllabel = "3dsv2" and label = "en"