Ключевые темы
Связанные публичные страницы
Если нужен не только разбор, а страница продукта, API или операционного сценария, начните с этих разделов VPOS.am.
Payout request должен быть привязан к периоду
Выплата без периода, получателя и валюты быстро превращается в ручную заметку, которую невозможно сверить.
Smart QR платежи могут приходить каждый день, но выплаты обычно закрываются по смене, неделе или месяцу. Поэтому payout request должен явно хранить periodStart, periodEnd, recipient, branch, currency, gross amount, fee amount и net amount.
Если оператор создает выплату без этих полей, позже невозможно надежно понять, какие verified payments в нее вошли. Это особенно болезненно для ресторанов, отелей, салонов, благотворительных проектов и команд с несколькими получателями.
- фиксировать periodStart и periodEnd;
- разделять employee, team, company и donation scopes;
- считать gross, fee и net отдельно;
- запрещать второй active payout на тот же scope и период.
Payout status должен иметь ограниченные переходы
Requested, processing, completed и cancelled должны быть конечным автоматом, а не свободным текстом.
У payout request должен быть ограниченный набор статусов и понятные переходы. Например, completed не должен снова становиться requested без отдельной корректировки, а cancelled не должен silently скрывать verified payments из отчетности.
Каждый переход статуса должен иметь actor, timestamp, method, reference и комментарий, если операция выполнена вручную. Это защищает от ситуации, когда выплата вроде бы закрыта, но бухгалтерия не видит банковский reference.
- не разрешать произвольные payout statuses;
- требовать method/reference при completed;
- логировать actor и request id;
- отправлять idempotent webhook о переходе статуса.
Какие исключения выводить оператору
Оператор должен видеть только случаи, требующие решения, а не весь поток успешных QR-платежей.
Платформа должна автоматически закрывать простые совпадения и выводить оператору короткий список исключений. Например: нет verified payments за период, уже есть active payout на этот scope, сумма изменилась после возврата, отсутствует payout reference или webhook delivery не прошел.
Такой подход масштабируется лучше, чем ручные таблицы. Команда видит, какие периоды закрыты, какие выплаты в processing и какие записи требуют ручного review перед бухгалтерским закрытием.
- no verified payments for payout period;
- duplicate active payout scope;
- refund changed net amount after request;
- completed payout without reference;
- webhook delivery failed after retries.
FAQ
Можно ли считать payout completed без банковского reference?
Технически можно, но лучше требовать method и reference для ручного completed. Иначе сверка с выпиской и бухгалтерией становится слабой.
Что делать, если после payout request появился refund?
Нужно создать exception или пересчитать payout до completed. Refund не должен silently менять уже закрытый период без audit trail.
Нужны ли webhooks для payout statuses?
Да, если внешняя система должна получать requested, processing, completed или cancelled. Повторная доставка webhook не должна создавать дубли.
