Новости и разборы
Сверка платежей: как связать попытку оплаты, отмену и учётную запись
Как сопоставлять Payment Intent, Payment Record и попытки оплаты: изменения Stripe, смысл отмены и рабочая очередь финансовых расхождений.
В учётной системе заказ отмечен как оплаченный, у провайдера видна неудачная попытка, а сотрудник поддержки сообщает об отмене. Все три записи могут относиться к одному заказу и при этом описывать разные события. Сверка платежей начинается с разделения этих сущностей: намерения оплатить, отдельной попытки, зарегистрированного результата и фактического денежного движения.
В Stripe API 2026-09-30.endive появились изменения Payment Records, которые помогают передавать связи и состояния точнее. Они дают интеграции дополнительные данные, но не заменяют правила финансового учёта. Полезный результат обновления — возможность объяснить расхождение и найти связанные записи, а не предположение, что сверка стала автоматической.
Связь Payment Intent и Payment Record
В changelog Stripe о payment_record описано новое expandable-свойство у Payment Intent. Оно содержит идентификатор связанного Payment Record. Stripe отмечает, что интеграция, использующая Payment Records, может получить связанную запись непосредственно через объект Payment Intent без отдельного поиска соответствия.
Это условная возможность для интеграций с Payment Records. Из анонса нельзя заключить, что любой заказ магазина уже имеет полную учётную запись или что связь автоматически проверяет сумму. Для приложения важны собственные идентификаторы заказа, связи с провайдером и правила обработки отсутствующих данных.
Начните с карты соответствий: внутренний заказ, Payment Intent, Payment Record и отдельные попытки, если они участвуют в процессе. Храните идентификаторы сущностей, а не пытайтесь сопоставлять записи только по email, похожей сумме или близкому времени. Совпадение этих признаков может быть поводом для проверки, но недостаточным основанием для автоматического объединения.
Отмена становится отдельным сообщаемым результатом
В публикации Stripe о reporting canceled payments значение canceled добавляется в outcome при сообщении о платеже или попытке. Ранее перечислены guaranteed и failed. При outcome: canceled требуется параметр canceled с временной отметкой canceled_at.
Stripe описывает создание Payment Record для отменённого платежа одним вызовом, а для существующей записи — сообщение об отменённой попытке без прежнего разделения на два сообщения. Это изменение способа регистрации результата. Оно не означает, что отправка такого сообщения сама выполняет отмену платёжной операции или возврат денег.
Поэтому внутренний статус «отменено» должен иметь точное определение. Отменённый заказ, отменённая попытка оплаты и выполненный возврат — разные состояния. Если приложение хранит их в одном поле, новая возможность API может просто добавить ещё одно значение к уже неоднозначной модели.
Новое значение wallet.type требует проверки потребителей
Третье изменение касается Link wallet details в Payment Records и Payment Attempt Records. Stripe добавляет тип link и объект с опциональным nullable-полем funding_source_group для карточных платежей через Link. Источник описывает этот идентификатор как непрозрачный и неизменяемый, определяемый при подтверждении.
Интеграция с исчерпывающим списком wallet.type должна предусмотреть новое значение. Отсутствие funding_source_group нельзя автоматически считать ошибкой оплаты: поле допускает null. Сам идентификатор не стоит интерпретировать как имя банка, клиента или отдельный бухгалтерский счёт — анонс такого смысла не даёт.
Эта деталь важна для сверки потому, что парсер не должен терять запись при появлении нового способа представления кошелька. Но совпадающий funding source group не заменяет идентификатор платежа и не доказывает принадлежность двух операций одному заказу.
Что сравнивать в рабочей сверке
Представим подписку, для которой клиент совершил две попытки оплаты: первая завершилась неудачей, вторая дала подтверждённый результат. Это иллюстративный сценарий. Система должна видеть обе попытки и отдельно знать, на каком основании она считает обязательство исполненным.
Для каждой сверяемой операции полезно иметь идентификаторы, сумму, валюту, время события, время получения и понятное состояние. Суммы сравниваются в согласованных единицах; время приводится к единому правилу; неизвестный результат остаётся неизвестным до получения достаточных данных. Выбор источника окончательного денежного состояния нужно согласовать с ответственным за учёт.
Важна и граница сравнения. Операционный результат оплаты, перечисление провайдером, комиссия и запись бухгалтерии могут отражаться в разное время. Новые поля Payment Records сами по себе не делают эти величины равными. Проверяйте только сопоставимые сущности и явно объясняйте, какие расхождения ожидаемы по срокам.
Превратить расхождение в рабочую задачу
Отчёт «не совпало» недостаточен. Разделите причины: отсутствует связь, неизвестное состояние, различается сумма, событие пришло поздно, требуется проверка финансовой операции. Каждому типу нужен ответственный и безопасное следующее действие.
При отсутствии записи не отмечайте заказ оплаченным только для закрытия отчёта. При сообщении об отмене сначала проверьте, что отменено и есть ли отдельное денежное движение. Для повторной проверки сохраните исходные идентификаторы и сведения о предыдущем решении. Так история становится объяснимой для поддержки и финансовой команды.
Этот процесс может стать частью внутренней бизнес-системы, где видны ответственный и следующая задача. Передача данных через API-интеграции требует собственных контрактов состояния. Архитектурное описание собственного API показывает контекст моделей и общих ресурсов, но не подтверждает использование Payment Records в том проекте.
Проверить смысл перед выпуском
При обновлении версии проверьте наличие новой связи, отменённый результат с временной отметкой, значение link и nullable-поле. Затем пройдите деловые сценарии: две попытки одного заказа, отсутствующая учётная запись, задержанное сообщение и отмена без возврата. Цель — убедиться, что система не выдаёт техническое событие за финансовое подтверждение.
Для подписочного продукта отдельно полезен процесс отмены подписки: прекращение будущих списаний и итог уже совершённой оплаты требуют разных правил. В магазине эту же границу следует сохранить при изменении заказа и возврате.
Начните с небольшой очереди расхождений, которую команда действительно может разобрать. Измеряйте возраст нерешённых случаев, полноту связей и причины ручных исправлений. Это даёт основу для следующего этапа автоматизации, не скрывая неопределённость за единым зелёным статусом.