Короткий ответ
Сверка связывает заказ, платеж, фактическое зачисление и бухгалтерский учет. Надежный процесс строится на устойчивых идентификаторах, конечных статусах, ежедневном реестре и отдельной обработке расхождений.
- Связывайте каждый платеж с внутренним номером заказа и идентификатором провайдера.
- Не считайте созданный или ожидающий платеж завершенной продажей.
- Разделяйте валовую сумму, комиссию, возвраты и сумму к перечислению.
- Фиксируйте владельца и срок разбора каждого расхождения.
1. Какие данные нужно связать
Минимальная цепочка состоит из заказа в учетной системе, платежной попытки у провайдера, подтвержденного результата и строки в реестре перечисления. Для каждой сущности нужны неизменяемые идентификаторы. Это позволяет отличать повторный запрос от нового платежа и восстанавливать историю без сопоставления только по сумме и времени.
В рабочей модели сохраняют идентификатор заказа, идентификатор платежа, сумму и валюту, метод оплаты, время создания и завершения, итоговый статус, размер комиссии, возвраты и ссылку на реестр. Персональные и платежные данные следует хранить только в необходимом объеме и в соответствии с применимыми правилами.
- задайте уникальный order_id на стороне мерчанта;
- сохраняйте provider_payment_id из ответа API;
- используйте единый часовой пояс в отчетах;
- не изменяйте исходные события задним числом.
2. Ежедневный цикл сверки
Сначала учетная система формирует перечень платежей, которые получила через API и webhook. Затем он сопоставляется с реестром провайдера по идентификаторам, сумме и финальному статусу. После этого отдельно проверяются комиссии, возвраты, отмены и перечисления.
Автоматическая сверка должна выделять исключения, а не скрывать их. Типовые группы: платеж есть у провайдера, но отсутствует в заказах; заказ отмечен оплаченным без конечного статуса; сумма не совпадает; возврат проведен не полностью; строка попала в другой расчетный период.
- автоматически сопоставьте точные совпадения;
- вынесите исключения в отдельную очередь;
- назначьте ответственного за финансовые расхождения;
- закрывайте период только после документированного разбора.
3. Статусы, комиссии и возвраты
Операционный отчет и бухгалтерская запись решают разные задачи. В отчете удобно показывать путь платежа и технический результат, а финансовый реестр должен объяснять движение денег: валовую сумму, удержания, возвраты и итог к перечислению. Условия и сроки зависят от договора и банковского контура.
Возврат необходимо связать с исходным платежом. Если возврат частичный, система должна хранить каждую операцию и доступный остаток. Это предотвращает возврат сверх оплаченной суммы и упрощает ответы поддержке.
- не смешивайте продажи и возвраты в одном итоговом показателе;
- храните причину и автора ручной корректировки;
- сверяйте договорные правила с форматом реестра;
- оставляйте проверяемый журнал изменений.
4. Как внедрить процесс
Начните с карты данных: где создается заказ, кто присваивает идентификаторы, какой источник определяет финальный статус и кто подтверждает перечисление. Затем утвердите формат реестра и правила обработки каждого типа исключения.
WHITECAPITAL предоставляет мерчантам статусы, webhooks и операционные данные в рамках согласованной инфраструктуры. Конкретный формат отчетности, доступность методов и расчетный цикл определяются после проверки бизнеса и подтверждаются документами подключения.
- зафиксируйте источник истины для каждого поля;
- протестируйте повторные webhook и пропущенные события;
- проведите пробную сверку до запуска;
- регулярно проверяйте долю ручных исключений.
Вопросы и ответы
Можно ли сверять платежи только по сумме?
Нет. Одинаковые суммы и близкое время встречаются часто. Основой должны быть уникальные идентификаторы заказа и платежа.
Какой статус считать оплатой?
Только финальный успешный статус, определенный документацией и договорным контуром. Статус создания или ожидания не подтверждает получение денег.
Как часто проводить сверку?
Частота зависит от объема и процесса, но ежедневная автоматизированная сверка с очередью исключений обычно дает управляемый результат.
Источники и правила
Используем официальные материалы платежной системы и политики WHITECAPITAL. Для конкретного подключения приоритет имеют договорные документы.
- WHITECAPITAL — условия использования API
- WHITECAPITAL — условия для мерчантов
- WHITECAPITAL — правила возвратов и диспутов
Материал предназначен для операционной ориентации и не является обещанием подключения, универсальной доступности метода, фиксированной комиссии или срока расчетов.