Blog · 2026-08-30

Automatizar check-in, pagos y sorteos: diseño de sistema de un bot de membresías en LINE

Desde la vinculación de identidad en LINE, la clave única que evita duplicados y el acreditado idempotente de pagos, hasta el trío obligatorio en la nube: arranque automático con systemd, alertas externas y respaldo cada 6 horas. Así se desarma la arquitectura de un bot de membresías que no necesita a nadie de guardia.

Lo que más personal consume en la operación de membresías son las acciones repetidas: validar el check-in cada día, entregar premios contra una lista, confirmar que el pago llegó y después avisar uno por uno por mensaje privado. Hecho a mano es lento y se escapan casos, y cuando la campaña crece el equipo de atención queda sepultado. Todo ese flujo se le puede entregar a un bot de LINE para que corra solo, con una condición: hay que resolver antes algunas decisiones de diseño, porque si no la automatización solo acelera los errores.

Vinculación: la identidad de LINE y la cuenta de socio son dos sistemas, primero la tabla de correspondencia

Lo que te entrega una LINE Official Account es un identificador de usuario emitido por la plataforma, y tu sistema de socios tiene otro esquema de cuentas. Los dos no coinciden por naturaleza. El primer paso de cualquier automatización es construir la tabla de vinculación entre identificador de LINE y cuenta de socio, y construirla estricta:

• La vinculación tiene que verificar titularidad. No basta con que el socio escriba un número de cuenta en el chat: hace falta un código de un solo uso o una aprobación desde el panel. Si no, cualquiera puede amarrar la cuenta de otro a su propio LINE.
• La unicidad se garantiza con restricciones en la base de datos: una identidad de LINE solo puede vincularse a una cuenta de socio, y una cuenta de socio solo puede vincularse una vez. Sin esas dos restricciones, tarde o temprano aparece alguien con varias vinculaciones cobrando premios repetidos, o alguien que se adelanta a vincular una cuenta ajena.
• Desvincular y revincular siempre se escribe en el historial de cambios. Cuando hay una disputa, ese historial es la única evidencia que permite aclarar lo que pasó.

Con la vinculación firme, el check-in, los sorteos, los pagos y los envíos quedan todos colgados de la misma identidad de socio, y recién ahí la automatización tiene cimiento.

Check-in y sorteos: elige bien la clave que evita duplicados, y deja que la base de datos bloquee

El error más común al prevenir duplicados es elegir la clave al nivel equivocado. Si quieres impedir "el mismo socio hace check-in dos veces el mismo día", la clave única es socio más fecha. Si quieres impedir "el mismo socio participa dos veces en el mismo sorteo", la clave es socio más campaña. Cuando la clave no está alineada con lo que de verdad quieres bloquear, las pruebas funcionales salen todas en verde y aun así se escapan casos.

Tres puntos de implementación:

• El bloqueo va en un índice único de la base de datos, no en un if dentro del código. Con doble clic, reenvíos de red o dos peticiones que entran al mismo tiempo, la lógica del programa puede dejar pasar ambas; el índice único no. Cuando choca la clave, responde "ya hiciste check-in hoy", que para el usuario es una respuesta normal y no un error.
• Hay que definir con precisión la zona horaria de "un día". Si la hora del servidor está a varias horas de diferencia de la del mercado local, alrededor de la medianoche siempre habrá gente que hace un check-in de más o de menos.
• La protección contra fraude tiene que ser en capas, y hay que asumir que alguien va a intentar inflar los números. Hicimos una página de registro con sorteo donde montamos cinco capas: límite por IP, lista negra, clave única por teléfono y correo, hash de huella de dispositivo y verificación humana. Después hicimos una limpieza multidimensional y de 142 registros auditamos alrededor de 118 reales; el resto eran datos de prueba, números inventados, cargas masivas desde el mismo segmento de red y autoinvitaciones. El frontend detiene los errores de dedo, no a quien viene con intención, así que la lista tiene que poder auditarse después.

Pago automático acreditado: la idempotencia importa más que la velocidad, y el envío va después del acreditado

En escenarios como iGaming, el pago consiste en acreditar directamente el premio o el reembolso en la billetera de juego del socio. El corazón del pago totalmente automático es que el backend del bot llame a la interfaz de acreditación del sistema de socios, y que cada operación lleve un número de referencia único: si se reenvía la misma referencia, el sistema devuelve el mismo resultado y no acredita una segunda vez. Eso es la idempotencia, y es la condición que permite reintentar un pago automático sin miedo.

• Lo más peligroso no es el fallo, es la incertidumbre. Si la petición de acreditado expira por tiempo, el dinero pudo haber entrado o no. Esa operación no se puede reintentar a ciegas ni marcar como fallida sin más: primero consultas la orden, confirmas su estado y después decides. Si las rutas de falla están mal diseñadas, la automatización se convierte en una pérdida automática.
• El orden se fija duro: el acreditado se confirma exitoso, y recién entonces sale el aviso por LINE. Un aviso duplicado son un mensaje de más; un acreditado duplicado es una pérdida directa. Las estrategias de reintento de los dos lados tienen que estar separadas.
• Cada pago deja registro y hay una conciliación programada: los registros de pago del lado del bot y los de acreditado del sistema de socios se cruzan periódicamente, y si falta uno salta la alerta. Totalmente automático no significa que nadie mire, significa que solo hace falta mirar lo anómalo.
• Los envíos tienen costo y cuota, así que los avisos de acreditado y los mensajes de marketing se administran por separado, para que los mensajes de sistema no se coman toda la cuota.

El trío obligatorio en la nube: arranque, alertas y respaldo, sin uno no está en producción

Un bot así es un servicio permanente que recibe mensajes las 24 horas, y dejarlo corriendo en una computadora de la oficina es un punto único de falla. Nuestra práctica estándar es desplegarlo en un servidor en la nube con el trío completo:

1. Arranque automático y recuperación ante caídas: systemd con Restart=always y habilitado, para que el servicio se levante solo cuando el servidor reinicia y el proceso se relance solo cuando se cae. En otro sistema con el mismo esqueleto de despliegue medimos que, tras matar el proceso a la fuerza, systemd lo recuperó en unos 6 segundos.
2. Monitoreo y alertas externas: un proceso muerto no puede avisar que murió, así que la alerta no puede depender del propio servicio. Se necesita un chequeo de vida externo que notifique al teléfono apenas se caiga.
3. Respaldo automático de datos: la tabla de vinculación y los registros de check-in y de pagos son la vida de este sistema. Nosotros respaldamos la base de datos cada 6 horas a almacenamiento de objetos en la nube, en un dominio de falla distinto al del servidor, y conservamos varias copias para poder retroceder. Si el servidor explota, pierdes unas horas de datos, no todo.

Cierre

El check-in, la vinculación, los pagos y los sorteos, vistos función por función, no son difíciles. Lo difícil es diseñar de una vez todas las rutas de falla: duplicados, expiraciones, vinculaciones robadas, registros inflados y caídas. La calidad de un sistema totalmente automático la deciden sus rutas de falla. Si tu operación de membresías sigue atascada en validar listas a mano y pagar manualmente, o si quieres agregarle a un bot existente protección contra duplicados y redundancia, escríbenos y vemos qué eslabón conviene automatizar primero.

Esta arquitectura la convertimos en producto

Todo el diseño de sistema anterior ya está armado en nuestra plataforma de gestión inteligente LINE OA, así que no tienes que ocuparte tú del servidor, las firmas, la idempotencia ni los respaldos.

• Integración por API: conecta el bot con tu propio sistema de pedidos o de socios, incluida la tabla de vinculación de identidad
• Seguimiento de embudo de 8 etapas: cada contacto se clasifica solo, sin que escribas una máquina de estados
• Gestión de contactos CRM: perfil de usuario, rastro de comportamiento y etiquetas en un solo lugar
• Envío segmentado: eliges destinatarios por etapa y etiqueta, y el gasto en mensajes va a la gente correcta
• Respuestas automáticas por palabra clave: disparadores por palabra clave, por evento y por condición
• Agente de soporte con IA: base de conocimiento RAG más un LLM, que deriva a una persona cuando no puede responder

Tres niveles, cuota mensual en USDT, sin contrato de permanencia:

La cuenta oficial que va en tu plan queda registrada a tu nombre, no bajo el nuestro en administración delegada. Las especificaciones completas están en Plataforma de gestión inteligente LINE OA, y si necesitas un sistema desarrollado totalmente a medida, revisa Desarrollo de software de automatización. Si prefieres entender primero la arquitectura de una LINE Official Account, mira la guía completa de LINE Official Account.