Интернет‑платежи чувствительны к задержкам и сбоям: минуты простоя и процентный пункт просадки авторизаций напрямую бьют по выручке. Поэтому SLA эквайринг — это не формальность, а способ управлять рисками: фиксируем время реакции поддержки, целевые метрики доступности и чёткие сценарии эскалации инцидентов. На этой странице — как устроена наша техподдержка платежей, какие процессы и метрики мы используем, и чего ждать в случае инцидента.
![Схема процесса эскалации — placeholder]
Если вы только изучаете тему, начните с раздела об основах интернет‑эквайринга и сравнения поставщиков (сравнение провайдеров).
Наша служба поддержки платежей работает 24×7 для критических инцидентов и в расширенном режиме для запросов низкого приоритета.
Каналы обращения:
Мы разделяем поддержку мерчанта (B2B) и консультации плательщиков: в интернете это снижает среднее время реакции поддержки и повышает FCR (решение с первого обращения). По вопросам интеграции используйте разделы API и документация и Интеграция с CMS.
Ниже — типовые целевые значения (могут отличаться для тарифа/регионов и закрепляются в договоре SLA по эквайрингу).
| Метрика | Описание | Целевое значение |
|---|---|---|
| Доступность платёжного шлюза (Uptime) | Время доступности критичных сервисов авторизации | 99.95% в месяц |
| MTTA (время до первичной реакции) | От открытия тикета до подтверждения принятия в работу | P1: ≤5 мин; P2: ≤15 мин; P3: ≤60 мин; P4: ≤1 раб. день |
| MTTR (время восстановления) | До возврата работоспособности или устойчивого workaround | P1: ≤60 мин до обходного решения, ≤4 ч до нормализации; P2: ≤4 ч; P3: ≤2 раб. дня |
| FCR | Доля запросов, решённых с первого контакта | ≥75% |
| Латентность API | P95 времени авторизации/клиринга | Авторизация ≤1.5 с; Webhook ≤60 с |
| Ошибки по вине платформы | 5xx и системные таймауты | ≤0.1% транзакций |
Дополнительно в SLA можем фиксировать: график плановых работ, окно информирования, RTO/RPO в рамках BCP (план непрерывности bcp).
Чёткая классификация ускоряет реакцию и корректно запускает эскалацию инцидентов.
| Приоритет | Критерии | Примеры | MTTA/MTTR (цель) |
|---|---|---|---|
| P1 — критический | Простой оплаты для всех/большинства мерчанта, безопасность, утечка | Массовые 5xx, недоступен checkout, компрометация ключей | 5 мин / 60 мин (workaround) |
| P2 — высокий | Серьёзное ухудшение качества сервиса | Резкий рост decline по банку/методу, задержка вебхуков | 15 мин / 4 ч |
| P3 — средний | Частичный функционал/единичные мерчанты | Ошибки при возвратах, рекуррентные отказы | 60 мин / 2 раб. дня |
| P4 — низкий | Консультации, улучшения, документирование | Запросы по аналитике, настройки витрины | 1 раб. день / по плану |
Под «workaround» понимаем обходной сценарий (включая переключение маршрута), который минимизирует ущерб и восстанавливает приём платежей.
Пример эскалационной матрицы для P1:
| Условие | Действие | Кого подключаем |
|---|---|---|
| 5 минут без ответа/эффекта | Эскалация менеджеру инцидента | Incident Manager (24×7) |
| 15 минут без восстановления | Эскалация на L3/архитекторов | L3, SRE, DevOps |
| 30 минут, высокий бизнес‑эффект | Эскалация внешним партнёрам | Банк‑эквайер/PSP, операторы SBP, дата‑центр |
| Любой риск безопасности | Параллельная ветка SecOps | DPO/CISO, юристы |
![Пример статус-страницы провайдера — placeholder]
Мы поддерживаем публичную status page с историей событий, текущим статусом модулей (авторизация, вебхуки, касса, личный кабинет) и подпиской на уведомления (email/мессенджер). При P1/P2 мы публикуем:
Рекомендуем закрепить у себя внутренний канал ретрансляции обновлений status page, чтобы коммерция, саппорт и IT видели единый источник истины.
Чтобы инциденты не останавливали продажи, мы заранее проектируем обходные маршруты и план непрерывности (BCP):
Для специфичных сценариев — рекуррентные платежи, маркетплейсы и split, международные платежи — предусмотрены отдельные runbook’и и маршруты.
Мы наблюдаем не только «жив ли хост», но и бизнес‑метрики:
Дашборды и автоматические отчёты доступны в разделе Аналитика и отчёты. По вашим запросам настраиваем бизнес‑алёрты (например, «просадка approve rate Visa RU на 3 п.п. за 5 минут»).
Каждый значимый инцидент — обязательный постмортем:
Итоги документируются и попадают в базу знаний, глоссарий и runbook’и (см. Глоссарий).
Чтобы ускорить решения, поддержка плотно работает с вашими разработчиками:
Если вы на старте, посмотрите, как быстро пройти онбординг — Как подключить, а условия обслуживания — в разделе Тарифы и комиссии.
Правильные данные ускоряют диагностику в разы. Пожалуйста, указывайте:
По кейсам возвратов и арбитража — раздел Возвраты и чарджбеки.
Ежемесячно предоставляем отчёты SLA: доступность, MTTA/MTTR, инциденты, выполненные действия по BCP и улучшениям. По договорённости — сервисные кредиты при нарушении SLO, а также сравнение динамики по провайдерам в рамках мульти‑эквайринга.
Инциденты нередко связаны со смежными компонентами:
В сложных интеграциях мы учитываем влияние этих компонентов на общий SLA эквайринга.
Надёжная техподдержка платежей — это процессы, метрики и дисциплина эскалации. Мы фиксируем SLA по эквайрингу, поддерживаем прозрачную status page, держим готовыми обходные маршруты и BCP, чтобы ваши продажи не останавливались.
Готовы обсудить ваш целевой SLA и сценарии устойчивости? Изучите базовые возможности интернет‑эквайринга, сравните варианты в разделе Сравнение провайдеров и оставьте заявку в разделе Как подключить. Дополнительные ответы — в FAQ и Глоссарии.