Project

General

Profile

Development #32249

Paiements sans voir le panier

Added by Emmanuel Cazenave 8 months ago. Updated 24 days ago.

Status:
Nouveau
Priority:
Normal
Assignee:
-
Category:
Gestion de contenu et thème
Target version:
Start date:
12 Apr 2019
Due date:
% Done:

0%

Patch proposed:
No
Planning:
No
Demande du club utilisateur:
No

Description

Il y a eu un début de travail dans ce sens #25725 dans lequel je me suis engouffré pour tomber sur d'autres interrogations #32239.

Bref ça pourrait commencer par la question veux-t-on pouvoir proposer une démarche de paiement dans laquelle l'usager ne passe pas par la vue panier, est-ce une demande
légitime et qui et quoi et pourquoi.


Related issues

Related to Lingo - Development #32239: Notifier lors d'un paiement en erreur Rejeté 12 Apr 2019
Related to Lingo - Support #36876: Paiement sans authentification : vue d'attente après paiement sur la plateforme de paiement Nouveau 13 Oct 2019
Related to Lingo - Development #36875: Paiement sans authentification : ajustements dans l'API Nouveau 13 Oct 2019

History

#1 Updated by Serghei Mihai 8 months ago

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.

#2 Updated by Emmanuel Cazenave 8 months ago

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.

#3 Updated by Serghei Mihai 8 months ago

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.

#4 Updated by Benjamin Dauvergne 8 months ago

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.

#5 Updated by Pierre Cros 8 months ago

Metz, aujourd'hui même.

#9 Updated by Frédéric Péters 8 months ago

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 ?

#10 Updated by Benjamin Dauvergne 8 months ago

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.

#11 Updated by Frédéric Péters 8 months ago

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.

#13 Updated by Frédéric Péters 8 months ago

#14 Updated by Frédéric Péters 8 months ago

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 ?

#15 Updated by Frédéric Péters 8 months ago

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.

#16 Updated by Benjamin Dauvergne 8 months ago

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).

#17 Updated by Pierre Cros about 1 month ago

  • Target version set to 2020
  • Category set to Gestion de contenu et thème

#18 Updated by Emmanuel Cazenave 24 days ago

  • Tracker changed from Project management to Development

#19 Updated by Emmanuel Cazenave 24 days ago

  • Related to Support #36876: Paiement sans authentification : vue d'attente après paiement sur la plateforme de paiement added

#20 Updated by Emmanuel Cazenave 24 days ago

  • Related to Development #36875: Paiement sans authentification : ajustements dans l'API added

Also available in: Atom PDF