Recorrentes de faturamento com Rails e ActiveMerchant: Melhores práticas, armadilhas, pegadinhas?

Question

Estamos preparando para o lançamento de uma grande aplicação web que tem estado em desenvolvimento desde o ano passado. Estamos prestes a iniciar o processo de integração ActiveMerchant para lidar com taxas de subscrição recorrentes para o serviço.

Eu estou procurando algum conselho sobre as melhores práticas, considerando nossas exigências (listados abaixo) e quaisquer heads-up adicionais para armadilhas comuns ou questões específicas que eu deveria estar dando atenção especial. O gateway de pagamento que será utilizado é PaymentExpress como é um dos poucos gateways suportados que tem recorrentes faturamento e doesn 't tem quaisquer condições especiais para empresas fora dos EUA que operam. O negócio por trás deste pedido é baseado fora do Reino Unido.

Os usuários do aplicativo criar uma conta com um sub-domínio onde eles podem acessar e personalizar o aplicativo e seus dados. Abaixo estão alguns dos requisitos / características que possam ter um efeito sobre como funciona o faturamento:

• Todos os usuários obter um teste de 30 dias
• Existem diferentes planos, incluindo um livre
• planos mais caros têm limites maiores sobre a quantidade de dados (por exemplo, usuários, projetos, etc) que podem ter na sua conta
• período de facturação será mensal, começando após o julgamento
• Haverá descontos / códigos de cupom para obter uma porcentagem de desconto no preço normal para um ano em planos, etc.
• plano de preços irá mudar à medida que recursos são adicionados

obstáculos específicos eu posso prever serão coisas incluindo o seguinte:

• Como lidar com a degradação quando violam os limites do plano para planos de nível inferior.
• Comportamento quando cartões de crédito expirar ou pagamentos não passam por (um modo de somente leitura forçada, talvez)
• Quando plano de preços alterações, queremos honrar os preços anteriores para os usuários existentes para um período de tempo (como a 6 meses), em seguida, começar a cobrar taxas mais elevadas. Se o preço plano diminui, ele terá efeito imediato.

Outro conselho que seria útil seria nada em relação ao fluxo da aplicação. Como deve formas de cobrança ser apresentada ao usuário? Quando deveria informações de cartão de crédito será necessário? Como devem as facturas sejam enviados, armazenados e acessíveis?

I deve divulgar que pretende basear um monte da base de código off SaaSy . SaaSy é projetado para ser usado como uma aplicação Rails separada que lida com todas as laterais da inscrição e gerenciamento de conta das coisas. No entanto, isso não funciona para nós, pois nunca planejou para este desde o início e que seria um processo tedioso a adaptar a aplicação ao trabalho assim. Consequentemente, vamos estar puxando código e idéias do SaaSy e fundindo-os em nosso aplicativo, uma tarefa muito menos tedioso.

Answer 1

RailsKits tem um Software as a Service kit que deve fazer o que você precisa. Ele foi construído com suporte para ensaios livres, modernização, rebaixamento, limites de planos, etc., e suporta PaymentExpress (e alguns outros).

Eu pesquisei um pouco para um projeto que estou fazendo, mas eu ainda não comprou ainda, então não posso responder por ele. No entanto, tenho visto alguns posts elogiando este kit.

Enquanto o RailsKit é relativamente barato quando comparado o que custaria para implementar todas as suas características mesmo, há um par de código aberto versões lá fora que visam realizar a mesma coisa. O que eu me lembro fora do topo da minha cabeça é chamado Freemium .

EDIT: eu esqueci de mencionar que Ryan Bates disse em seu mais recente Railscast que o seu próximo episódio ou dois vai lidar com faturamento recorrente, de modo a manter-se atento para isso. Ele normalmente faz um episódio por semana, e os cinco que ele tem feito desde 22 de dezembro toda a cobertura manipulação de pagamentos de diferentes tipos.

Answer 2

Uma coisa que eu queria acrescentar: mantenha em mente que você não precisa usar o recurso de faturamento recorrente que está embutido no gateway. Em geral, estes sistemas são legado e muito difícil de lidar, nós ficar estragado no mundo trilhos.

Você tem muito mais flexibilidade apenas usá-los para uma finalidade (a conta de um cartão de crédito, e talvez também cartões de crédito da loja para conformidade PCI). Em seguida, role seu próprio faturamento recorrente em seus trilhos aplicativo com um trabalho cron, um campo de data para quando eles são pagos através, e quantia que cada pessoa está a pagar (no caso, eles usaram um cupom) etc.

Um pequeno exemplo: às vezes as pessoas vão cancelar uma assinatura mensal no meio do mês. Eles querem se certificar de que eles não se esqueça de cancelar antes do próximo pagamento. A maioria de gateway de faturamento que eu vi irá encerrar imediatamente a conta recorrentes (ou enviar-lhe uma mensagem indicando isso). Na realidade, o usuário pagou até o final do mês e deve ser dada mais 2 semanas de acesso. Você pode fazer isso se você tem rolado sua própria cobrança recorrente em trilhos, mas não se você estiver usando o gateway de faturamento recorrentes. Apenas um pequeno exemplo.

Answer 3

Peepcode tem um PDF para venda (70 páginas) que detalha vários aspectos de processamento de pagamentos e práticas da indústria para isso. Pode valer a pena conferir:

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

Answer 4

Eu também estou no meio da criação de um site baseado em assinatura e estas são as nossas necessidades atuais. Eles podem ajudá-lo a respeito de melhores práticas:

• Os usuários serão capazes de escolher um dos os planos de assinatura.
• Os usuários serão obrigados a entrar no seu cartão de crédito detalhes para se inscrever para seu plano escolhido.
• Todos os principais cartões de crédito e débito must ser aceito incluindo Maestro e American Express.
• Cada plano terá um livre de 30 dias julgamento para cartões de crédito dos usuários deve só pode ser carregado depois de 30 dias período expirar. No entanto, a validade de créditos de cartões deve ser verificada pelo no momento da inscrição.
• Os usuários serão enviadas poucos dias antes de seu cartão de crédito é cobrado para notificá-los de que eles serão cobrado em breve, a menos que cancelar sua conta. Se cancelar a sua conta dentro de seu teste gratuito de 30 dias, a sua cartão de crédito não deve ser cobrado.
• Depois de um período de teste gratuito, os usuários será cobrado antecipadamente por sua uso do sistema - ou seja, eles vão pré-pagamento.
• Os usuários serão automaticamente debitadas a cada mês para o seu plano escolhido. A cada mês, os usuários receberão um enviar e-mail alguns dias de antecedência para notificar -lhes que eles serão cobrados. Uma vez o pagamento foi feito, os usuários serão enviada uma factura mostrando que o seu pagamento tenha sido recebido.
• Os usuários serão capazes de atualizar ou downgrade de suas contas a qualquer momento. Quando os usuários upgrade / downgrade, seu próxima taxa de assinatura será no a nova taxa. Os usuários só poderão a rebaixar suas contas para um plano que pode lidar com seus dados. Para exemplo, se eles têm atualmente 10 projetos ativos que não podem fazer o downgrade para o plano básico porque o básico plano permite apenas 5 projetos. Eles terá de excluir ou arquivar 5 projectos antes de você puderem downgrade para Basic.
• Os usuários poderão fazer login para sua conta e alterar ou actualizar os seus detalhes do cartão de crédito.
• Os usuários serão capazes de cancelar sua Conta a qualquer momento. Haverá, sem ser mais encargos de subscrição após um usuário cancelou sua conta. No entanto, os usuários não serão reembolsados durante parte do mês eles têm já pago.
• Todas as partes do sistema de pagamento deve ser 100% compatível com PCI DSS; Incluindo sistemas de qualquer terceiro partido.
• O sistema de pagamento deve apoiar notificação automatizado e de nova tentativa de renovações de assinatura falhou.
• O sistema de pagamento deve apoiar vales de desconto com datas de validade.
• detalhes do cartão de crédito não deve ser processado por ou armazenados em nossos servidores
• que deve sempre ser processadas / armazenadas pelo nosso 3rd party parceiro de processamento de pagamentos. Nós não quer a responsabilidade pela fixação esses detalhes e cumprir normas legais e regulamentares.
• Os usuários serão capazes de registrar em seu contas e ver um full billing história, incluindo datas e valores pago. Também terá de ser capaz de efetuar login em um sistema para ver planos de pagamento do cliente e pagamento história. Isso será essencial para atendimento ao cliente.

Nós também estamos olhando para http://chargify.com/ que parece que poderia salvar um muito tempo de codificação.