error 04 - vads_trans_date
- un e-mail d'alerte vous
indiquant que la transaction est définitivement perdue dans le cas d'une valeur
incorrecte du champ vads_trans_date ou d'un décalage trop important par rapport à
l'heure de la plateforme.Vous obtenez alors un message d'erreur du type :
Un dysfonctionnement s'est produit lors de la demande de paiement, merci de vérifier que les paramètres postés sont cohérents vis à vis de la documentation. - un e-mail
d'avertissement vous indiquant que la différence entre l'heure UTC
de notre plateforme et l'heure UTC définie dans votre formulaire de paiement est
trop importante. Dans le cas où votre boutique envoie une heure trop éloignée de l'heure réelle du paiement, celle-ci peut être tolérée provisoirement, l'internaute poursuit alors le paiement d'une manière tout à fait normale.Cependant vous recevez un e-mail d'avertissement vous informant de l'incohérence du champ vads_trans_date (date et heure).
Le paiement est alors impossible et la transaction est définitivement interrompue.
Vous recevez un e-mail d'alerte contenant l'élément du formulaire que la plateforme n'a pas pu traiter.
Nous vous invitons à vérifier la ou les causes suivantes pour résoudre le problème :
- Causes de l'erreur dans le cas d'un e-mail d'alerte
La date transmise dans vads_trans_date est au-delà du décalage toléré. En mode production, la plateforme de paiement tolère un décalage entre l'heure transmise dans vads_trans_date et l'heure UTC de la plateforme de 30 min dans le passé et jusqu'à 1h30 dans le futur.
Vous recevrez un e-mail d'alerte si ce décalage est supérieur à 60 min dans le passé ou supérieur à 2h30 dans le futur.
Exemple :
S'il est 12h00 UTC, vous ne recevrez pas d'e-mail d'alerte si l'heure transmise dans vads_trans_date est valorisée entre 11h30 UTC et 13h30 UTC.
Par contre, vous recevrez un e-mail d'alerte si l'heure transmise est antérieure à 11h00 UTC ou postérieure à 14h30 UTC.
La date n'est pas envoyée sous le format AAAAMMJJHHMMSS (année, mois, jour, heure, minute, seconde). Exemple :
Pour le 17 octobre 2019 à 8h54 et 36 secondes le champ vads_trans_date doit être 20191017085436.
La date n'est pas basée sur le fuseau horaire UTC (temps universel coordonné). Il est impératif que la date soit basée sur le fuseau horaire UTC.
En haut de l'e-mail vous visualisez la date et l'heure UTC à laquelle nous avons reçu la demande de paiement.
Dans ce même e-mail vous visualisez la valeur du champ vads_trans_date que la plateforme de paiement a reçue.
Assurez-vous que la différence d'heure n'est pas trop importante par rapport à l'heure où nous avons reçu la demande paiement.
Heure :
L'heure correcte doit être comprise entre -30mn et +2h30 par rapport à l'heure à laquelle nous recevons la demande paiement.
Exemple :
Si nous recevons une demande de paiement le 15 juillet 2019 à 14h30m00s (heure UTC), le champ DATE devra être compris entre 20190715140000 (15 juillet 2019 à 14h00) et 20190715160000 (15 juillet à 16h00).
Rappel sur le fuseau horaire UTC :
En fonction de la zone et de la période de l'année il peut y avoir un décalage différent avec l'heure UTC.
Par exemple à Paris le 12 juillet 2019 à 14h50, il est 12h50 UTC car à cette période de l'année Paris a un décalage de +2 heures (heure d'été) avec l'heure UTC. Dans la requête de paiement vous devrez donc envoyer 20190712125000 (12 juillet 2019 à 12h50).
En revanche à Paris le 12 janvier 2019 à 14h50, il est 13h50 UTC car à cette période de l'année Paris a un décalage de +1 heure (heure d'hiver) avec l'heure UTC.
Dans la requête de paiement vous devrez donc envoyer 20190112135000 (12 janvier 2019 à 13h50).
L'heure doit être calculée sur 24h et non sur 12h. L'heure doit être calculée sur 24 heures et non sur 12 heures.
Exemple :
Si nous recevons une demande de paiement le 15 juillet 2019 à 14h30 UTC (soit 2h30 post meridiem), la valeur du champ vads_trans_date devra être 20190715143000 et non 20190715023000.
Votre client a attendu trop longtemps avant de cliquer sur le bouton "Payer". Si ce type d'erreur n'est pas fréquent, il est possible que l'internaute ait trop attendu avant de cliquer sur le bouton "Payer".
Dans ce cas la date conservée est celle calculée lors de l'affichage de la page contenant le bouton "Payer". C'est pourquoi il est fortement conseillé de calculer la date au moment du clic sur le bouton "Payer".
Exemple :
Un client passe une commande à 12h et revient à 14h pour cliquer sur le bouton "Payer".
Si votre formulaire est pré-généré avant le clic sur le bouton "Payer" alors votre date sera valorisée à 12h, mais l'heure de la plateforme de paiement sera elle à 14h. L'écart entre les deux dates est alors trop grand et la plateforme de paiement retourne une erreur.
Votre client a utilisé l'historique de son navigateur. Si ce type d'erreur n'est pas fréquent, il est possible que l'internaute soit revenu quelques heures plus tard sur la page de votre boutique permettant d’initialiser le paiement (page avec le bouton "Payer") en utilisant l'historique de son navigateur.
Dans ce cas la date conservée est celle calculée lors de sa première visite sur cette page. C'est pourquoi il est fortement conseillé de calculer la date au moment du clic sur le bouton "Payer".
- Causes de l'erreur dans le cas d'un e-mail d'avertissement
La date transmise dans vads_trans_date est au-delà du décalage toléré. En mode production, la plateforme de paiement tolère un décalage entre l'heure transmise dans vads_trans_date et l'heure UTC de la plateforme de 30 min dans le passé et jusqu'à 1h30 dans le futur.
Au-delà, vous recevrez un e-mail d'avertissement si ce décalage est compris entre 30 min et 60 min dans le passé ou entre 1h30 et 2h30 dans le futur.
Exemple :
S'il est 12h00 UTC, vous ne recevrez pas d'e-mail d'avertissement si l'heure transmise dans vads_trans_date est valorisée entre 11h30 UTC et 13h30 UTC.
Par contre, vous recevrez un e-mail d'avertissement si l'heure transmise est comprise entre 11h00 et 11h30 UTC ou entre 13h30 et 14h30 UTC.
La date n'est pas basée sur le fuseau horaire UTC (temps universel coordonné). Il est impératif que la date soit basée sur le fuseau horaire UTC.
En haut de l'e-mail vous visualisez la date et l'heure UTC à laquelle nous avons reçu la demande de paiement.
Dans ce même e-mail vous visualisez la valeur du champ vads_trans_date que la plateforme de paiement a reçue.
Assurez-vous que la différence d'heure n'est pas trop importante par rapport à l'heure où nous avons reçu la demande paiement.
Heure :
L'heure correcte doit être comprise entre -30mn et +2h30 par rapport à l'heure à laquelle nous recevons la demande paiement.
Exemple :
Si nous recevons une demande de paiement le 15 juillet 2019 à 14h30m00s (heure UTC), le champ DATE devra être compris entre 20190715140000 (15 juillet 2019 à 14h00) et 20190715160000 (15 juillet à 16h00).
Rappel sur le fuseau horaire UTC :
En fonction de la zone et de la période de l'année il peut y avoir un décalage différent avec l'heure UTC.
Par exemple à Paris le 12 juillet 2019 à 14h50, il est 12h50 UTC car à cette période de l'année Paris a un décalage de +2 heures (heure d'été) avec l'heure UTC. Dans la requête de paiement vous devrez donc envoyer 20190712125000 (12 juillet 2019 à 12h50).
En revanche à Paris le 12 janvier 2019 à 14h50, il est 13h50 UTC car à cette période de l'année Paris a un décalage de +1 heure (heure d'hiver) avec l'heure UTC.
Dans la requête de paiement vous devrez donc envoyer 20190112135000 (12 janvier 2019 à 13h50).
Votre client a attendu trop longtemps avant de cliquer sur le bouton "Payer". Si ce type d'erreur n'est pas fréquent, il est possible que l'internaute ait trop attendu avant de cliquer sur le bouton "Payer".
Dans ce cas la date conservée est celle calculée lors de l'affichage de la page contenant le bouton "Payer". C'est pourquoi il est fortement conseillé de calculer la date au moment du clic sur le bouton "Payer".
Exemple :
Un client passe une commande à 12h et revient à 14h pour cliquer sur le bouton "Payer".
Si votre formulaire est pré-généré avant le clic sur le bouton "Payer" alors votre date sera valorisée à 12h, mais l'heure de la plateforme de paiement sera elle à 14h. L'écart entre les deux dates est alors trop grand et la plateforme de paiement retourne une erreur.
Votre client a utilisé l'historique de son navigateur. Si ce type d'erreur n'est pas fréquent, il est possible que l'internaute soit revenu quelques heures plus tard sur la page de votre boutique permettant d’initialiser le paiement (page avec le bouton "Payer") en utilisant l'historique de son navigateur.
Dans ce cas la date conservée est celle calculée lors de sa première visite sur cette page. C'est pourquoi il est fortement conseillé de calculer la date au moment du clic sur le bouton "Payer".