Сайт должен быть понятен банку и покупателю
Требования к сайту - это не формальность, а способ снизить споры, chargeback и ошибки поддержки.
Перед подключением vPOS сайт должен ясно показывать, кто принимает оплату, что продается, как клиент получает товар или услугу и как оформляется возврат. Это не просто хорошая практика: AEB в требованиях к vPOS прямо указывает HTTPS, домен/URL сайта или приложения, реальные IP-данные, а также наличие правил оплаты, зоны ответственности и процедуры рассмотрения жалоб.
Практический ответ для бизнеса: до заявки в банк сайт должен выглядеть как готовая торговая точка, а не как landing page с кнопкой "оплатить". Если нет условий оплаты, возврата, контактов и понятного описания услуги, банковская проверка может вернуться с замечаниями до технической интеграции.
- HTTPS на всех страницах checkout;
- рабочий домен и URL сайта или приложения для заявки;
- контакты компании и канал поддержки;
- условия оплаты, доставки или оказания услуги;
- политика возврата и отмены;
- privacy policy и обработка персональных данных.
Техническая готовность backend
vPOS нельзя безопасно подключать только frontend-кнопкой. Решение об оплате должен принимать backend.
Frontend может показать кнопку и перенаправить клиента, но он не должен решать, оплачен ли заказ. Backend должен создать платеж, сохранить идентификаторы, проверить финальный статус и только после этого обновить заказ.
AEB описывает выдачу TEST integration data до передачи live/REAL данных, а Inecobank указывает, что специалисты помогают установить vPOS в online domain и выполнить software settings. Значит, готовность backend - это обязательная часть запуска: без тестового сценария, журналов и проверки callback нельзя считать интеграцию завершенной.
- endpoint для создания платежной попытки;
- success/fail страницы без доверия к query parameters;
- webhook или callback endpoint;
- server-side проверка суммы, валюты и order id;
- логирование критичных платежных событий.
Что проверить перед отправкой сайта на review
Лучше найти проблемы до банковской проверки, чем возвращаться к доработкам после отказа или замечаний.
Перед отправкой сайта на review нужно пройти пользовательский путь от карточки товара или услуги до попытки оплаты. Все цены, условия и контакты должны быть доступны без скрытых договоренностей, а страницы политики и условий не должны быть пустыми шаблонами.
Также важно проверить, что технический владелец понимает, где смотреть логи, как повторить проверку статуса и кто отвечает за спорные платежи. Для AEB отдельно важно хранение информации о транзакциях и товарах/услугах минимум один год; даже если выбран другой банк, эта логика полезна для поддержки, бухгалтерии и chargeback-разборов.
- нет пустых страниц и тестового контента;
- цены и валюта отображаются явно;
- возврат и отмена описаны простым языком;
- контакты совпадают с оператором оплаты;
- тестовый платеж проходит полный lifecycle.
FAQ
Обязателен ли HTTPS для подключения vPOS?
Да, для платежного checkout HTTPS является базовым требованием. Конкретные детали зависят от провайдера, но без безопасного соединения запуск платежей рассматривать нельзя.
Можно ли принимать оплату без страницы возвратов?
Это риск. Для клиента, банка и поддержки должны быть понятны правила отмены, возврата и обработки спорных ситуаций.
Что должен делать backend после success redirect?
Он должен отдельно проверить статус платежа у провайдера или дождаться trusted webhook, а не доверять только возврату пользователя на сайт.
Источники
- Armeconombank - VPOS requirements and tariffsОфициальные условия: HTTPS, домен/URL, TEST/REAL данные, правила оплаты/ответственности/жалоб и требования к хранению информации.
- Inecobank - VPOS installation and supportОфициальное описание процесса заявки, установки vPOS и 3D Secure/SecureCode.
- Evocabank - V-POS TerminalОфициальное описание установки V-POS на сайт и мобильное приложение.
