Open WhyNotHugo opened 3 years ago
Hello, sorry for the late response, because of some reason I never noticed this issue notification neither the other one.
As you stated, I'm seeing that the self.create_payment
is being created unconditionally. You're totally right, two preferences aren't needed.
I'm using this library along with a customized version of an old saleor version. I think the way saleor handled the payments allowed the tricky behavior to pass without causing any trouble. But let's change it so it can be used in any implementation of django-payments.
How about something like this?
def get_form(self, payment: BasePayment) -> None:
if not payment.id:
payment_data = self.create_payment(payment)
redirect_to = self.get_value_from_response(
payment_data, self.init_point)
payment.change_status(PaymentStatus.WAITING)
payment.save()
raise RedirectNeeded(redirect_to)
redirect_to = self.get_value_from_response(json.loads(payment.extra_data), self.init_point)
raise RedirectNeeded(redirect_to)
If there is not payment.id (the payment has never been saved) we send the preference to mercadopago via create_payment
, we get the the full response from mercadopago and save it in payment.extra_data
, which contains the required payment url in "init_point"
key. If there is a payment.id
(a preference was previously created) we simply redirect the user to the same payment url we received from mercadopago response.
It appears to work, what do you think about it? I may be forget something.
I'm looking into migrating from my own implementation (https://github.com/jazzband/django-payments/pull/232) to yours, especially since yours uses a newer SDK and some newer API endpoints.
I've noticed a big variation that makes things very tricky; when I create a preference, I save its
id
intopayment.transaction_id
. This makes sure I have an externally unique id for each preference, so I'm fully certain that data can be crossed between both systems in case of discrepancy.However, I've noticed that your library does not save anything in
payment.trasaction_id
; you're only saving a the payment's id after you receive a payment confirmation. This can be tricky, because if the confirmation is not received/processed for some reason, there's no way to map thePayment
object to a preference.self.create_payment
is also called unconditaionally viaget_form
, so if the preference had already been created, a second one is created. This can result in two Preferences being created (and paid!), but only one reflected in the database model.I've though about making some changes to use
payment.transaction_id = preference_id
, but I think that would very likely break for you, since your database contains something difference. Do you think there's another fix around this that could work?