При разработке с помощью симулятора IPN PayPal вы можете столкнуться с ситуацией, когда при проверке сообщения он продолжает возвращать «Недействительно» , независимо от установленной вами кодировки или всех условий, которые соответствуют и являются действительными .
Команда разработчиков Paypal печально известна тем, что игнорирует все запросы, и документы, как известно, трудно читать, поэтому отладка этих проблем невероятно трудна и может стоить вам часов на оплачиваемые часы. Я даже дошел до того, что настроил работающий сервер для тестирования симулятора IPN, опасаясь, что Ngrok был виноват при локальном тестировании, и даже добавил сертификат к конечной точке, чтобы запустить HTTPS — без всяких проблем. В конце концов, решение было, как обычно, простым, но неясным.
Симптом (сбой) вызван полем даты, если оно содержит идентификатор часового пояса. Все это, однако, вызвано тем фактом, что в PHP есть две разные функции кодирования / декодирования URL: raw и non-raw.
Вот пример.
Допустим, у нас есть дата в симуляторе IPN:
Fri Aug 19 2016 09:25:00 GMT+0100 (GMT Daylight Time)
Это прибывает в конец слушателя (в вашем коде PHP) как это:
Fri%20Aug%2019%202016%2009%3A25%3A00%20GMT+0100%20%28GMT%20Daylight%20Time%29
Подстрока GMT+0100urldecode+
Fri Aug 19 2016 09:25:00 GMT 0100 (GMT Daylight Time)
Обратите внимание, что +
Когда это перекодируется для отправки обратно в Paypal для проверки, проверка завершается неудачно, потому что в поле больше нет того значения — знак + Это очень, очень крошечная деталь, которую невероятно трудно обнаружить при ручной проверке значений поля, но она есть. В соответствии с документацией Paypal этого достаточно для подтверждения возврата «НЕДОПУСТИМО».
Есть два решения этой проблемы:
- Используйте
rawurlencoderawurldecodeОни также кодируют символ+ - Используйте клиент Paypal IPN Listener, в который он встроен. Я недавно отправил патч на него, и он работает как шарм.
Надеюсь, этот маленький намек спас кого-то от множества разочаровывающих поисков!