Recurring Billing Database Design

Question

Estoy escribiendo una aplicación que implicará la facturación recurrente de un importe fijo mensual (o semanal), y puede durar hasta que se cancele la suscripción. El cliente puede pagar varios períodos por adelantado. Puede cancelar la suscripción y luego regresar después de ciertos períodos impagos. Necesito el sistema para avisarme cuando un período está vencido.

Así que me estoy quemando mi cerebro sobre cómo diseñar la base de datos (tal vez no es un problema sino una base de datos de programación de uno),

Ha cualquiera llegado a este tipo de aplicaciones? ¿Qué enfoque se ha tomado?

Answer 1

Creo que se está complicando demasiado.

Crear un usuario tabla:

pk id_user 
nm_user 
fl_status (active, canceled, pendent, etc) 

crear una suscripción de tabla de un usuario a muchas suscripciones:

pk id_subscription 
fk id_user 
fl_type (maybe there are different subscriptions, with different prices) 
dt_in 
dt_out 

crea un pago mesa de una suscripción a muchos pagos:

pk id_payment 
fk id_subscription 
fl_type (card, payment order, something else) 
fl_status (generated, sent, confirmed, canceled because of subscription canceled, canceled because of something else, etc) 
dt_generated 
dt_sent 
dt_confirmed 
dt_canceled 
[I think you will need another fields to follow and confirm the payment, but it depends of your payment model) 

Ahora necesitará construir algunos robots que se ejecutarán todos los días en un momento específico.

Si obtiene todos los clientes activos y el último pago de cada uno sabrá si se debe generar un nuevo pago si el último pago confirmado se realizó más de x días en comparación con la fecha real (depende si es prepago, postpago, etc.). En caso afirmativo, generó una nueva orden de pago.

Un robot enviará un correo electrónico o algo con la orden (y luego la bandera como).

Otro robot confirmará el pago utilizando su modelo de pago.

Por supuesto, debe definir su modelo muy bien porque cada estado de usuario necesita un robot para mantener las cosas hasta que se cancela o se envía a un juez debido a la falta de pago. es mucho trabajo que hacer, pero no hay gran problema.

ps: si se trata de un sistema más complejo, la base de datos persistirá, usted tendrá toda la información que necesita, tiene un registro de cada orden, usted sabe lo que le sucedió a cada uno de ellos porque tienen fechas y estado. Puede estimar, mensualmente, cuántas fechas de vencimiento tendrá, cuántas pagará después de un día, después de dos, y así sucesivamente.

Answer 2

Creo que puede estar tratando de ser demasiado inteligente con el diseño y pensar demasiado. Si piensa en el problema comercial, cada intervalo de pago es efectivamente una factura. ¿Por qué no crear una tabla de facturas y dejar que una tarea programada inserte una factura a intervalos determinados según la periodicidad de cada cuenta y si está activa durante ese intervalo?

Al tener una fila de factura real, obtiene un InvoiceID al que puede hacer referencia cuando busca el pago de un cliente y rastrea el estado de pago individualmente para cada facturación.

A veces simple es lo mejor.