A new member tried to register on our site this morning. We use Paypal Standard buttons - they were directed to Paypal to complete their transaction but had an issue during the auto-return to our site.
Normally an email would be dispatched to the user following their Paypal payment, including a registration link. However in this case the user didn’t receive an email - this is confirmed by the user and also checking our GMail Sent Items as we use GMail SMTP.
We have both IPN and PDT settings configured in S2Member and have plenty of successful registrations to prove this has been working correctly. We had debug logs turned off as this is a live Production service. The IPN log on the Paypal Developer site shows that an IPN notification was successfully sent as part of this transaction.
Following the issue, we enabled debug logs and re-sent the IPN notification from the Paypal Developer console. The S2Member IPN logging shows the following summary for this retry:
[s2member_log] => Array
(
[0] => IPN received on: Sat Oct 29, 2022 1:20:25 pm UTC
[1] => s2Member POST vars verified through a POST back to PayPal.
[2] => s2Member originating domain (`$_SERVER["HTTP_HOST"]`) validated.
[3] => Ignoring this IPN request. The `txn_type/status` does NOT require any action on the part of s2Member.
)
This is interesting as it hasn’t discarded the notification as a duplicate, but instead determined it doesn’t require any action.
I then noticed that a recent plugin update had been applied since our last registration (successful) went through, so I had a look at the diff. This seems to include a change to $paypal[item_number] appending an additional colon before the conditional processing is applied to determine how to handle the notification. This can be confirmed in the logging output in the IPN logs, which now includes the following:
[txn_type] => web_accept
[item_number] => 2::6 M:
(note the trailing colon - the Paypal transaction has an item number of just 2::6 M)
Looking at the subsequent conditional code for handling these IPNs, this additional character appears to mean the item_number no longer matches any of the item_number regexes in syscon.inc.php
Happy to be proven/told this is incorrect and the issue lies elswhere, but as I’ve spent a couple of hours digging into this already I thought I’d share and see if any developers can comment. This issue is preventing us from signing up new users at the moment so keen to help find a resolution if it’s a general issue, or go back to the drawing board if it’s something specific to our installation.
Cheers.
