Повторяющийся биллинг с Rails и ActiveMerchant: лучшие практики, ловушки, gotchas?

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

Я ищу советы относительно передовой практики, учитывающей наши требования (перечисленные ниже), и любые дополнительные хедз-ап для общих ошибок или конкретных вопросов, которые я должен уделять особое внимание. Платежным шлюзом, который мы будем использовать, является PaymentExpress, поскольку он является одним из немногих поддерживаемых шлюзов, который имеет повторяющийся биллинг и не имеет особых условий для компаний, работающих за пределами США. Бизнес, стоящий за этим приложением, основан на Великобритании.

Пользователи приложения создают учетную запись в поддомене, где они могут получить доступ и настроить приложение и их данные. Ниже приведены некоторые требования/функции, которые могут повлиять на работу биллинга:

Все пользователи получают 30-дневную пробную версию
Существуют разные планы, в том числе бесплатный
Более высокие тарифные планы имеют более высокие ограничения на количество данных (например, пользователей, проектов и т.д.), которые они могут иметь в своем аккаунте
Период оплаты будет ежемесячно, начиная с пробного периода
Там будут скидки/коды купонов, чтобы получить процент от нормальной цены за год по планам и т.д.
Планирование цен будет изменяться по мере добавления функций.

Конкретные препятствия, которые я могу предвидеть, будут следующие вещи:

Как справиться с понижением рейтинга, когда они нарушают лимиты плана для планов более низкого уровня.
Поведение, когда срок действия кредитных карт истекает, или платежи не проходят (возможно, режим, доступный только для чтения)
При изменении планов ценообразования мы хотим соблюдать предыдущие цены для существующих пользователей за период времени (например, 6 месяцев), а затем начать взимать более высокие ставки. Если цена плана снижается, она вступает в силу немедленно.

Другим советом, который был бы полезен, было бы все, что касалось потока приложения. Как должны быть представлены пользователю биллинговые формы? Когда должна требоваться информация о кредитной карте? Как следует отправлять, хранить и получать счета-фактуры?

Я должен сообщить, что мы планируем основать большую часть базы кода SaaSy. SaaSy предназначен для использования в качестве отдельного приложения Rails, которое обрабатывает все функции регистрации и управления учетными записями. Однако это не сработает для нас, так как мы никогда не планировали это с самого начала, и было бы утомительным процессом адаптировать наше приложение к тому, чтобы работать так. Следовательно, мы будем тянуть код и идеи от SaaSy и объединять их в наше приложение, гораздо менее утомительную задачу.

Ответ 1

RailsKits имеет Программное обеспечение как комплект услуг, который должен делать то, что вам нужно. Он имеет встроенную поддержку для бесплатных испытаний, модернизации, понижения, ограничений по планированию и т.д., И он поддерживает PaymentExpress (и некоторые другие).

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

В то время как RailsKit относительно недорог, когда сравнивается то, что стоило бы вам реализовать все свои функции самостоятельно, есть пара версий с открытым исходным кодом, которые направлены на достижение того же самого. Тот, который я помню с головы, называется Freemium.

EDIT: Я забыл упомянуть, что Райан Бэйтс сказал в своем последнем Railscast, что его следующий эпизод или два будут касаться повторяющегося выставления счетов, поэтому Следите за этим. Обычно он делает один эпизод в неделю, а пять, которые он делал с 22 декабря, покрывают обработку платежей разных типов.

Ответ 2

Одна вещь, которую я хотел добавить: помните, что вам не нужно использовать повторяющуюся функцию выставления счетов, встроенную в шлюз. В общем, эти системы являются устаревшими и очень трудными для решения проблемы, мы испорчены в мире рельсов.

Вы получаете гораздо большую гибкость, просто используя их для одной цели (для оплаты кредитной карты и, возможно, также для хранения кредитных карт для соответствия PCI). Затем сверните свой собственный повторяющийся биллинг в вашем приложении rails с заданием cron, поле даты для того, когда они будут оплачены, и суммой, которую платит каждый человек (в случае, если они использовали купон) и т.д.

Один маленький пример: иногда люди отменяют ежемесячную подписку в середине месяца. Они хотят, чтобы они не забыли отменить до следующего платежа. Большинство повторных счетов, которые я видел, мгновенно прекращают учетную запись (или отправляют вам сообщение с указанием этого). На самом деле, пользователь заплатил в конце месяца и должен получить еще две недели доступа. Вы можете сделать это, если у вас есть собственный повторяющийся биллинг в рельсах, но нет, если вы используете повторяющийся биллинг шлюза. Небольшой пример.

Ответ 3

Peepcode имеет PDF для продажи (70 страниц), в котором подробно описаны различные аспекты обработки платежей и отраслевые практики. Возможно, стоит проверить:

http://peepcode.com/products/activemerchant-pdf

Ответ 4

Я также посещу сайт на основе подписки, и это наши текущие требования. Они могут помочь вам в передовой практике:

Пользователи смогут выбрать один из планы подписки.
Пользователи должны будут ввести свои данные кредитной карты, чтобы зарегистрироваться их избранный план.
Все основные кредитные и дебетовые карты должны принимаются в том числе Маэстро и American Express.
У каждого плана будет 30-дневный бесплатный , поэтому кредитные карты пользователей должны взимается только после 30-дневного период истекает. Однако, действительность кредитных карт должны быть проверены на время регистрации.
Пользователи будут отправлены по электронной почте несколько дней до оплаты кредитной карты уведомить их о том, что они будут если они отменяют свои Счет. Если они отменяют свою учетную запись в течение 30 дней бесплатной пробной версии, их кредитная карта не взимается.
После любого бесплатного ознакомительного периода пользователи будут взиматься заранее за их использование системы - то есть они будут предоплата.
Пользователи будут автоматически списаны каждый месяц для их выбранного плана. Каждый месяц пользователям будет отправлено отправьте электронное письмо за несколько дней до уведомления что они будут списаны. однажды оплата была произведена, пользователи будут отправил по электронной почте счет-фактуру, платеж получен.
Пользователи смогут обновить или понизить их учетные записи в любое время. Когда пользователи обновляют/понижают, их следующая плата за подписку будет новый курс. Пользователи смогут только понизить свои счета до плана которые могут обрабатывать свои данные. Для Например, если в настоящее время у них 10 активные проекты, которые они не могут понизить к Основному плану, поскольку Основной план позволяет только 5 проектов. Oни придется удалять или архивировать 5 проектов, которые вы можете сделать перейдите на Basic.
Пользователи смогут войти в свою учетной записи и изменить или обновить их Сведения о кредитной карте.
Пользователи смогут отменить свои учетной записи в любое время. Здесь не будет дополнительные абонентские платежи после пользователь отменил свою учетную запись. Однако пользователи не будут возвращены за часть месяца, которую они имеют уже оплачены.
Все части платежной системы должны быть совместимым с PCI DSS на 100%; в том числе любые сторонние системы.
Платежная система должна поддерживать автоматическое уведомление и повтор неудачные обновления подписки.
Платежная система должна поддерживать скидочные ваучеры с датами истечения срока действия.
Сведения о кредитной карте не должны быть обработанные или хранящиеся на наших серверах.
они всегда должны обрабатываться/храниться сторонней стороной партнер по обработке платежей. Мы не нести ответственность за обеспечение безопасности эти детали и соблюдение правовых норм и правил.
Пользователи смогут войти в свои учетные записи и просмотр полного биллинга история, включая даты и суммы оплачено. Нам также необходимо будет возможность входа в систему для просмотра планы оплаты и оплаты клиентов история. Это будет необходимо для обслуживание клиентов.

Мы также смотрели http://chargify.com/, который, похоже, мог бы сэкономить много времени на кодирование.