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: 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 d'autorisation peut être effectuée en utilisant: 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 Valeur retournée dans la réponse à la première demande d'autorisation dans le paramètre 'authentication3DSecure '. 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 l'authentication3DSecure stocké lors de la création du wallet). Obligatoire dans les autres cas 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; Somme des montants déjà autorisés. Absent pour 'autres paiements récurrents' 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 Le tableau ci-dessous précise le montant à fournir à la demande d'authentification en fonction du paiement 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). 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 : Le paramètre authentication3DSecure n'est jamais envoyé. 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 .Stockage des données de paiement dans un wallet Payline.
Valorisation des demandes de paiement subséquentes (MIT)
Paramétrage de l'autorisation
Paramètre Présence Commentaire linkedTransactionID C Valeur retournée dans la réponse à la première demande d'autorisation dans le paramètre 'linkedTransactionId'. authentication3DSecure C Objet Payment action O mode O CPT amount O Montant de l'échéance (prime sur recurring.amount) cumulatedAmount C Objet Recurring billingRank C autres champs Mêmes valeurs que dans les appels précédents Montant authentifié
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 128 ou 129 échelonnés, NX, installments 124 ou 125 Montant total: somme du montant des échéances Grand fathering
**PV4-999999999999'
**PV4-999999999999
', la mémorise et l'utilise comme identifiant de transaction initiale dans les demandes de paiement ultérieures.Changement et renouvellement de carte