-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
✨ (backend) Credit card - Enable multiple users to register the same credit card #1008
Open
jonathanreveille
wants to merge
11
commits into
main
Choose a base branch
from
feat/credit_card_shared_accross_users
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
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
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
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.
We want to able a group of organization members to pay their orders with a common credit card. We discovered that we cannot do this action because of the unicity of the token value received from the payment provider when tokenizing a credit card. That lead us to block a new entry of the same credit card for another user. To enable this, we have decided to track down the different users who will use the same credit card, and by this, introduce the field owners that is a ManyToMany relationship to the User model.
Since the field owner has disapeared, we needed to update the credit card factory to add multiple owners if they are passed in testing.
We needed to change the required owner filter to be able to filter through the field `owners` instead.
With the new relationship, we need to update every line of code where we create a credit card by adding the owner afterwards.
Update every test that required changements due to the new field `owners` in the model CreditCard.
Update the line of code where we create the credit card in the debug view of a payment.
jonathanreveille
force-pushed
the
feat/credit_card_shared_accross_users
branch
from
January 10, 2025 16:58
4cc968d
to
4f502f6
Compare
We should add owners to the credit card if the token generated by the payment provider already exists on our side.
jonathanreveille
changed the base branch from
main
to
feat/add_webhook_url_to_refund_transaction
January 10, 2025 17:09
jonathanreveille
changed the base branch from
feat/add_webhook_url_to_refund_transaction
to
main
January 10, 2025 17:09
New tests showing what happens when promoting the card for example. And also, what happens when tokenizing a same card by 2 differents users. They should both be owners, and only 1 card should exist.
jonathanreveille
force-pushed
the
feat/credit_card_shared_accross_users
branch
from
January 10, 2025 17:19
9904596
to
0aa5b41
Compare
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
This PR will solve this issue
We want members to be able to use the same credit card to use for their purchases.
We had a constraint of unicity on the token provided by the payment provider on our database which
blocked that use case.
Proposal
ManyToManyField
Add new logic :