Key topics
Related public pages
If you need the product, API or operations page rather than only the article, start with these VPOS.am sections.
Booking payment should know dates and terms
Amount without booking id, stay dates and policy version does not help decide cancellation, transfer or no-show.
In a hotel, guesthouse or serviced apartment, payment is rarely just product payment. It belongs to specific dates, room, rate, guest, cancellation rules and booking source. If payment link lives separately, team manually matches amounts with chat history and calendar.
Reliable model creates payment request from booking engine or CRM: booking id, stay dates, room/rate id, amount, currency, expiration, cancellation policy version and source channel are fixed before payment. Booking status changes only after server-side verification.
- connect payment request with booking id;
- fix stay dates, tariff and source channel;
- do not confirm booking from payment screenshot;
- separate pending, confirmed, cancelled, no_show and manual review.
Deposit, hold and no-show need explicit rules
Prepayment, deposit and preauthorization may look similar to guest, but they are different backend scenarios.
Hospitality teams often want deposit, partial payment, amount hold or no-show fee. But preauthorization, capture and void depend on bank, provider and contract. If hold support is not confirmed, safer approach is deposit payment or payment link with clear refund rules.
Rules should be technical: cancellation window, refundable amount, no-show condition, policy version and manual exception. Operator then sees what can be refunded, what needs review and which events were already sent to CRM/ERP.
- do not promise card hold without provider confirmation;
- store cancellation window and policy version;
- treat refund/no-show fee as separate event;
- manual exception needs actor, reason and timestamp.
Reconciliation should connect booking, payment and channel reports
Calendar, channel manager, CRM and payment report should match before day or month close.
In hospitality, money arrives through different scenarios: website, manager link, channel manager, direct customer, deposit, remaining balance, cancellation or refund. If these events live separately, period report becomes manual reconciliation of calendar, bank statement and CRM.
Reconciliation should compare booking calendar, payment records, provider report, refunds, channel source and ERP export. Payment layer stores ids and statuses, while sensitive guest data remains in booking/CRM system with restricted access.
- reconcile confirmed bookings and verified payments;
- show refunds, no-show and manual changes separately;
- do not store unnecessary guest data in payment log;
- export provider reference to ERP/accounting.
FAQ
Can booking be confirmed after return URL?
Prefer confirming after webhook or server-side status lookup. Return URL can open before final payment event.
How is deposit different from hold?
Deposit is usually an actual payment with possible refund. Hold reserves amount until capture/release and depends on bank or provider support.
How should no-show be recorded?
Through predefined rules: cancellation window, no-show condition, refundable amount, policy version and audit trail.
