Produits Entr'ouvert » Combo

Est-ce que l'URL de callback ne sert qu'au retour "machine" et pas au retour "utilisateur" depuis la page de paiement ? Sur w.c.s. il y avait ce souci (relatif). C'est une bonne chose de séparer les deux.

La même URL est actuellement transmise pour toute une série d'usages (accepturl, declineurl, exceptionurl, cancelurl), mais pas return_url; je n'arrive pas à dire d'un coup d'œil à eopayment si on est ainsi assuré que la distinction machine/usager est correcte.

J'ai l'impression qu'on se place trop bas là, declineurl, etc.. c'est spécifique à un backend. On devrait avoir basiquement deux URLs, l'URL de retour client et l'URL de retour machine. Il faudrait les passer comme tel à eopayment qui se débrouille pour les mettre dans les champs qui vont bien.

A coup de git grep je ne vois aucun des backends utiliser declineurl, accepturl,... je rate quelque chose?
Mais même si on passe des urls de retour machine et utilisateur au backend, c'est à l'application appelant le backend de définir (dans son urls.py) ces urls et traiter les requetes.

Dans l'exemple de Paybox, l'url de callback(donc url machine) est passée en parametre au backend lors de son initialisation et donc quelque soit cette url, je dirais que c'est à lingo de la définir et la gèrer.

• PBX_EFFECTUE, PBX_REFUSE, PBX_ANNULE, PBX_ATTENTE je dirai qu'il faut définir les 4 sur la même page de retour "utilisateur" de lingo; aucune n'est actuellement supportée par eopayment,
• PBX_REPONDRE_A supporté via le paramètre callback dans les options.

Soit tu définis tout ça dans le backoffice soit tu modifies eopayment.

Serghei Mihai a écrit :

Dans l'exemple de Paybox, l'url de callback(donc url machine) est passée en parametre au backend lors de son initialisation et donc quelque soit cette url, je dirais que c'est à lingo de la définir et la gère

Tu peux relever l'URL utilisée par lingo et la recopier dans le backoffice de la banque aussi.

Benjamin Dauvergne a écrit :

Je viens de relire le guide d'intégration, pour Paybox il y 5 URLS définissables pour la transaction ou globalement via le backoffice:

• PBX_EFFECTUE, PBX_REFUSE, PBX_ANNULE, PBX_ATTENTE je dirai qu'il faut définir les 4 sur la même page de retour "utilisateur" de lingo; aucune n'est actuellement supportée par eopayment,
• PBX_REPONDRE_A supporté via le paramètre callback dans les options.

Yep, je passe l'url de callback dans les options de paybox:

{
  "rang": "...", 
  "callback": "https://mesdemarches.fontenay-sous-bois.fr/lingo/callback/4/", 
  "site": "...", 
  "platform": "...", 
  "shared_secret": "....", 
  "identifiant": "..." 
}

Et donc cette url doit répondre un 200.
Les autres urls, PBX_EFFECTUE, PBX_REFUSE, PBX_ANNULE sont définies dans le backoffice paybox, on peut les oublier pour l'instant.

Et donc, c'est bon ? On peut fermer ce ticket où as-tu encore un doute sur quelque chose ?

Il y a deux aspects différents :

• d'une part on peut avoir des éléments à payer qui soient locaux, ou pas.
• d'autre part on peut avoir besoin d'un retour du service de paiement qui soit "humain" (redirection vers l'accuel), ou pas (code 200).

Là tu mélanges les deux et considère que quand c'est des éléments locaux, il faut le retour "humain", et quand c'est des éléments distants, il faut le retour "robot".

Normalement dans les tests le middleware CSRF est déjà désactivé tout seul (en tout cas avec les TestCase Django ça le fait. Vérifié à l'instant sur passerelle, la désactivation n'est pas effective dans les tests qui utilisent webtest, mais les tests qui utilisent le client classique de pytest-django (fixture automatique nommée client) ça marche. Je propose d'utiliser le client classique plutôt que webtest (qui en plus cache les traces ce qui n'est pas bien pratique) à moins qu'on me signale un besoin particulier couvert par celui-ci.

Pour ces tests qui font des POST sans passer par les formulaires qui seraient normalement utilisés par les gens et qui auraient du coup le csrf token correct, pour ces tests, en effet, le client django normal devrait sans doute être utilisé.

Ok.