DESCRIPTION DES CODES D'ERREUR :
Mail d'alerte - Transaction définitivement perdue
En mode PRODUCTION, dans le cas d'une valeur incorrecte du champ DATE, l'internaute obtient lors d'un paiement le message d'erreur suivant sur son navigateur :
CAUSES DE L'ERREUR DE DATE AVEC MAIL D'ALERTE
| 1 - La date n'est pas envoyée sous le format AAAAMMJJHHMMSS (année, mois, jour, heure, minute, seconde). |
|
Exemple :
Pour le 17 octobre 2011 à 8h54 et 36 secondes le champ date doit etre 20111017085436. |
| 2 - La date n'est pas basée sur le fuseau horaire UTC (temps universel coordonné). |
|
Pour rappel il est impératif que la date soit basée sur le fuseau horaire UTC. En haut du mail (en vert dans l'exemple ci-dessus) vous visualisez la date et l'heure UTC à laquelle nous avons reçu la demande de paiement. Dans ce même mail vous visualisez la valeur du champ DATE que la plateforme de paiement a reçue (trans_date - en rouge dans l'exemple ci-dessus) 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 2011 à 14h30m00s (heure UTC), le champ DATE devra être compris entre 20110715140000 (15 juillet 2011 à 14h00) et 20110715160000 (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 2011 à 14h50, il est 12h50 UTC car à cette periode 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 20110712125000 (12 juillet 2011 à 12h50). En revanche à Paris le 12 janvier 2011 à 14h50, il est 13h50 UTC car à cette periode 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 20110112135000 (12 janvier 2011 à 13h50). |
| 3 - L'heure doit être calculée sur 24h et non sur 12h. |
|
Pour rappel 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 2012 à 14h30 UTC (soit 2h30 post meridiem), la valeur du champ DATE devra être 20120715143000 et non 20120715023000. |
| 4 - 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. |
| 5 - 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". |
Si vous faites appel à une agence WEB pour l'administration de votre boutique veuillez prendre contact avec celle-ci en lui communiquant l'adresse suivante :
https://secure.payzen.eu/error_code/04.php
Mail d'avertissement - Différence entre la date reçue et l'heure UTC trop importante
En mode PRODUCTION, dans le cas ou votre boutique envoie une heure trop éloignée de l'heure réelle du paiement, celle ci peut etre tolérée provisoirement, l'internaute poursuit alors le paiement d'une manière tout à fait normale.Cependant vous recevez un mail d'avertissement vous informant de l'incohérence du champ DATE (date et heure).Ci dessous un exemple de mail d'avertissement:
CAUSES DE L'ERREUR DE DATE AVEC MAIL D'AVERTISSEMENT
| 1 - La date n'est pas basée sur le fuseau horaire UTC (temps universel coordonné). |
|
Pour rappel il est impératif que la date soit basée sur le fuseau horaire UTC. En haut du mail (en vert dans l'exemple ci-dessus) vous visualisez la date et l'heure UTC à laquelle nous avons reçu la demande de paiement. Dans ce même mail vous visualisez la valeur du champ DATE que la plateforme de paiement a reçue (trans_date - en rouge dans l'exemple ci-dessus) 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 2011 à 14h30m00s (heure UTC), le champ DATE devra être compris entre 20110715140000 (15 juillet 2011 à 14h00) et 20110715160000 (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 2011 à 14h50, il est 12h50 UTC car à cette periode 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 20110712125000 (12 juillet 2011 à 12h50). En revanche à Paris le 12 janvier 2011 à 14h50, il est 13h50 UTC car à cette periode 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 20110112135000 (12 janvier 2011 à 13h50). |
| 2 - 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. |
| 3 - 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". |
Si vous faites appel à une agence WEB pour l'administration de votre boutique veuillez prendre contact avec celle-ci en lui communiquant l'adresse suivante :
https://secure.payzen.eu/error_code/04.php
