Projet

Général

Profil

Bug #19709

Seule la réponse "callback" du service de paiement est prise en compte

Ajouté par Frédéric Péters il y a plus de 6 ans. Mis à jour il y a plus de 5 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
27 octobre 2017
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:

Description

Sur un cas particulier, avec Ingenico Atos (sips2) à Liège, le déroulé a été le suivant :

  • appel à l'URL lingo/callback/1 avec code 97 (erreur de timeout entre ingenico et la banque)
  • appel à l'URL lingo/callback/1 avec code 97 (again)
  • retour de l'utilisateur sur l'URL lingo/return/1 avec enfin code 00 (succès)

Mais le code reçu sur lingo/return/, on n'en fait rien.

À part le résultat final, une 200 pour "callback" et une 302 pour l'usager sur "return", le code ne devrait-il pas être identique (/partagé) ? Des raisons dans d'autres systèmes de paiement pour que ça ne soit pas le cas ?


Fichiers

Révisions associées

Révision f860a552 (diff)
Ajouté par Frédéric Péters il y a environ 6 ans

lingo: handled signed responses on the return URL (#19709)

Révision 6eba5417 (diff)
Ajouté par Frédéric Péters il y a environ 6 ans

tests: update remote item payment test as return now process them (#19709)

Historique

#1

Mis à jour par Frédéric Péters il y a plus de 6 ans

  • Description mis à jour (diff)
#2

Mis à jour par Frédéric Péters il y a plus de 6 ans

Aussi, côté ingenico ils ne peuvent pas recevoir l'adresse de notification serveur (callback / automatic_return_url) dans la requête, donc en présence de plusieurs régies c'est nécessaire de passer par de la notif de paiement via le navigateur, donc prise en compt eici.

#4

Mis à jour par Benjamin Dauvergne il y a environ 6 ans

En fait ça dépend si le retour synchrone (via navigo de l'utilisateur) est signé ou pas, certains backend signent d'autres pas, l'information doit être uniquement utilisée si elle est signée. Donc oui on pourrait partager le code dans Return et Callback sans trop de soucis, eopayment plaçant l'information de signature dans response.signed.

#5

Mis à jour par Benjamin Dauvergne il y a environ 6 ans

Ticket simple et assignable à n'importe qui (juste déplacer du code s'assurer au niveau de la couverture des tests que c'est testé).

#6

Mis à jour par Frédéric Péters il y a environ 6 ans

  • Assigné à mis à Frédéric Péters

Ticket simple et assignable à n'importe qui (...)

Je me le prends quand même…

#7

Mis à jour par Frédéric Péters il y a environ 6 ans

#8

Mis à jour par Benjamin Dauvergne il y a environ 6 ans

On perd complètement ce bout de comportement:

        if payment_response.result in (eopayment.PAID, eopayment.ACCEPTED):
            messages.info(request, regie.get_text_on_success())

Ce n'était pas important ? Dans le cas contraire il faudrait quand même récupérer des bouts de response.

#9

Mis à jour par Frédéric Péters il y a environ 6 ans

Non ça doit être une erreur, merci.

#10

Mis à jour par Frédéric Péters il y a environ 6 ans

Voilà avec un test comme quoi le message de réussite apparait bien.

#12

Mis à jour par Frédéric Péters il y a environ 6 ans

  • Statut changé de En cours à Résolu (à déployer)
commit f860a552c2cdd2da2cb8076eca068b3b81563a62
Author: Frédéric Péters <fpeters@entrouvert.com>
Date:   Mon Feb 19 13:54:48 2018 +0100

    lingo: handled signed responses on the return URL (#19709)
#13

Mis à jour par Frédéric Péters il y a plus de 5 ans

  • Statut changé de Résolu (à déployer) à Solution déployée

Formats disponibles : Atom PDF