Структура базы для подписок: четыре таблицы, без которых будет больно

Структура базы для подписок: четыре таблицы, без которых будет больно

Частая ошибка — хранить подписку как два поля в таблице пользователей: тариф и дата окончания. Работает ровно до первого спорного платежа.

Минимальная схема:

— plans — тарифы: название, цена, период, что открывает.
— subscriptions — сама подписка: пользователь, план, статус (активна, отменена, просрочена, на паузе), дата начала, дата следующего списания, идентификатор в платёжной системе.
— payments — каждая попытка списания: подписка, сумма, статус, ответ платёжки, дата. Включая неудачные.
— subscription_events — журнал изменений: кто, когда и почему поменял статус.

Зачем журнал: когда подписчик пишет «я отменил месяц назад, а вы списали», вы должны за минуту увидеть, что и когда происходило.

Зачем хранить неудачные платежи: они показывают, где теряются деньги. Карта просрочена, недостаточно средств, банк отклонил — это разные ситуации с разными действиями.

Одна таблица на всё — это долг, который отдаётся при первом чарджбэке.

—
Чтобы быть в курсе рынка — подпишись на @ponty_payment