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

There's no transaction_id for unpaid preferences #4

Open
WhyNotHugo opened this issue Sep 6, 2021 · 1 comment
Open

There's no transaction_id for unpaid preferences #4

WhyNotHugo opened this issue Sep 6, 2021 · 1 comment

Comments

@WhyNotHugo
Copy link

I'm looking into migrating from my own implementation (jazzband/django-payments#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 into payment.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 the Payment object to a preference.

self.create_payment is also called unconditaionally via get_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?

@EduardoZepeda
Copy link
Owner

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.

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

No branches or pull requests

2 participants