Ключевые темы
Связанные публичные страницы
Если нужен не только разбор, а страница продукта, API или операционного сценария, начните с этих разделов VPOS.am.
Платеж должен открывать доступ по правилу, а не вручную
После verified payment система должна понимать, какой ученик, курс, группа и период оплачены.
В онлайн-школах платеж часто начинается с менеджера: выставить счет, отправить ссылку, отметить ученика и открыть доступ. Если эти действия не связаны через backend, появляются ручные paid-статусы, доступ без оплаты и сложные споры по датам.
Надежнее создавать payment request из CRM или LMS: ученик, курс, группа, период, сумма, валюта и срок действия ссылки фиксируются до оплаты. После verified status backend открывает доступ или ставит задачу оператору, если нужна ручная проверка.
- не открывать доступ по скриншоту оплаты;
- связывать payment id с student id и course id;
- хранить период обучения и дату старта;
- логировать ручное открытие доступа отдельно.
Рассрочка и частичная оплата требуют отдельного schedule
Несколько платежей за курс нельзя моделировать одним paid/failed статусом.
Для курсов часто используют предоплату, рассрочку, помесячные платежи или оплату модулями. Это не должно превращаться в один order status. Нужен schedule: expected amount, due date, paid amount, grace period, reminders and access rules.
Если provider не поддерживает автосписание, нельзя обещать автоматическую подписку. Практичный старт - payment links, reminders и controlled access: доступ продлевается после verified payment или manual override с audit trail.
- разделять full price, paid amount и remaining amount;
- не создавать несколько активных ссылок на один период;
- фиксировать grace period и next due date;
- синхронизировать доступ только после verified payment.
Refund и перенос группы должны быть видны поддержке
Смена группы, пауза обучения и частичный возврат ломают сверку, если нет единого timeline.
Образовательные услуги часто меняются после оплаты: ученик переносит группу, берет паузу, покупает другой курс или просит частичный возврат. Если платежный слой не знает этих событий, бухгалтерия видит только сумму, а поддержка разбирает контекст вручную.
Полезная модель хранит payment status, access status, group transfer, refund request, provider refund reference and CRM notes. Тогда команда видит, что оплачено, какой доступ выдан и что нужно вернуть или перенести.
- refund не должен удалять историю доступа;
- перенос группы должен иметь reason и actor;
- частичный refund считать отдельным событием;
- сверять CRM, LMS и provider report перед закрытием месяца.
FAQ
Можно ли открыть доступ к курсу сразу после return URL?
Лучше открывать доступ после webhook или server-side status lookup. Return URL может быть открыт без финального платежного события.
Как принимать оплату в рассрочку за курс?
Нужно хранить schedule платежей и создавать отдельные payment attempts. Автосписание возможно только если provider и договор поддерживают такой сценарий.
Что делать при переносе ученика в другую группу?
Связать перенос с исходным payment/access record, сохранить reason, actor и дату. Платежная история не должна теряться при смене группы.
