не работает платежная система LiqPay

они одинаковые


HtIQG8Aqnbb0IOzfnv+UsM8bPgg=

HtIQG8Aqnbb0IOzfnv+UsM8bPgg=

Отлично. Значит поиск проблемы сузился до одного куска.
Код:
<вставить здесь 1>
if($sign == $signature && ($data_json["status"] == "success" || $data_decode["status"] == "wait_accept" || $data_json["status"] == "sandbox")){
$Profile->profileBalance(array("id_user"=>intval($id[0]),"summa"=>round($data_json["amount"],2),"method"=>"LiqPay","title"=>$title_payment,"id_order"=>intval($id[1])),"+");
<вставить здесь 2>
if($bonus["procent"]){
$summa = (($data_json["amount"] / 100) * $bonus["procent"]);
$Profile->profileBalance(array("id_user"=>intval($id[0]),"summa"=>round($summa,2),"method"=>"LiqPay","title"=>$bonus["title"],"id_order"=>intval($id[1])),"+");
}

Здесь. То же вывод в файл.
<вставить здесь 1>
file_put_contents("./log.txt", "{$sign}\n\n{$signature}\n\n{$data_json["status"]}\n\n{$id[0]}\n\n{$id[1]}\n\n".(round($data_json["amount"],2))."\n\n{$title_payment}\n\n");
<вставить здесь 2>
file_put_contents("./log1.txt", "Обновление баланса завершено");

Первый вывод покажет данные, которые используются в проверке и при отправке обновления баланса, второй, что процедура баланса отработала.
 
вставила, вот что получилось в log.txt:



а файла log1.txt нет..

а здесь пробовала ставить 0

$sign = base64_encode( sha1(
trim($param["private_key"]) .
$data .
trim($param["private_key"])
, 1 ));

тогда подписи не одинаковые..
 
Последнее редактирование:
оставьте 1, чтобы подписи были одинаковые
и
$data_json = json_decode(base64_encode($data), true);

заменить на

$data_json = json_decode(base64_decode($data), true);

очепяточка у вас вышла)
 
спасибо!! получилось)) счёт пополнился!! :sun:
Сам только что заметил что опечатка.
Вот таким образом можно самостоятельно проходить без бреакпоинтов по скрипту и смотреть выводы в тех или иных местах на будущее. В данном случае благодаря выводу перед if и внутри видно, что данные в массиве $data_json отсутствуют. Поэтому if не срабатывает. Соответственно функция пополнения баланса не вызывается.

И еще - обратите внимание на то, что ликпей может возвращать данные на сервер два раза. Первый при возврате на страницу result_url после оплаты. Туда в POST передаются данные по оплате. Второй запрос будет просто от сервера к серверу на адрес из server_url. С теми же данными. Поэтому запросы и пополнения могут двоиться. Для того чтобы этого не было нужно сохранять ID и статус самой транзакции. И проверять их при обработке
 
Последнее редактирование:
Сам только что заметил что опечатка.
Вот таким образом можно самостоятельно проходить без бреакпоинтов по скрипту и смотреть выводы в тех или иных местах на будущее. В данном случае благодаря выводу перед if и внутри видно, что данные в массиве $data_json отсутствуют. Поэтому if не срабатывает. Соответственно функция пополнения баланса не вызывается.

И еще - обратите внимание на то, что ликпей может возвращать данные на сервер два раза. Первый при возврате на страницу result_url после оплаты. Туда в POST передаются данные по оплате. Второй запрос будет просто от сервера к серверу на адрес из server_url. С теми же данными. Поэтому запросы и пополнения могут двоиться. Для того чтобы этого не было нужно сохранять ID и статус самой транзакции. И проверять их при обработке
Ну вот, я еще с рыбалки не вернулся , все решили)
Кто-то в логи пишет кто-то брайки ставит и выводит на экран, принцип отладки никто не отменял, а методика у каждого своя:)
Garphild +1
 
Ну вот, я еще с рыбалки не вернулся , все решили)
Кто-то в логи пишет кто-то брайки ставит и выводит на экран, принцип отладки никто не отменял, а методика у каждого своя:)
Garphild +1

Полностью согласен за одним маленьким исключением. В данном случае брайки не совсем получится, так как код на сервере без дебаггера, поэтому если отлаживать ответ ликпея не на возврат, а на серверный реквест, то ни на экран ни и брейк не получится. Остаются только логи. Плюс если продакшн, то усложняется логика вывода на экран. Нужно смотреть кому можно, а кому нельзя выводить.

Кстати, Вы навели на мысль о том, что result_url не всегда вызывается. Иногда пользователи не переходят на страницу обратно. Иногда быстро закрывают и переход не происходит даже при автопереходе.
 
Полностью согласен за одним маленьким исключением. В данном случае брайки не совсем получится, так как код на сервере без дебаггера, поэтому если отлаживать ответ ликпея не на возврат, а на серверный реквест, то ни на экран ни и брейк не получится. Остаются только логи. Плюс если продакшн, то усложняется логика вывода на экран. Нужно смотреть кому можно, а кому нельзя выводить.

Кстати, Вы навели на мысль о том, что result_url не всегда вызывается. Иногда пользователи не переходят на страницу обратно. Иногда быстро закрывают и переход не происходит даже при автопереходе.
на result_url вообще опираться не стоит, его использовать только для "Спасибо за ваши денюшки". Запрос то можно и подделать при желании.
 
на result_url вообще опираться не стоит, его использовать только для "Спасибо за ваши денюшки". Запрос то можно и подделать при желании.
С одной стороны да. Но с другой стороны это резервирование. У меня в практике встречалась такая штука, что сервер не передавал данные или передавал несколько раз. Редко но было. И было такое, что у клиента админ чутка подправил сегмент обработки оплаты от сервера. В результате все статусы оказались потеряны от сервера. А от резалта спасли данные тем, что не нужно было потом руками все статусы заказов за сутки перебивать. Очень быстро сверили и норм.
При любых раскладах нужно проверять транзакцию. Подделать крайне сложно такие запросы. Только если не проверяется ничего или минимум. В примере, который мы здесь решали, есть проблема следующего характера - не проверяется ни состояние заказа ни транзакция. Только подпись. Поэтому повторив 5 раз пост от ликпея на страницу возврата можно получить 5 пополнений вместо одного, если не проверять заказ и/или проведение транзакции. В этом случае работа исключительно с серверным запросом оправдана с учетом Вашего комментария. Но представьте себе на секунду что серверный урл не получил данных... Оплата потеряна, клиент в бешенстве, тикеты валятся лавиной, все берутся за голову и идут либо вешаться либо проверять платежи и компенсировать клиенту его "нервы". А если нормально проверять и транзакцию и заказ по статусу, то получается нормальное резервирование, которое позволяет избежать ряда трудностей.
 
Назад
Сверху