Bug #115823
openbaskets: micmac sur la notification du paiement
0%
Description
Depuis une démarche:
1. on crée un panier via /api/regie/<regie>/baskets/ avec payer_external_id=abcd pour l'usager connecté
2. on crée une ligne de panier sur /api/regie/foo/baskets/lines/<line_uuid>/ avec validation_callback_url à URL_1 et payment_callback_url à URL_2
3. on ajoute un item avec un montant,etc.. à cette ligne
4. on renvoie l'usager sur {{ lingo_url }}/basket/
5. l'usager valide son panier, on reçoit bien la notification de validation sur URL_1 avec le lien vers l'API pour récupérer le PDF de la facture
6. l'usager paie la facture, on reçoit une notification de paiement quasi vide sur @URL_2@amathias
Ce qui se passe c'est que Basket.signal_paid_invoice() appelle Basket.notify(payload=payment.get_notification_payload() if payment else None) sauf que ce payment n'est pas le paiement venant d'avoir lieu mais le résultat de payment = basket.make_payments_with_credits() qui en l'occurrence ne renverra jamais rien pour un paiement unitaire.
Le chemin normal de notification d'un paiement d'une facture serait dans Payment.make_payment() qui appelle à son tour Invoice.notify() avec le payload de paiement, sauf que ça suppose que la facture porte ait un attribut payment_callback_url ce qui n'est pas le cas et semble incompatible avec l'idée d'une URL de notification par ligne de panier.
- dans Transaction.handle_backend_response() conserver le paiement créé et le passer en paramètre lors de la notification des paniers: @Basket.signal_paid_invoice(invoice, payment)@amathias
- dans
Basket.signal_paid_invoice()notifier du paiement classique par CB, et de l'éventuel paiement par crédit si il a eu lieu (et sinon ne pas notifier ce cas du tout, contrairement à ce qui est fait actuellement)
PS: tout ça dans le cadre de la mise en place du paiement pour Nice, #115641 qui demande du paiement unitaire de tickets d'entrée