Что должно быть готово до TEST-доступов
Банк или провайдер проверяет не только код интеграции, но и готовность сайта принимать оплату.
Перед TEST-доступами сайт должен быть технически и содержательно готов: HTTPS, стабильный домен, страницы с контактами, условия оплаты, возврата, доставки или оказания услуги. Это не формальность, потому что платежный провайдер оценивает, куда клиент вводит карту и какие правила видит до оплаты.
AEB в открытых vPOS-условиях описывает требования к сайту и этапы TEST/REAL подключения. Даже если конкретный банк использует свой checklist, бизнесу полезно заранее закрыть этот минимум, чтобы не терять время на замечания после подачи заявки.
- работающий HTTPS и корректный домен;
- контакты, юридические данные и правила возврата;
- понятное описание товаров или услуг;
- success, fail и pending pages;
- ответственный разработчик для TEST-доступов.
Какие тест-кейсы пройти обязательно
Одна успешная тестовая оплата не доказывает, что payment flow готов к production.
Минимальная тестовая матрица должна включать успешную оплату, отказ, pending, закрытие вкладки, повторный переход по success URL, повторную доставку webhook, повторную попытку оплаты того же заказа и проверку CRM/ERP-статусов.
Если проект включает фискализацию, тестируется отдельная очередь чеков: чек после confirmed payment, ошибка данных, retry, ручная проверка и связь receipt с payment id. Если есть возвраты, тестируется полный и частичный refund.
- создание платежной сессии с фиксированной суммой;
- server-side проверка финального статуса;
- idempotency при повторном webhook;
- CRM/ERP получает только нормализованные статусы;
- оператор видит correlation id для поддержки.
Когда можно переходить в REAL
REAL-запуск безопасен, когда команда понимает не только happy path, но и правила разбора исключений.
Переходить в REAL стоит после того, как все критичные сценарии прошли тест, логи доступны, webhook endpoint стабилен, а команда поддержки знает, что делать с pending, failed, refund и mismatch-случаями.
Лучше запускать production постепенно: один канал, один метод оплаты, ограниченный набор товаров или счетов, ежедневная сверка и быстрый канал связи между менеджером, разработчиком и ответственным за платежи.
- есть список пройденных тест-кейсов;
- есть rollback или временное отключение оплаты;
- есть инструкция для поддержки;
- первые дни включена ежедневная сверка;
- ошибки пишутся в журнал, а не только в консоль сервера.
FAQ
Можно ли переходить в REAL после одной успешной тестовой оплаты?
Нет. Нужно проверить отказ, pending, повторный webhook, закрытие вкладки, повторную оплату, CRM/ERP-статусы и поддержку спорных случаев.
Что делать, если банк просит доработать сайт перед подключением?
Закрыть замечания как часть launch checklist: HTTPS, контакты, условия оплаты, возврата, описание товаров или услуг и корректные страницы результата оплаты.
Нужно ли тестировать возвраты до запуска?
Да, если возвраты доступны в бизнес-процессе. Важно проверить связь refund с исходным payment id, CRM/ERP-статус и фискальный сценарий.
Источники
- Armeconombank - VPOSОфициальная страница с требованиями к сайту, TEST/REAL этапами и условиями vPOS.
- Evocabank - V-POS terminalОфициальное описание V-POS для сайта и мобильного приложения с 3D Secure.
- Stripe Documentation - Webhook signatures and deliveryОфициальные рекомендации по проверке подписи, повторной доставке и поведению webhook-событий.
