Project

General

Profile

Development #26914

Paiment différé à une date arbitraire

Added by Emmanuel Cazenave 7 months ago. Updated 7 months ago.

Status:
Nouveau
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
02 Oct 2018
Due date:
% Done:

0%

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

Description

Actuellement le paiement différé est possible dans publik (au moins avec système systempayv2, pour les autres protocoles, je ne sais pas).

Il faut configurer la régie de paiement avec "vads_capture_delay: x" ou x est un nombre de jour qui décale la date de remise en banque de x jours par rapport au moment de la création de la transaction.

Le besoin ici est de pouvoir définir une date de remise en banque totalement arbitraire (cette date étant calculée dans le workflow).
Définir un vads_capture_delay dans une régie de paiement ne permet pas d'atteindre cet objectif.


Related issues

Related to EOPayment - Development #26992: Paiement différé à une date arbitraire Solution déployée 04 Oct 2018
Related to Combo - Development #27045: Paiement différé à une date arbitraire Solution déployée 05 Oct 2018

History

#1 Updated by Frédéric Péters 7 months ago

Mais il faut l'usager devant son ordi pour démarrer la transaction; donc on parle juste ici d'envoyer un message à un moment pour lui dire "reviens, faut payer" ?

#3 Updated by Emmanuel Cazenave 7 months ago

J'explique peut-être un peu mieux ici : #25351

#4 Updated by Benjamin Dauvergne 7 months ago

Il y a forcément un ticket à ouvrir sur eopayment ici (pas sur Publik en fait), ajouter un capture_date à Payment.request(), si le backend le supporte on calcule par exemple une valeur pour vads_capture_delay sinon on crash. Coté lingo il faut voir comment initialiser ça, je ne sais où mais vraisemblable qu'il faut garder ça au niveau du BasketItem (et empêcher de payer des Items avec des dates de remise1 différentes):

Aussi j'attire l'attention sur le fait que le mode de remise "manuel" chez Payzen n'a aucun intérêt pour nous (ça veut dire qu'un agent vient dans le BO pour déclencher le prélèvement de l'argent), il n'y a pas d'API pour faire cela (par contre il y a une API "REST" et "SOAP" pour faire cela, mais c'est sur le mode Stripe, i.e. il faut présenter des IHMs à payzen dans nos UIs, en échange on obtient un token qui représente le numéro de CB des gens et on appelle l'API avec cela, c'est malheureusement en dehors du spectre de ce que eopayment supporte pour l'instant).

1 La date de remise c'est le moment où l'argent sera prélevé sur le compte

#5 Updated by Emmanuel Cazenave 7 months ago

Aussi j'attire l'attention sur le fait que le mode de remise "manuel" chez Payzen n'a aucun intérêt pour nous (ça veut dire qu'un agent vient dans le BO pour déclencher le prélèvement de l'argent)

Il y au contraire un certain intérêt voir un intérêt certain, le paiement de caution = paiement différé à validation manuelle (cf #25351) (parce que le cas général c'est caution non prélevée au final donc aucune action nécessaire de la part de l'agent).

#6 Updated by Benjamin Dauvergne 7 months ago

Emmanuel Cazenave a écrit :

Aussi j'attire l'attention sur le fait que le mode de remise "manuel" chez Payzen n'a aucun intérêt pour nous (ça veut dire qu'un agent vient dans le BO pour déclencher le prélèvement de l'argent)

Il y au contraire un certain intérêt voir un intérêt certain, le paiement de caution = paiement différé à validation manuelle (cf #25351) (parce que le cas général c'est caution non prélevée au final donc aucune action nécessaire de la part de l'agent).

Je pensais qu'on préférerait un système automatique ou au moins contrôlable depuis les workflows, mais soit.

#7 Updated by Emmanuel Cazenave 7 months ago

Benjamin Dauvergne a écrit :

Je pensais qu'on préférerait un système automatique ou au moins contrôlable depuis les workflows, mais soit.

J'ai rien contre, mais comme tout ça c'est pour hier ...

#8 Updated by Emmanuel Cazenave 7 months ago

#9 Updated by Emmanuel Cazenave 7 months ago

Also available in: Atom PDF