Produits Entr'ouvert » w.c.s. » Au quotidien

D'un côté j'ai l'impression que tu voudrais pouvoir avoir une régie dans laquelle, par exemple, le paramètre "siret" ne serait pas défini, et que celui-ci se trouve dès lors définissable dans les options de workflow présentées.

De l'autre je ne vois pas du tout comment ça répond aux cas d'usage présentés.

Par ailleurs je trouve ce niveau d'indirections un peu trop élevé (formulaire -> workflow -> régie -> option du système de paiement).

Frédéric Péters a écrit :

D'un côté j'ai l'impression que tu voudrais pouvoir avoir une régie dans laquelle, par exemple, le paramètre "siret" ne serait pas défini, et que celui-ci se trouve dès lors définissable dans les options de workflow présentées.

Mauvais exemple parce que siret c'est typiquement un paramètre qu'on définit une fois pour toute. Dans les APIs de paiement j'ai des paramètres stables dont on dira que c'est plutôt de la configuration -- "siret" par exemple -- mais aussi des paramètres qui vont changer à chaque transaction. Je pourrai différencier les deux par soucis de clarté dans la présentation mais ça ne simplifiera pas le problème que ces paramètres sont différents pour chaque backend, qu'il y en a pleins et qu'il faudrait pouvoir leur attribuer des valeurs extraites du formulaire et/ou individuellement pour un formulaire.

De l'autre je ne vois pas du tout comment ça répond aux cas d'usage présentés.

Je ne sais pas de quel cas d'usage tu parles; mon problème c'est que j'ai les messages de notification envoyés par SystemPay (ex. SPPLUS) au régisseur qui ne contiennent aucune information sur le paiement sinon son montant, pour changer cela il faut pouvoir faire remonter des informations du formulaire vers l'appel au web-service de paiement et malheureusement ce sera jamais pareil (en général) à la fois dans le formulaire mais aussi dans les APIs ou les même champs ne sont pas toujours disponibles.

Comme pour moi le maillon faible de la chaine c'est w.c.s. (on est pas certain de recevoir une notification de la plateforme de paiement, c'est du best-effort) il faut qu'un maximum d'informations soient transmises à la plateforme de paiement. En plus leur backoffice est mieux foutu pour retrouver un paiement, les filtrer, les trier, etc...

Par ailleurs je trouve ce niveau d'indirections un peu trop élevé (formulaire -> workflow -> régie -> option du système de paiement).

On pourrait supprimer le concept de régie sans trop de soucis et déporter toute la mécanique dans le status item de création de facture. Outre que ça me parait un travail inutile vu qu'actuellement ça fonctionne, on ne gagne pas grande chose parce que la régie on la configure une fois pour toute et puis on y touche plus et garder les régies ça peut-être intéressant si on envisage d'avoir une vrai partie backoffice qui permette de traiter les factures et les transactions; mais je n'ai pas l'impression que ce soit dans les tuyaux.

Après avoir supprimer les régies je ne vois pas comment aller plus loin, à moins d'intégrer le code d'eopayment dans auquotidien ou w.c.s.

Si d'un côté on a des paramètres qui ne changent pas, comme le SIRET, et de l'autre des paramètres qui changent à chaque transaction, pour moi la voie logique est d'avoir les premiers comme allant dans la configuration des régies, et les seconds dans la configuration de l'action d'ajout de paiement (comme l'est le montant du paiement, par exemple).

À regarder le code, ce serait donc à cette ligne qu'il faudrait passer les informations supplémentaires que tu voudrais, nom, prénom, etc. :

(order_id, kind, data) = payment.request(amount, next_url=url)

Après je pense avoir capté un peu ta motivation, tu as envie de laisser descendre toute la complexité et la diversité des API de paiement dans w.c.s. (je cite "ces paramètres sont différents pour chaque backend", "'il y en a plein"), et moi je n'ai pas du tout envie de ça, j'ai envie d'une API qui définisse la couche d'abstraction nécessaire et le niveau de détail utile à w.c.s., i.e. s'il est utile pour la majorité des systèmes de paiement de remonter "nom, email, téléphone", que ces paramètres soient explicitement définis, plutôt que de les voir suinter à travers l'API.

redmine@entrouvert.com écrivait:

À regarder le code, ce serait donc à cette ligne qu'il faudrait passer
les informations supplémentaires que tu voudrais, nom, prénom, etc. :

(order_id, kind, data) = payment.request(amount, next_url=url)

Oui.

Après je pense avoir capté un peu ta motivation, tu as envie de
laisser descendre toute la complexité et la diversité des API de
paiement dans w.c.s. (je cite "ces paramètres sont différents pour
chaque backend", "'il y en a plein"), et moi je n'ai pas du tout envie
de ça, j'ai envie d'une API qui définisse la couche d'abstraction
nécessaire et le niveau de détail utile à w.c.s., i.e. s'il est utile
pour la majorité des systèmes de paiement de remonter "nom, email,
téléphone", que ces paramètres soient explicitement définis, plutôt
que de les voir suinter à travers l'API.

Ça me va très bien mais ce n'était pas dans tes premiers propos;
j'ajoute name, email, telphone, info1, info2 et info3 comme paramètre de
payment.request() et je les pousserai vers l'API de paiement quand ce
sera possible.

Je pense que ça me va bien ainsi, mais de quels premiers propos parles-tu ?, j'ai peut-être oublié un argument important.