Skip to content

STATUS_MODEL.md

Latest commit

 

History

History
61 lines (47 loc) · 5.87 KB

STATUS_MODEL.md

File metadata and controls

61 lines (47 loc) · 5.87 KB

Ниже приведено описание статусной модели диспута (спора), исходя из логики кода и предназначения каждого статуса:

  1. created

    • Что означает? Диспут только что заведён в нашей системе, но ещё не «зарегистрирован» у провайдера платежей (или только в процессе регистрации).
    • Переходы:
      • Успешная регистрация в провайдере → pending
      • Провайдер сообщил, что диспут уже существует → already_exist_created
      • Ошибка при создании (или неожиданный ответ) → failed или manual_pending

  2. pending

    • Что означает? Диспут «в ожидании» — то есть он зарегистрирован у провайдера, но ещё не завершён. Мы периодически опрашиваем провайдера, чтобы узнать итог.
    • Переходы:
      • Если провайдер сообщает, что диспут выигран (или иначе закрыт в пользу заявителя) → create_adjustment
      • Если провайдер сообщает об отказе → failed
      • Если в ответах провайдера возникает ситуация, требующая ручного разбора → manual_pending
      • Если время ожидания результата от провайдера истекло → pooling_expired

  3. create_adjustment

    • Что означает? На этом этапе нужно создать так называемую «корректировку» (adjustment) в биллинге, то есть вернуть деньги или иначе оформить итог в финансовом учёте.
    • Переходы:
      • Корректировка в биллинге прошла успешно → succeeded
      • При ошибке или нештатном сценарии → failed или manual_pending

  4. succeeded

    • Что означает? Финальный положительный статус; диспут закрыт с успехом. Деньги (или иные условия) возвращены, вопросов больше нет.
    • Переходы: Нет (конечный статус).

  5. failed

    • Что означает? Финальный статус с ошибкой или отказом (провайдер отказал, произошла невосстановимая проблема, или сам диспут оказался бесперспективен).
    • Переходы: Нет (конечный статус).

  6. manual_pending

    • Что означает? Полуфинальный статус, указывающий на то, что нужен «ручной» разбор специалиста (например, провайдер вернул незапланированный ответ, или произошла логическая ошибка, которую автообработка не смогла решить).
    • Переходы: Обычно после ручного разбора может быть «переотправка» в один из следующих статусов (например, вернуться к created или сразу в pending), либо вручную закрыть диспут как failed.

  7. already_exist_created

    • Что означает? Когда при первом создании у провайдера выясняется, что диспут с такими параметрами уже есть. Обычно обозначает, что «мы» считали диспут новым, а провайдер уже его обрабатывает.
    • Переходы: Как правило, такой диспут «зависает» в этом статусе, но при ручном участии может быть переведён в другое состояние (например, pending).

  8. pooling_expired

    • Что означает? Статус, показывающий, что мы слишком долго ждали ответа от провайдера (или он не меняется) и решили признать диспут «протухшим» (expired).
    • Переходы: Обычно система переводит диспут в failed либо оставляет в pooling_expired как в финальном состоянии (для учёта, что дальше автоматизировать бессмысленно).

  9. cancelled

    • Что означает? Диспут был отменён/отозван (по инициативе мерчанта, банка или другого внешнего запроса).
    • Переходы: Это, как правило, тоже конечный статус.

Итоговая «цепочка» переходов

Чаще всего диспут проходит основную цепочку:

  1. created → 2. pending → 3. create_adjustment → итог: succeeded или failed.

При этом возможны ветвления в «нетипичные» статусы:

  • already_exist_created
  • manual_pending
  • pooling_expired
  • cancelled

Все «финальные» статусы (failed, succeeded, cancelled, иногда pooling_expired) означают, что автоматический процесс закончился.