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

feat: adding extra information to payment processor response #8

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

andrey-canon
Copy link
Collaborator

Description

This will add user basic information to the payment processor response and also will associate the basket if it's possible.

Check last records in https://edunext.ecommerce.stage.nelp.gov.sa/admin/payment/paymentprocessorresponse/

This will add user basic information to the payment processor response and also will associate the basket if it's possible.
finally:
verification_response.update({

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I test this in queries and its working nice.
image


if status == PaymentStatus.FAILURE:
return redirect(reverse('payment_error'))
if status == PaymentStatus.PENDING:
elif status == PaymentStatus.PENDING:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is it better elif than the previous if ?, this is only curiosity of the change

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in this case it doesn't make any difference, probably pylint errors since that elif is after a return statement , but this is part of a testing that I made so I shouldn't have included

@@ -248,21 +269,19 @@ def get(self, request, encrypted_resource_path=None):
check_status = self._get_check_status(request)

try:
status = PaymentStatus.PENDING

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did you remove this default?
Is there not a case where the default, if check_status status is false, verify_status does not return a status?

Copy link
Collaborator Author

@andrey-canon andrey-canon Sep 7, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't remove that, I consider this is as part of the initial conditions so I moved that line here

verification_response.get('merchantTransactionId')):
transaction_id = verification_response['merchantTransactionId']

if verification_response and 'merchantMemo' in verification_response:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think is better check if isinstance(verification_response, dict) . Maybe this avoid if by x or y reason the

def _verify_status(self, resource_path):

doesn't return a dict for response...

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That could be possible if someone makes a big change in the _verify_status method and that will require multiple code changes, one of them could be your suggestion, however the current implementation should be according to the current code and not suppositions, the method returns this that is a dictionary, if that isn't the case the method will fail here so I consider isinstance(verification_response, dict) unnecessary or the response is a dict or the code fail before

return self._handle_pending_status(request, encrypted_resource_path, resource_path)

basket_id = OrderNumberGenerator().basket_id(verification_response['merchantMemo'])
basket = self._get_basket(basket_id)

transaction_id = verification_response['id']
Copy link

@johanseto johanseto Sep 7, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand why not all transaction_id are with the id? I mean this line is not inside and if block, and it's the last one that changes.
This also happens in the current main implementation.
The only reason is that something else failed before this line and transaction_id was set to verification_response['merchantxxxx']

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actully the correct basket submitted are set with the id that send processor.
2023-09-07_13-41
And the failed to save the merchantxxx in the transaction_id.
image

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

me neither

Copy link

@johanseto johanseto Sep 7, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@andrey-canon what do you think in that behavior is ok that good transactions keep the id(processor sent) and the others keep the 'merchantxxxx' in transaction_id??

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

personally I prefer to keep the same transaction id for all the operations, it's easier to filter error and success cases, however that is out of the scope of this pr and I would like to keep changes at minimum

@johanseto johanseto self-requested a review September 7, 2023 22:14
Copy link
Collaborator

@omar-nelc omar-nelc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. Thanks @andrey-canon!

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.

3 participants