Оформлено, оплачено и исполнено означают разные события
Представим мастерскую, которая продаёт печатные открытки через сайт. Заполненная форма создаёт заказ, платёжный сервис подтверждает расчёт, сотрудник собирает конверт, затем фиксируется передача в доставку. У каждого этапа своё подтверждение. Запись о поступлении денег ещё не говорит, что конверт собран или отправлен. Некоторые способы оплаты подтверждаются с задержкой. Поэтому переход покупателя на страницу завершения оформления нельзя без проверки считать окончательным подтверждением платежа. Кроме того, покупатель может заплатить и потерять соединение до открытия такой страницы. Правила обработки должны опираться на подтверждённые события платёжной системы и состояние заказа, а не только на действия браузера. Конкретную техническую реализацию проверяют по документации используемого сервиса.
Повторное сообщение не создаёт второе обязательство
Сервисы могут повторно доставлять уведомления, например при сетевых затруднениях. Если каждое сообщение запускает новую отправку, один оплаченный заказ рискует превратиться в два конверта. Поэтому обработчик должен узнавать уже обработанное событие, а процесс исполнения должен учитывать, что сделано по самому заказу. Совместную проверку этих условий стоит поручить разработчику интеграции. В учебной мастерской заказу присваивается внутренний номер. По нему можно сопоставить состояние оплаты и исполнения. Номер заказа, идентификатор платежа и идентификатор уведомления имеют разные роли; подменять один другим без разбора нельзя. Человеку, разбирающему проблему, полезна короткая история событий: когда создан заказ, чем подтверждена оплата, кто начал сборку и чем подтверждена отправка. Наличие такой истории сокращает гадание между участниками процесса.
У зависшего заказа должен быть следующий хозяин
Даже правильная автоматизация нуждается в процедуре разбора исключений. Определите, кто замечает оплаченные, но не исполненные заказы, где они отображаются и какое действие следует после обнаружения. Отдельно предусмотрите ситуации, когда товар закончился, адрес требует уточнения или платёж ещё не подтверждён. Не обозначайте все эти случаи одним словом ошибка. Допустим, утром у мастерской три записи: номер 17 оплачен и ждёт сборки, номер 18 ожидает подтверждения оплаты, номер 19 уже передан в доставку. Повторное уведомление о номере 19 не означает необходимость снова собирать конверт. Для номера 17 нужен ответственный за исполнение, а для номера 18 проверка статуса. В сообщениях покупателю отражайте подтверждённое состояние. Обещание скорой отправки не должно автоматически появляться раньше, чем понятны возможность и срок исполнения.
Попробуйте на практике
Проверьте цепочку вымышленной мастерской на бумаге, без проведения платежей и изменения работающей системы.
- Нарисуйте четыре этапа: оформление, подтверждение оплаты, сборка и передача в доставку. Напротив каждого укажите, какое событие подтверждает переход.
- Внесите заказы 17, 18 и 19 из примера. Для каждого запишите текущее состояние и ответственного за следующий шаг.
- Добавьте повторное уведомление об оплате номера 19. Объясните, какие записи нужно сопоставить, чтобы не запустить повторное исполнение.
- Добавьте ситуацию: номер 17 оплачен, но уведомление не обработано. Опишите, какая сверка обнаружит расхождение и кто займётся его разбором.
Как проверить результат. Проверка пройдена, если повторное уведомление не создаёт новую отправку, ожидающий платёж не объявлен подтверждённым, а оплаченный незавершённый заказ имеет понятный следующий шаг.
Частые вопросы
Достаточно ли смотреть только на сумму поступлений?
Нет. Сумма не показывает, по каким заказам исполнение завершено. Для проверки нужны связанные записи о конкретных обязательствах.
Можно ли поручить всю цепочку одному человеку?
В маленькой мастерской это возможно. Всё равно полезно разделять этапы и фиксировать переходы, чтобы после перерыва восстанавливать состояние по записям, а не по памяти.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.