Опубликовано 25 сентября 2026 г. VPOS.am integration team 10 мин чтения

Tilda и vPOS АраратБанка: от тестовых платежей к рабочему запуску

Как проверить весь путь заказа в тестовой среде и переключить рабочий сайт, сохранив контроль статусов и план возврата к прежней оплате.

Tilda и vPOS АраратБанка: от тестовых платежей к рабочему запуску

В фокусе статьи

Tilda и vPOS АраратБанка: от тестовых платежей к рабочему запускуИнтеграции CMS, CRM и ERPинтеграция оплаты с CRMоплата по ссылке из CRMWooCommerce payment gateway Armenia

Шаг 1. Сверьте банковский пакет до настройки сайта

Тестовая и рабочая среды, кабинет мерчанта и API-доступ решают разные задачи; их параметры нельзя смешивать.

Bank contract → Sandbox → Production
Confirm environments, permissions and return paths before changing the storefront.

Сначала запросите у банка параметры обеих сред: адрес API, идентификатор мерчанта, валюту, разрешённые операции, адреса возврата и уведомлений, требования к доменам и ограничения по IP. Уточните, допускает ли один договор несколько сайтов. Наличие метода в руководстве ещё не означает, что операция разрешена именно вашему мерчанту.

Если банк выдал отдельных пользователей для кабинета и API, меняйте их временные пароли по отдельности через подтверждённый банком интерфейс. Срок действия временного доступа уточните в письме или у поддержки и смените пароль сразу после выдачи. Если он истёк, запросите новый; не проверяйте API-пользователя входом в неподходящую веб-консоль. Пароли и тестовые карты не помещайте в Tilda, адреса страниц, переписку или репозиторий.

  • Отдельно зафиксируйте параметры sandbox и production.
  • Получите подтверждение прав на оплату, возврат и отмену.
  • Уточните у банка точный кабинет смены пароля и срок временного доступа.
  • Храните API-доступ в защищённом хранилище VPOS.am.

Шаг 2. Пройдите весь платёжный цикл на тестовой витрине

Проверка заканчивается только тогда, когда банк подтвердил платёж, а Tilda получила достоверный итог заказа.

Tilda → VPOS.am → Bank → Verified status → Tilda
A bank redirect alone is not a completed payment test.

Создайте отдельный тестовый маршрут банка в VPOS.am и привяжите его к тестовому проекту Tilda. В настройке Custom Payment Gateway сопоставьте поля заказа и все поля, участвующие в подписи, проверьте сумму, валюту, адреса возврата и серверного уведомления. Сохраните настройки, откройте их повторно и опубликуйте тестовую страницу с корзиной.

Для каждого тестового заказа пройдите путь от корзины до размещённой у банка платёжной страницы и обратно на сайт. Затем проверьте банковский статус серверным запросом, запись платежа в VPOS.am и подписанное уведомление Tilda. Согласно документации Tilda, заказ помечается оплаченным только после уведомления с правильной подписью, номером заказа, суммой и признаком успешной оплаты. Страница «Спасибо» этого не доказывает. Количество обязательных оплат и сценарии возврата/отмены определяйте по заданию банка для вашего договора.

  • Сверьте идентификатор заказа, сумму, валюту и финальный статус в банке и VPOS.am.
  • Проверьте доставку уведомления и статус заказа в Tilda.
  • Проведите возврат и отмену только при подтверждённых банком правах.
  • Сохраните обезличенный отчёт испытаний без карт, паролей и одноразовых кодов.

Шаг 3. Ищите ошибку на том участке, где остановился заказ

Журнал Tilda, журнал VPOS.am и ответ банка помогают различить ошибку настроек, отсутствие прав и незавершённый платёж.

Storefront → Signature → Bank → Notification
Inspect the first failed boundary instead of repeating an unknown payment.

Если покупатель видит страницу «Спасибо», но не попадает на оплату, сначала откройте журнал ошибок в разделе «Заявки» (Leads) Tilda: заказ мог не пройти проверку полей ещё до VPOS.am. При ошибке подписи сверяйте сохранённый порядок и соответствие полей конкретной установки, а не только общий шаблон. Для длинных номеров заказов нужен стабильный банковский идентификатор в допустимом формате с обратной связью к исходному заказу.

Если создание платежа и чтение статуса работают, а возврат или отмена отвечают Access denied, причиной могут быть отсутствующие права на эти операции. Сверьте точный ответ API и запросите подтверждение у банка. Сообщение о необходимости сменить пароль означает другую причину отказа. После прерванной 3-D Secure-проверки или сетевого сбоя сначала выясните состояние уже созданного заказа; повторная попытка без сверки может создать двойную оплату.

  • Нет перехода в банк: проверьте ошибки Tilda, маппинг и опубликованную конфигурацию.
  • Ошибка подписи: сверьте секрет, набор и порядок полей конкретной установки.
  • Отказ только при возврате/отмене: проверьте разрешения мерчанта у банка.
  • Результат неизвестен: прочитайте статус существующего платежа до нового списания.

Шаг 4. Переводите рабочие сайты по одному с планом отката

Успешный sandbox-тест не включает рабочий эквайринг автоматически: нужны отдельные реквизиты, права и контрольный платёж.

One site → Live check → Reconcile → Next site
Preserve the old payment setup until the new route is proven.

После подтверждения банка создайте отдельный рабочий маршрут и сохраните действующие настройки платёжного способа на сайте. Проверьте, допускает ли 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)Где просматривать заявки и сообщения об ошибках при работе с платёжными системами.