Bonjour Frédéric,
Pardon de déterrer ce ticket, je me permet de prendre la température qu'en a l'éventuelle intégration de ce moyen de paiement, nous avons récemment eu la demande de deux communes à ce sujet dont Braine-l'Alleud qui compte l'employer, c'est certain. Serait-ce possible d'évaluer le travail qui serait à fournir ?
D'avance merci,
Bien à toi,
Daniel

Valentin Deniaud a écrit :

Premier jet, avec remarques et questions.

Mollie ça fonctionne bien, la doc est top. Quelques 500 aléatoires mais rien de bien méchant.

Le seul problème pour l'instant c'est celui des paiements pas immédiat genre virement. Là de ce que je lis du code de lingo j'ai l'impression qu'on a un statut waiting, où l'usager ne doit pas pouvoir retenter un paiement (?).
Sauf qu'ici, Mollie n'a pas de statut waiting correspondant. Aucun moyen de savoir si l'usager a simplement quitté la page et est revenu sur combo, où si il a sélectionné « virement » puis a été redirigé et a une transaction ouverte dans le BO Mollie...
Je vais me creuser la tête encore un peu là dessus, peut-être que j'ai raté un truc, mais si ces interrogations évoquent quelque chose de déjà rencontré ça m'intéresse.

On parle de virement ou de prélèvement ? J'ai aucun souci pour dire qu'on ne supporte ni l'in ni l'autre sauf si c'est un besoin exprimé par IMIO. Mais de ce que je lis il y a plusieurs statuts sur un objet payment (https://docs.mollie.com/payments/status-changes) dont open et pending (je ne sais pas lequel on obtient dans le cas d'un prélèvement), par ailleurs dans les détails spécifique de la méthode "GET Payment"(https://docs.mollie.com/reference/v2/payments-api/get-payment) on voit qu'il y a encore plus de détails selon la méthode de paiement et notamment pour "Bank Transfer":

consumerAccount : string = Only available if the payment has been completed – The consumer’s bank account. This may be an IBAN, or it may be a domestic account number.

Je dirai que que lorsque Mollie reçoit le virement, ils appelleront le webhook avec le statut "paid" sur l'objet paiement non ? Et même si le webhook n'est pas appelé on peut déjà traité le retour en redirect classique.

Bloquant mais moins, le paramètre description est obligatoire à la création d'un paiement. Je crois qu'on a rien pour faire un truc bien, on peut juste mettre une description dans la configuration du backend, elle sera globale à tous les paiements, bof bof. Trouver un texte général pour que ça passe (« Paiement sur Publik ») ou faire du dev dans lingo, pour à chaque paiement passer un texte généré à la volée sympa (« Nom Prénom - Inscription pour la cantine, Réservation Piscine ») ?

En fait la plupart des backends permettent d'afficher un texte ou en tout cas de personnaliser la page de d'accueil du paiement, ce serait bien d'en faire le tour, d'adapter l'interface d'eopayment en conséquence et de le gérer dans lingo (si on a une régie de recette unique par internet, ce qu'on suggère partout, c'est bien d'indiquer pour quel service on est en train de payer). Mais ce sera pour un autre ticket, ça ne sert à rien d'entamer ça ici.

Et dernier truc, on peut passer un paramètre 'locale'. Si il est omis, la locale du navigateur est utilisée pour la langue de la page de paiement. Est-ce que ça serait mieux de passer explicitement 'fr' ?

Non c'est bien de laisser le site gérer ça avec le navigateur comme on fait nous aussi en fait il me semble, si un jour on implémente de quoi forcer la locale, on s'en occupera.

Relecture¶

            {
                'name': 'payment_methods',
                'caption': _('Allowed payment methods'),
                'type': list,
            },

tu as mis service_url = 'https://api.mollie.com/v2/payments' mais plus loin tu fais

        resp = self.call_endpoint('POST', 'payments', data=body)
....
    def call_endpoint(self, method, endpoint, data=None):
        url = urljoin(self.service_url, endpoint)

que se passe-t-il si les éléments dans metadata={} sont nuls ? ne faudrait-il pas construire metadata en fonction des données vraiment disponible (email, first_name, last_name) ?

Le reste m'a l'air parfait.

Valentin Deniaud a écrit :

Pour le virement, OK pour dire qu'on ne s'en préoccupe pas spécialement tant qu'il n'a pas été évoqué. Effectivement le webhook est appelé sur paid, mon interrogation portait sur ce qu'on devait faire en attendant (actuellement, on dit à l'usager d'attendre, mais le bouton Payer reste accessible, alors qu'on a un statut eopayment.WAITING qui bloque ça, tout en permettant d'annuler et de repayer). On pourrait effectivement aller nous même voir le statut du paiement au moment du redirect, déduire que open + bank_transfer = paiement en attente, mais on a pas l'id de la transaction à ce moment là (on l'a, mais dans lingo, il faudrait pouvoir le passer à eopayement, bref).

Clairement lingo n'est pas prévu pour du paiement avec validation réellement différé ; un cas d'usage qui existe c'est du paiement « à déclenchement différé » via backend.validate()/.cancel() mais ça suppose que la transaction soit dans le statut PAID, ce qui en gros signifie qu'on a eu la validation du processeur de paiement carte bancaire que l'argent est là et le compte existe (ce qui ne veut pas dire qu'au moment de déclencher le paiement ça va fonctionner) donc on y est presque. Le souci avec le prélèvement/virement c'est que clairement le retour ne garantit rien du tout (un peu plus en cas de prélèvement, mais pas tellement).

Les limites de lingo c'est quelque chose qu'on devrait documenter clairement (j'ai le problème aujourd'hui même avec le SICTIAM à Cannes qui veut faire du paiement sans panier à Cannes, ce qui est impossible via TIPI / PayFiP car l'email est obligatoire et tel que le code est écrit le code ne peut venir que du compte lié à la transaction).

Si tu veux ouvrir un ticket ce serait pour clarifier dans eopayment la signification des statuts non-finaux dans eopayment (RECEIVED, ACCEPTED, WAITING), est-ce que le paiement a eu lieu ? est-ce qu'on peut repayer ? annuler ? etc... et ensuite adapter le comportement de lingo en fonction de ce qu'on aura décidé.

Typiquement pour un type de paiement totalement différé on devrait définir d'utiliser uniquement WAITING, ce qui signifierait un truc est en cours mais on ne sait pas si ça sera payé un jour et il faudra prévoir que les démarches ou les connecteurs qui attendent des notifications de paiement le gèrent aussi ("Sur une démarche : ok on attend votre paiement, quand ce sera fait on vous préviendra. ») si possible et sur le portail aussi (via une section "paiement en cours" dans la cellule des paiements). C'est un projet assez long de coordonner tout ça.

En fait la plupart des backends permettent d'afficher un texte

Oui, je le notais ici parce que c'est un paramètre obligatoire contrairement à d'habitude. Je le laisse donc blanc avec required=True, charge à la personne qui fait la config de trouver le bon texte.

Ok, on devra y penser nous dans un premier temps puis ça ira mieux avec l'IHM.

si tu connais la liste depuis leur doc, met la dans 'choices', quand l'interface de configuration arrivera dans lingo ça marchera tout seul (sinon ce champs ne marchera pas du tout).

Je l'ai viré, la moyens de paiement s'activent ou pas via le BO de Mollie, c'est suffisant IMO.

Ok.

tu as mis service_url = 'https://api.mollie.com/v2/payments' mais plus loin tu fais [...] le suffixe payments ne serait-il pas en trop dans service_url ?

Yep, ça passait parce que urljoin('example.com/test', 'test') donne 'example.com/test'.

C'est ce que je me suis dit après coup, mais c'est mieux avec la bonne URL, sur le coup c'est toujours perturbant de faire le "join" dans sa tête et de tomber sur un truc zarbi.

que se passe-t-il si les éléments dans metadata={} sont nuls ? ne faudrait-il pas construire metadata en fonction des données vraiment disponible (email, first_name, last_name) ?

Oui soyons safe.

Ok.

Valentin Deniaud a écrit :

Je te laisse revalider avec le bout de code en plus pour refaire ou pas une requête au moment de la redirection.

Benjamin Dauvergne a écrit :

ici à quoi sert-elle puisqu'il n'y a pas la méthode validate() qui est son pendant pour procéder au paiement ?

Parce qu'ici dans le cas d'un paiement différé, on est notifié par callback quand c'est bon. Pas besoin de méthode validate donc, et mieux que ça il n'est pas possible d'en écrire une (pas d'api qui permette de changer le statut d'un paiement).
Je serais pour garder, j'ai pu tester que ça marchait.

En fait le cas d'usage de validate c'est qu'on demande par défaut une durée quelconque (genre prélever dans 3 mois) et depuis le workflow on déclenche le prélèvement au moment ou quelque chose se passe (genre la location d'une salle s'est passée sans soucis, on annule les arrhes, ou c'est la merde on les prend tout de suite). Le callback n'y change rien.