Олег

не удачный пример с платежными системами.
Данные об оплате поступают от мерчанта.
В 99% процентов случаев Ваш сайт просто отправляет посетителя на сайт платежной системы так как пройти сертификацию для работы с данными карт (Payment Card Industry Data Security Standard (PCI DSS) ) большой гиморой.
Для переадресации требуется сумма платежа, идентификатор участника платежной системы в чью пользу оплата, обычно к обязательным полям добавляют возможность добавить идентификатор оплаты со стороны продавца.
Названия полей и их количество немного отличаются от платежной системе к системе.

Есть вторая схема. Предварительная регистрация платежа (бакенд дергает апи и получает ид оплаты). Редиректит пользователя на оплату конкретного счета.

Факт успешной оплаты может проверяться по инициативе со стороны бека, так и через механизм обратных вызовов (хуков)

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

Даже в этом случае (пользователь ничего не передает) верить не желательно.
Стоит перепроверить контрольную сумму. Ограничить доступ к хукам по ip.

Типовой способ защиты: расчет контрольной суммы от
секретнаястрока+поле_данных1+поледанных2+....+полеN

Но способ не подходит для JS так как строка будет видна :(

Обычно для оплаты пользователя переадресовывает на страницу эквайринга. Если внедрять на свой сайт , то требуется сертификация по псд.

Прехук перед платежом может быть или отсутствовать . Тогда пайлоад платежа идёт вместе с пост редириктом на оплату. У мерчантов два бак урла. Успех и отказ. Это обычно во внутреннем билинге проверяешь. Пречек полезной инфы не несёт так как реально приходит за несколько милисекунд до авизо.

А вот авизо это уже не временные данные, как вы считаете, а главный метод биллинга. Деньги клиент заплатил .