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
Cette page précise le paramétrage des commandes pour lesquelles le commerçant:
- ne peut effectuer l'envoi de la totalité des marchandises dans les 7 jours;
- accepte une pré-commande avec livraison lointaine (> 7 jours).
Le numéro de carte peut être saisi par l'acheteur ou récupéré d'un wallet.
Le scénario se déroule comme suit:
- Pendant la phase de commande, le commerçant:
- utilise le mode de paiement lié à la pré-commande;
- effectue une authentification avec le montant total de la commande;
- effectue une demande d'information à 0 € si aucun envoi effectué immédiatement, une demande d'autorisation du montant de l'envoi prêt à être effectué ou du montant de l'acompte;
- Au gré des expéditions en dehors la présence de l'acheteur, il:
- effectue une autorisation + validation du montant de l'expédition en référençant la première autorisation .
L'intérêt de ce cas d'usage est de ne pas réduire la capacité à acheter du client en impactant inutilement l'encours de carte.
Prérequis / contraintes:
- l'acheteur initie la commande en ligne depuis du site web ou de l'application mobile du marchand;
- le marchand utilise l'interface Pages Web de Paiement;
- Le cryptogramme d'authentification reste valide 180 jours après l'authentification.
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 | O | 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 choice, c'est l'ACS qui décide du type d'authentification en fonction de sa propre analyse de risque. |
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.
| Paramètre | Présence | Commentaire |
|---|---|---|
| linkedTransactionID | O | Valeur récupérée en phase de commande |
| authentication3DSecure | 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 | O | Somme des montants déjà autorisés. |
O : Obligatoire ; F: Facul tatif ; C : Conditionnel