Ключевые темы
Связанные публичные страницы
Если нужен не только разбор, а страница продукта, API или операционного сценария, начните с этих разделов VPOS.am.
Payment request должен быть связан с регистрацией
Оплата без attendee id и ticket type не помогает команде понять, кто оплатил и какой доступ получил.
Для конференции, семинара, мастер-класса или закрытой встречи платеж начинается раньше входа в зал. Система должна знать событие, тип билета, участника, лимит мест, сумму, валюту, срок действия ссылки и CRM reference до перехода на оплату.
Если payment link отправлен без registration context, поддержка будет сверять имена, скриншоты и банковские строки вручную. Надежнее создавать payment request из backend или CRM и переводить регистрацию в paid только после server-side verification.
- создавать payment request из registration id;
- фиксировать ticket type, event id и attendee id;
- не подтверждать вход по скриншоту оплаты;
- разделять pending, paid, expired, cancelled и manual review.
Capacity, waitlist и expiration должны быть правилами
Продажа билетов ломается, когда несколько клиентов оплачивают один лимит мест или старая ссылка остается активной.
Для мероприятий критичны лимиты: общий зал, тарифы, VIP-места, группы, промокоды и waitlist. Payment layer не должен обещать место, если лимит уже изменился или ссылка просрочена. Поэтому перед подтверждением нужен повторный server-side check.
Практичная схема: reservation имеет срок жизни, payment request истекает вместе с ней, а webhook или status lookup подтверждает регистрацию только если capacity rule все еще выполняется. Иначе запись уходит в manual review или refund workflow.
- синхронизировать expiration оплаты и резерва места;
- не держать бесконечно активные ссылки на ограниченный тариф;
- проверять capacity перед paid confirmation;
- хранить reason для waitlist и manual review.
Refund, check-in и сверка должны жить в одной timeline
После оплаты появляются переносы, отмены, частичные возвраты и вход на площадку, которые нельзя терять из платежной истории.
Мероприятия часто меняются после оплаты: участник просит вернуть билет, заменить имя, перейти на другой тариф или прийти по списку. Если check-in и refund живут отдельно от платежа, команда теряет контекст и закрывает день вручную.
Единая timeline показывает registration status, payment status, ticket status, refund request, entry event and provider reference. Так можно сверить продажи, фактический вход, возвраты и исключения без пересборки Excel перед отчетом.
- refund не должен удалять ticket history;
- смена attendee требует actor, reason и timestamp;
- check-in status не равен payment status;
- сверять tickets sold, entries, refunds и provider report.
FAQ
Можно ли подтверждать билет по return URL после оплаты?
Надежнее подтверждать билет после webhook или server-side status lookup. Return URL может открыться до финального платежного события.
Как защититься от перепродажи сверх лимита мест?
Нужно связывать payment request с reservation, задавать expiration и повторно проверять capacity перед final paid confirmation.
Что делать при возврате билета?
Создать отдельное refund event с reason, actor, суммой и provider reference. Историю регистрации и оплаты удалять нельзя.
