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:
- de garder la maîtrise des paiements MIT ;
- tout en s'affranchissant des contraintes PCI-DSS, et de l'authentification pilotée par Monext.
Le commerçant
- initie le paiement CIT avec un doWebPayment
- récupère l'identifiant de regroupement de la réponse du getWebPaymentDetails
- récupère le token PAN du getWebPaymentDetails ou crée un wallet
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
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ètre | Présence | Commentaire |
---|---|---|
Objet Payment | ||
amount | O | 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 |
cumulatedAmount | O | 0 |
Objet Order | ||
amount | O | Contient le montant à authentifier, dépend du cas de paiement. |
Objet Recurring (facultatif pour les codes action 128 et 129) | ||
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 | C | 1 pour la 1ère échéance Obligatoire pour les codes action (122, 123, 124, 125) Facultatif pour les codes action (128, 129) |
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 | F | Laisser vide (géré par Monext) |
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 | F | Laisser vide (géré par Monext) |
sdk | F | Laisser 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.
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:
- le numéro de contrat
- l'identifiant de wallet
- 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.
linkedTransactionID | C | Valeur retournée dans la réponse à la première demande d'autorisation CIT dans le paramètre 'linkedTransactionId' (dans le getWebPaymentDetails si CIT en mode web). 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 |
authentication3DSecure | C | Valeur retournée dans la réponse à la première demande d'autorisation CIT dans le paramètre 'authentication3DSecure ' (dans le getWebPaymentDetails si CIT en mode web). Absent si Grand fathering, Facultatif pour actions 128/129 . Obligatoire dans les autres cas |
Objet Payment | ||
---|---|---|
action | O | En fonction du code utilisé pour la commande (CIT): Si 122 ou 123 alors 123; Si 124 ou 125 alors 125; Si 128 ou 129 alors 129; |
mode | O | CPT |
amount | O | Montant de l'échéance (prime sur recurring.amount) |
cumulatedAmount | C | Somme des montants déjà autorisés. Absent pour 'autres paiements récurrents' |
Objet Recurring | ||
billingRank | C | 2 pour la 2e échance, 3 pour la 3e, etc ... Obligatoire pour les codes action (122, 123, 124, 125) Facultatif pour les codes action (128, 129), valeur strictement supérieure à 1 |
autres champs | Mêmes valeurs que dans les appels précédents Facultatif pour les codes 128 et 129 Obligatoires dans les autres cas. | |
O : Obligatoire ; F: Facul tatif ; C : Conditionnel
Montant authentifié
Le tableau ci-dessous précise le montant à fournir à la demande d'authentification en fonction du paiement
Paiement | Payment code | Montant authentifié |
---|---|---|
récurrents avec des échéances en nombre défini et de même montant | 122 ou 123 | Montant total: somme du montant des échéances |
autres récurrents Paiement d'abonnement à un bien ou un service par prélèvements sur une carte enregistrée par le commerçant
| 128 ou 129 | Montant de la première échéance. |
échelonnés, NX, installments | 124 ou 125 | Montant 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 traitement de la première MIT sans identifiant de regroupement est spécifique.
Le marchand pour cette échéance :
- envoie la demande de paiement en utilisant comme identifiant de regroupement la valeur '
**PV4-999999999999'
- récupère l'identifiant de regroupement présent dans la réponse,
- si cet identifiant est différent de '
**PV4-999999999999
', le mémorise et l'utilise comme identifiant de regroupement dans les MIT ultérieures.
Le paramètre authentication3DSecure 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 paramètre authentication3DSecure .
Il peut ensuite reprendre le recouvrement des échéances en utilisant le nouvel identifiant de regroupement et le nouveau paramètre authentication3DSecure .