Ключевые темы
Связанные публичные страницы
Если нужен не только разбор, а страница продукта, API или операционного сценария, начните с этих разделов VPOS.am.
QR-страница должна быть платежной сущностью
Чаевые, донаты и invoice targets отличаются бизнес-смыслом, но все должны ссылаться на контролируемый payment flow.
QR-код для чаевых или доната часто воспринимают как простую картинку. В production-сценарии это публичная платежная точка: у нее есть target type, получатель, доступные суммы, валюта, публичная страница, payment session и правила отображения результата.
Важно заранее различить employee, team, company, donation, invoice и custom targets. Тогда одна и та же платежная инфраструктура может обслуживать разные сценарии, а операторы видят, почему платеж создан и куда он должен попасть в отчетности.
- не делать QR-код единственным источником данных;
- хранить target type, recipient id и branch id;
- создавать payment session только после server-side validation;
- показывать клиенту понятные pending, success и failed states.
Статусы должны разделять оплату, отзыв и выплату
Successful payment, feedback, payout request и payout completed - разные события, их нельзя смешивать в один статус.
После QR-оплаты может появиться отзыв, оценка, запись в отчет, payout request и уведомление через webhook. Эти события связаны, но имеют разные жизненные циклы. Оплата может быть verified, а payout еще requested или processing.
Для безопасности не стоит обещать автоматический split settlement, если он не подтвержден банковским или provider-контрактом. На раннем этапе payout records лучше считать операционными записями для отчетности, сверки и ручного закрытия периода.
- payment status не равен payout status;
- feedback не должен менять финансовый статус;
- payout request должен иметь период, сумму и ответственного;
- manual payout completion нужно логировать с reference.
Как закрывать смену и месяц без таблиц
Оператору нужен короткий список verified payments, payout batches и исключений, а не ручной поиск по банковским выпискам.
Для ресторана, отеля, сервиса или благотворительной организации важна не только сама оплата. Нужно понимать, какие QR-платежи прошли за смену, к какому получателю они относятся, какие суммы включены в payout request и какие операции требуют ручной проверки.
Практичный процесс закрывает exact matches автоматически: verified payments группируются по периоду, target, branch и currency. Исключения - mismatch суммы, отмена, возврат, отсутствующий payout reference или ручная корректировка без комментария.
- группировать payments по period, target и currency;
- сверять gross, fee и net amounts отдельно;
- создавать payout batches только по verified payments;
- отправлять webhook о payout status без раскрытия секретов.
FAQ
Можно ли сразу обещать автоматические выплаты по QR-чаевым?
Нет, если split settlement или card payout не подтвержден банком или provider-контрактом. На старте payout лучше вести как операционную запись для отчетности и ручного закрытия.
Чем QR-чаевые отличаются от обычной payment link?
QR-чаевые обычно связаны с получателем, сменой, отзывом и payout отчетом. Payment link чаще связан со счетом, заказом или конкретной суммой.
Нужно ли делать webhook по payout status?
Да, если внешняя CRM/ERP или отчетная система должна знать, что payout requested, processing, completed или cancelled. Webhook должен быть подписан и идемпотентен.
