Ключевые темы
Связанные публичные страницы
Если нужен не только разбор, а страница продукта, API или операционного сценария, начните с этих разделов VPOS.am.
Платеж должен быть связан со столом и POS-чеком
Если оплата приходит как сумма без table id, order id и check id, кассир и менеджер разбирают платеж вручную.
В ресторане, кафе, фудкорте или баре payment flow часто начинается со стола, QR-меню, официанта, кассы, delivery order или pre-order формы. Если платеж не связан с table id, POS check id, order lines and channel, команда потом не понимает, какой чек закрывать.
Практичная схема создает payment request из POS или backend: table/order id, check id, amount, currency, channel, expiration and service context фиксируются до оплаты. POS получает paid status только после trusted webhook или server-side status lookup.
- хранить table id, order id и POS check id;
- разделять dine-in, takeaway и delivery channel;
- не закрывать чек по return URL или скриншоту;
- синхронизировать кассу, кухню и CRM/POS после verified payment.
Split bill, tips и service fee должны быть отдельными строками
Разделение счета, чаевые и сервисный сбор имеют разные правила, получателей и отчетность.
Split bill может создать несколько payment attempts для одного POS-чека. Чаевые могут относиться к официанту, смене, команде или заведению. Service fee может зависеть от правил заведения. Если все это смешать в одну сумму, возникают ошибки в выплатах, возвратах и отчетах.
Backend должен хранить line type, recipient, shift, consent/status fields and refund path. Нельзя автоматически добавлять чаевые или сбор без понятного правила и подтверждения в интерфейсе. Возврат части заказа не должен удалять исходный платеж и историю чаевых.
- split bill связывать с одним POS check id;
- tips хранить отдельно от food/order amount;
- service fee должен иметь правило и видимость для гостя;
- partial refund не должен ломать payout report.
Ежедневная сверка должна видеть кассу, доставку и provider report
Ресторану нужно закрывать день по POS, delivery orders, verified payments, refunds, tips и provider references.
Для ресторана важна не только сумма по провайдеру. Нужно видеть, какие чеки закрыты в POS, какие delivery orders оплачены, где был partial refund, где чаевые ушли в payout report, а какие платежи ждут manual review.
Сверка сравнивает POS checks, shifts, delivery channels, verified payments, refunds, tips ledger, provider report and accounting export. Так управляющий видит реальные расхождения, а не ищет платежи в переписке и банковском кабинете.
- сверять POS checks и provider references;
- видеть void, refund, partial refund и duplicate attempts;
- закрывать смену после сверки tips и orders;
- не хранить лишние персональные данные гостя в payment log.
FAQ
Можно ли закрывать ресторанный чек сразу после return URL?
Лучше закрывать чек после server-side verification или trusted webhook. Return URL может открыться до финального статуса платежа.
Как учитывать чаевые при онлайн-оплате?
Чаевые лучше хранить отдельной строкой с recipient или shift reference, payment id, refund path и payout status.
Что делать, если гости делят счет?
Создавать несколько payment attempts, связанных с одним POS check id, и закрывать чек только когда правила split bill выполнены.
