Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 3.4.3
-
Fix Version/s: 3.6.0
-
Component/s: None
-
Labels:None
Description
Someone inquired with PayPal regarding failed refunds due to an "Internal Error". The reply was:
"Thank you for contacting PayPal Merchant Technical Service.
Internal error usually occurs if there are wrong variables passed in the
API call or if there are any intermittent issue at PayPal's end during
the time of transaction.
Looking into your API requests, I can see that you are trying to make a
partial refund for this transaction: 8P5262567W398632Yfor an amount of :
2.50 USD. However, looking into the transaction, I noticed that, the
total amount received for that transaction is 2. 50 USD. In that case,
if you are going to make a partial refund it has be to for an amount
lesser than 2.50 USD.
However, if you are going to make a full refund, you need to pass the
REFUNDTYPE =Full and you do not need to set an AMT value for it.
You may refer to this documentation on how RefundTransaction API is done :
https://developer.paypal.com/docs/classic/api/merchant/RefundTransaction_API_Operation_NVP/
Do get back to us if the issue still occurs. Thank you"
It appears PayPal is not able to distinguish a full amount from a partial amount except to refuse the refund as an internal error based on the REFUNDTYPE.
I suggest updating the PayPal Payments Standard gateway to fetch the associated transaction in ::refund to determine whether the given amount is the full transaction amount, and setting the REFUNDTYPE as FULL or PARTIAL accordingly.
Activity
I know it worked before because I implemented and tested it. My guess is PayPal made some changes since then which broke backwards compatibility. Either that, or they no longer allow refunds in sandbox.
Cody Phillips (Inactive)
added a comment - I know it worked before because I implemented and tested it. My guess is PayPal made some changes since then which broke backwards compatibility. Either that, or they no longer allow refunds in sandbox. REFUNDTYPE, CURRENCY, NOTE (if empty) are optional. I would test without those fields present and see what happens.
Cody Phillips (Inactive)
added a comment - REFUNDTYPE , CURRENCY , NOTE (if empty) are optional. I would test without those fields present and see what happens. With those fields removed, PayPal still returns "Timeout processing request". It appears that all fields, given or not, result in that timeout response for the RefundTransaction method.
I'm not sure if this is a limitation of the sandbox or not. But since I'm unable to test refunds successfully, all we could do is set the fields according to the API.
Tyson Phillips (Inactive)
added a comment - With those fields removed, PayPal still returns "Timeout processing request". It appears that all fields, given or not, result in that timeout response for the RefundTransaction method.
I'm not sure if this is a limitation of the sandbox or not. But since I'm unable to test refunds successfully, all we could do is set the fields according to the API. Can we open a ticket with PayPal and get an official response on this? Would like to get to the bottom of it, whether it's a bug with their sandbox or API.
Cody Phillips (Inactive)
added a comment - Can we open a ticket with PayPal and get an official response on this? Would like to get to the bottom of it, whether it's a bug with their sandbox or API. cURL posts array data by automatically changing the header Content-Type to multipart/form-data, which PayPal rejects with a generic "Internal Error". Solution was to post data as a query string instead.
Tyson Phillips (Inactive)
added a comment - cURL posts array data by automatically changing the header Content-Type to multipart/form-data, which PayPal rejects with a generic "Internal Error". Solution was to post data as a query string instead. 
Blesta currently only allows full refunds, so we should be able to simply set FULL as the type, right? Is an amount even needed then?