🐛(backend) cancel and refund installments to update with response instead of notification in payment backends #993
+212
−1,160
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jonathanreveille
force-pushed
the
feat/add_webhook_url_to_refund_transaction
branch
6 times, most recently
from
8cc921c to
48fc29d
Compare
jonathanreveille
changed the title
jonathanreveille
changed the title
jonathanreveille
force-pushed
the
feat/add_webhook_url_to_refund_transaction
branch
from
48fc29d to
d5db896
Compare
jonathanreveille
force-pushed
the
feat/add_webhook_url_to_refund_transaction
branch
7 times, most recently
from
d5547b7 to
c7536e9
Compare
jonathanreveille
force-pushed
the
feat/add_webhook_url_to_refund_transaction
branch
5 times, most recently
from
3ad2e5c to
7cb8f73
Compare
kernicPanel
approved these changes
Jan 7, 2025
jbpenrath
reviewed
Jan 8, 2025
wilbrdt
reviewed
Jan 8, 2025
With the actual payment provider backend we are using (Lyra), it seems like we don't get the events through our notification URL when the action is 'refund'. It's problematic because we use the notifications to update our objects. After couple of attempts to add the ipnTargetUrl into the payload of the cancel/refund request, it was not possible to receive the event afterwards. Knowing that, we now update our objects once we receive the response from the call of that endpoint. Only for cancel or refund situation, we don't rely on the notification anymore. Fix #793
jonathanreveille
force-pushed
the
feat/add_webhook_url_to_refund_transaction
branch
from
7cb8f73 to
bc1e1b0
Compare
We are now using Lyra as a payment backend. We have discovered that Lyra does not let us handle through notifications our refunded installments and forces us to use the response of that call. To mimick the behavior, we have decided to change the behavior as well of the dummy payment backend to update the objects once we call the method to cancel or refund an installment for an order.
The `OrderGeneratorFactory` used for the debug payment view was not appropriate because it creates a transaction when the state of the order in in pending payment. When we create a payment with the debug view, and we want to refund it, the method `get_transaction_references_to_refund` would find 2 different transactions with the same amount to refund. Only one out of two is known to the payment provider, and thus, it would raise an error while attempting to refund the order from the backoffice of Joanie.
jonathanreveille
force-pushed
the
feat/add_webhook_url_to_refund_transaction
branch
from
bc1e1b0 to
bb96253
Compare
wilbrdt
approved these changes
Jan 10, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Purpose
With the actual payment provider backend we are using (Lyra), it seems like we don't get the events through (
handle_notification) on our notification URL when the action is 'refund'. It's problematic because we use the notifications to update our objects once there is an event that occurs on the payment backend.After couple of attempts to add the
ipnTargetUrlinto the payload of the cancel/refund request, it was not possible to receive the event afterwards.Knowing that, I've decided to update the objects after the call with the response back from the payment provider. The payment provider itself suggested us to use the response directly to update our objects once calling the method
cancel_or_refund.Proposal
cancelOrRefundfrom Lyra Backend to update our objects when refund or cancel is done ( and refactor mail sending when order is fully refunded).DummyPaymentBackend.DebugPaymentViewto avoid creating 2 transactions when using theOrderGeneratorFactory