comment code

src/Controller/PaymentController.php

@@ -147,6 +147,63 @@ class PaymentController extends AbstractController
         return $this->redirect($captureToken->getTargetUrl());
     }
 
+    /* COMMENT LES FLUX SONT-ILS CREES SUITE A LA CREATION D'UN PAIEMENT PAYZEN ?
+     *
+     *
+     *
+     * CAS 1 : Paiement standard
+     * Deux voies de signalement coexistent :
+     *
+     * Voie 1 : via la notification instantannée payzen.
+     * Un paramètre appelé "URL de notification à la fin du paiement" est configuré dans le backoffice payzen et
+     * est renseigné à payement/notify. Cette valeur est utilisée par payzen, sauf si la variable vads_url_check
+     * est transmise, auquel cas c'est cette dernière valeur qui prime.
+     * Ici, vads_url_check est transmise à la valeur payment/notify/{token}.
+     * Remarque : son usage systématique n'est pas recommandé par Payzen.
+     * L'URL est ainsi captée par NotifyController.php.
+     *
+     * Voie 2 : via la redirection du client.
+     * Cette voie n'est pas garantie (si l'utilisateur ferme son navigateur assez tôt, il ne sera pas redirigé).
+     * A vérifier : l'URL de redirection est la combinaison entre une configuration côté backoffice et
+     * un complément que nous transmettons.
+     * Lorsque la redirection a bien lieu, c'est donc le contrôleur doneAction de PaymentController.php qui est sollicité,
+     * avec une requête au format payement/done/?payum_token={token}
+     *
+     * Remarquons dans ces deux stratégie la présence d'un token permettant l'authentification de l'agent Payzen et
+     * la récupération de l'objet paiement préalablement enregistré en base.
+     *
+     *
+     *
+     * CAS 2 : Paiement récurrent
+     *
+     * Dans le cadre de notre implémentation, un paiement récurrent commence par un paiement initial (occurence n°0).
+     * Pour cette occurence n°0, au niveau du mode de communication, on est sur un processus en apparence similaire au
+     * CAS 1. Un examen minutieux de ce process m'a cependant permis de mettre en évidence des comportements que
+     * je n'ai pas réussi à comprendre :
+     * En ouvrant les vannes pour tester le déclenchement d'une création de flux à chaque notification rattachée
+     * à un paiement récurrent, j'ai observé la génération de pas moins de 5 événements, opérant donc
+     * un accroissement de solde de +750 mona au lieu de +150 mona !!!
+     * - 2 événements via /payement/notify/{token}
+     * - 3 événements après l'execution de la ligne $gateway->execute($status = new GetHumanStatus($token)); dans doneAction.
+     *
+     * Le fonctionnement du module Payum est sans doute très intelligent mais il est trop complexe à maitriser pour moi.
+     * Il fait également appel à des mécanismes dont l'usage systématique est déconseillé par Payzen (utilisation de la variable
+     * vads_url_check).
+     *
+     * Bref. De toute façon, la gestion des notifications successives d'un paiement récurrent ne peut pas être gérée
+     * via les voies 1 ou 2 en l'état.
+     * En effet la variable vads_url_check ne fonctionne pas en mode récurrent et Payzen nous notifie à l'aide
+     * d'une requête post au format de l'"URL de notification à la création d'un abonnement" (mal nommé), configurée à payement/notify,
+     * (mais on aurait pu mettre autre chose pour plus de clarté). Il faut donc créer un controlleur spécifique qui va traiter
+     * cette notification sans disposer du token utilisé par les voies 1 ou 2.
+     *
+     * Voie 3 : le traitement de la requête se fait finalement simplement dans notifyRecurringPaymentAction sans utiliser
+     * les mécanismes complexes de Payum.
+     *
+     * Yvon KERDONCUFF
+     * 26/03/2024
+     */
+
     /**
      * Collects payzen recurring payment payment occurence in place of default payum system.
      *
@@ -195,17 +252,7 @@ class PaymentController extends AbstractController
     }
 
     /**
-     * Ce contrôleur est sollicité lorsque Payzen renvoie le cotisant sur l'URL de retour.
-     *
-     * IMPORTANT : ce contrôleur n'est PAS sollicité directement par Payzen via l'URL de notification.
-     * En effet, le module Payzen écrase (au moins dans certains cas) cette URL en transmettant la route
-     * payum_notify_do via la variable vads_url_check.
-     *
-     * Pour plus de clarté, on gagne à modifier finalement l'URL de retour Payzen dans le backoffice de sorte
-     * à pointer vers notifyAction également (INSTALL.md modifié).
-     *
-     * Comme si ce n'était pas assez compliqué comme ça, les notifications de paiement récurrents n'arrivent
-     * cependant pas à NotifyController et on les capte ici avec le controller notifyRecurringPaymentAction.
+     * Ce contrôleur est sollicité lorsque Payzen renvoie le cotisant sur l'URL de retour,
      *
      * @Route("/payment/done/", name="payment_done")
      */