Arquitectura del monedero y conciliación de lotería: checklist para operadores
El monedero de lotería es más que el saldo que ve el jugador. Al elegir una plataforma, hay que evaluar el registro de transacciones que explica ese saldo, la liquidación de compras y premios y cómo finanzas detecta diferencias entre sistemas. Esta checklist se centra en esos límites operativos. Elegir un proveedor de pagos es […]
El monedero de lotería es más que el saldo que ve el jugador. Al elegir una plataforma, hay que evaluar el registro de transacciones que explica ese saldo, la liquidación de compras y premios y cómo finanzas detecta diferencias entre sistemas.
Esta checklist se centra en esos límites operativos. Elegir un proveedor de pagos es una decisión distinta: consulta la guía de arquitectura de pagos de lotería para comparar métodos, procesadores y acuerdos comerciales. Aquí la pregunta es si cada movimiento puede explicarse y conciliarse.
Define qué significa cada saldo
Solicita un diccionario de saldos antes de revisar pantallas. Distingue efectivo disponible, fondos reservados, saldos promocionales y retiradas pendientes. Especifica la moneda de cada importe, la política de conversión cuando corresponda y el sistema que constituye la fuente de referencia de cada estado.
- ¿Puede soporte explicar por qué el saldo disponible difiere del saldo del registro contable?
- ¿Qué acciones reservan, liberan, cargan o abonan fondos y quién puede iniciarlas?
- ¿La exportación incluye saldo inicial, movimientos y saldo final con referencias estables?
Mapea el ciclo del boleto y su liquidación
Define el comportamiento esperado antes de aprobar una integración. Una notificación de pago, un boleto aceptado y el resultado final del sorteo son eventos distintos: especifica cómo se relacionan.
| Evento | Pregunta de aceptación |
|---|---|
| Compra aceptada | ¿Existe un vínculo trazable entre el boleto, el cargo y su estado final? |
| Compra rechazada | ¿Se liberan los fondos reservados sin emitir un boleto válido para jugar? |
| Cancelación o reembolso | ¿La reversión está vinculada al asiento original y a un motivo autorizado? |
| Liquidación del premio | ¿Puede rastrearse cada abono hasta el sorteo, boleto y versión de liquidación? |
Acuerda el tratamiento de reintentos y excepciones
HTTP no hace seguro cualquier reintento: RFC 9110 distingue los métodos idempotentes. Acuerda el tratamiento de duplicados en compras, pagos y notificaciones a nivel de aplicación; no lo deduzcas de una respuesta API satisfactoria.
- Repite la misma referencia de compra y comprueba que no genera un segundo cargo o boleto no deseado.
- Interrumpe la respuesta tras el envío y demuestra cómo se recupera el estado final de la operación.
- Define cómo tratar notificaciones tardías, duplicadas o desordenadas y cómo escalar si falla la recuperación automática.
Diseña la conciliación para finanzas, no solo para desarrollo
Para un registro de efectivo y una moneda, concilia saldo inicial más abonos contabilizados menos cargos contabilizados con el saldo final. Define todas las categorías de asientos y el corte del informe: esta comprobación por sí sola no concilia al proveedor de pagos ni al banco.
Compara por separado los registros de la plataforma con las liquidaciones del procesador y los registros bancarios pertinentes. Documenta comisiones, reembolsos, contracargos, diferencias de moneda y desfases temporales. Cada excepción necesita responsable, evidencia, estado e historial de resolución. La guía de integración API de lotería ayuda a definir los datos intercambiados entre sistemas.
Controla los ajustes y protege el historial de auditoría
Establece reglas de aprobación para ajustes manuales, reembolsos y acceso a exportaciones. Exige actor, momento, motivo e identificadores vinculados de transacción para cada cambio. OWASP recomienda excluir o proteger credenciales y datos sensibles de pago en los registros.
Incluye acceso a exportaciones y respuesta a incidentes en la revisión de seguridad y SLA. Si sustituyes una plataforma, acuerda cómo demostrar saldos iniciales y boletos pendientes durante la migración de plataforma, en vez de reconstruirlos después del lanzamiento.
Utiliza cuatro casos de aceptación en la demo
Solicita el historial de eventos, los asientos y la exportación financiera de cada caso. Evalúa el flujo completo, no una captura del saldo final. Documenta los casos no soportados y el trabajo necesario antes de firmar.
- Una compra normal seguida del resultado del sorteo y una liquidación trazable con premio o sin él.
- Una compra rechazada seguida de liberación de la reserva, sin cargo duplicado tras el reintento.
- Una cancelación o reembolso con referencia original, actor autorizado y exportación coherente.
- Una diferencia de conciliación deliberada en un entorno de prueba, asignada a un responsable y resuelta con evidencia.
Incluye los límites operativos en el alcance
Compara los módulos de plataforma y el alcance de entrega con las responsabilidades de registro contable, procesador y finanzas que necesitas. Especifica quién configura reglas, supervisa excepciones, aprueba cambios y entrega exportaciones. Incluye estos entregables en el plan de implantación; la conciliación no es una tarea para después del lanzamiento.
Referencias técnicas
- RFC 9110: semántica HTTP y métodos idempotentes (en inglés)
- OWASP: guía de registros de actividad (en inglés)
Analiza tus requisitos de monedero y conciliación
Prepara tu flujo de pagos, monedas, responsabilidad del registro contable y requisitos actuales de informes. WhiteLotto puede analizar el alcance de plataforma y las cuestiones de integración de tu proyecto.