Песочница эквайринг это безопасная среда для интеграции и отладки платежных сценариев без реального списания средств. В песочнице вы проводите тестирование платежей API, проверяете обработку успешных и ошибочных ответов, учитесь работать с вебхуками и симулируете редкие ситуации, которые сложно поймать в реальной жизни. Это обязательный этап перед полноценным запуском онлайн оплат.
Если вы только начинаете, начните с материала Базовая интеграция и общая схема платежа см. Интеграция с нуля. Также полезно заранее понимать плюсы и минусы работы напрямую с банком или через агрегатора см. Банки против агрегаторов.
В типичной схеме у вас два независимых окружения
Компоненты песочницы
Важно обеспечить разделение секретов и логов. Храните sandbox и prod ключи отдельно, а для вызовов используйте явные флаги окружения.
Тестовые карты это специально выпущенные номера карт для проверки сценариев в песочнице. Они позволяют получить предсказуемый результат успех, отказ, 3DS‑аутентификация, недостаточно средств и так далее. Конкретный список карт и кодов результата зависит от провайдера, поэтому сверяйтесь со страницами провайдеров на нашем сайте
Обязательно протестируйте как минимум такие базовые сценарии
| Сценарий | Данные для проверки | Ожидаемый результат |
|---|---|---|
| Успешная оплата без 3DS | Тестовая карта Visa или Mastercard, валидный срок, CVC, сумма 10.00 | Статус успеха, авторизация и списание, корректный webhook о платеже |
| Успешная оплата с 3DS | Карта со сценарием 3DS challenge, как указано провайдером | Окно 3DS, подтверждение, затем успешный платеж и webhook |
| Недостаточно средств | Карта с признаком insufficient funds в песочнице | Отказ с кодом 51 или аналогичным, корректная обработка на фронте |
| Общий отказ банка | Карта с general decline в песочнице | Отказ без списания, понятное сообщение пользователю |
| Неверный CVC | Валидный номер карты, но неправильный CVC | Отказ, корректная валидация и логирование |
| Просроченная карта | Срок действия в прошлом | Отказ на этапе авторизации |
| Частичная операция захвата | Предавторизация на 100.00 и capture на 60.00 | Частичный захват, правильный статус и суммы |
| Возврат и отмена | Успешный платеж затем полный и частичный refund или reversal | Корректные статусы возвратов и вебхуки |
Подробно о 3DS и требованиях безопасности см. раздел PCI DSS, 3DS и SCA. Возвраты и отмены разобраны в паттернах Refunds и Reversals.
Эмуляция вебхуков позволяет проверить обработку асинхронных событий без ожидания реальной банковской обработки. Большинство провайдеров поддерживают ручной вызов событий из кабинетa или API вызов для пересылки тестового webhook на ваш адрес.
Рекомендации
Типовые события для проверки
| Событие | Когда отправляется | Полезная проверка |
|---|---|---|
| payment.succeeded | Платеж успешно завершен | Создание заказа, начисление товара услуги, идемпотентность при повторе |
| payment.failed | Платеж отклонен | Отсутствие списаний и корректная ошибка пользователю |
| refund.succeeded | Возврат средств | Обратная проводка, уведомление клиента, корректная сумма |
| refund.failed | Ошибка возврата | Логи и алерты для ручной проверки |
По мониторингу ошибок и повторным доставкам см. Ошибки и мониторинг.
Negative testing это системная проверка ошибочных и пограничных состояний. В платежах важно увидеть, как ваш бэкенд и фронтенд ведут себя в случаях отказов и нестабильности.
Что обязательно протестировать
Нагрузочное тестирование помогает выявить узкие места до релиза и согласовать лимиты с провайдером. Планируйте стенд и тестовые данные заранее.
Рекомендации
Важно согласовать проведение нагрузочного тестирования с провайдером, чтобы не нарушать правила песочницы и не получить блокировку.
Сводный чек‑лист который можно превратить в ваши автотесты и регрессию
Инициация платежа
3DS и риск проверки
Вебхуки
Захват, возвраты и отмены
Подписки и токенизация
Мобильные сценарии
Сверка и учет
Безопасность
У каждого провайдера свои настройки песочницы, перечни тестовых карт и коды ошибок. Ищите на страницах
Если требуется единая логика по нескольким провайдерам, абстрагируйте обработку вебхуков и ошибок через ваши внутренние коды и используйте адаптеры.
Рекомендуемый порядок миграции
Можно ли использовать реальные карты в песочнице
Нет, используйте только тестовые карты и значения, предоставленные провайдером.
Как тестировать 3DS если банк требует подтверждение по SMS
В песочницах обычно предусмотрен стаб 3DS. Сверьтесь с документацией вашего провайдера и разделом PCI и 3DS.
Что делать если webhook не пришел
Проверьте доступность вашего endpoint, подписи и повторные доставки. При необходимости включите эмуляцию и ручную повторную отправку см. Вебхуки и идемпотентность и Ошибки и мониторинг.
Как синхронизировать статусы если вебхуки задерживаются
Используйте безопасный повторный запрос статуса по API с идемпотентными ключами и регулярную сверку см. Сверка платежей.
Как выбрать провайдера с удобной песочницей
Сравните функциональность, стабильность sandbox, полноту тестовых сценариев и SLA поддержки см. Банки против агрегаторов.
Песочница эквайринг, тестовые карты и системный QA процесс экономят вам недели и деньги на этапе запуска платежей. Эмулируйте вебхуки, проводите negative testing и не забывайте про нагрузочное тестирование, чтобы уверенно выходить в прод. Начните с настройки базового контура и первых автотестов см. Интеграция с нуля, затем пройдите чек‑лист на этой странице и завершите миграцию. Готовы начать Прямо сейчас откройте песочницу у выбранного провайдера, настройте вебхуки и проведите первую серию тестов.