Open sentry-io[bot] opened 2 years ago
Update:
I wasn't able to get through the order completion using Paypal test account locally or on RC, I get Your order was declined. Please choose another payment method
. I need to check how I can do a successful transaction using Paypal.
The Cybersource is complaining about invalid field data as seen
On the other hand, While I was comparing the data, the only difference I see between a regular refund locally and the refund payload in this issue is that the amount is being sent as a string in this issue whereas while testing locally I could see the amount is a float. This could be a reason for this error since CyberSource is complaining about field data being invalid.
The other thing is, I was testing this through the Refund
button in Django Admin, while this issue was raised through the refund sheet.
Some of the things we might need to compare are how the amount is mentioned in the sheet, And what Successful payment response data we had in Fulfilled Orders
in Django Admin.
Please disregard the part in my above comment where I mentioned the issue might be the amount.
The issue is related to the Transaction Id
, Where Cybersource is complaining about the transaction id being invalid and this one of the reasons this could happen is that the transaction id we are sending for the refund request doesn't exist on Cybersource and this I was able to reproduce locally too by sending a non-existent transaction id in refunds.
The things I'd suggest verifying are:
6637068427226920904262
?transaction_id
Based on point#2, We might also want to see the associated transaction objects with this order in Django Admin. There should ideally be one transaction object having transaction_id
in the data.
@pdpinch Could you try to refund this order through Django Admin, Just to check if there is any issue with the refunds through the sheets flow.
I tried through the django admin and got another 500 error:
I also tried making a PayPal order in RC. I was surprised to find that it points to sandbox.paypal.com and not the live service. Unfortunately, I go the same error as you did.
Hmm, This looks like the same issue, The transaction_id
being sent for refund is invalid as per CyberSource. Could we check on Cybersource dashboard production and verify that there is a transaction entry there with id 6637068427226920904262
?
I think so:
Let me know if there's more information that would be helpful. Or we can Zoom Friday morning.
I think a Zoom call might be helpful to check if we can see any specific logs that might be coming from Paypal or if there is something specific wrong to this transaction only, At this point, seeing the logs, CyberSource seems to be complaining about the transaction_id
which I assumed might not be present in Cybersource transactions but it is there. So there might be something else blocking the refund for a Paypal transaction. If possible, We might also want to fix Paypal transaction in RC to reproduce this error locally.
I put through a PayPal refund through the EBC manually, and I noticed that I had to enter the refund amount. Are we passing the refund amount through the API?
I put through a PayPal refund through the EBC manually, and I noticed that I had to enter the refund amount. Are we passing the refund amount through the API?
Yes, The refund implementation does that and it's flexible in two ways. (Reference)
req_amount
field from the payment transaction response)There might be another thing to look for while refunding through EBC, We need to reflect that in our database too just like the implementation does that, e.g. Ideally we should:
Sentry Issue: MITXONLINE-2DA