Skip to content
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
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

jonathanreveille
Copy link
Member

@jonathanreveille jonathanreveille commented Jan 9, 2025

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

  • Prepare migration file to pass smoothly to a ManyToManyField
  • Update payment backends
  • Update failing tests
  • Update payment debug view

Add new logic :

  • Change in payment backend tokenizing a credit card, if it already exists, we should just add a new user into the new field owners
  • Add tests to make sure that if a card is promoted, then it is for all owners ( promote, create, delete, edit )

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.
@jonathanreveille jonathanreveille self-assigned this Jan 9, 2025
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 jonathanreveille force-pushed the feat/credit_card_shared_accross_users branch from 4cc968d to 4f502f6 Compare January 10, 2025 16:58
We should add owners to the credit card if the token
generated by the payment provider already exists on our
side.
@jonathanreveille jonathanreveille changed the base branch from main to feat/add_webhook_url_to_refund_transaction January 10, 2025 17:09
@jonathanreveille 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 jonathanreveille force-pushed the feat/credit_card_shared_accross_users branch from 9904596 to 0aa5b41 Compare January 10, 2025 17:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant