Короткий ответ
Для SaaS платеж должен надежно управлять правом доступа: планом, периодом, организацией клиента и моментом активации. Платежная попытка не равна подписке, а возврат требует отдельного правила.
- Разделяйте аккаунт, заказ, платежную попытку и право доступа.
- Активируйте тариф только после финального успешного статуса.
- Сделайте платежные ссылки и СБП частью управляемого счета.
- Сверяйте оплаты, продления и возвраты по идентификаторам.
1. Модель счета и доступа
В SaaS клиент покупает не абстрактный платеж, а определенный план, срок или объем. На сервере создается счет с зафиксированной ценой, валютой, налоговой логикой и получателем доступа. Платежная попытка связывается со счетом, но не заменяет его.
Право доступа хранится отдельно: организация, пользователи, план, дата начала и окончания. Такая модель позволяет повторить неудачную оплату, не создавая дубликат подписки, и объяснить финансовой команде, за что получена сумма.
- зафиксируйте план и период в счете;
- не передавайте цену только из интерфейса;
- свяжите платеж с организацией клиента;
- ведите историю изменений доступа.
2. СБП и платежные ссылки
Динамический QR и платежная ссылка подходят для выставления счета конкретному клиенту. В назначении и интерфейсе стоит показывать план, период и номер счета. Срок действия платежа должен соответствовать коммерческому предложению.
Метод оплаты выбирается из фактически доступных для мерчанта вариантов. Возможность автоматических периодических списаний нельзя предполагать: она зависит от конкретного метода, согласований и технической реализации.
- создавайте отдельную ссылку для каждого счета;
- не переиспользуйте оплаченный платеж;
- объясните клиенту, какой аккаунт будет активирован;
- покажите безопасный сценарий повторной попытки.
3. Активация и повторные события
Доступ включается после подтвержденного конечного статуса. Обработчик webhook проверяет подпись, сумму, валюту, идентификатор и текущий статус счета. Повторное уведомление должно возвращать успешный технический ответ, не продлевая доступ второй раз.
Если событие задержалось, интерфейс показывает ожидание и предлагает обновить статус. Сотруднику поддержки нужен поиск по счету и платежу, но ручная активация должна быть контролируемой и оставлять журнал.
- используйте идемпотентную активацию;
- проверяйте сумму и принадлежность счета;
- не доверяйте только переходу пользователя;
- логируйте ручные решения.
4. Продления, возвраты и сверка
Продление — новый счет и новая платежная попытка, связанная с тем же клиентом. Это упрощает учет периодов и исключает неоднозначность. Возвраты и прекращение доступа должны следовать опубликованным условиям и фактически оказанной услуге.
WHITECAPITAL может поддержать согласованный прием платежей через СБП, QR, ссылки и API. Конкретная доступность функций, включая карточные или повторные сценарии, определяется после KYB/KYC, комплаенса и согласования банковского контура.
- не смешивайте платежи разных периодов;
- сверяйте счета, статусы и перечисления;
- опишите условия прекращения услуги;
- тестируйте границы расчетного периода.
Вопросы и ответы
Можно ли использовать одну платежную ссылку для всех клиентов?
Для надежного учета лучше создавать ссылку для конкретного счета, клиента и суммы.
Поддерживаются ли автоматические подписки?
Это зависит от доступного и одобренного платежного метода. Возможность нельзя считать универсальной.
Когда активировать доступ?
Только после финального успешного серверного статуса, обработанного идемпотентно.
Источники и правила
Используем официальные материалы платежной системы и политики WHITECAPITAL. Для конкретного подключения приоритет имеют договорные документы.
- WHITECAPITAL — условия использования API
- WHITECAPITAL — условия для мерчантов
- WHITECAPITAL — правила возвратов и диспутов
Материал предназначен для операционной ориентации и не является обещанием подключения, универсальной доступности метода, фиксированной комиссии или срока расчетов.