ruby-on-rails ruby web-applications payment recurring-billing

ruby on rails - Facturación recurrente con Rails y ActiveMerchant: ¿Mejores prácticas, trampas, errores?



ruby-on-rails web-applications (4)

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 las tarifas de suscripción recurrentes para el servicio.

Estoy buscando asesoramiento sobre las mejores prácticas teniendo en cuenta nuestros requisitos (que se enumeran a continuación) y cualquier información adicional para peligros comunes o problemas específicos que debería estar dando una consideración especial. La pasarela de pago que utilizaremos es PaymentExpress ya que es una de las pocas pasarelas admitidas que tiene facturación recurrente y no tiene condiciones especiales para las compañías 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 pueden tener un efecto sobre cómo funciona la facturación:

  • Todos los usuarios obtienen una prueba de 30 días
  • Hay diferentes planes, incluido uno gratis
  • Los planes de mayor precio tienen límites más grandes sobre 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 de un año en planes, etc.
  • El precio del plan cambiará a medida que se agreguen características

Los obstáculos específicos que puedo prever serán los siguientes:

  • Cómo gestionar la degradación cuando infringen los límites del plan para planes de nivel inferior.
  • Comportamiento cuando caducan las tarjetas de crédito o no se realizan los pagos (puede que se aplique un modo de solo lectura)
  • Cuando los precios del plan cambian, queremos respetar los precios anteriores para los usuarios existentes durante un período de tiempo (como 6 meses) y luego comenzar a cobrar tarifas más altas. Si el precio del plan disminuye, tendrá efecto inmediatamente.

Otro consejo que sería útil sería cualquier cosa con respecto al flujo de la aplicación. ¿Cómo deben presentarse 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 ser utilizado como una aplicación independiente de Rails que maneja todo el lado de la administración de cuentas y registros. Sin embargo, esto no nos funciona, ya que nunca planeamos esto desde el principio y sería un proceso tedioso adaptar nuestra aplicación a un trabajo así. En consecuencia, vamos a extraer código e ideas de SaaSy y fusionarlas en nuestra aplicación, una tarea considerablemente menos tediosa.

RailsKits tiene un kit de Software como servicio que debe hacer lo que necesita. Tiene soporte integrado para pruebas gratuitas, actualización, degradación, 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 todavía no lo he comprado, así que no puedo responderlo. Sin embargo, he visto algunas publicaciones en el blog elogiando este kit.

Si bien el RailsKit es relativamente económico cuando se compara con lo que le costaría implementar todas sus características, hay un par de versiones de código abierto que tienen el objetivo de lograr lo mismo. El que recuerdo de la parte superior de mi cabeza se llama Freemium .

EDITAR: Me olvidé de mencionar que Ryan Bates dijo en su Railscast más reciente que su próximo episodio o dos se ocuparán de 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 el manejo de pagos de diferentes tipos.

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

Obtiene mucha más flexibilidad solo utilizándolos para un propósito (facturar una tarjeta de crédito, y quizás también almacenar tarjetas de crédito para cumplir con PCI). Luego, imprima su propia factura recurrente en su aplicación de rieles con un trabajo de cron, un campo de fecha para el momento en que se pagan, y el monto que cada persona está pagando (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 que no se olviden de cancelar antes del próximo pago. La mayoría de la facturación periódica de puerta de enlace que he visto cancelará instantáneamente la cuenta (o le enviará un mensaje indicándoselo). En realidad, el usuario ha pagado hasta el final del mes y se le deben dar 2 semanas más de acceso. Puede hacer esto si ha transferido su propia factura recurrente en rieles, pero no si está utilizando la facturación recurrente de la puerta de enlace. Solo un pequeño ejemplo.

También estoy en el medio de configurar un sitio web basado en suscripción y estos son nuestros requisitos actuales. Ellos pueden ayudarlo con respecto a la mejor práctica:

  • Los usuarios podrán elegir uno de los planes de suscripción.
  • Los usuarios deberán ingresar los detalles de su tarjeta de crédito para inscribirse en su plan elegido.
  • Deben aceptarse todas las principales tarjetas de crédito y débito, incluyendo Maestro y American Express.
  • Cada plan tendrá una prueba gratuita de 30 días, por lo que las tarjetas de crédito de los usuarios solo se deberán cobrar después de que expire el período de 30 días. Sin embargo, la validez de las tarjetas de crédito debe verificarse al momento 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 se les cobrará pronto a menos que cancelen su cuenta. Si cancelan su cuenta dentro de su período de prueba de 30 días, no se le deberá cobrar a su tarjeta de crédito.
  • Después de un período de prueba gratuito, los usuarios deberán pagar por adelantado el uso del sistema, es decir, pagarán por adelantado.
  • A los usuarios se les cobrará automáticamente todos los meses por su plan elegido. Cada mes, los usuarios recibirán un correo electrónico con unos días de anticipación para notificarles que se les cobrará. Una vez que se haya realizado el pago, a los usuarios se les enviará por correo electrónico una factura que muestre que se ha recibido su pago.
  • Los usuarios podrán actualizar o degradar sus cuentas en cualquier momento. Cuando los usuarios actualizan / degradan, su próximo cargo de suscripción será a la nueva tarifa. Los usuarios solo podrán degradar sus cuentas a un plan que pueda manejar sus datos. Por ejemplo, si actualmente tienen 10 proyectos activos, no pueden degradar al plan Básico porque el plan Básico solo permite 5 proyectos. Tendrán que eliminar o archivar 5 proyectos antes de que puedan degradar a Basic.
  • Los usuarios podrán iniciar sesión en su cuenta y cambiar o actualizar sus datos de tarjeta de crédito.
  • Los usuarios podrán cancelar su cuenta en cualquier momento. No habrá más cargos de suscripción después de que un usuario haya cancelado su cuenta. Sin embargo, los usuarios no recibirán reembolso durante parte del mes que ya hayan pagado.
  • Todas las partes del sistema de pago deben ser 100% PCI DSS; incluyendo cualquier sistema de terceros.
  • El sistema de pago debe admitir notificaciones automáticas y reintentar las renovaciones de suscripción fallidas.
  • El sistema de pago debe admitir cupones de descuento con fechas de caducidad.
  • Los datos de la tarjeta de crédito no deben ser procesados ​​ni almacenados en nuestros servidores
  • siempre deben ser procesados ​​/ almacenados por nuestro socio de procesamiento de pagos de terceros. No queremos responsabilidad para asegurar estos detalles y cumplir con las normas y regulaciones legales.
  • Los usuarios podrán iniciar sesión en sus cuentas y ver un historial de facturación completo, incluidas las fechas y los montos pagados. También necesitaremos poder iniciar sesión en un sistema para ver los planes de pago de los clientes y el historial de pagos. Esto será esencial para el servicio al cliente.

También hemos estado buscando en http://chargify.com/, que parece que podría ahorrar mucho tiempo de codificación.