Чек-лист перед переводом платежей в LIVE: из тестового режима в продакшн без ошибок

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

Разница между тестом и live — это не просто переключатель. Это отдельные ключи, аккаунт, который нужно полностью верифицировать, отдельные вебхуки и куча юридических деталей, которые в ЕС обязательны. Ниже — чек-лист, который мы проходим перед каждым запуском платежей, в порядке важности. Это не теория: именно эти вещи ломаются чаще всего.

1. Live-ключи, активированный аккаунт, ничего тестового в коде

Первая ловушка — ключи. В Stripe (и почти у любого процессора) есть набор тестовых ключей и набор live-ключей, полностью раздельных. Данные между ними не переносятся — заказы, клиенты и подписки из теста не существуют в live.

Проверьте, что:

• Live-ключ находится в переменных окружения, НЕ прописан в коде и НЕ загружен в Git.
• Вы заменили его везде: фронтенд (публичный ключ), бэкенд (секретный ключ) и любой подключённый сервис.
• Аккаунт полностью активирован: данные компании, банковский счёт для выплат, верификация личности (KYC) завершена. Без этого вы можете принимать оплату, но не выводить деньги.
• Вы убрали тестовые кнопки, товары и цены со страницы live.

Один забытый `sk_test_` означает платежи, которые выглядят работающими, но ничего реально не собирают.

2. Вебхуки: где ломается большинство платежей

Самая частая ошибка при запуске: тестовый вебхук остаётся, а продакшн-вебхук отсутствует или имеет неверный секрет. Результат жёсткий — клиент платит, деньги доходят до процессора, но ваш сайт об этом никогда не узнаёт, и заказ остаётся неподтверждённым.

Проверьте, что:

• Вы создали ОТДЕЛЬНЫЙ endpoint вебхука для режима live, со своим секретом подписи.
• Вы проверяете подпись каждого события перед обработкой (иначе любой может подделать вам платёж).
• Вы обрабатываете события идемпотентно: одно и то же событие может прийти дважды, и ваш код не должен выполнять заказ дважды.
• Вы полагаетесь на вебхук для финального подтверждения, а не на редирект в браузере — пользователь может закрыть вкладку до возврата.

Протестируйте его реальным платежом, а не только симулятором.

3. Суммы, валюта и НДС: ошибки, которые стоят точных денег

Большинство процессоров работают в наименьшей единице валюты. 100 евро отправляются не как «100», а как 10000 (центов). Классическая ошибка — правильно показать на странице, но отправить сумму умноженной или делённой неверно, и именно клиент сообщает вам, что его списали не на ту сумму.

Проверьте, что:

• Суммы считаются на сервере, никогда не берутся из цены, присланной браузером (её любой может подменить).
• Валюта корректна и одинакова везде.
• НДС включён и чётко показан, а итоговая цена в оформлении совпадает со страницей товара.
• Вы используете ключи идемпотентности при создании платежа, чтобы двойной клик не создал два списания.

Тестовая транзакция с реальной суммой сразу покажет, сходятся ли цифры.

4. 3D Secure, SCA и что происходит при неудачном платеже

В ЕС строгая аутентификация (SCA / 3D Secure) обязательна для большинства платежей картой. В тестовом режиме тестовые карты часто проходят без шага подтверждения от банка. В продакшне реальный клиент получает SMS или уведомление в банковском приложении — и если ваш поток не обрабатывает этот шаг, платёж как будто «зависает».

Проверьте, что:

• Оформление поддерживает шаг аутентификации 3D Secure и ждёт его результат.
• У вас есть чёткие состояния сбоя: карта отклонена, недостаточно средств, аутентификация прервана — с понятными клиенту сообщениями.
• Клиент может повторить попытку, не теряя корзину.
• Возвраты работают: сделайте один по-настоящему, чтобы знать, как это выглядит, когда возврат реально понадобится.

Оформление без состояний ошибок молча теряет клиентов.

5. Юридическая часть: без неё платёж не полон

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

Проверьте, что:

• Условия использования, Политика конфиденциальности (GDPR) и Политика возврата доступны из оформления заказа.
• Цены показаны с включённым НДС.
• Данные компании видны (название, регистрационный номер, адрес, контакты).
• Где требуется, есть ссылка на платформу онлайн-урегулирования споров ЕС и информация о защите прав потребителей.
• Счёт выставляется автоматически после оплаты — подключите оформление к системе выставления счетов с самого начала, а не латайте позже.

Это кажется бюрократией до первой жалобы. Решите один раз, как надо, и больше об этом не думаете.

6. Финальный тест: реальная транзакция, затем возврат

Последний шаг перед тем, как назвать себя live: сделайте реальный платёж сами, своей картой, на небольшую сумму. Это единственный способ увидеть всю цепочку работающей вместе — оформление, 3D Secure, вебхук, подтверждение заказа, письмо, счёт и деньги, появляющиеся на счёте выплат.

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

В MPO Web Studio мы создаём сайты со встроенными платежами удалённо, по всей стране, и проходим именно этот путь запуска вместе с клиентом — с уже готовым демо ещё до того, как вы что-то оплатите. Если хотите, чтобы мы прошли этот чек-лист по вашему сайту перед запуском, напишите нам в WhatsApp, и мы разберём его шаг за шагом.