Заявка истекла, деньги пришли: жизненный цикл P2P-ордера

Разберём условную оплату на 10 000. Срок инструкции закончился в 10:15. Покупатель отправил перевод в 10:14, банк получателя отразил его в 10:17, а оператор увидел запись в 10:20. Магазин к тому времени отменил заказ. Кто опоздал и можно ли считать оплату несуществующей? Ответ зависит от времён и правил конкретной операции, но деньги уже требуют учёта независимо от цвета заявки.

Жизненный цикл P2P-ордера неудобно описывать одной цепочкой «создан, оплачен, завершён». В нём одновременно меняются доступность реквизитов, состояние банковского перевода, степень доказанности поступления и обязательство перед мерчантом. Исключения возникают именно там, где один из этих процессов ушёл вперёд остальных.

У заявки и поступления разные идентификаторы

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

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

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

Полезны промежуточные состояния

После создания заявка ожидает назначения, затем получает исполнителя и резерв. Реквизиты становятся доступны клиенту. Указание покупателя «оплатил» переводит её в ожидание проверки, но не обязано немедленно создавать подтверждённую выручку. Обнаруженное поступление сначала проверяется, затем получает распределение по заявке. Только после этого наступает предусмотренное договором финансовое признание.

За ним отдельно следуют расчёт с участником и выплата мерчанту. Открытый спор, возврат или корректировка могут возникнуть позднее. Эта схема предлагается как операционная модель; названия статусов у поставщиков отличаются. Важно сохранить смысл переходов и не заставлять один статус одновременно означать получение SMS, получение денег и окончательный расчёт.

Есть и документированные исключения у конкретных API. В описании PayStar указано, что P2P-заявка после обращения может измениться из Failed в Success с прежними идентификаторами. Там же история событий не объявляется гарантированно полной трассировкой. Это свойство описанного интерфейса, которое нужно подтвердить для своего подключения, а не универсальное правило любой P2P-платформы.

Разберём позднее поступление по минутам

Вернёмся к переводу на 10 000. В журнале сохраняются как минимум момент окончания инструкции 10:15, банковское время поступления 10:17 и время обнаружения 10:20. Время отправки 10:14 известно из доказательства покупателя и может требовать проверки. Эти отметки не заменяют друг друга. Если договор учитывает момент зачисления получателю, раннее нажатие покупателем кнопки само по себе не продлевает срок.

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

Мерчант при этом проверяет свой заказ. Товар мог закончиться, бронь исчезнуть, а клиент уже купить замену. Восстановление платёжного факта не даёт права автоматически повторить исполнение. Финансовый статус и решение магазина связываются через явную обработку исключения. Так исправление оплаты не превращается в неожиданную повторную доставку или второй активированный продукт.

Две части одного платежа

Клиент должен внести 10 000, но пришло 6 000. Такая запись не становится полной оплатой из-за того, что в назначении есть номер заказа. Оператор фиксирует полученные 6 000 и недостающие 4 000. Дальнейшее действие зависит от условий: разрешённое ожидание доплаты, изменение заказа с согласия сторон или возврат. Частичную оплату нельзя молча объявить допустимой, если правила используемого метода её запрещают.

Позже появляется перевод на 4 000. Если модель разрешает несколько переводов и проверки обоих источников пройдены, две отдельные записи можно распределить на одну заявку. Их сумма даёт 10 000, но доказательства и банковские референсы остаются раздельными. Если второй перевод пришёл от иного лица или на другие реквизиты, совпадения общей суммы недостаточно для автоматического завершения.

Особенно опасно дописывать недостающую часть вручную как «компенсацию системы», когда денег нет. Это меняет экономику операции и требует явного решения: кто финансирует разницу и почему. Иначе поддержка улучшит конверсию на экране, создав необъяснимый долг в расчётах.

Дубль сообщения и второй перевод выглядят похоже

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

Два реальных перевода по 10 000 представляют другую ситуацию. Совпадение суммы и имени не позволяет удалить второй как технический дубль. Нужно проверить банковские идентификаторы и фактические записи. Если это отдельные зачисления, одно оплачивает заказ, а второе становится избыточным поступлением с самостоятельным обязательством по урегулированию. Здесь дедупликация «по сумме за пять минут» приводит к потере клиентских денег в учёте.

Что считать достаточным доказательством

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

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

Закрытая заявка должна оставлять воспроизводимую историю: что ожидалось, что действительно поступило, какие доказательства проверены, как распределена сумма и какое обязательство возникло. Тогда поздний перевод становится управляемым исключением. Без этой истории он превращается в спор между тремя скриншотами и двумя уверенными голосами в чате.