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.
Payment request should know tour context
Amount without date, route, participant count and manager reference does not help support during transfer or cancellation.
Tours, excursions, transfers and travel services are often sold through manager, form, messenger or CRM. Payment link should not be a standalone link for amount; it should be a payment object with tour date, route/package id, participant count, customer record, amount, currency and expiration.
After verified payment, CRM can mark deposit paid, full paid or manual review. But final status should not come from return URL or screenshot because payment provider may deliver final status later.
- connect payment request with tour booking id;
- fix tour date, package id and participant count;
- store manager reference and source channel;
- separate deposit paid, fully paid, cancelled and manual review.
Group booking and partial payments need a schedule
Group can pay deposit, remaining balance, additional participant amount or partial refund, so one paid status is not enough.
Travel scenarios often include prepayment, remaining balance before tour date, added participants, individual discounts and partial cancellation. If all of this is stored as one order, team cannot see who paid how much and what still needs to be requested.
Schedule should store expected amount, paid amount, due date, payment attempts, reminders and manager tasks. If provider does not support auto-charge, do not promise it: payment links and controlled reminders are usually safer start.
- separate deposit amount and balance due;
- do not create several active links for one payment period;
- added participant should create adjustment event;
- manual discount/refund needs actor and reason.
Cancellation, weather and refund should be events
Tour transfer because of weather, participant cancellation and money refund should not erase original payment history.
Tours depend on date, group, transport, weather and suppliers. Transfer or cancellation should not delete payment: it should create separate events with reason, actor, date and refund path. This matters for support, accounting and disputed operations.
Daily reconciliation compares tour bookings, verified payments, unpaid balances, cancellations, refunds, CRM tasks and provider report. Manager sees which groups are ready, where reminder is needed and which operations require manual review.
- refund should not delete original payment;
- tour transfer needs old date, new date and reason;
- weather cancellation is stored as separate business event;
- reconcile CRM, provider report and accounting export.
FAQ
Can tour deposit be accepted by payment link?
Yes, if link is connected with tour booking id, date, participant count, amount and expiration, and paid status appears after server-side verification.
How to track remaining balance before tour?
Store schedule: expected amount, paid amount, due date, reminders and separate payment attempts for deposit and balance.
What should happen when tour is transferred?
Keep original payment and create transfer event with old date, new date, reason and actor. Payment history should not disappear.
