Arquitectura técnica de Lightning PoS
Componentes, límites y flujo de datos de un punto de venta Lightning con confirmación resiliente.
El problema
Un checkout Lightning cruza varios límites: interfaz, precio externo, proveedor Lightning y eventos asíncronos. Si cada capa interpreta el estado por su cuenta, aparecen dobles registros y pantallas que nunca terminan.
Implementación
El cliente PWA administra catálogo y carrito. El servicio de checkout fija el total en MXN, obtiene una cotización y solicita una invoice a LNbits. La venta guarda un identificador propio y el hash de pago para correlacionar señales.
PWA ── checkout ──> API ── invoice ──> LNbits
│ │ │
└── estado <─────────┴── webhook/WS ───┘La confirmación aplica una transición idempotente. WebSocket mejora la inmediatez; webhook entrega una señal servidor a servidor y polling recupera el estado cuando las conexiones persistentes fallan.
Validación
Las pruebas repiten eventos, cortan WebSocket y consultan la invoice desde dos clientes. El resultado esperado es una venta pagada, un registro y una única actualización visible.
Conclusión
La resiliencia no proviene de elegir un canal perfecto, sino de permitir señales redundantes sobre una transición de estado segura.