Refunds are processed in PayPal despite expected State error in Drupal

Do you have any error to share from the logs?

    catch (BadResponseException $exception) {
      $this->logger->error($exception->getResponse()->getBody()->getContents());
      throw new PaymentGatewayException('An error occurred while refunding the payment.');
    }

    if (strtolower($response['status']) !== 'completed') {
      throw new PaymentGatewayException(sprintf('Invalid state returned by PayPal. Expected: ("%s"), Actual: ("%s").', 'COMPLETED', $response['status']));
    }

The error should be logged...What was displayed in the UI as well? Could be that the response has changed and the status isn't "COMPLETED" as expected? Is this a partial refund?

I just tried reproducing this locally and couldn't... I'd appreciate if we could get a screenshot / dump of the response. I just tried performing a partial and a full refund and both worked, see the attached screenshots:

hm... Quick q: do you have Webhooks configured? I'm wondering if there is a race condition or something... Since I'm testing locally this isn't happening to me.

Partial refund.

Sorry for the lack of clarity in the OP but I was busy contacting the customer to straighten out the mess, so I just plopped this in so I didn't forget.

Can you confirm if you have Webhooks configured? If so, I think we might have an issue where the webhook is actually causing a double refund... Not really sure how we can prevent that unfortunately...
We'd either need to know that a particular event was processed or whether the refund was initiated from Drupal... Basically the intent was to make sure refunds initiated from PayPal directly would be reflected into Drupal.

In the meantime, perhaps you can stop listening to the PAYMENT.CAPTURE.REFUNDED event?

Chatted with Ryan on this on Slack. We should check if it is possible to embed context in the API request so we can easily identify events that were initiated from on site activity (e.g: a refund triggered from the Drupal admin).

@tonytheferg: Anyway you could test the patch?

I don't have webhooks configured.

I would need to set up the test account to test the patch as this happened on a live site.

Ok so my analysis isn't correct even though I believe this is also a problem.
Could you check if the status returned was "pending" perhaps? We can't consider "pending" refunds as "completed", so perhaps we should add special handling for this and add a message informing the merchant.
Anything else that could help us further diagnose the issue?

If webhooks are configured properly, then I believe the payment would be later marked as refunded.

Will merge the MR (that is unrelated), but update this issue status back to Postponed until more information is provided.

Yes, When I get some free time, I can try to reproduce in a sandbox, or if I have another paypal refund on the live site, I can try as well, and provide better info.

Thanks!

But do you have logs for the problematic refund?

Unfortunately no, as the log only goes back to the 18th.

Maybe I do in one of the dev environments. I'll follow up