Sommaire
Un paiement complexe mixte est un cas de paiement qui s'effectue en plusieurs phases: 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: Le commerçant 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.Préambule : Qu'est-ce qu'un paiement complexe mixte
Généralités du cas de paiement Pré-commande ou expédition tardive
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 immédiatement.
Le scénario se déroule comme suit:
- 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é;
- 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ètre | Présence | Commentaire |
|---|---|---|
| linkedTransactionID | Vide pour la demande initiale | |
| Objet Payment | ||
| amount | O | 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. |
| action | O | 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. |
| mode | O | CPT : |
| Objet Order | ||
| amount | O | Montant total de la commande. C'est ce montant qui est utilisé dans la demande d’authentification. |
| expectedDeliveryDate | F | 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 | ||
| ChallengeInd | F | Au choix du marchand en fonction de son analyse de risque. Par défaut: No Preference, c'est l'ACS qui décide du type d'authentification en fonction de sa propre analyse de risque. |
O : Obligatoire ; F: Facultatif ; 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.
| Paramètre | Présence | Commentaire |
|---|---|---|
| linkedTransactionID | O | Valeur récupérée en phase de commande |
| Objet Payment | ||
| amount | O | Montant de l'expédition |
| action | O | 127: pour effectuer une demande d'autorisation et de validation |
| cumulatedAmount | R | Somme des montants déjà autorisés. (Fortement recommandé par CB) |
O : Obligatoire ; F: Facul tatif ; C : Conditionnel ; R : Recmmandé