Итак, я тестировал свой сценарий IPN и разрабатывал его для того, что мне нужно, но я столкнулся с проблемой, в которой я получил «К сожалению, мы не смогли отправить IPN.» ошибка.
Все опции, не упомянутые по умолчанию
Сценарий 1 — Успех
Transaction Type: Web Accept
All default information.
Сценарий 2 — Успех
Transaction Type: Web Accept
Receiver_email: [email protected]
Сценарий 3 — Успех
Transaction Type: Web Accept
Receiver_email: [email protected]
Item_name: My Item
Сценарий 3 — Успех
Transaction Type: Web Accept
Receiver_email: [email protected]
Item_name: My Item
mc_gross: 39.99
Сценарий 4 — Успех
Transaction Type: Web Accept
All defaults;
custom: Jimmy|0
Сценарий 5 — Успех
Transaction Type: Web Accept
All defaults;
Reveiver_email: [email protected]
custom: Jimmy|0
Сценарий 6 — СБОЙ
Transaction Type: Web Accept
All defaults;
Reveiver_email: [email protected]
Item_name: My Item
custom: Jimmy|0
Сценарий 7 — СБОЙ
Transaction Type: Web Accept
Receiver_email: [email protected]
Item_name: My Item
mc_gross: 39.99
custom: Jimmy|0
Итак, почему я могу отправить
обычай: Джимми | 0
в сценарий 4-5 а затем отправить всю другую информацию, как показано в сценарий 1-3 без проблем, но как только я добавлю значение из сценарий 6 (настраиваемое поле) на мои значения для отправки, он ломается.
Я проверил это с примерно 4-5 различными значениями и отправил в общей сложности почти IPN-запросы, пытаясь выяснить это.
Кажется, что при совместном использовании Item_name и Custom методы это вызывает, как показано в сценарий 5 и 6
Обратите внимание, что при удалении значения разделителя из пользовательского ‘|’ IPN отправит, но почему разделитель вызывает проблемы, когда он работает во всех других сценариях? Я также расширил поле Custom до нескольких символов, чтобы убедиться, что это не проблема длины.
!! Кажется, что при смене разделителя, отправляемого в IPN, он работает нормально, однако кажется, что проблема, вызывающая ошибку, на самом деле заключается в моем методе explode ().
$custom = explode('~', $_POST['custom']);
$referral = $custom[0];
$software_type = $custom[1];
Какой бы персонаж я ни взорвал, это приведет к ошибке.
Однако, при печати $ referral и $ software_type в error_log, он дает правильные значения:
[04-Nov-2014 02:18:11 America/Los_Angeles] [Referral]: Jimmy
[04-Nov-2014 02:18:11 America/Los_Angeles] [Software]: 0
В вашем сценарии IPN должно быть что-то не так, что может привести к сбою при включении в него определенных данных. Это приведет к тому, что значение, отличное от 200 OK, будет отправлено обратно на сервер PayPal, поэтому они предположат, что это не удалось.
Вы должны быть в состоянии проверить журналы своего веб-сервера, чтобы увидеть фактические ошибки, которые происходят, которые вы обычно видели бы в браузере, если бы запускали его напрямую.
На этом замечании, хороший способ устранения неполадок такого рода — это создать свой собственный симулятор, чтобы вы могли сделать именно это. Создайте базовую HTML-форму с действием, установленным на ваш IPN URL. Включите скрытые поля, которые напоминают имена / значения параметров, которые вы ожидаете получить от IPN PayPal. Затем загрузите его в браузер и отправьте напрямую, чтобы увидеть результат на экране.
Имейте в виду, что при тестировании этого способа данные не поступают с сервера PayPal. Как таковой, он будет НЕПРАВИЛЬНЫМ, поэтому, если в вашем коде есть логика для обработки, вам необходимо соответствующим образом настроить ее для тестирования таким образом.
Других решений пока нет …