Produits Entr'ouvert » EOPayment

Ok il faut utiliser return_url_template pour renvoyer le order_id.

Benjamin Dauvergne a écrit :

Ok il faut utiliser return_url_template pour renvoyer le order_id.

Je trouve que ça marche bien en utilisant simplement return_url, patch wip incoming.

Valentin Deniaud a écrit :

Premier jet, avec quelques remarques :

• Je ne fais que du python3, sauf avis contraire.

• que les tests ne s'exécutent qu'en python3 (ça c'est fait)
• que le module ne soit déclaré qu'en python3 dans init.py (ça non)

• J'ai mis keyware comme nom, mais ça devrait à mon avis être emspay, non ?
  • D'ailleurs je me demande bien ce que c'est Keyware par rapport à EMS, si quelqu'un sait.

Aucune idée, je ne comprends pas vraiment le lien entre les deux non plus, si tu finis par trouver tu peux à la l'écrire dans une docstring si ça a un intérêt.

• La dénomination « transaction_id » présente partout est un joyeux pataquès : ça ne veut pas dire la même chose entre eopayment et lingo, et également à l'intérieur même de ces modules. J'espère avoir réussi à correctement rétro-ingénier le truc, mais je le note pour que ça soit regardé à la relecture.

Ça ne veut rien dire du tout du coté des systèmes de paiement non plus :/ Ce sont tous des mots creux comme order_id, request_id, transaction_id, etc... Dans ems il y a aussi une notion de transaction (le paiement lui même je suppose) et d'order (une commande/facture demandant un paiement), mais jamais les informations utile, genre est-ce qu'ils sont capable de bloquer la création d'un ordre pour un merchant_order_id existant ou payé et/ou de nous renvoyer le même order_id (et est-ce qu'on peut relancer le paiement sur un même order_url). Fonctionnellement la doc est super légère mais c'est un peu toujours pareil.

• Il n'y a pas de gestion des exceptions autour de payment.request dans lingo, ticket ? (payfip_ws lève déjà des exceptions dans cette méthode, c'est pas moi qui ait commencé)

Tu peux oui.

Sinon, ce qu'il reste (au moins) à faire :

• Implémenter l'annulation (quand à la validation, je ne sais ni à quel moment ça sert ni si ça sera utilisé, donc par défaut je ne m'y intéresse pas).

A priori les cas d'utilisation de la validation/annulation venaient initialement d'IMIO donc il y a des chances que ça devienne nécessaire mais je laisserai Fred dire.

• Tester avec un paiement qui marche : les accès fournis par EMS ne permettent que d'avoir des erreurs. Je leur ai envoyé un mail.

Ok, faudra attendre ça pour vraiment valider.

Merci pour le coup d'œil.

Benjamin Dauvergne a écrit :

que le module ne soit déclaré qu'en python3 dans init.py (ça non)

Yep, je fais ça.

et est-ce qu'on peut relancer le paiement sur un même order_url

Non et c'est assez logique : un order_id est généré à chaque tentative de paiement, et est présent dans order_url. Donc une fois une tentative de paiement effectuée, une requête sur order_url ne réaffiche pas la page de paiement mais renvoie la même réponse que l'issue de la tentative.

est-ce qu'ils sont capable de bloquer la création d'un ordre pour un merchant_order_id existant ou payé et/ou de nous renvoyer le même order_id

Je ne comprends pas bien d'où on sort ce merchant_order_id et à quoi il sert. Ce serait un identifiant généré par nous ? Qui identifie quoi ?
En fait, c'est lié à une autre histoire d'ids que j'ai le sentiment de ne pas avoir comprise : dans le modèle Transaction de lingo, il y a order_id et bank_transaction_id. Donc en extrapolant sur la terminologie, bank_transaction_id doit être le order_id fourni par EMS. Et Transaction.order_id généré par nous. Pourquoi en avoir deux, pourquoi ne pas se baser seulement sur le order_id de EMS ?

Valentin Deniaud a écrit :

Merci pour le coup d'œil.

Benjamin Dauvergne a écrit :

que le module ne soit déclaré qu'en python3 dans init.py (ça non)

Yep, je fais ça.

et est-ce qu'on peut relancer le paiement sur un même order_url

Non et c'est assez logique : un order_id est généré à chaque tentative de paiement, et est présent dans order_url. Donc une fois une tentative de paiement effectuée, une requête sur order_url ne réaffiche pas la page de paiement mais renvoie la même réponse que l'issue de la tentative.

Ouaip mais il y a l'autre endpoint payment links qui fait ça et c'est pas bien clair la différence entre ces deux URLs de paiement à part qu'une permet de revenir pour payer plusieurs fois jusqu'à ce que ça aboutisse et pas l'autre.

est-ce qu'ils sont capable de bloquer la création d'un ordre pour un merchant_order_id existant ou payé et/ou de nous renvoyer le même order_id

Je ne comprends pas bien d'où on sort ce merchant_order_id et à quoi il sert. Ce serait un identifiant généré par nous ? Qui identifie quoi ?

Un numéro de facture par exemple.

En fait, c'est lié à une autre histoire d'ids que j'ai le sentiment de ne pas avoir comprise : dans le modèle Transaction de lingo, il y a order_id et bank_transaction_id. Donc en extrapolant sur la terminologie, bank_transaction_id doit être le order_id fourni par EMS. Et Transaction.order_id généré par nous. Pourquoi en avoir deux, pourquoi ne pas se baser seulement sur le order_id de EMS ?

Certains backend demandent de recevoir un numéro (la plupart d'entre eux) et eopayment le génère, d'autres le génèrent eux même (PayFiP WS, EMS), dans les deux cas c'est le premier élément renvoyé par payment.request(...) et c'est conservé dans Transaction.order_id. bank_transaction_id selon le connecteur c'est la même chose que order_id mais dans d'autres cas c'est le numéro d'autorisation du réseau CB (sips2) ou une combinaison d'autres trucs (dans payfip_ws c'est order_id + refdet) en fait ça ne sert pas à grand chose si dans les BO on peut toujours chercher par order_id.

Benjamin Dauvergne a écrit :

Valentin Deniaud a écrit :

Je ne comprends pas bien d'où on sort ce merchant_order_id et à quoi il sert. Ce serait un identifiant généré par nous ? Qui identifie quoi ?

Un numéro de facture par exemple.

De ce que je lis du code j'en déduis que tu disais ça pour info mais que ça ne concerne pas ce backend de paiement.

Ouaip mais il y a l'autre endpoint payment links qui fait ça et c'est pas bien clair la différence entre ces deux URLs de paiement à part qu'une permet de revenir pour payer plusieurs fois jusqu'à ce que ça aboutisse et pas l'autre.

Ça me paraît assez clair, d'un côté il y a /orders/ qui pour des infos te donne un lien de paiement, de l'autre il y a /paymentlinks/ qui pour des infos te donne un lien qui permet d'être redirigé vers un lien de paiement, dans les cas où tu ne peux pas redonner toi-même les infos à chaque fois (cas d'usage qui ne nous concerne pas, donc). En tout cas pour les deux on a un order_id qui change à chaque tentative.

si dans les BO on peut toujours chercher par order_id

Là il y a peut-être un truc à faire, le BO de EMS ne permet pas de chercher par order_id, seulement par... merchant_order_id. Donc on pourrait générer un id à chaque requête, le passer par merchant_order_id, puis le mettre dans Transaction.order_id, et mettre le order_id de EMS dans Transaction.bank_transaction_id ? Enfin bon, tout ça pour contourner la limitation d'un BO...
Sinon je mets order_id pour les deux et roulez jeunesse.

Valentin Deniaud a écrit :

Benjamin Dauvergne a écrit :

Valentin Deniaud a écrit :

Je ne comprends pas bien d'où on sort ce merchant_order_id et à quoi il sert. Ce serait un identifiant généré par nous ? Qui identifie quoi ?

Un numéro de facture par exemple.

De ce que je lis du code j'en déduis que tu disais ça pour info mais que ça ne concerne pas ce backend de paiement.

Ça concerne ce backend, mais ce n'est pas exploitable via eopayment/lingo.

Là il y a peut-être un truc à faire, le BO de EMS ne permet pas de chercher par order_id, seulement par... merchant_order_id. Donc on pourrait générer un id à chaque requête, le passer par merchant_order_id, puis le mettre dans Transaction.order_id, et mettre le order_id de EMS dans Transaction.bank_transaction_id ? Enfin bon, tout ça pour contourner la limitation d'un BO...
Sinon je mets order_id pour les deux et roulez jeunesse.

Pfiou.. oui si ça marche.

C'est un retour qu'on peut faire à IMIO qui l'entendra certainement.

PS: pour être clair le patch ne pourra pas intégrer eopayment tant qu'on ne pourra pas tester ça de bout en bout en vrai (ça ne sert un peu à rien), on peut bien sûr leur annoncer fièrement qu'on a fini mais qu'il est impossible de tester.

• mettre les liens vers la doc en commentaire dans le code, pour un truc aussi obscure ça fait toujours plaisir

• @staticmethod
      def _clean_amount(amount):

  devrait aller dans PaymentCommon je pense (en classmethod).