VangardPay — Регламент работы платежного провайдера

VangardPay — Provider Settlement & Traffic Processing
Версия 2.0 | Апрель 2026 | КОНФИДЕНЦИАЛЬНО

⚠️ Внимание: Документ обязателен к ознакомлению перед началом работы. Доступ выдаётся по решению руководства VangardPay. Материал запрещён к свободному распространению.

1. Общие положения

1.1. Роль платёжного провайдера в экосистеме

Платёжный провайдер — внешняя платёжная компания (PSP), на которую VangardPay маршрутизирует трафик для исполнения операций Pay-in/Pay-out.

1.2. Термины и определения

• Ордер — платёжное поручение, созданное мерчантом в VangardPay и переданное провайдеру на исполнение.
• Pay-in — приём средств от плательщика (пополнение/депозит).
• Pay-out — выплата средств получателю.
• DEPOSIT-режим — провайдер работает на предоплаченном балансе (VangardPay использует депозит провайдера).
• SETTLE-режим — провайдер исполняет трафик «в долг» в пределах лимита, расчёт производится позже.
• Working balance — рабочий баланс провайдера (доступный для исполнения ордеров).
• Frozen balance — замороженный баланс под активные/ожидающие ордера.
• Dispute balance — баланс в диспутах/апелляциях.
• settleThreshold — максимальный допустимый долг провайдера в SETTLE-режиме.

1.3. Приоритет источников

Все заявления в официальных инструкциях VangardPay, FAQ, системных уведомлениях и в официальном Telegram-канале VangardPay являются приоритетными по отношению к настоящему регламенту.

2. Поведение и коммуникация

2.1. Каналы связи

• Все операционные вопросы ведутся только в согласованных рабочих чатах.
• Личные сообщения сотрудникам поддержки VangardPay запрещены, если не инициированы сотрудником.

3. Ответственность

3.1. Ответственность провайдера

Провайдер отвечает за:

• исполнение ордеров в заявленных лимитах/методах/банках;
• корректность статусов и доказательств по операциям;
• своевременное информирование о сбоях, ограничениях и изменениях условий;
• соблюдение антифрод мер и AML правил, а именно чистоты USDT.

3.2. Ответственность VangardPay

VangardPay отвечает за:

• маршрутизацию трафика (cascading/orchestration);
• учёт ордеров и отражение статусов в кабинете провайдера;
• расчёт комиссий по согласованным ставкам;
• коммуникацию с провайдером и управление апелляциями на уровне платформы и чата.

4. Онбординг провайдера

4.1. Предусловия

• Назначены ответственные и контакты 24/7.
• Согласованы лимиты, комиссии, политика апелляций.

4.2. Минимальные требования для работы

5. Финансовая модель и балансы

5.1. Типы балансов

Провайдер ведёт следующие балансы:

• Рабочий — основные средства в USDT, доступные для исполнения ордеров.
• Замороженный — средства, временно заблокированные на время обработки ордеров. При заморозке: balance -= amount, frozenBalance += amount. При завершении: списание. При отмене: разморозка обратно.
• Апелляционный — удержания на время разбирательств по апелляциям.
• Переходной — средства, удерживаемые для покрытия возможных будущих апелляций и chargeback'ов. По мере стабильной и предсказуемой работы провайдера (истечение hold-периода, отсутствие диспутов) постепенно переводятся в рабочий баланс.

5.2. Режимы работы

5.2.1. DEPOSIT (предоплата)

Провайдер авансирует средства. Перед обработкой ордера средства замораживаются из рабочего баланса.

Ордер создан (5000 RUB = 61.65 USDT):
  balance: 10000 → 9938.35 USDT  (-61.65)
  frozenBalance: 0 → 61.65 USDT  (+61.65)

Ордер завершён:
  frozenBalance: 61.65 → 0 USDT  (списание)
  transitBalance: 0 → 6.17 USDT  (+комиссия 10%)
  Мерчант: +55.48 USDT (за вычетом комиссии мерчанта)

5.2.2. SETTLE (постоплата)

Провайдер работает в долг. Средства не замораживаются при создании ордера. Провайдер расчитывается позже.

Ордер создан (5000 RUB = 61.65 USDT):
  Средства НЕ замораживаются
  settleThreshold проверяется для лимита долга

Ордер завершён:
  transitBalance -= 61.65 USDT  (долг провайдера)
  transitBalance += 6.17 USDT   (доход провайдера)
  Нетто: transitBalance -= 55.48 USDT

5.3. Пополнение и вывод средств

Пополнение рабочего баланса (DEPOSIT-режим)

Пополнение осуществляется переводом USDT (сеть TRC20) на адрес, предоставленный VangardPay. Зачисление происходит после подтверждения транзакции в сети.

Вывод средств

Вывод рабочего баланса — по заявке через согласованный канал. Вывод переходного (transit) баланса — поэтапно после истечения hold-периода (50% через 7 дней с момента начисления, оставшиеся 50% — ещё через 7 дней, итого 14 дней до полного вывода).

5.4. Запреты и требования

• Запрещено изменять финансовые условия «задним числом» по уже созданным ордерам.
• Провайдер обязан заранее уведомлять об изменениях комиссий/лимитов/банков.
• Запрещено пополнение рабочего баланса USDT с уровнем риска (risk score) более 40%. Транзакции, не прошедшие проверку AML, отклоняются автоматически. Средства возвращаются отправителю за вычетом сетевой комиссии.

6. Апелляции и диспуты

• Провайдер обязан соблюдать согласованные SLA по обработке.
• При деградации (рост pending/timeout) — немедленно уведомить VangardPay и/или временно остановить метод/банк.

6.1. Классификация апелляций

Категория A — Ошибка плательщика

Качество информирования плательщика на платёжной форме мерчанта напрямую влияет на объём апелляций. Провайдер обязан корректно обрабатывать каждый тип.

Категория B — Фрод

При выявлении фрода провайдер немедленно уведомляет VangardPay и блокирует подозрительный реквизит/метод.

Категория C — Техническая ошибка

Сбой автоматики: задержка webhook, потеря SMS-подтверждения, таймаут банковского API. Провайдер обязан предоставить технические логи (webhook-запросы/ответы, trace ID, таймстемпы) для расследования.

6.2. Процедура рассмотрения

Этап 1. Первичная апелляция

1. VangardPay направляет провайдеру апелляцию: vpId, категория, сумма, доказательства (чек / видео плательщика).
2. Провайдер проверяет лог транзакций на своей стороне.
3. Решения:
   • Платёж найден, не привязан к другому ордеру → провайдер подтверждает → апелляция одобрена, статус ордера меняется на COMPLETED.
   • Платёж не найден → провайдер отклоняет с приложением банковской выписки или лога → переход на проверку саппортом и возможную вторичную апелляцию.
   • Платёж зачтён по другому ордеру → провайдер предоставляет mapping (ID платежа → vpId) → окончательное отклонение, вторичная апелляция невозможна.

После отклонения саппорт VangardPay проверяет документы и запрашивает у мерчанта дополнительные доказательства (видео). Если мерчант не предоставляет документы в течение 24 часов — апелляция отклонена.

Этап 2. Вторичная апелляция

Возможна только при отклонении по причине «Платёж не обнаружен». Следующие причины отклонения являются окончательными и не подлежат вторичной апелляции:

• Зачтён по другому ордеру — платёж уже привязан к другой операции
• Фрод (категория B) — повторные попытки могут привести к блокировке

1. VangardPay передаёт провайдеру расширенные доказательства (видеозапись плательщика).
2. Провайдер обязан в течение 3 банковских дней:
   • Предоставить встречное видео или расширенный лог → решение в пользу провайдера.
   • Или подтвердить апелляцию.
3. Если провайдер не предоставляет доказательства в срок → апелляция закрывается в пользу мерчанта.

6.3. Иерархия доказательств

От слабого к сильному:

6.4. Требования к доказательствам провайдера

При отклонении апелляции — минимум одно из:

• Банковская выписка / лог транзакций: приходные операции за период TTL ордера. Отсутствие поступления с указанной суммой и временем.
• Видеозапись системы мониторинга: вход в систему → операция (или её отсутствие) → суммы, даты, реквизиты.
• Технический лог (для категории C): webhook-запросы/ответы, HTTP-статусы, trace ID.

При подтверждении: достаточно указать факт обнаружения платежа с ID операции на стороне провайдера.

6.5. Сроки рассмотрения (SLA)

Служба апелляций провайдера должна работать 24/7.

6.6. Автоматическое отключение от трафика

6.7. Dispute balance

На время рассмотрения спора сумма перемещается в dispute balance провайдера:

• Решение в пользу мерчанта → списание из dispute balance, зачисление мерчанту.
• Решение в пользу провайдера → возврат в рабочий / transit баланс.

7. Отчётность и сверка (Reconciliation)

7.1. Ежедневная сверка

Провайдер обязан:

1. Ежедневно сверять количество и суммы завершённых ордеров с данными VangardPay.
2. При обнаружении расхождений — немедленно сообщить через рабочий чат с указанием ID ордеров.
3. Вести внутренний учёт: начальный баланс дня, объём операций, комиссии, итоговый баланс.

7.2. Отчёты

• VangardPay предоставляет данные по ордерам провайдера через кабинет провайдера.
• Данные можно выгрузить в CSV/Excel.
• Сверка производится по UTC.

8. Безопасность и комплаенс

8.1. AML

Провайдер обязан:

• Проверять и использовать для пополнения баланса USDT с уровнем риска менее 41%.
• Пополнение баланса запрещено с санкционных бирж, миксеров и смарт-контрактов.

8.2. Запрещённые действия

• фальсификация чеков/доказательств;
• манипуляция статусами;
• сокрытие инцидентов;
• использование трафика для иных целей.

9. Заключительные положения

Настоящий регламент обязателен для исполнения провайдером после начала обработки трафика VangardPay.

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

При возникновении спорных ситуаций, не описанных в регламенте, решение принимается администрацией VangardPay в индивидуальном порядке.

© 2026 VangardPay. Все права защищены.