Cycle de vie d’un paiement récurrent
L’abonnement démarre à sa date d’effet.
La plateforme de paiement va alors créer les paiements en suivant l’échéancier déterminé par la règle de l’abonnement envoyée dans le formulaire de création de l’abonnement (champ vads_sub_desc).
Dans le cadre de l'application de la DSP2, la plateforme de paiement transmet, dans la demande d'autorisation, une référence de chaînage, afin d'éviter les refus pour défaut d'authentification (soft decline).
A chaque échéance d'un abonnement, si la règle URL de notification à la création d'un abonnement est activée et correctement configurée, le site marchand recevra le résultat du paiement sur son URL de notification (IPN).
La notification contient notamment :
- le champ vads_subscription, qui indique la référence de l'abonnement,
- le champ vads_recurrence number, qui indique le numéro de l'échéance,
- le champ vads_occurrence_type, qui indique de quelle échéance il s'agit (première, énième ou dernière échéance),
- le champ vads_trans_status qui indique le statut du paiement (accepté ou refusé).
En cas de paiement refusé :
- le marchand ne sera pas averti par e-mail,
- le paiement ne sera pas représenté automatiquement.
Si le moyen de paiement a atteint sa date d'expiration, une transaction refusée est créée sans appel à la banque émettrice. Le détail de l'erreur (vads_payment_error) est valorisé à 8 - La date d'expiration de la carte ne permet pas cette action.
Si les données du moyen de paiement ont été purgées suite à une inactivité de 15 mois, une transaction refusée est créée sans appel à la banque émettrice. Le détail de l'erreur (vads_payment_error) est valorisé à 107 - Le moyen de paiement associé à l'alias n'est plus valide.
Cas particulier des récurrences à fréquence quotidienne
- celui de la veille (correspondant à la date d'effet),
- et celui du jour.
Pour éviter cela, il est conseillé de transmettre une date d'effet au lendemain du jour de la création de l'abonnement.