Facturación recurrente con Rails y ActiveMerchant: ¿Mejores prácticas, trampas, trampas?

Question

Nos estamos preparando para el lanzamiento de una gran aplicación web que ha estado en desarrollo durante el año pasado. Estamos a punto de comenzar el proceso de integración de ActiveMerchant para manejar tarifas de suscripción recurrentes para el servicio.

Estoy buscando algún consejo con respecto a las mejores prácticas teniendo en cuenta nuestros requisitos (enumerados a continuación) y cualquier aviso adicional para dificultades comunes o problemas específicos que debería considerar especialmente. La pasarela de pago que utilizaremos es PaymentExpress , ya que es una de las pocas pasarelas admitidas que tiene facturación recurrente y no No existen condiciones especiales para las empresas que operan fuera de los EE. UU. El negocio detrás de esta aplicación se basa en el Reino Unido.

Los usuarios de la aplicación crean una cuenta con un subdominio donde pueden acceder y personalizar la aplicación y sus datos. A continuación se detallan algunos de los requisitos / características que podrían tener un efecto sobre cómo funciona la facturación:

• Todos los usuarios obtienen una prueba de 30 días
• Existen diferentes planes, incluido uno gratuito
• Los planes de mayor precio tienen límites más grandes en la cantidad de datos (por ejemplo, usuarios, proyectos, etc.) que pueden tener en su cuenta
• El período de facturación será mensual, comenzando después de la prueba
• Habrá descuentos / códigos de cupones para obtener un porcentaje del precio normal durante un año en los planes, etc.
• El precio del plan cambiará a medida que se agreguen características

Los obstáculos específicos que puedo prever serán cosas que incluyen lo siguiente:

• Cómo manejar la degradación cuando violan los límites del plan para los planes de nivel inferior.
• Comportamiento cuando las tarjetas de crédito caducan o los pagos no se realizan (quizás se aplique un modo de solo lectura)
• Cuando los cambios en los precios del plan, queremos respetar los precios anteriores para los usuarios existentes por un período de tiempo (como 6 meses), luego comenzar a cobrar tarifas más altas. Si el precio del plan disminuye, surtirá efecto de inmediato.

Otro consejo que sería útil sería cualquier cosa relacionada con el flujo de la aplicación. ¿Cómo se deben presentar los formularios de facturación al usuario? ¿Cuándo se debe solicitar la información de la tarjeta de crédito? ¿Cómo se deben enviar, almacenar y acceder a las facturas?

Debo revelar que planeamos basar gran parte de la base de código en SaaSy . SaaSy está diseñado para usarse como una aplicación Rails separada que maneja todos los aspectos de registro y administración de cuentas. Sin embargo, esto no funciona para nosotros, ya que nunca lo planeamos desde el principio y sería un proceso tedioso adaptar nuestra aplicación para que funcione así. En consecuencia, sacaremos código e ideas de SaaSy y las fusionaremos en nuestra aplicación, una tarea considerablemente menos tediosa.

Answer 1

RailsKits tiene un Kit de software como servicio que debe hacer lo que necesita. Tiene soporte incorporado para pruebas gratuitas, actualizaciones, degradaciones, límites de planes, etc., y es compatible con PaymentExpress (y algunos otros).

Lo he investigado un poco para un proyecto que estoy haciendo, pero aún no lo he comprado, así que no puedo garantizarlo. Sin embargo, he visto algunas publicaciones de blog alabando este kit.

Si bien RailsKit es relativamente económico en comparación con lo que le costaría implementar todas sus funciones usted mismo, hay un par de versiones de código abierto que tienen como objetivo lograr lo mismo. El que recuerdo fuera de mi cabeza se llama Freemium .

EDITAR: Olvidé mencionar que Ryan Bates dijo en su el Railscast más reciente que su próximo episodio o dos tratará con la facturación recurrente, así que esté atento a eso. Por lo general, hace un episodio por semana, y los cinco que ha hecho desde el 22 de diciembre cubren pagos de manejo de diferentes tipos.

Answer 2

Una cosa que quería agregar: tenga en cuenta que no necesita usar la función de facturación recurrente integrada en la puerta de enlace. En general, estos sistemas son heredados y muy difíciles de manejar, nos miman en el mundo de los rieles.

Obtiene mucha más flexibilidad con solo usarlos para un propósito (facturar una tarjeta de crédito y quizás también almacenar tarjetas de crédito para el cumplimiento de PCI). Luego, transfiera su propia facturación recurrente en su aplicación de rieles con un trabajo cron, un campo de fecha para cuando se les paga y la cantidad que paga cada persona (en caso de que usen un cupón), etc.

Un pequeño ejemplo: a veces las personas cancelan una suscripción mensual a mediados de mes. Quieren asegurarse de no olvidar cancelar antes del próximo pago. La mayoría de las facturas recurrentes de pasarela que he visto cerrarán instantáneamente la cuenta (o le enviarán un mensaje indicándolo). En realidad, el usuario ha pagado hasta fin de mes y debería tener 2 semanas más de acceso. Puede hacerlo si ha incluido su propia facturación recurrente en rieles, pero no si está utilizando la facturación recurrente de la pasarela. Solo un pequeño ejemplo.

Answer 3

Peepcode tiene un PDF a la venta (70 páginas) que detalla varios aspectos del procesamiento de pagos y las prácticas de la industria para esto. Puede valer la pena echarle un vistazo:

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

Answer 4

También estoy a punto de configurar un sitio web basado en suscripción y estos son nuestros requisitos actuales. Pueden ayudarlo con respecto a las mejores prácticas:

• Los usuarios podrán elegir uno de los planes de suscripción.
• Los usuarios deberán ingresar su detalles de la tarjeta de crédito para inscribirse su plan elegido.
• Todas las principales tarjetas de crédito y débito deben ser aceptado incluyendo Maestro y American Express.
• Cada plan tendrá 30 días gratis prueba para que las tarjetas de crédito de los usuarios solo se cobrará después de los 30 días el período expira Sin embargo, la validez de las tarjetas de crédito deben verificarse en la hora de registrarse.
• Los usuarios recibirán un correo electrónico unos días antes de que se cargue su tarjeta de crédito para notificarles que serán cobrado pronto a menos que cancelen su cuenta. Si cancelan su cuenta dentro de su prueba gratuita de 30 días, su la tarjeta de crédito no debe ser cargada.
• Después de cualquier período de prueba gratuito, los usuarios se le cobrará por adelantado por su uso del sistema, es decir, lo harán prepago.
• Se cobrará a los usuarios automáticamente cada mes para su plan elegido. Cada mes, los usuarios recibirán un correo electrónico con unos días de anticipación para notificar ellos que serán acusados. Una vez se ha realizado el pago, los usuarios serán envió por correo electrónico una factura que muestra que su se ha recibido el pago.
• Los usuarios podrán actualizar o rebajar sus cuentas en cualquier momento. Cuando los usuarios actualizan / degradan, sus el próximo cargo de suscripción será a las La nueva tarifa. Los usuarios solo podrán rebajar sus cuentas a un plan que pueden manejar sus datos. por ejemplo, si actualmente tienen 10 proyectos activos que no pueden degradar al plan básico porque el básico El plan solo permite 5 proyectos. Ellos tendrá que borrar o archivar 5 proyectos antes de que puedan degradar a Básico.
• Los usuarios podrán iniciar sesión en su cuenta y cambiar o actualizar su detalles de la tarjeta de crédito.
• Los usuarios podrán cancelar su cuenta en cualquier momento. No habrá cargos adicionales de suscripción después de un El usuario ha cancelado su cuenta. Sin embargo, los usuarios no serán reembolsados durante parte del mes tienen ya pagado.
• Todas las partes del sistema de pago deben ser 100% compatible con PCI DSS; incluso cualquier sistema de terceros.
• El sistema de pago debe soportar notificación automatizada y reintento de renovaciones de suscripción fallidas.
• El sistema de pago debe soportar cupones de descuento con fechas de vencimiento.
• Los datos de la tarjeta de crédito no deben ser procesado o almacenado en nuestros servidores
• siempre deben ser procesados ??/ almacenados por nuestro tercero socio de procesamiento de pagos. Nosotros no querer la responsabilidad de asegurar estos detalles y cumplir con normas y reglamentos legales.
• Los usuarios podrán iniciar sesión en su cuentas y ver una facturación completa historial incluyendo fechas y cantidades pagado. También necesitaremos ser capaz de iniciar sesión en un sistema para ver planes de pago del cliente y pago historia. Esto será esencial para servicio al cliente.

También hemos estado mirando http://chargify.com/ que parece que podría salvar un mucho tiempo de codificación.