Ключевые темы
Связанные публичные страницы
Если нужен не только разбор, а страница продукта, API или операционного сценария, начните с этих разделов VPOS.am.
Booking payment должен знать даты и условия
Сумма без booking id, дат проживания и policy version не помогает решить отмену, перенос или no-show.
В отеле, гостевом доме или апарт-отеле платеж редко является просто оплатой товара. Он относится к конкретным датам, номеру, тарифу, гостю, правилам отмены и источнику бронирования. Если payment link живет отдельно, команда вручную сопоставляет суммы с перепиской и календарем.
Надежная модель создает payment request из booking engine или CRM: booking id, stay dates, room/rate id, amount, currency, expiration, cancellation policy version and source channel фиксируются до оплаты. Статус бронирования меняется только после server-side verification.
- связывать payment request с booking id;
- фиксировать stay dates, tariff и source channel;
- не подтверждать booking по скриншоту оплаты;
- разделять pending, confirmed, cancelled, no_show и manual review.
Deposit, hold и no-show требуют явных правил
Предоплата, депозит и preauthorization могут выглядеть похоже для гостя, но в backend это разные сценарии.
Hospitality-команды часто хотят депозит, частичную оплату, удержание суммы или no-show fee. Но preauthorization, capture и void зависят от банка, провайдера и договора. Если поддержка hold не подтверждена, безопаснее использовать deposit payment или payment link с понятными refund rules.
Правила должны быть техническими: cancellation window, refundable amount, no-show condition, policy version and manual exception. Тогда оператор не принимает решение из памяти, а видит, что можно вернуть, что требует review и какие события уже были отправлены в CRM/ERP.
- не обещать card hold без подтверждения провайдера;
- хранить cancellation window и policy version;
- refund/no-show fee оформлять отдельным событием;
- manual exception должен иметь actor, reason и timestamp.
Сверка должна соединять booking, payment и channel reports
Календарь, channel manager, CRM и платежный отчет должны сходиться до закрытия дня или месяца.
В hospitality деньги приходят из разных сценариев: сайт, менеджерская ссылка, channel manager, прямой клиент, депозит, остаток суммы, отмена или возврат. Если эти события живут отдельно, отчет за период превращается в ручную сверку календаря, банковской выписки и CRM.
Сверка должна сравнивать booking calendar, payment records, provider report, refunds, channel source and ERP export. Платежный слой хранит ids и статусы, а чувствительные данные гостя остаются в booking/CRM-системе с ограниченными правами.
- сверять confirmed bookings и verified payments;
- показывать refunds, no-show и manual changes отдельно;
- не хранить лишние guest data в payment log;
- экспортировать provider reference в ERP/accounting.
FAQ
Можно ли подтвердить бронирование после return URL?
Лучше подтверждать после webhook или server-side status lookup. Return URL может открыться до финального платежного события.
Чем deposit отличается от hold?
Deposit обычно является фактической оплатой с возможным возвратом. Hold резервирует сумму до capture/release и зависит от поддержки банка или провайдера.
Как учитывать no-show?
Через заранее описанные правила: cancellation window, no-show condition, refundable amount, policy version и audit trail.
