...
archive.oldDays.emailFieldsMapReference=15 quant à lui permet simplement de purger la table email_fields_map_reference qui est une table temporaire utilisée lors du paiement et dont les informations doivent normalement être utilisées et requises sur un interval de temps court (entre moment où l'utilisateur quitte l'application esup-pay pour aller sur le formulaire de paiement et le moment où paybox envoie l'information que le paiement s'est effectivement bien déroulé).
Le paiement sur Paybox a été effectué mais la transaction n'apparait pas dans la liste des Transactions sur l'interface.
Lorsque le paiement est effectué sur Paybox, Paybox tente d'appeler esup-pay sur son url de callback. C'est grâce à cet appel qu'esup-pay enregistre la transaction effectuée et envoie également éventuellement un mail à un gestionnaire.
Ainsi sur votre serveur web, dans ses logs d'accès, vous devez trouver des appels des serveurs paybox qui font des GET sur une url en /payboxcallback
Cette requête est prise en compte par esup-pay, mais dans un tout premier temps, une vérification (par spring-security) sur les IP est réalisée : en effet, l'idée est de n'autoriser que les serveurs paybox à appeler cette url de callback /payboxcallback
Ainsi le fichier security.properties liste l'ensemble des serveurs paybox.
Si un client appelle le /payboxcallback sans faire partie de ce listing d'IP, alors l'application renvoie un 403 (Forbidden) en réponse HTTP au lieu d'un 200 - on peut retrouver ces codes dans les fichiers logs d'accès à votre serveur web.
Si un serveur paybox de production appelle cette url est que esup-pay ne retourne pas un code HTTP 200, paybox enverra un mail de warning au mail de contact paybox de l'établissement.
Un problème courant lors de la mise en oeuvre de esup-pay est que l'application n'a pas connaissance de l'IP des clients véritablement et donc des serveurs paybox, mais de l'IP d'un éventuel proxy qui se situe entre esup-pay et les clients.
Installation d'esup-pay derrière un proxy