Преамбула
Моя цель - создать повторно используемый код для нескольких проектов (а также опубликовать его на github) для управления подписками. Я знаю о чередующихся поставщиках биллинга, но это не то, к чему стремится этот модуль. Он должен быть просто оболочкой / помощником для расчета баланса аккаунта, простых уведомлений о продлении подписки и обработки расчетов цены.
Есть страны, в которых вы не можете использовать повторяющийся биллинг из-за того, что поставщики или возможности оплаты не имеют достаточной поддержки или не поддерживают ее, либо слишком дороги (микроплатежи). И есть люди, которые не хотят использовать повторяющиеся счета, но оплачивают свой счет вручную / выставляют счет в конце года. Поэтому, пожалуйста, не предлагайте PayPal регулярные счета, регулярные или аналогичные услуги.
Ситуация
Предположим, у вас есть модель, которая может подписаться на план подписки (например User
). Эта модель имеет поле, в котором хранится идентификатор плана подписки, на который она в данный момент подписана. Таким образом, при каждом изменении плана оно записывается.
Существует модель (например SubscriptionPlanChanges
) со следующими полями, записывающими упомянутые изменения:
subscriber
относящиеся к модели подписки (User
в данном случае)from_plan
определение идентификатора плана, который модель имела до измененияto_plan
определение идентификатора плана, выбранного модельюcreated_at
поле даты и времени, в котором хранятся измененияvalid_until
сохраняет дату до фактической подпискиpaid_at
также поле даты и времени, которое определяет, была ли (и когда) подписка оплачена
Конечно, этот макет является дискуссионным.
Вопрос об остатке на счете.
Когда пользователь меняет свой план подписки, мне нужно сравнить поля плана, получить цены и рассчитать вычет для нового плана на основе текущего плана valid_until
и его цены. Скажем: вы подписались на год плана А, но через 6 месяцев вы переходите на план Б, поэтому вы получаете половину уплаченной цены за 6 месяцев плана А.
Что мне интересно: если пользователь, например, переключается на бесплатный тариф, у него есть кредит, который можно вычесть, если пользователь захочет снова переключиться. Вы бы кэшировали это значение в дополнительном поле или каждый раз рассчитывали все записи, относящиеся к этому пользователю? Вы бы добавили / изменили что-то в макете стола?
Вопрос легкого понимания
Когда наступает конец периода подписки, пользователь получает уведомление и имеет возможность продлить свою подписку, заплатив снова. Проще всего было бы просто обновить paid_at
и valid_until
с новыми вариантами подписки. Однако я не уверен, что вы храните все данные, которые могут кому-то понадобиться, например историю платежей / подписок.
Другим вариантом будет создание дополнительной записи для этого, где from_plan
и to_plan
имеют одинаковый идентификатор (таким образом символизирующий «без изменений»). Но не мешает ли это каким-то образом рассчитать остаток на счете?
Если бы кто-то мог указать мне правильное направление относительно логики обработки таких подписок, я был бы очень признателен.
ОБНОВЛЕНИЕ
Спасибо за помощь к настоящему времени. Я думаю, что мой вопрос был слишком расплывчатым, поэтому я постараюсь быть более точным, используя меньше абстракций. К сожалению, я еще не смог решить свою проблему.
Случай А
User
можно выбрать Subscription Plan A
. Это в настоящее время хранит, SubscriptionPlanChange
чтобы отслеживать это. Например, через 5 месяцев User
обновляет подписку на Subscription Plan B
. Таким образом, он платит цену за свою новую подписку, вычитая цену плана a за неиспользованные 7 месяцев.
Дело Б
Через 3 месяца User
откатывается на свое Subscription Plan A
. Он не должен платить, но получает за это баланс, так что в конце подписки он вычитает этот баланс для своей новой подписки.
В случае C
User
можно выбрать план подписки для подуслуги, которая имеет независимые планы подписки. То же самое Case A
и Case B
может применяться к этой подписке на субсервис.
_Case D_
Пользователь отменяет одну из своих подписок. Это приводит к пополнению его баланса.
Мой вопрос (в настоящее время, по крайней мере) в основном зависит от того, как правильно хранить эти данные, чтобы я мог воспроизвести историю подписок для бизнес-анализа и рассчитать сальдо, получать непогашенные платежи на основе подписок и т. Д.
Я также не уверен, следует ли сохранять баланс, например, в самой модели пользователя, или он не сохраняется, но может быть рассчитан в любое время на основе сохраненных данных / истории.
Некоторые вещи стоит отметить, хотя я не думаю, что они должны создавать проблемы:
- Это не должно быть
User
, это может быть что угодно, поэтомуSubscriber
полиморфна Plans
не обязательно должны быть планы, но могут быть, например,Magazines
как упомянуто. Это то, что я описал с Case C и Case D .