Пример SJM — платёж и спорная операция

Учебная карта связывает обычный платёжный путь с отказом, спорной операцией и service recovery. Нормативные сроки и основания зависят от продукта и юрисдикции: source_required.

Назначение карты

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

Границы процесса

Старт

Клиент инициирует платёж или замечает операцию, которую хочет оспорить.

Завершение

Клиент получает подтверждённый итоговый статус и понятный дальнейший маршрут.

Что не входит в карту

• Конкретные antifraud-правила и внутренняя архитектура банка.
• Детальное право оспаривания по конкретной юрисдикции.
• Реальные названия платёжных систем и интеграций.

Слои карты

Этап	Действие клиента	Frontstage	Backstage / systems	Условия и ошибки	Метрики
1. Инициация	Вводит данные платежа	Форма, сумма, получатель, комиссия	Проверка полноты и условий	Ошибка ввода, неясная комиссия	Drop-off, ошибки формы
2. Подтверждение	Подтверждает действие	Подтверждение и предупреждения	Авторизация и проверки	Тайм-аут, отклонение, повторная попытка	Approval rate, latency
3. Результат	Проверяет статус	Успешно, отклонено или в обработке	Фиксация статуса, уведомление	Зависший статус, расхождение каналов	Время статуса, обращения
4. Спор	Сообщает о проблеме	Форма обращения, номер, SLA	Регистрация, классификация, сбор evidence	Недостаточно данных, неверная маршрутизация	Время регистрации, повторные обращения
5. Разрешение	Получает ответ	Итог и следующий шаг	Проверка, решение, corrective action	Неполный ответ, нет объяснения	Срок ответа, reopen rate

Основной сценарий

Клиент вводит данные платежа, подтверждает операцию и получает статус. Если платёж прошёл — клиент видит подтверждение. Если клиент оспаривает операцию — обращение регистрируется, проверяется и получает решение.

flowchart TD
    A[Клиент вводит данные платежа] --> B[Подтверждение операции]
    B --> C{Авторизация прошла?}
    C -->|Да| D[Платёж исполнен]
    C -->|Нет| E[Клиент видит причину отказа]
    C -->|Тайм-аут| F[Зависший статус — риск дубля]
    D --> G{Клиент согласен с результатом?}
    G -->|Да| H[Путь завершён]
    G -->|Нет — оспаривает| I[Регистрация спора]
    I --> J[Сбор evidence и классификация]
    J --> K[Проверка и решение]
    K --> L[Клиент получает ответ]
    F --> M[Клиент обращается в поддержку]
    E --> M

Обязательные негативные ветки

• Платёж отклонён до подтверждения.
• Клиент повторяет попытку и рискует создать дубль.
• Статус отличается между приложением и поддержкой.
• Клиент оспаривает операцию без понятной инструкции.
• Ответ требует дополнительного evidence или продления.
• Клиент не получил уведомление о решении.

Узкие места

• Неясный статус при тайм-ауте авторизации.
• Нет механизма обнаружения дублей перед повторной попыткой.
• Клиент не видит нормативного срока ответа по спору.
• Расхождение статуса операции между каналами.
• Форма спора не подсказывает, какие данные нужны.

Региональные ссылки

• Россия: SJM — Россия и применимость 161-ФЗ.
• ЕС: SJM — Европейский союз и действующая база PSD2; PSD3 / PSR пока не выдавать за действующее право.
• США: SJM — США и применимость Regulation E.

Tooling и сопровождение

Инструмент	Что должен поддерживать	Что проверить
Форма платежа	полная информация о комиссии, подтверждение до отправки	понятна ли клиенту итоговая сумма до нажатия
Авторизационная система	статусы, тайм-ауты, retry-логика	есть ли защита от дублей при повторной попытке
Система уведомлений	статус операции, срок ответа по спору, промежуточные статусы	получает ли клиент уведомление при каждой смене статуса
Система обращений	регистрация спора, сбор evidence, SLA, история	корректно ли запускаются SLA и маршрутизация по типу спора
Мониторинг	тайм-ауты, зависшие авторизации, аномальные паттерны	может ли поддержка быстро найти транзакцию по обращению

Тестовый слой

Проверка	Что подтвердить	Evidence
Требования	условия платежа, статусы, сроки спора описаны проверяемо	Тест-анализ требований сервиса
Чек-лист	есть positive, rejection, timeout, duplicate и dispute cases	Чек-листы и тест-кейсы сервиса
Негативные ветки	каждый отказ, тайм-аут и расхождение статуса проверен	ручное тестирование + QA-отчёт
Defect report	дубль, неверный статус, не запустился SLA — отдельный дефект	Дефекты сервиса и RCA
Regression	после изменения авторизации, формы спора или уведомлений повторяются критичные проверки	regression set

Quick wins

• Добавить явное предупреждение при повторной попытке с зависшим статусом.
• Показывать клиенту нормативный срок ответа при регистрации спора.
• Убедиться, что статус операции одинаков во всех каналах.
• Добавить подсказки в форму спора: какие данные нужны.
• Отправить уведомление при любой смене статуса спора.

Системные улучшения

• Ввести механизм idempotency / защиты от дублей при повторной авторизации.
• Обеспечить единый источник статуса операции для всех каналов.
• Настроить автоматический SLA-контроль по типу и сроку спора.
• Связать повторяющиеся причины споров с анализом продуктовых условий и antifraud.
• Обновлять SJM и условия продукта после изменения нормативной базы.

Вопросы для уточнения

• Какие причины отклонения платежа наиболее частые?
• Есть ли защита от дублей при повторной попытке?
• Как клиент узнаёт нормативный срок ответа по спору?
• Какие категории споров чаще всего нарушают SLA?
• Расходится ли статус транзакции между приложением и поддержкой?
• Обновляется ли база знаний после повторяющихся споров?

Связанные материалы

• Метрики для SJM
• SJM — privacy, compliance и customer harm
• SJM — Россия
• SJM — Европейский союз
• SJM — США
• Тестирование и качество сервисов
• Тест-анализ требований сервиса
• Дефекты сервиса и RCA

Вывод

Платёжный путь выглядит линейным, пока не появляется тайм-аут, дубль или оспариваемая операция. SJM помогает видеть, где неопределённость статуса превращается в клиентский вред, и где backstage-логика расходится с тем, что видит клиент.