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


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 prestar especial consideración. La pasarela de pago que usaremos es Payment Express ya que es una de las pocas puertas de enlace compatibles que tiene facturación recurrente y no tiene 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 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 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 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 deberían 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 una gran cantidad de la base de código 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.


32
2018-01-23 05:08


origen


Respuestas:


RailsKits tiene un Kit de software como servicio eso debería hacer lo que necesitas. 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.

EDIT: olvidé 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.


5
2018-01-23 16:51



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 saber cuándo 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.


8
2018-05-27 18:52



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

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


4
2018-02-06 04:04



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 su detalles de la tarjeta de crédito para suscribirse 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 le 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 el momento de registrarse.
  • Los usuarios recibirán un correo electrónico por unos días antes de que se cargue su tarjeta de crédito para notificarles que serán cargados pronto a menos que cancelen su cuenta. Si cancelan su cuenta dentro de su prueba gratuita de 30 días, su tarjeta de crédito no debe ser cargada
  • Después de cualquier período de prueba gratuito, los usuarios se cobrará por adelantado por su uso del sistema - es decir, lo harán pagar por adelantado.
  • Los usuarios serán cargados automáticamente todos los meses para su plan elegido. Cada mes, los usuarios recibirán un correo electrónico unos días antes para notificar ellos que se les cobrará. Una vez el pago se ha realizado, los usuarios serán enviado por correo electrónico una factura que muestra que su el pago ha sido recibido.
  • Los usuarios podrán actualizar o rebajar sus cuentas en cualquier momento. Cuando los usuarios actualizan / degradan, su el próximo cargo de suscripción será en la nueva tasa. Los usuarios solo podrán para degradar sus cuentas a un plan que puede 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 eliminar o archivar 5 proyectos antes que ustedes pueden rebaja 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á más cargos de suscripción después de una 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 ser compatible notificación automática y reintentos de renovaciones de suscripción fallidas.
  • El sistema de pago debe ser compatible vales de descuento con fechas de caducidad.
  • Los detalles 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 reglas y regulaciones legales.
  • Los usuarios podrán iniciar sesión en su cuentas y ver una facturación completa historial que incluye 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 ahorrar mucho tiempo de codificación.


3
2017-11-16 16:46