Content
| Sommaire | ||||
|---|---|---|---|---|
|
| Extrait | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
|
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 ;récurrents, c'est à dire paiements récurrents de montants variables et/ou de durée indéterminée. Par exemple, paiement de facture d'abonnement de montant variant en fonction de la consommation et/ou sans date de fin
- échelonnés, aussi appelés NX ou échelonnés ou aussi appelés NX, installments.
Généralités
Ces paiements s'effectuent en deux phases:
- une phase de commande associée au paiement de la première échéance, initiée par l'acheteur sur les pages du de l'e-commerçant appelée CIT, Customer Initiated Transaction;
- 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'autorisationde 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 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éanceValeurs 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ètre |
|---|
| Présence | Commentaire | |
|---|---|---|
| Objet Payment | ||
| amount | F | Montant de la première échéance |
| . | ||
| action | O | 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 |
| mode | O | CPT |
Indiquez le réseau à utiliser pour l'authentification et le paiement (le même pour les deux demandes)
Facultatif, par défaut Payline utilise la valeur du réseau configuré dans le contrat.
| cumulatedAmount | O | 0 |
| Objet Order | ||
|---|---|---|
| amount | O | Contient le montant à authentifier, dépend du cas de paiement. |
| Objet Recurring | ||
|---|---|---|
| firstAmount | O | Montant de la première échéance (prime sur payment.amount) |
| amount | C | Montant des échéances suivantes Obligatoire pour les codes action (122, 123, 124, 125) Vide pour les codes action (128, 129) |
| billingCycle | C | 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) |
| billingLeft | C | 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) |
| billingRank | O | 1 pour la 1ère échéance |
| endDate | C | 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 | ||
| ip | C | Doit être valorisé quand l'acheteur utilise un navigateur web |
| Objet ThreeDSinfo | ||
| ChallengeInd | ||
| F | '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. | ||
| browser | C | Doit être valorisé quand l'acheteur utilise un navigateur web. |
| sdk | C | Doit ê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ètre | Présence | Commentaire |
|---|---|---|
authentication3DSecure.md | O | |
authentication3DSecure.pares | O |
| Inclure page | ||||
|---|---|---|---|---|
|
Pages associées
Authentication3DSecureSi 3DS V1: message Pares envoyé par l'ACS et reçu par le commerçant (ce message est encodé en base 64)
Si 3DS V2 - challenge: message CRes envoyé par l'ACS et reçu par le commerçant (ce message est encodé en base 64)
Si 3DS V2 - frictionless : vide
Si 3DS V2 - frictionless : contient le resultConainer retourné par la réponse au dernier appel au web service verifyEnrollment.
Sinon : vide
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
Authentication3DSecureSi 3DS V1: message Pares envoyé par l'ACS et reçu par le commerçant (ce message est encodé en base 64)
Si 3DS V2 - challenge: message CRes envoyé par l'ACS et reçu par le commerçant (ce message est encodé en base 64)
Si 3DS V2 - frictionless : vide
Si 3DS V2 - frictionless : contient le resultConainer retourné par la réponse au dernier appel au web service verifyEnrollment.
Sinon : vide
Montant authentifié
Le tableau ci-dessous précise le montant fournit à la demande d'authentification en fonction du paiement
Montant de la première échéance
Le montant des autres échéances ne doit pas excéder celui de la première.
| Contenu par étiquette | ||||||||
|---|---|---|---|---|---|---|---|---|
|