способы проверки подписки на услугу freemium

Question

У нас есть продукт freemium, в котором указано, что некоторые функции доступны, если была оплачена ежемесячная подписка; если не оплачено, то бесплатные возможности остаются доступными.

Вот как я думаю об обработке, но хотел проверить:

1) Когда кто-то приобрел свою подписку, создается регулярный график выставления счетов.

2) У пользователя будет поле (paid_up), установленное на «y»

3) Когда пользователь снова входит в систему, сценарий аутентификации проверяет, является ли paid_up значением "y". Если это так, он создает токен сеанса

4) Я думаю, что мне нужен пакетный скрипт, который переключит тумблер. Хотите знать, как это сделать? Сохранить дату последней обработки кредитной карты?

Answer 1

Написав несколько из них ранее, вы должны сделать несколько вещей.

Во-первых, как уже упоминалось, вам нужно какое-то поле paid_through_date. Это важно по ряду причин, но главная из них заключается в том, что он дает вам дополнительную гибкость в случае, например, отказа ваших серверов, и вы решаете, что пользователям следует предоставить дополнительный день бесплатного обслуживания. Просто верните их значение paid_through_date на один день. Это также упрощает реализацию бесплатных пробных версий.

Во-вторых, не используйте такие вещи, как Automated Recurring Billing от Authorize.net, даже если вы работаете в системе подписки. Вы хотите полностью контролировать, когда запланирован платеж, и перекладывание этой ответственности на ваш шлюз в большинстве случаев является плохой идеей. Большинство шлюзов позволит вам хранить кредитные карты на своих серверах. Они вернут вам удостоверение личности для этой карты, и вы сможете взимать плату за этот промежуточный идентификатор вместо самой карты.

В-третьих, ЗАПИСАТЬ ВСЕ СДЕЛКИ. Я не могу переоценить это достаточно. На самом деле, вы, вероятно, должны также предоставить этот журнал пользователю. В основном это просто таблица всех выполненных ими платежей, сумм и окончательного баланса. Распространено также выставлять счета в эту таблицу. Счета имеют положительную сумму, платежи и кредиты имеют отрицательную сумму, и просто суммируйте все, чтобы пользователь получил окончательный баланс. Вы можете очень легко ввести произвольные кредиты в эту таблицу, если пожелаете.

Запустите скрипт cron, который запускается каждые 24 часа и проверяет, что пользователям нужно для создания счета. Этот скрипт cron должен иметь три критических свойства: во-первых, если по какой-то причине он не запускается, вы не должны терять дневные расходы. Во-вторых, если он запускается более одного раза в день или прерывается и выполняется повторно, он не должен взимать плату дважды. И в-третьих, если дата на сервере была случайно изменена на 2090, она не должна автоматически выставлять счета всем вашим пользователям за миллионы долларов. Точно так же, сбросы к датам в прошлом (в частности, 1 января 1970 г.) также должны стать причиной возникновения ада. По моему опыту, переход на летнее время редко является проблемой.

Я думаю, что это охватывает большинство важных вещей, но в биллинговых системах всегда есть небольшие хитрости, за которыми нужно следить.

Answer 2

Я бы работал над этим с другого конца, и там было бы поле с оплаченной датой и датой оплаты. Таким образом, пользователи смогут отменить подписку и получить выгоду от оплаты, которую они сделали.

Answer 3

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

Для каждого клиента, который должен
Запустите биллинг на свой аккаунт
В случае успеха:
Сброс повторяется до 0
Отметить их как платных клиентов
Перейти к следующему аккаунту
В противном случае:
Увеличьте счетчик повторов
Отправить уведомление клиенту
Если их счетчик повторов достигает максимума:
Переключите переключатель, чтобы пометить их как свободные

Вы можете сделать то же самое в пакетном режиме, если что-то еще запускает биллинг и просто сообщает вам результаты, просто замените «Запустить биллинг на их счет» на «Чтение результатов с последней попытки биллинга». Ваш счетчик повторов будет реализовывать что-то вроде льготного периода, при условии, что ваш биллинг выполняется ежедневно, поэтому у него будет шанс решить проблему с биллингом, а не просто отозвать свои премиальные функции только из-за истечения срока действия их карты или чего-то подобного. 1005 *

Answer 4

Конечно, вы бы создали столбец с названием «last_payment». Если вы используете MySQL, вы можете создать это как поле DATE. Каждый раз, когда вы получаете ежемесячный платеж, я предполагаю, что компания, выставляющая счета на кредитные карты, разместит что-то в сценарии на вашем сайте. (т.е. PayPal отправляет IPN). Каждый раз, когда это будет получено, вы будете делать запрос, такой как:

UPDATE members SET `last_payment`=CURDATE() WHERE user_id='$user_id';

Я бы предложил запустить скрипт на CRON, который запускается раз в 24 часа, и выполняет этот запрос:

UPDATE members SET paid_up='N' WHERE DATEDIFF(CURDATE(),last_payment) > '30';

Это обновит все записи, где оплата не была произведена в течение 30 дней или более, и установит для поля paid_up значение N. Тогда ваш обычный код входа будет работать.

Если вы не хотите использовать CRON, вы можете изменить свой запрос на вход в систему примерно так:

SELECT 1 FROM members WHERE 
username='$user' AND password='$password'
AND DATEDIFF(last_payment) <= '30';

Кстати, ваша компания, занимающаяся обработкой кредитных карт, может иметь способ отправить вам сообщение POST при отмене подписки, что позволит вам установить для поля paid_up значение N.

Надеюсь, это поможет. Не стесняйтесь комментировать, если у вас есть какие-либо вопросы:)