@kai.nissen Can we get some sort of recent example here? I have tried to pick up this ticket but I cannot find any hint in the logs to get started with this, so a concrete case would help.

Seeing nothing in the log files is part of the problem. A more recent example wouldn't help, I guess. When I wrote this ticket, I also sent (by email) the body of an IPN that was rejected by our server. I will search for it and forward it to you again. Maybe you can reproduce that on the test server using PayPal's IPN simulator.

Half a year ago... Sorry, I did not send it by mail, but shared it with you on ZeDa/Nextcloud:
https://zeda.wikimedia.de/index.php/f/1858079

Not sure if it helps, but maybe you can also debug locally by disabling the IPN verification (the one that sends the data back to PayPal).

After debugging this locally, it appears that the issue in this specific example comes from the fact that the first donation which started the recurring PayPal donation is missing the utoken in the database. The donation is an old recurring PayPal donation from 2013, so the data is likely messed up for some reason.

This means that the following if condition from vendor/wmde/fundraising-donations/src/UseCases/HandlePayPalPaymentNotification/HandlePayPalPaymentCompletionNotificationUseCase.php is true and no new donation is created:

		if ( !$this->authorizationService->systemCanModifyDonation( $request->getInternalId() ) ) {
			return $this->createUnhandledResponse( 'Wrong access code for donation' );
		}

However, for some reason the logs do not contain any mention of Wrong access code for donation which is a bit odd. We definitely need some more examples in order to be able to see if there is a pattern or if there are multiple issues spread out across all problematic cases. Since the PayPal login is not working right now, we will try again in a few days, alternatively it would be great if you had any more examples of this issue @kai.nissen.