В фокусе статьи
Шаг 1. Сверьте банковский пакет до настройки сайта
Тестовая и рабочая среды, кабинет мерчанта и API-доступ решают разные задачи; их параметры нельзя смешивать.
Сначала запросите у банка параметры обеих сред: адрес API, идентификатор мерчанта, валюту, разрешённые операции, адреса возврата и уведомлений, требования к доменам и ограничения по IP. Уточните, допускает ли один договор несколько сайтов. Наличие метода в руководстве ещё не означает, что операция разрешена именно вашему мерчанту.
Если банк выдал отдельных пользователей для кабинета и API, меняйте их временные пароли по отдельности через подтверждённый банком интерфейс. Срок действия временного доступа уточните в письме или у поддержки и смените пароль сразу после выдачи. Если он истёк, запросите новый; не проверяйте API-пользователя входом в неподходящую веб-консоль. Пароли и тестовые карты не помещайте в Tilda, адреса страниц, переписку или репозиторий.
- Отдельно зафиксируйте параметры sandbox и production.
- Получите подтверждение прав на оплату, возврат и отмену.
- Уточните у банка точный кабинет смены пароля и срок временного доступа.
- Храните API-доступ в защищённом хранилище VPOS.am.
Шаг 2. Пройдите весь платёжный цикл на тестовой витрине
Проверка заканчивается только тогда, когда банк подтвердил платёж, а Tilda получила достоверный итог заказа.
Создайте отдельный тестовый маршрут банка в VPOS.am и привяжите его к тестовому проекту Tilda. В настройке Custom Payment Gateway сопоставьте поля заказа и все поля, участвующие в подписи, проверьте сумму, валюту, адреса возврата и серверного уведомления. Сохраните настройки, откройте их повторно и опубликуйте тестовую страницу с корзиной.
Для каждого тестового заказа пройдите путь от корзины до размещённой у банка платёжной страницы и обратно на сайт. Затем проверьте банковский статус серверным запросом, запись платежа в VPOS.am и подписанное уведомление Tilda. Согласно документации Tilda, заказ помечается оплаченным только после уведомления с правильной подписью, номером заказа, суммой и признаком успешной оплаты. Страница «Спасибо» этого не доказывает. Количество обязательных оплат и сценарии возврата/отмены определяйте по заданию банка для вашего договора.
- Сверьте идентификатор заказа, сумму, валюту и финальный статус в банке и VPOS.am.
- Проверьте доставку уведомления и статус заказа в Tilda.
- Проведите возврат и отмену только при подтверждённых банком правах.
- Сохраните обезличенный отчёт испытаний без карт, паролей и одноразовых кодов.
Шаг 3. Ищите ошибку на том участке, где остановился заказ
Журнал Tilda, журнал VPOS.am и ответ банка помогают различить ошибку настроек, отсутствие прав и незавершённый платёж.
Если покупатель видит страницу «Спасибо», но не попадает на оплату, сначала откройте журнал ошибок в разделе «Заявки» (Leads) Tilda: заказ мог не пройти проверку полей ещё до VPOS.am. При ошибке подписи сверяйте сохранённый порядок и соответствие полей конкретной установки, а не только общий шаблон. Для длинных номеров заказов нужен стабильный банковский идентификатор в допустимом формате с обратной связью к исходному заказу.
Если создание платежа и чтение статуса работают, а возврат или отмена отвечают Access denied, причиной могут быть отсутствующие права на эти операции. Сверьте точный ответ API и запросите подтверждение у банка. Сообщение о необходимости сменить пароль означает другую причину отказа. После прерванной 3-D Secure-проверки или сетевого сбоя сначала выясните состояние уже созданного заказа; повторная попытка без сверки может создать двойную оплату.
- Нет перехода в банк: проверьте ошибки Tilda, маппинг и опубликованную конфигурацию.
- Ошибка подписи: сверьте секрет, набор и порядок полей конкретной установки.
- Отказ только при возврате/отмене: проверьте разрешения мерчанта у банка.
- Результат неизвестен: прочитайте статус существующего платежа до нового списания.
Шаг 4. Переводите рабочие сайты по одному с планом отката
Успешный sandbox-тест не включает рабочий эквайринг автоматически: нужны отдельные реквизиты, права и контрольный платёж.
После подтверждения банка создайте отдельный рабочий маршрут и сохраните действующие настройки платёжного способа на сайте. Проверьте, допускает ли Tilda параллельный способ оплаты: занятый слот может означать реальное переключение текущих продаж. Назначьте окно переноса и ответственных, затем переводите сначала один сайт, оставляя остальные на прежнем маршруте.
Проведите согласованный контрольный платёж небольшой суммы и сверьте финальный статус банка, запись VPOS.am, заказ Tilda и банковский отчёт. Если результат расходится, приостановите новый маршрут, восстановите прежнюю конфигурацию и разберите неопределённые операции до повторного запуска. Только после успешной проверки первого сайта переходите к другим. Фискальный чек ведите отдельным контролируемым процессом: подтверждение денег и выпуск чека имеют разные статусы.
- Не переносите тестовый пароль или маршрут в рабочую среду.
- Зафиксируйте прежние настройки и порядок возврата к ним.
- Проверяйте каждый сайт и домен отдельно.
- Закрывайте запуск по банковскому статусу, уведомлению Tilda и сверке отчёта.
FAQ
Достаточно ли страницы «Спасибо», чтобы считать заказ оплаченным?
Нет. Проверьте финальный статус у банка и доставку корректного серверного уведомления в Tilda. Возврат браузера сам по себе не подтверждает списание.
Почему API отвечает на оплату, но отклоняет возврат?
Права на возврат и отмену могут выдаваться отдельно. Сверьте точный ответ API и запросите подтверждение разрешённых операций у банка.
Можно ли сразу заменить текущую оплату на всех сайтах?
Безопаснее сохранить прежнюю конфигурацию и переводить сайты по одному после согласованного контрольного платежа и сверки его результата.
Источники и документация
- AraratBank — POS terminal и Virtual POS / e-commerceОфициальное описание банковской услуги для онлайн-платформ; права и условия подключения определяются договором.
- Tilda Help Center — Custom Payment GatewayОфициальный порядок передачи заказа, настройки подписи и уведомления, после которого заказ получает статус оплаты.
- Tilda Help Center — Заявки (Leads)Где просматривать заявки и сообщения об ошибках при работе с платёжными системами.