Sandbox-ключ в production отвергается намеренно, а выглядит как поломка

Стенд для приёмки. Ключи от песочницы провайдера — те же, что работали локально. Авторизация не проходит. Ключи перепроверены посимвольно, время на сервере верное, исходящие запросы уходят.

Причина

APP_ENV=production — и приложение (или SDK провайдера) переключается на боевые эндпоинты и боевую проверку учётных данных. Sandbox-ключ там невалиден по определению: он и не должен работать против прода.

То есть система ведёт себя правильно. Ломается ожидание: «стенд — значит почти прод, поставим production, чтобы было ближе к бою».

Решение

Стенд, работающий с песочницей провайдера, — это не production:

APP_ENV=staging

Соответствие фиксируется явно, в одном месте, и лучше в README проекта:

Окружение	APP_ENV	Ключи провайдера	Куда ходит
локально	local	sandbox	песочница
стенд приёмки	staging	sandbox	песочница
прод	production	боевые	боевые эндпоинты

Пара «окружение ↔ ключи» должна быть жёсткой. Как только на одном стенде оказывается production-режим с sandbox-ключами, час уходит на отладку того, что работает правильно.

Что здесь на самом деле поучительно

Это класс ошибок «система защищается, а мы читаем это как сбой». Отличительный признак — отказ консистентный: не плавает, не зависит от нагрузки, воспроизводится сто раз из ста. Плавающая ошибка — обычно инфраструктура. Стабильный отказ на верных, казалось бы, данных — почти всегда осознанная проверка, которую мы не учли.

Прежде чем чинить, стоит спросить: а не отвергает ли меня система намеренно? Ответ экономит вечер.