Produits Entr'ouvert » Publik

En sachant que le paiement direct d'un montant, sans passer par le panier, a été commandé et fait pour Arles.

On peut se dire qu'on arrête cette pratique, qu'après l'ajout du montant dans le panier on invite l'usager de se rendre sur la page du panier et payer.

Et j'y donne mon opinion, je me suis engouffré dans cet essai de camouflage du panier parce que ça me fait bizarre cette histoire de panier dans Publik par rapport à ce qui se fait ailleurs : quand je fais des courses sur internet je remplis un panier puis je le paie ok, quand je paie une facture en ligne je procède directement au paiement sans voir un panier, my 2 cents.

Par ailleurs il y a aussi la notion de "paiement direct" ou on paie un item sans passer par l'ajout dans le panier.

IMHO, on doit pouvoir supporter les deux, mais en définissant strictement les parcours.

Plus généralement les collectivités publiques doivent faire le lien de bout en bout entre les paiements et les factures et le panier nous en empêche, à l'origine c'est uniquement une demande belge, aucune ville française n'a demandé de panier.

Metz, aujourd'hui même.

En sachant que le paiement direct d'un montant, sans passer par le panier, a été commandé et fait pour Arles.

Si ça a été fait, ça fonctionne, et donc rien à faire ?

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

En sachant que le paiement direct d'un montant, sans passer par le panier, a été commandé et fait pour Arles.

Si ça a été fait, ça fonctionne, et donc rien à faire ?

Je sens le sarcasme, mais donc non on ne peut pas dire que ça fonctionne. Ça marche en apparence mais ça casse tous les cas d'erreur et en crée des bizarres où quand on revient sur le portail on va voir apparaître les erreurs qu'on aurait du voir avant.

Pas de sarcasme, je ne sais pas ce qui a pu être fait pour assurer le cas "paiement direct"; je connais juste le fonctionnement panier usuel (https://doc-publik.entrouvert.com/admin-fonctionnel/les-tutos/paiement/), le paiement de facture, et ma proposition pour gérer le paiement "anonyme" (dans #9039 et messages "Paiement en ligne obligatoire pour les collectivités" sur la liste).

Et donc je me répètre, si le cas "paiement direct" est déjà géré, c'est super et c'est ça qu'il faut pour la situation présente.

Et donc, à parler "collecter les besoins, analyser, tout ça" dans #32239, au plus simple pour commencer, ce serait de déjà avoir une idée de ce qui existe aujourd'hui, Serghei, tu peux en dire plus ?

une idée de ce qui existe aujourd'hui

Donc, dans a7076e6e1, deux choses : une URL de paiement direct, "lingo/item/(?P<item_id>\d+)/pay" et dans le retour de l'API d'ajout au panier cette URL. Ce qui permet dans un monde rêvé, en passant une URL de retour, de faire l'aller-retour wcs-combo-site de paiement-combo-wcs.

Deux choses :

• ça idéalise les communications, en misant tout sur l'idée que le callback du site de paiement soit plus rapide que l'usager redirigé vers wcs.
• ça nécessite que l'usager soit connecté.

J'ai abordé ce second point sur la liste de discussion (12 mars 16h39), pour le premier, je notais la nécessité d'avoir une vue sur combo pour faire patienter l'usager, quelques secondes le temps que le callback arrive (et donc aussi un petit appel ajax pour voir si le callback est arrivé), avant de le rediriger vers le next_url.

Comme on a donc une vue côté usager, on peut l'exploiter également en situation d'erreur, pour informer l'usager qu'il doit éventuellement retenter le paiement, ce qui permet de ne pas faire porter ça côté workflow w.c.s.

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

une idée de ce qui existe aujourd'hui

Donc, dans a7076e6e1, deux choses : une URL de paiement direct, "lingo/item/(?P<item_id>\d+)/pay" et dans le retour de l'API d'ajout au panier cette URL. Ce qui permet dans un monde rêvé, en passant une URL de retour, de faire l'aller-retour wcs-combo-site de paiement-combo-wcs.

Deux choses :

• ça idéalise les communications, en misant tout sur l'idée que le callback du site de paiement soit plus rapide que l'usager redirigé vers wcs.
• ça nécessite que l'usager soit connecté.

J'ai abordé ce second point sur la liste de discussion (12 mars 16h39), pour le premier, je notais la nécessité d'avoir une vue sur combo pour faire patienter l'usager, quelques secondes le temps que le callback arrive (et donc aussi un petit appel ajax pour voir si le callback est arrivé), avant de le rediriger vers le next_url.

À vrai dire cette vue serait nécessaire aussi pour le panier, on pourrait en faire la vue général de retour post-paiement; à noter que pour les APIs qui signent le retour synchrone on peut se passer d'attendre le retour asynchrone.

Comme on a donc une vue côté usager, on peut l'exploiter également en situation d'erreur, pour informer l'usager qu'il doit éventuellement retenter le paiement, ce qui permet de ne pas faire porter ça côté workflow w.c.s., on pourrait même notifier immédiatement (c'est peut-être déjà le cas, il me semble qu'au niveau de l'API je signale que le retour synchrone était signé).

Il y a de toute façon une race condition qu'on ne peut pas contourner, il n'y a que via les systèmes de tokenization où on dispose d'un web-service qui permet de déclencher réellement le paiement qu'on serait tranquille (on a un retour synchrone du résultat du paiement). Sur la plupart des sites de paiement les paniers/factures sont bloqués tant qu'un retour n'a pas été reçu (à Nanterre via SAGA/Tipi web-service, ça dure 10 minutes).