Биллинг

Зачем нужно

Биллинг фиксирует финансовые отношения с клиентом и связывает оплату с доступом к продуктам.

Кто использует

• менеджер — видит оплату и задолженность;
• финансовый администратор — делает корректировки;
• support — объясняет клиенту статусы;
• система — открывает или ограничивает доступ.

Сценарии

• выставить счёт;
• принять оплату;
• обработать возврат;
• применить скидку;
• пересчитать остаток;
• открыть доступ после оплаты;
• зафиксировать задолженность.

Данные

• invoice;
• payment;
• refund;
• discount;
• balance;
• debt;
• entitlement link;
• billing event.

Правила

• Цена и продукт не должны жить только в биллинге.
• Финансовая корректировка требует причины и аудита.
• Доступ к обучению должен быть связан с оплатой через явное правило.
• Возврат не должен удалять исторический факт оплаты.
• Покупатель, плательщик, получатель продукта и учебный субъект разделены.
• Взрослый может оплатить продукт для ребёнка; linked user ребёнка может оплатить продукт себе; будущий семейный продукт может назначаться на family_group.
• Billing/CRM не должны строить модель “кто оплатил = кто учится”.

Понятие	Смысл
purchaser	user, инициировавший покупку
payer	платёжный субъект / billing contact
beneficiary	получатель продукта: student_profile, user или future family_group
enrollment subject	учебный subject для LMS/competitions

API

Канонические операции описаны в ../api-map.md: GET/POST /invoices, GET /invoices/{invoiceId}, POST /invoices/{invoiceId}/issue, GET /payments, POST /payments/provider-webhook/{provider}, POST /refunds, POST /adjustments и GET /accounts/{accountId}/balance.

Серверная часть

Серверная часть выполняет финансовые изменения в транзакциях, обрабатывает webhooks платёжных провайдеров и обеспечивает идемпотентность событий.

Интерфейс

• финансовый блок в карточке;
• список счетов и платежей;
• ручная корректировка;
• история возвратов;
• предупреждения о долге.

Интеграции

• CRM-карточка;
• product/offer data;
• payment provider;
• LMS entitlement;
• management analytics.

Безопасность

Финансовые действия доступны ограниченным ролям. Все изменения требуют аудита.

Нестандартные случаи

• частичная оплата;
• двойной webhook;
• возврат после открытия доступа;
• ручная скидка;
• спорный платёж.

Готовность

• платежи и долги видны в CRM;
• доступы открываются по правилам;
• возвраты и корректировки аудируются;
• финансовая история не теряется.