После возврата с платёжного сайта корзина пустеет или снова появляется вход? Сначала проверьте, отправил ли браузер cookie сессии в первом запросе обратно в магазин. SameSite может ограничить её передачу между сайтами, даже когда cookie ещё хранится, а серверная сессия не истекла.
Не меняйте всем cookie режим на None и не просите покупателя платить повторно. Отдельно установите состояние платежа на сервере, затем найдите первый запрос, в котором потерялась связь с прежней сессией.
1. Зафиксируйте именно возврат браузера
Воспроизводите сбой в тестовом режиме платёжного провайдера, на тестовом заказе. До перехода откройте DevTools → Network и включите Preserve log. Запишите браузер и версию, время с часовым поясом, исходный домен магазина и адрес возврата без секретных параметров.
У первого запроса обратно проверьте:
- метод: GET или POST;
- контекст: переход всей вкладки или загрузка внутри iframe;
- HTTPS, имя хоста и путь;
- наличие нужной cookie и причину её исключения в панели Cookies или Issues;
- HTTP-код и последующие перенаправления.
Серверный webhook — отдельный запрос от провайдера: в нём нет браузерной сессии покупателя. Не принимайте его за возврат пользователя и не требуйте от него session cookie.
Не пересылайте значения Cookie, Set-Cookie, платёжные параметры и полный HAR. Для разбора достаточно атрибутов cookie, факта отправки и обезличенной цепочки запросов. Порядок очистки описан в руководстве по безопасной передаче HAR.
2. Сопоставьте SameSite с методом и контекстом
SameSite управляет отправкой cookie между сайтами. По справочнику MDN:
- Strict ограничивает cross-site передачу, включая первый переход с платёжного сайта.
- Lax допускает cookie при переходе верхнего уровня с безопасным методом, например GET; обычный cross-site POST под это исключение не попадает.
- None разрешает cross-site передачу, но требует Secure. Другие ограничения браузера при этом сохраняются.
Для возврата внутри чужого iframe исключение Lax для перехода всей вкладки не действует. Проверяйте фактический контекст, а не только название callback в настройках.
При отсутствующем SameSite некоторые браузеры применяют Lax с временным послаблением для недавно установленных cookie: POST может пройти в первые две минуты. Поэтому успешная быстрая оплата и сбой после паузы не доказывают истечение серверной сессии. Явный Lax и отсутствие атрибута могут вести себя по-разному.
Условный диагностический пример: тестовая сессия работает до оплаты, но первый cross-site POST обратно не содержит cookie с явным Lax. Если DevTools подтверждает исключение по SameSite, причина локализована; ответ 200 от главной страницы её не опровергает.
3. Отделите запрет браузера от потери состояния на сервере
Cookie отсутствует в запросе
Сначала прочитайте причину исключения. Затем проверьте Domain и Path: возврат на www вместо основного хоста или на другой путь может не подходить области cookie. Убедитесь, что весь маршрут использует HTTPS и cookie не истекла.
Также проверьте, не отклонил ли браузер исходный Set-Cookie и нет ли одноимённых cookie с разными областями. Не расширяйте Domain на все поддомены без необходимости.
Cookie отправлена, но пользователь всё равно вышел
Сопоставьте запрос с безопасными серверными логами: найдено ли прежнее состояние, не истёк ли его срок, какой узел обработал возврат. Проверьте, не создал ли обработчик новую пустую сессию и не заменил ли cookie ответом Set-Cookie.
В этой ветке смена SameSite не объясняет проблему. Дальнейший маршрут — проверка срока и хранилища сессий.
4. Исправляйте конкретную схему возврата
Для обычного перехода всей вкладки через GET оцените явный Lax, если это соответствует модели безопасности приложения. Если провайдер возвращает POST, проверьте поддерживаемую им схему перехода и требования к обработчику.
None; Secure рассматривайте только для cookie, которой действительно нужен cross-site контекст. Не отключайте HttpOnly, HTTPS или CSRF-защиту и не переносите идентификатор сессии в URL. Разбор SameSite на web.dev отдельно предупреждает: None не отменяет ограничения сторонних cookie.
Не заменяйте редирект наугад: изменение метода может нарушить контракт провайдера. Если теряется именно тело запроса, используйте отдельный разбор перехода POST → GET.
Возврат браузера должен показывать результат, подтверждённый сервером по документированному протоколу провайдера. Например, документация Stripe рекомендует обрабатывать платёжные события, а не полагаться только на страницу успеха. Для своего провайдера проверьте подпись уведомления или серверный запрос статуса; номер заказа в URL сам по себе не подтверждает оплату и право просмотра.
5. Подтвердите исправление исходным сценарием
Повторите тест быстрым возвратом и после паузы, в затронутом браузере и в фактическом контексте интеграции. Проверьте успешный платёж, отмену и повторное открытие страницы результата.
Критерии: ожидаемая cookie передаётся там, где должна; сервер находит нужную сессию; заказ сохраняет подтверждённый статус; повторный возврат не создаёт повторное списание или выдачу. Отдельно проверьте обработку уведомления без возврата браузера.
Когда нужна дополнительная диагностика
Web-Puls помогает контролировать доступность публичных URL, но обычная внешняя проверка не воспроизводит оплату и не подтверждает сохранность приватной сессии. Для этой ошибки нужен тест браузерного пути вместе с серверными событиями.
Если место потери сессии осталось неясным, отправьте заявку на диагностику: укажите публичный адрес магазина, браузер, время, метод и контекст возврата, причину исключения cookie и последние изменения интеграции. Специалист оценит задачу и согласует формат работ; пароли, cookie и платёжные данные для первичной оценки не нужны.