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

Content


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 ;
  • échelonnés, aussi appelés NX ou  installments.

Généralités

Ces paiements s'effectuent en deux phases:

  1. une phase de commande associée au paiement de la première échéance, initiée par l'acheteur sur les pages de l'e-commerçant appelée CIT, Customer Initiated Transaction;
  2. une seconde constituée des demandes de paiement des échéances suivantes initiées par le marchand hors la présence de l'acheteur appelée MIT Merchant Initiated Transaction.

La demande de paiement de la première échéance doit obligatoirement être authentifiée avec un challenge.

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

Les suivantes sont transmises:

  • sans demande d'authentification préalable;
  • en référençant la première autorisation.



Valorisation des demandes d'authentification et d'autorisation


Nous donnons dans les tableaux ci-dessous les valeurs des champs caractéristiques des différents objets de l'interface web service (cf. traitement authentification + autorisation pour l'enchaînement des web services).

Dans un premier temps les valeurs communes aux demandes d'authentification et d'autorisation puis les spécificités de l'autorisation.

Première échéance

Valeurs communes aux demandes d'authentification et d'autorisation

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
  amountFMontant 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
  amountF

Montant total de la commande

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
  ipCDoit être valorisé quand l'acheteur utilise un navigateur web
Objet ThreeDSinfo
  ChallengeIndF

Payline force la demande de challenge 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.

  browserCDoit être valorisé quand l'acheteur utilise un navigateur web.
  sdkCDoit être valorisé quand l'acheteur est connecté via une application mobile utilisant un sdk.

Spécificités autorisation

L'autorisation peut être effectuée avec un

  • doAuthorization;
  • doImmediateWalletPayment;


ParamètrePrésenceCommentaire
authentication3DSecure.mdO
authentication3DSecure.paresO

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

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

Elle n'est possible que si l'autorisation a été effectuée avec un doAuthorization.

Elle est facultative.


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.

Autres échéances

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.

Paramétrage de l'autorisation

La demande d'autorisation peut être effectuée en utilisant:

  • doAuthorization;
  • doImmediateWalletPayment;
  • doScheduledWalletPayment.


ParamètrePrésenceCommentaire
linkedTransactionIDCValeur retournée dans la réponse à la première demande d'autorisation dans le paramètre 'linkedTransactionId'.

Si l'autorisation initiale est effectuée avant la mise en application des RTS SCA se référer à la description du  ‘Grand fathering

Facultatif pour actions 128/129 avec utilisation d'un doImmediateWalletPayment ou doScheduledWalletPayment si le wallet a été créé avec la transaction de la 1ere échéance (Payline utilise le linkedTransactionID stocké lors de la création du wallet).

Obligatoire dans les autres cas

resultContainerC

Valeur retournée dans la réponse à la première demande d'autorisation dans le paramètre 'resultContainer'.

Absent si Grand fathering,

Facultatif pour actions 128/129 avec utilisation d'un doImmediateWalletPayment ou doScheduledWalletPayment si le wallet a été créé avec la transaction de la 1ere échéance (Payline utilise le resultContainer stocké lors de la création du wallet).

Obligatoire dans les autres cas

Objet Payment
  actionOMême valeur que dans les appels précédents
  modeOCPT
  amountOMontant de l'échéance (prime sur recurring.amount)
  cumulatedAmountC

Somme des montants déjà autorisés.

Absent pour 'autres paiements récurrents'

Objet Recurring
  billingRankC

2 pour la 2e échance, 3 pour la 3e, etc ...

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

Recommandé pour les codes action (128, 129), valeur strictement supérieure à 1

  autres champs
Mêmes valeurs que dans les appels précédents



Montant authentifié

Le tableau ci-dessous précise le montant à fournir à la demande d'authentification en fonction du paiement

PaiementPayment codeMontant authentifié
récurrents avec des échéances en nombre défini et de même montant122 ou 123Montant total: somme du montant des échéances
autres récurrents128 ou 129

Montant de la première échéance

Pour American Express, Mastercard, le montant des autres échéances ne doit pas excéder celui de la première.

Semble remis en cause actuellement (A CONFIRMER).

échelonnés, NX, installments124 ou 125Montant total: somme du montant des échéances

Grand fathering

Ce paragraphe traite des paiements récurrents et Nx initiés avant l'application de la dsp2 et  n'ayant pas pu récupérer auprès du serveur d'autorisation la référence d'autorisation initiale.

Le marchand pour chaque demande de paiement d'échéance :

  • envoie comme identifiant de transaction initiale la valeur : '**PV4-999999999999'
  • récupère l'identifiant de transaction dans la réponse à la demande de paiement
  • si cet identifiant est différent de '**PV4-999999999999', la mémorise et l'utilise comme identifiant de transaction initiale dans les demandes de paiement ultérieures.

Le resultContainer n'est jamais envoyé.

Changement et renouvellement de carte

Ce paragraphe traite du cas du changement de carte pour un paiement récurrent ou n fois en cours.

Le changement est effectué par l'acheteur sur les pages du commerçant.

Le commerçant propose à son acheteur de venir modifier ses données de paiement.

Il lui présente une demande de paiement récurrent de montant variable de durée indéterminée (code 128).

Il récupère l'identifiant de regroupement (linkedTransactionId) et le resultContainer.

Il peut ensuite reprendre le recouvrement des échéances en utilisant le nouvel identifiant de regroupement et le nouveau resultContainer.