PayPal warns that IPNs sent to UC fail to connect -- bad path?

And you know it's not a bug because....?

PayPal told me they might "decertify" Ubercart (whatever that means) because of UC's repeated IPN failure and no support by "the vendor" to fix it.

I've searched here and ubercart.org and found mostly IPN problem reports, and a few users sharing their guesses about what's going on. But none of them apply to my situation because they use a different level of PayPal. I've not seen anything resembling support there, thought I'd try here.

I guess it's shoot-the-messenger day.

I've narrowed it down to UC responding to PayPal's incoming IPN with this message:

"IPN for a different PayPal account attempted."

This level of payment/IPN interaction between UC and PayPal is not in any configuration I can find. And this seems to be much-reported behavior, with various theories of why and what to do. Seems like a bug, since "support" implies the user can and should do something differently, vs. the built-in CODE working differently.

Again, at the user level, my site's UC and PayPal play together nicely. The problem seems to show only in logs and periodic complaint e-mails from PayPal.

The question is, which side of the process creates the problem? Is the proper info not being sent by UC to PayPal, or not being sent from PayPal back to UC, or is UC not properly accepting/parsing/applying the returned account info?

I think the cause of the error message is UC comparing two values that aren't particularly related.

Here's the code in uc_paypal.pages.inc:

 if (variable_get('uc_paypal_wps_email', '') && $receiver_email != variable_get('uc_paypal_wps_email', '')) {
    watchdog('uc_paypal', 'IPN for a different PayPal account attempted.', array(), WATCHDOG_ERROR);
    return;
  }

UC is comparing an e-mail address entered in the PayPal Express Checkout section with the e-mail used by PayPal to send the IPN. But in my UC, PayPal Website Payments Pro is used, and Express Checkout is NOT enabled, not used, and the section is collapsed on the form.

In my case, the e-mail address set for Express Checkout did not match what PayPal uses to send IPN, but there's no UI clue that they should match. Why should a setting for an unused PayPal mode matter to a different PayPal mode? But assuming it really does matter, I've just changed the e-mail to see if this cures the IPN error.

Maybe UC shouldn't be using a value specific to a non-enabled payment method to validate a different type of payment method and process.

Or maybe the UI is the weak point If UC needs to ALWAYS use the incoming PayPal e-mail address for IPN validation, don't bury it. Move the e-mail field out of the Express Checkout collapsible section. make it prominent in the main PayPal Website Payments Pro section, and label it something like "Required: Must match e-mail address of user's PayPal account; if PayPal e-mail later is changed, this must be changed too."

Also adding to confusion is that UC stores two data elements that seem to be PayPal related e-mail addresses -- but only the one discussed above really is. At the time a user creates API Credentials in PayPal, the CURRENT e-mail address becomes one element of the credentials, and this then gets entered in UC as API_Username. HOWEVER, while it originates as an e-mail address, it is only used in the API as an arbitrary name, not as the user's actual PayPal ACCOUNT name or e-mail.

In fact, if the user e-mail address is later changed in PayPal, it doesn't alter the credentials. PayPal uses the user's current e-mail address for sign-in, and to send e-mail to the user. But PayPal seems happy to have an old and even non-functioning e-mail address in the API Credentials, since it doesn't actually use it to send e-mail.

Hmmm..

"Please report issues here only if you have isolated a specific bug in the code or deficiency in the documentation."

Longwave's link was to a WPS matter, but I'm using WPP. I apologize if it reveals a WPP answer, but that's the problem with using discussions as documentation -- it's often not labeled clearly and completely. Which is why I explained that UC itself seems to contribute to the problem by mislabeling the nature of the e-mail field.

Ubercart.org seems to be dormant -- lots of questions, almost no recent answers -- hardly the place for "support". I know this because I searched and searched. Thankfully Drupal.org is not dormant, which is why I posted here. In fact, no one has pointed to anything useful anywhere else.

Insulting me doesn't change any of the facts, but it speaks volumes about who is "behind" UC. I've designed and built commercial software for a long time, and would never allow what likely is a trivial UI matter to drag on while shooting down anyone who doesn't "get it". Go ahead and lock the thread, I'm done.