Таблица соответствия статусов
Единый справочник статусов сделок, выплат, споров, выводов и whitelist-pass'ов на платформе Syncra V2
Справочник и соответствие статусов
В этом разделе приведена каноническая таблица всех состояний сущностей платформы Syncra V2. Колонка V1 compat приведена исключительно справочно — для мерчантов, мигрирующих с платформы V1.
Все строковые значения регистрозависимы (передаются как
UPPER_SNAKE_CASE), кроме amount_match_status, который всегда
lowercase (full / partial / overpaid).
Типы реквизитов (Requisite Types)
Платформа не привязана к конкретной стране или платёжной инфраструктуре: выбор рынка (РФ, СНГ, Турция, ЕС, ...) определяется конфигурацией тенанта. Любой платёжный инструмент — это реквизит одного из пяти типов:
| Тип реквизита | Описание | Ключевое поле в CheckoutView |
|---|---|---|
BANK_CARD | Перевод по номеру банковской карты (Card2Card, P2P). Базовый метод для РФ/СНГ. | card_number, holder_name |
E_WALLET | Перевод на электронный кошелёк (цифровой идентификатор). | card_number (идентификатор кошелька), holder_name |
SBP | Перевод по номеру телефона через Систему быстрых платежей (РФ). | phone_number, holder_name |
SIM | Перевод, привязанный к SIM-номеру (мобильные каналы). | phone_number |
BANK_TRANSFER | Международный банковский перевод по IBAN (ISO 13616). Havale (TR), SEPA (EU) и аналоги. IBAN шифруется тем же способом, что и PAN. | iban, holder_name |
Тип реквизита не передаётся в запросе CreateMerchantPayIn. Он
определяется конфигурацией связки «мерчант → payment_method_id → валюта»
и возвращается клиенту на платёжной странице через поля CheckoutView.
Статус сверки сумм (AmountMatchStatus)
Передаётся только в webhook-событиях PayIn (поле amount_match_status в
CallbackEventPayload) и в CheckoutView. Всегда lowercase.
| Значение | Описание |
|---|---|
full | Поступившая сумма точно совпала с заявленной. |
partial | Поступило меньше заявленного. |
overpaid | Поступило больше заявленного. |
amount_match_status — это не OrderStatus, а производный атрибут
сделки в COMPLETED / PAYMENT_VERIFIED. Приоритет при отображении:
overpaid > partial (сделка не может быть одновременно в обоих).
Входящие платежи (PayIn OrderStatus)
Канонический жизненный цикл PayIn-сделки включает 11 значений. Переходы между статусами управляются системой автоматически.
| Канонический статус V2 | Финальный? | Описание состояния | V1 compat (справочно) |
|---|---|---|---|
INITIALIZED | Нет | Сделка создана, ожидает эскроу-лока и оплаты. | 1 WaitingPayment / 31 WaitingPaymentChannel |
ESCROW_LOCKED | Нет | Эскроу-холд зарезервирован, реквизиты выданы клиенту. | 1 WaitingPayment |
PAYMENT_NOTIFIED | Нет | Клиент нажал «Я оплатил», ожидает проверки трейдером. | 2 ConfirmedByPayer |
PAYMENT_VERIFIED | Нет | Поступление средств подтверждено трейдером, сумма сверена. | 11 Paid |
COMPLETED | Да (Успех) | Сделка финально завершена успешно. amount_match_status=full/partial/overpaid уточняет исход. | 11 Paid / 14 OverPaid / 15 PartiallyPaid |
EXPIRED | Да (Таймаут) | Сделка истекла по payment_timeout_at до верификации. | 13 Timeout |
APPEALED | Нет | По сделке открыта апелляция — передана в арбитраж. | 21 Disput |
REFUND_PENDING | Нет | Инициирован возврат средств клиенту, ожидает исполнения. | 32 RollingBack / 16 Returned |
SPAM_REJECTED | Да (Отказ) | Сделка отклонена системой защиты от мошенничества. | 12 Cancelled |
SOFT_DISPUTED | Нет | Мягкий спор: расхождение данных без полной апелляции. | 21 Disput |
CANCELLED | Да (Отказ) | Игрок или мерч явно отменил сделку до подтверждения платежа. Только PayIn; эскроу-холды снимаются автоматически. | 12 Cancelled |
V1-коды 14 (OverPaid) и 15 (PartiallyPaid) не являются отдельными
OrderStatus в V2. Сделка остаётся в COMPLETED, а переплата/недоплата
сигнализируется полем amount_match_status = overpaid / partial.
При работе через V1-протокол в callback эти значения транслируются
обратно в коды 14/15.
Диаграмма переходов PayIn:
SPAM_REJECTED присваивается системой защиты от мошенничества вне карты
переходов и не имеет входящих дуг. CANCELLED — терминальный статус
явной отмены: достижим только из INITIALIZED, ESCROW_LOCKED и
PAYMENT_NOTIFIED (см. PayIn → Отмена
сделки); после перехода эскроу-холды
снимаются автоматически, fee_breakdown обнуляется, матчи переходят
в FAILED.
Поля суммы сделки (deal-amount)
| Поле | Тип | Описание |
|---|---|---|
amount | int64 | Заявленная фиатовя сумма (минорные единицы). Может быть изменена оператором до PAYMENT_VERIFIED (см. amend). |
amount_version | int64 | Монотонный счётчик правок суммы. Новая сделка стартует с 1; каждый amend +1. В вебхуке deal.amount_changed передаётся вместе со старой/новой суммой; в запросе amend используется как optimistic-lock (If-Match). |
amount_usdt | int64 | USDT-эквивалент по курсу сделки (exchange_rate_micro); при amend пересчитывается тем же курсом. |
received_amount | int64 | Фактически полученная сумма (провайдер/сверка). Сохраняется навсегда, в т.ч. у EXPIRED-сделок — источник суммы сеттлмента. |
amount_match_status | string | full / partial / overpaid — результат сверки (received_amount vs amount). |
parent_deal_id | string(UUID) | Только у сеттлмента: истёкший оригинал (см. settle-as-received). |
origin_appeal_id | string(UUID) | Только у сеттлмента: апелляция, резолвом которой он создан (одна апелляция → один сеттлмент). |
Исходящие выплаты (PayOut Status)
Канонический жизненный цикл PayOut включает 7 значений. PayOut использует отдельный домен статусов от PayIn.
| Канонический статус V2 | Финальный? | Описание состояния | V1 compat (справочно) |
|---|---|---|---|
INITIALIZED | Нет | Стартовый статус: выплата создана, баланс захолдирован. Наблюдается только в граничных случаях (провайдер-ветка, гонки) — при синхронном авто-матчинге ответ создания приходит сразу MATCHED/UNASSIGNED. | 1 WaitingProcessing |
MATCHED | Нет | Трейдер/команда назначена. Типичный статус сразу после создания при синхронном авто-матчинге (есть свободный трейдер). | 1 WaitingProcessing |
UNASSIGNED | Нет | Свободного трейдера нет на момент создания (нет ёмкости каскада). Система автоматически продолжает мэтчинг: при успехе → MATCHED; при истечении SLA на назначение → EXPIRED. Ручное назначение остаётся доступным для оператора. | 1 WaitingProcessing |
PROCESSING | Нет | Трейдер осуществляет перевод средств получателю. | 40 InProgress / 50 PayingRightNow |
COMPLETED | Да (Успех) | Средства отправлены получателю, эскроу-холд списан. | 10 Paid |
FAILED | Да (Отказ) | Выплата отклонена (неверные реквизиты, отмена трейдером). Холд возвращён на баланс мерчанта. | 30 Failed |
EXPIRED | Да (Таймаут) | PayOut истёк до завершения перевода (в т.ч. по SLA на назначение из UNASSIGNED); холд возвращается мерчанту. | 30 Failed |
Диаграмма переходов PayOut:
PayOut не использует статусы PayIn (PAYMENT_NOTIFIED,
PAYMENT_VERIFIED, APPEALED и т.д.). Это разные жизненные циклы.
Апелляции / Диспуты (Appeal Status)
Канонический жизненный цикл апелляции включает 5 значений.
| Канонический статус V2 | Финальный? | Описание состояния | V1 compat (справочно) |
|---|---|---|---|
OPEN | Нет | Апелляция создана, ожидает назначения арбитра. | 1 |
IN_PROGRESS | Нет | Арбитр рассматривает спор, ведётся чат. | 2 IN_REVIEW |
REOPENED | Нет | Апелляция открыта повторно для доп. расследования. | 6 |
SATISFIED | Да | Спор разрешён в пользу инициатора (мерчанта). | 3 RESOLVED_MERCHANT / 5 REFUNDED |
REJECTED | Да | Спор отклонён (доказательства недостаточны). | 4 RESOLVED_TRADER |
V1-значения IN_REVIEW, RESOLVED_MERCHANT, RESOLVED_TRADER,
REFUNDED, CLOSED не существуют в V2. Маппинг — только на стороне
V1-протокола для мигрирующих мерчантов.
Криптовалютные выводы (Withdrawal Status)
Жизненный цикл вывода USDT на внешний кошелёк включает 3 значения. Вывод — отдельная сущность от PayOut.
| Канонический статус V2 | Финальный? | Описание состояния | V1 compat (справочно) |
|---|---|---|---|
PENDING | Нет | Заявка создана, средства зарезервированы, ожидает on-chain broadcast. | 1 |
APPROVED | Да (Успех) | On-chain tx отправлена, ledger списан. V1 видит это как COMPLETED. | 3 COMPLETED |
CANCELLED | Да (Отказ) | Отклонена админом или отменена до broadcast. Возврат на баланс. | 4 FAILED |
Это доменный статус заявки (вебхуки p2p.finance.withdrawal_*).
У вывода две другие статусные поверхности: синхронный ответ
POST /wallet/withdraw возвращает COMPLETED/PENDING_MANUAL, а
листинг GET /wallet/withdrawals дополнительно различает PENDING
(ждёт одобрения) и COMPLETED (broadcast прошёл) — все три описаны
в Wallet → Статусы заявки на вывод.
PROCESSING зарезервирован для будущего шага подтверждения блока между
APPROVED и финальным подтверждением — в текущей версии API не
возвращается.
Whitelist Pass Status
Жизненный цикл пред-одобренного whitelist-pass'а включает 4 значения. Pass — это двухфазный механизм: резервация при создании сделки, подтверждение при завершении.
| Канонический статус V2 | Финальный? | Описание состояния |
|---|---|---|
ACTIVE | Нет | Pass доступен для матчинга. |
RESERVED | Нет | Сделка забронировала pass; другая сделка не может его занять. |
USED | Да | Сделка-владелец pass'а успешно завершена. Терминальный. |
EXPIRED | Да | TTL pass'а истёк до использования. Терминальный. |
Диаграмма переходов pass'а:
RESERVED → ACTIVE происходит автоматически при истечении/отмене
сделки-владельца — pass возвращается в пул.
Полный реестр числовых кодов V1 (compat-контур)
Это исчерпывающий реестр числовых статусов, которые V1-протокол
(/v1/payments/incoming|outgoing, /v1/merchant/withdraw,
/v1/disputs) возвращает в поле status — как в REST-ответах, так и в
телах вебхуков. Набор кодов соответствует V1-спеке платформы
(MerchantApiPaymentProfile.status /
MerchantApiWithdrawProfile.status).
Интеграторам, работающим по V1-протоколу, следует зарегистрировать все перечисленные коды — это исключает зависание операций на незнакомых статусах.
Исходящие выплаты (outgoing — /v1/payments/outgoing)
| Код | Имя | Финальный? | Когда возвращается (внутренние V2-статусы) |
|---|---|---|---|
1 | WaitingProcessing | Нет | создана / ожидает обработчика (INITIALIZED, MATCHED, UNASSIGNED, PENDING) |
40 | InProgress | Нет | трейдер принял в работу (PROCESSING, ESCROW_LOCKED, PAYMENT_NOTIFIED) |
50 | PayingRightNow | Нет | перевод исполняется (EXECUTING, TRADER_SENT, PAYMENT_VERIFIED); исход — код 10 или 30; sentAt/sentAmount заполняются в финальном статусе |
10 | Paid | Да (успех) | выплата исполнена (COMPLETED, PAID) |
20 | PaidPartially | Да | зарезервирован для совместимости; текущей версией API не возвращается — в V2 частичные выплаты не поддерживаются |
30 | Failed | Да (отказ) | отказ: отмена, неверные реквизиты, таймаут (EXPIRED), спор (DISPUTED) — в V1-протоколе отдельных кодов для таймаута и спора у выплат не предусмотрено, всё возвращается как 30; холд возвращается |
Подтверждение по исходящим: коды 2, 13, 14, 16, 21 по
/v1/payments/outgoing не возвращаются ни при каких условиях — они
не входят в набор кодов выплат. Фактический набор исходящих кодов:
1, 40, 50 (промежуточные) → 10, 30 (финальные).
Вебхуки PayOut используют коды этого же реестра: PROCESSING →
40 (InProgress), FAILED/EXPIRED → 30 (Failed), COMPLETED →
10 (Paid).
Входящие платежи (incoming — /v1/payments/incoming)
| Код | Имя | Финальный? | Когда возвращается (внутренние V2-статусы) |
|---|---|---|---|
1 | WaitingPayment | Нет | ожидает оплаты (PENDING, WAITING_PAYMENT, ESCROW_LOCKED) |
31 | WaitingPaymentChannel | Нет | канал/метод не определён (AWAITING_METHOD, PROCESSING, EXECUTING) |
2 | ConfirmedByPayer | Нет | плательщик подтвердил оплату (CUSTOMER_CONFIRMED, TRADER_RECEIVED) |
32 | RollingBack | Нет | возврат в процессе: GET-запрос /v1/payments/incoming/{id} возвращает 32 на статусе REFUND_PENDING; вебхук на той же стадии возвращает 16 |
21 | Disput | Нет | спор (DISPUTED, APPEALED, SOFT_DISPUTED) |
11 | Paid | Да (успех) | оплачен (COMPLETED, PAID, PAYMENT_VERIFIED) |
12 | Cancelled | Да | отменена, в т.ч. системой защиты (CANCELLED, SPAM_REJECTED) |
13 | Timeout | Да | истекла по окну оплаты (EXPIRED) |
14 | OverPaid | Да | переплата (OVERPAID) |
15 | PartiallyPaid | Да | недоплата (UNDERPAID) |
16 | Returned | Да* | возврат инициирован (REFUND_PENDING). Не безусловный финал: после возврата сделка может вернуться в рабочий цикл. * вебхук-контур возвращает 16 на стадии REFUND_PENDING |
1000 | Unknown | — | резервный код (UNKNOWN) |
Крипто-выводы (withdraw — /v1/merchant/withdraw)
| Код | Имя | Финальный? |
|---|---|---|
1 | Created | Нет |
2 | InProgress | Нет |
3 | Completed | Да (успех) |
4 | Failed | Да (отказ) |
Правило обработки: любой незарегистрированный код следует трактовать как промежуточный и продолжать опрос — финальными являются только перечисленные выше.