Ключевые темы
Связанные публичные страницы
Если нужен не только разбор, а страница продукта, API или операционного сценария, начните с этих разделов VPOS.am.
Billing schedule не равен payment status
Расписание говорит, когда нужно попытаться получить оплату, но не доказывает, что деньги получены.
В CRM регулярный счет часто выглядит как повторяющаяся задача: каждый месяц выставить invoice, отправить ссылку и закрыть оплату. Но billing schedule не должен сам менять финансовый статус. Он только создает expected payment или payment attempt.
Факт оплаты должен появляться после provider webhook или server-side status lookup. Если провайдер поддерживает tokenized recurring, это отдельный контрактный и технический сценарий. Если нет, безопаснее начинать с recurring invoices и payment links.
- хранить plan, period, due date и amount отдельно от payment status;
- создавать payment attempt идемпотентно;
- не обещать автосписание без provider support;
- разделять invoice generated, payment pending и payment verified.
Retries и dunning должны быть ограниченными
Повторные попытки и напоминания нужны, но они не должны спамить клиента или создавать дубли.
Неуспешная оплата подписки не всегда означает отказ клиента. Возможны техническая ошибка, expired link, временная проблема банка, недостаточно средств или изменение тарифа. Поэтому retries должны иметь ограничение, backoff и понятный финальный статус.
Dunning flow должен учитывать каналы уведомлений, язык клиента, grace period и ручное вмешательство оператора. CRM должна видеть next retry, last failure reason и дату блокировки услуги, если бизнес это применяет.
- ограничить количество retry attempts;
- не отправлять несколько активных payment links на один период;
- логировать failure reason без лишних card details;
- после лимита переводить период в manual review.
Сверка должна учитывать plan changes, refunds и partial periods
Подписки ломаются на изменениях тарифа, паузах, возвратах и частичных периодах, если нет audit trail.
Регулярный billing нужно сверять не только по успешным платежам. Важны изменения плана, пробные периоды, паузы, partial refund, ручное продление и перенос даты списания. Без audit trail поддержка не сможет объяснить, почему услуга активна или заблокирована.
Практичный reconciliation показывает period status, paid amount, expected amount, provider references, CRM entitlement и список исключений. Тогда бухгалтерия и поддержка закрывают месяц без ручной сборки таблиц.
- сравнивать expected amount и verified amount;
- учитывать plan change внутри периода;
- показывать refund и partial refund как отдельные события;
- синхронизировать service entitlement только после verified payment.
FAQ
Можно ли делать автосписания картой для подписки?
Только если выбранный платежный провайдер и договор поддерживают tokenized recurring или похожий механизм. Без этого лучше запускать recurring invoices и payment links с напоминаниями.
Что делать с неуспешной регулярной оплатой?
Создать failed attempt, сохранить безопасную причину ошибки, запустить ограниченный retry/dunning flow и не отключать услугу без понятного grace period или бизнес-правила.
Когда продлевать доступ к услуге?
После verified payment или явного manual override с audit trail. Плановая дата счета сама по себе не должна продлевать финансово зависимый доступ.
