Сверка, отчётность и аналитика платежей

Сверка, отчётность и аналитика платежей (Reconciliation)

Что такое сверка платежей и зачем она нужна

Сверка платежей (reconciliation) — это сопоставление ваших заказов и транзакций с данными платёжных провайдеров и банковских расчётов. Цель — подтвердить, что каждый платёж учтён, суммы совпадают, комиссии корректны, а возвраты и сторно отражены верно. Без системной сверки легко терять деньги из‑за задержек статусов, дублирования запросов, частичных захватов или ошибок при отменах.

Ключевые задачи, которые решает сверка платежей API:

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

Если вы используете несколько банков и агрегаторов, потребность в едином reconciliation увеличивается кратно. Подробнее о стратегиях выбора стека — в обзоре Банки vs агрегаторы.

Как работает reconciliation в API Платежи Онлайн

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

Основа процесса:

1. Инициация. Вы создаёте платёж (order + payment) через единый протокол. См. Базовая интеграция.

2. События. Провайдеры отправляют нам события: авторизация, 3‑D Secure, списание, отмена, возврат. Мы приводим их к общей схеме.

3. Обновления статусов. Ваше приложение получает изменения через вебхуки и/или периодическую сверку по API.

4. Ежедневная отчётность. Ночная (или инкрементальная) сверка закрывает «хвосты»: поздние списания, частичные возвраты, пересчёт комиссий.

5. Финальный расчёт. Отражаем итоги по выплатам и комиссиям в отчётах для бухучёта и DWH.

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

Унификация статусов: карта соответствий провайдеров

Таблица ниже иллюстрирует, как мы сопоставляем статусы разных эквайеров. На стороне API вы работаете с нормализованными значениями, что критично для сверки и отчётности.

Нормализованный статус	Сбербанк	YooMoney	T‑Bank	Belarusbank	Описание
pending	CREATED	pending	NEW	pending	Платёж создан, ожидает следующего шага
authorized	APPROVED	waiting_for_capture	AUTHORIZED	authorized	Сумма заблокирована на карте (hold)
captured	DEPOSITED	succeeded	CONFIRMED	captured	Списание завершено, деньги на пути к зачислению
failed	DECLINED	canceled	CANCELED	failed	Отказ, списания нет
canceled	CANCELED	canceled	CANCELED	canceled	Отменено до списания
refunded_partial	REFUNDED (partial)	refunded (partial)	PARTIAL_REFUND	refunded_partial	Частичный возврат
refunded_full	REFUNDED (full)	refunded (full)	REFUNDED	refunded_full	Полный возврат
reversed	REVERSED	—	REVERSED	reversed	Сторнирование/разворот операции
chargeback	CHARGEBACK	dispute_opened	CHARGEBACK	chargeback	Чарджбэк (претензия банка)

Примечание: конкретные коды могут отличаться в зависимости от версии API конкретного провайдера. Подробности см. карточки интеграций: Сбербанк эквайринг, YooMoney, T‑Bank, Belarusbank.

Поток данных: вебхуки, polling и отчётные выгрузки

Мы поддерживаем несколько способов доставки обновлений для стабильной сверки:

• Вебхуки (рекомендуется). События: payment.created, payment.authorized, payment.captured, payment.failed, refund.succeeded, payout.settled, chargeback.opened. Для защиты от дублей используйте идемпотентность — см. паттерн Webhooks и idempotency.

• Polling по окну времени. Инкрементальные выборки по updated_at с «водяным знаком» (watermark) для бэкапов и перезапусков.

• Ежедневные отчёты (выгрузки платежей). Автоматически формируем пакетные выгрузки за сутки/неделю/месяц и доставляем в S3/SFTP или отдаём по API.

Рекомендации по расписанию:

• инкрементальная сверка раз в 5–15 минут (операционные дэшборды);
• закрытие дня в 02:00 локального времени мерчанта (финансовая отчётность);
• недельные сводки по чарджбэкам и комиссиям для контроллинга.

Отчётность эквайринг для финансов и бухгалтерии

Система формирует набор стандартных отчётов, чтобы упростить закрытие периода и внутренний аудит:

• Реестр оплат: все операции с нормализованными статусами и идентификаторами (payment_id, order_id, rrn, provider_reference).
• Комиссии эквайринга: расчёт fee_amount/fee_rate на транзакцию и в агрегате. Сопоставление с актами провайдера.
• Реестр возвратов и сторно: full/partial, дата инициирования и фактического списания.
• Отчёт по выплатам/зачислениям: ожидаемые и фактические поступления, лаги, валюта.
• Движение по чарджбэкам: новые, выигранные/проигранные кейсы, net‑влияние на выручку.

Формула для финансового учёта (упрощённо):

Gross Payments − Refunds − Chargebacks − Fees = Net Settlements.

Особенности отражения операций:

• Разделяйте authorization и capture: списание может быть частичным или отложенным.
• Сторно и возвраты обрабатывайте через унифицированный поток — см. Возвраты и развороты.
• Учитывайте 3‑D Secure flow и доп. проверки, влияющие на конверсию и риск — см. PCI DSS и 3‑DS.

Выгрузки платежей и интеграции с DWH

API Платежи Онлайн поддерживает настраиваемые выгрузки платежей в нужных форматах и каналах доставки.

Формат	Доставка	Типичные сценарии
CSV, XLSX	UI, SFTP, S3	Финансовая отчётность, обмен с бухучётом
JSON Lines	API, S3	Инкрементальные загрузки в DWH/ETL
Parquet	S3	Аналитика больших объёмов в ClickHouse/BigQuery
Google Sheets	API	Операционный мониторинг для нефинансовых команд

Рекомендуемые поля для аналитики и сверки:

• Идентификаторы: payment_id, order_id, merchant_id, provider, provider_reference, rrn.
• Финансы: amount, currency, fee_amount, fee_rate, settlement_amount, exchange_rate.
• Состояния: status_normalized, created_at, authorized_at, captured_at, settled_at, refunded_at.
• Канал и риск: method, channel (web/app), device, country, ip, 3ds_result, decline_code.
• Клиент и товар: customer_id, subscription_id, product_category, meta.

Если вы строите мобильную воронку оплаты, обратите внимание на SDK для мобильных приложений.

Метрики конверсии и дашборды оплаты

Чтобы управлять выручкой, важны корректные метрики конверсии и прозрачные дашборды оплаты. Мы считаем и визуализируем:

• Initiation rate: начатые платежи / попытки перехода к оплате.
• Authorization rate: успешные авторизации / попытки, отдельно по 3‑DS.
• Capture rate: списания / авторизации.
• Paid conversion (оплачено): списания / начатые платежи.
• 3‑DS challenge rate и pass rate: частота и успешность прохождения 3‑D Secure — см. PCI/3‑DS.
• Decline breakdown: причины отказов по кодам и провайдерам, рекомендации по ретраям.
• A/B по провайдерам и методам: роутинг по одобряемости и комиссиям.

Пример воронки: initiated → 3DS (optional) → authorized → captured → settled → refunded. Для мобильных и подписочных сценариев дополнительно учитываются ретраи и автообновление карт.

Возвраты, рекуррентные платежи и фрод-аналитика

• Рекуррентные платежи. Анализируем первую оплату vs последующие, показатель dunning success (возврат задолженности), churn по картам. Подробности реализации — в разделе Рекуррентные подписки.

• Возвраты и сторно. Считаем N‑day refund rate, долю частичных возвратов, эффект на Net Settlements. Настройки потоков — в Refunds & Reversals.

• Фрод и чарджбэки. Отслеживаем chargeback ratio, win rate по представлениям (representments), скоринговые триггеры. Алерты и расследования — см. Ошибки и мониторинг.

Примеры сценариев сверки по популярным провайдерам

• YooMoney. Частая схема: waiting_for_capture → succeeded или canceled. При частичном захвате отражаем captured_amount < authorized_amount. Интеграция: YooMoney API.

• Сбербанк эквайринг. Типично двухфазное списание: APPROVED (hold) → DEPOSITED (capture). Возвраты могут приезжать позже отчёта дня — включайте ночную досверку. Интеграция: Сбербанк Acquiring API.

• T‑Bank. Поддерживает динамический 3‑DS и детальные decline codes. Совмещайте авторизационную конверсию и риск‑метрики для оптимального роутинга. Интеграция: T‑Bank API.

• Belarusbank. Простая линейка статусов, возможны задержки по settlement. Рекомендуем включать polling на уровне часа. Интеграция: Belarusbank API.

Быстрый старт: 5 шагов к надёжной сверке

1. Подключите базовую интеграцию и создайте тестовые платежи — см. Основы интеграции и Песочницу.

2. Включите вебхуки и идемпотентность, настройте ретраи доставки — см. Webhooks & Idempotency.

3. Настройте выгрузки платежей по расписанию: ежедневные CSV для бухгалтерии и JSONL для DWH.

4. Соберите дашборды оплаты: конверсия, 3‑DS, отказные коды, комиссии, возвраты.

5. Добавьте мониторинг ошибок и деградаций — см. Ошибки и мониторинг.

Мониторинг и SLA: на что алертить

• Падение authorization/approval rate у конкретного провайдера или BIN‑группы.
• Всплеск 3‑DS challenge rate или growth отказов по коду «Do not honor».
• Задержки вебхуков >5 минут или рост доли повторных доставок.
• Несоответствие сумм в отчётах по комиссиям vs акты провайдера.
• Ошибки nightly‑выгрузок и лаг в settlement‑данных.

Типовые цели SLA для сверки: 99.9% доставка вебхуков, <15 минут RTO инкрементальной сверки, закрытие дня до 06:00 локального времени.

Итоги и следующий шаг

Сверка платежей API — это не только контроль сумм и статусов, но и фундамент для прозрачной отчётности эквайринг, эффективного роутинга и роста конверсии. Единые статусы, гибкие выгрузки платежей и понятные дашборды оплаты позволяют принять верные решения быстро и подтверждать их цифрами.

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