Produits Entr'ouvert » EOPayment

Mais du coup on n'exploite pas l'info avant d'éxecuter request ?

Serghei Mihai a écrit :

Mais du coup on n'exploite pas l'info avant d'éxecuter request ?

L'idée ce serait plutôt d'exploiter ça au niveau de AddBasketItemApiView en tout premier lieu, pour éviter que la démarche ne crée des Item impayables, ensuite pour les Item déjà créé ou les factures directement au niveau de BasketItemPayView et PayView pour éviter de dépendre d'un message créé par eopayment, ça obligerait à définir une API au niveau des exceptions pour retourner un message intelligible. C'est aussi nécessaire aussi en général qu'eopayment lève des exceptions avec des messages directement exploitables, surtout qu'on peut les traduire depuis un moment, pour l'utilisateur mais ici je préfère quelque chose de restreint au problème notamment pour l'exploiter dans AddBasketItemApiView.

On peut ouvrir un autre ticket pour faire en sorte que PaymentException dipose d'une méthode get_user_message() qui retournerait toujours quelque chose qu'on puisse présenter à l'utilisateur via messages.warning(request, ...). Si je prends le cas de payfip web-service il y a les erreurs SOAP (ici M3) qu'on pourrait codifier mais il y a aussi les erreurs réseaux qui sont remontés en termes barbares:

                raise PayFiPError('Cound not initialize the SOAP client', e)
...
            raise PayFiPError('erreur-soap', str(zeep_error), zeep_error)

Dans ces deux cas e.get_user_message() devrait retourner un truc de la forme "Le serveur de paiement est actuellement indisponible à cause d'un problème réseau. Veuillez réessayer plus tard.".