Ключевые темы
Связанные публичные страницы
Если нужен не только разбор, а страница продукта, API или операционного сценария, начните с этих разделов VPOS.am.
Payment request должен знать tour context
Сумма без даты, маршрута, количества участников и manager reference не помогает поддержке при переносе или отмене.
Туры, экскурсии, трансферы и travel-услуги часто продаются через менеджера, форму, мессенджер или CRM. Payment link должен быть не отдельной ссылкой на сумму, а платежным объектом с tour date, route/package id, participant count, customer record, amount, currency and expiration.
После verified payment CRM может отметить deposit paid, full paid или manual review. Но финальный статус нельзя ставить по return URL или скриншоту, потому что платежный провайдер может прислать финальный статус позже.
- связывать payment request с tour booking id;
- фиксировать tour date, package id и participant count;
- хранить manager reference и source channel;
- разделять deposit paid, fully paid, cancelled и manual review.
Group booking и частичные оплаты требуют schedule
Группа может платить депозит, остаток, доплату за участника или частичный refund, поэтому одного paid status недостаточно.
В travel-сценариях часто есть предоплата, остаток суммы перед датой тура, добавление участников, индивидуальные скидки и частичная отмена. Если все это хранить как один заказ, команда не видит, кто сколько оплатил и что еще нужно запросить.
Schedule должен хранить expected amount, paid amount, due date, payment attempts, reminders and manager tasks. Если provider не поддерживает auto-charge, не нужно обещать автосписание: payment links и controlled reminders обычно безопаснее для старта.
- разделять deposit amount и balance due;
- не создавать несколько активных ссылок на один период оплаты;
- добавление участника должно создавать adjustment event;
- manual discount/refund должен иметь actor и reason.
Cancellation, weather и refund должны быть событиями
Перенос тура из-за погоды, отмена участника и возврат денег не должны стирать исходную платежную историю.
Туры зависят от даты, группы, транспорта, погоды и поставщиков. Перенос или отмена не должны удалять платеж: они должны создавать отдельные события с reason, actor, date and refund path. Это важно для поддержки, учета и спорных операций.
Ежедневная сверка сравнивает tour bookings, verified payments, unpaid balances, cancellations, refunds, CRM tasks and provider report. Так менеджер видит, какие группы готовы, где нужен reminder и какие операции требуют ручного review.
- refund не должен удалять original payment;
- перенос тура требует old date, new date и reason;
- weather cancellation хранится как отдельный business event;
- сверять CRM, provider report и accounting export.
FAQ
Можно ли принимать предоплату за тур payment link-ом?
Да, если ссылка связана с tour booking id, датой, количеством участников, суммой и сроком действия, а paid status ставится после server-side verification.
Как учитывать остаток суммы перед туром?
Хранить schedule: expected amount, paid amount, due date, reminders и отдельные payment attempts для депозита и остатка.
Что делать при переносе тура?
Сохранить original payment и создать transfer event с old date, new date, reason и actor. История платежа не должна исчезать.
