Проверка IPN возвращает недействительным, так как PayPal отправляет неверный набор символов в POST для прослушивателя IPN

Все следующее находится в песочнице PayPal:

У меня есть настройка подписки / повторного платежа PayPal, которая использует прослушиватель IPN в качестве последнего шага для создания или обновления подписки пользователя в базе данных моего веб-сайта. Тем не менее, когда я получил данные POST от PayPal и отправил их обратно для проверки, единственный ответ, который я получил, — «НЕВЕРНЫЙ».

Я знаю, что мой код отправляет данные POST обратно в PayPal правильно, потому что я получаю ответ «ПРОВЕРЕНО», когда я имитирую правильный POST для моего слушателя, жестко кодируя строку данных POST со значением «Сообщение IPN», как видно из IPN PayPal Страница истории.

Поэтому мой код, который отправляет данные POST обратно в PayPal для окончательной проверки, работает, а мой прослушиватель IPN получает переменные POST для транзакции. Есть только разница в строке POST-данных, которую создает мой прослушиватель IPN для отправки обратно в PayPal, и в строку POST-data, которую PayPal ожидает получить.

PayPal заявляет, что прослушиватель IPN должен отправить обратно полученные POST-данные с теми же значениями, порядком и кодировкой, в которые их отправил PayPal.

Я думаю, что проблема заключается в кодировании, потому что в PayPal POST для моего слушателя charset имеет значение «windows-1252», которое должно быть «UTF-8». Тем не менее, «form_charset» имеет правильное значение «UTF-8».

Я установил кодировку UTF-8 в обоих полях ввода в моем профиле продавца PayPal, и у меня есть скрытый ввод в исходной форме / кнопке PayPal с именем «charset» и значением «UTF-8». Подскажите пожалуйста, есть ли другой способ установить кодировку, которую я пропустил.

Часть строки данных POST, которую, как утверждает PayPal, отправляет, включает в себя:&notify_version = 3.8 «, за которым следуют другие переменные. Когда я вручную вставляю эту строку для проверки своего кода,»&не «преобразуется в» ¬ «при печати на странице, что, насколько я понимаю, означает, что используемая кодировка символов» windows-1252 «, потому что» ¬ «находится в наборе символов windows-1252, а» ¬ «не находится в набор символов UTF-8, поэтому, если используется UTF-8,&не «не будет преобразован, как это.

Как я могу заставить PayPal фактически отправлять данные POST моему слушателю IPN с кодировкой символов UTF-8? Имейте в виду, что это регулярный платеж, поэтому некоторые аспекты могут отличаться.

Я не думаю, что проблема на моем конце, так как я пробовал разные методы, разные способы кодирования / декодирования публикуемых данных, внешние библиотеки, cUrl / сокеты, SSL с разными версиями, разные заголовки, перезапуск сервера, воссоздание покупка и т. д.
Поэтому Paypal отправляет мне неверные данные POST или я неправильно формирую строку сообщения. Последнее возможно, но я попробовал все методы, которые я мог найти для формирования строки сообщения, и ни один из них не работал.

Я работал над этой проблемой в течение нескольких дней безрезультатно, поэтому любая помощь или указатели будут очень признательны.

PS:
несколько заметок, которые могут иметь или не иметь отношение к делу:

• Эта система подписки была создана несколько месяцев назад и перестала работать необъяснимым образом в какой-то момент в последние несколько недель. В это время AFAIK не было изменено никакого соответствующего кода.

• В первый день, когда я начал отлаживать эту проблему, учетная запись продавца для песочницы имела совершенно неверные данные, она была указана как личная учетная запись, когда это должна была быть служебная учетная запись, что означало, что ни одна из настроек IPN не была доступна. На следующий день та же учетная запись по непонятным причинам сработала и оказалась бизнес-учетной записью, как и должна была быть в первую очередь. Я не знаю каких-либо действий с моей стороны, вызывающих это изменение. Может быть, отправка PayPal неправильной кодировки символов — похожая проблема? Какая-то система кеширования на работе cron? Я просто размышляю на данный момент, я действительно понятия не имею.

• Что касается моего последнего пункта, вход в учетную запись продавца в песочнице был очень ненадежным. Иногда я пытаюсь снова войти в систему после тайм-аута сеанса и получить код ошибки, который имеет смысл только в контексте регистрации новой учетной записи. В других случаях вход в систему просто не работает, в результате чего во многих случаях, когда я пытаюсь войти в систему после тайм-аута сеанса, мне приходится очищать свои куки, чтобы снова войти в работу.