BeneficiosCenter¶

Beneficios por medio de pago, decididos en milisegundos y configurados sin programar.

Tipre presenta un servicio central que le dice al GatewayQR qué descuento corresponde a cada tipo de cuenta DINI, antes de autorizar el pago. Supermercados DINO lo configura desde una consola web; el POS no cambia su forma de cobrar.


Primer cliente	Supermercados DINO — Córdoba
Medio de pago	DINI (cuentas Negocios y Gift Card)
Integración	GatewayQR de Tipre
Respuesta objetivo	menos de 20 ms (p99)

El problema¶

Hoy, aplicar un descuento por billetera QR implica tocar código en el POS y coordinar con la billetera cada vez que Marketing cambia una campaña. No hay un lugar único donde ver qué beneficio se ofreció, a quién y cuándo.

La propuesta¶

BeneficiosCenter concentra las reglas: qué porcentaje, para qué tipo de cuenta DINI, en qué sucursales, en qué franja de fechas y horarios, y desde qué monto de ticket. El GatewayQR lo consulta en cada pago y adjunta el resultado a la intención que viaja al autorizador.

Regla de oro del contrato

La respuesta trae un solo porcentaje por tipo de cliente. Si dos beneficios compiten por la misma cuenta, gana el de mayor prioridad. Los beneficios nunca se acumulan.

Qué incluye¶

Pieza	Qué hace
API de resolución	Para el GatewayQR, autenticada por API key, con auditoría de cada consulta y su respuesta.
Consola web	Dos roles: Administrador configura; Operador consulta lo procesado sin poder modificar.
ABM de tipos de cliente	Cada uno atado al `payment_method_id` de DINI (990 Negocios, 991 Gift Card, y los que vengan).
ABM de beneficios	Porcentaje, vigencia, días y horarios, sucursales, monto mínimo, tope opcional, prioridad, tipos de cliente asociados.
Marca blanca	Logo, color y nombre del cliente se cargan por configuración, sin recompilar.

Qué no hace¶

No autoriza ni mueve dinero. Solo informa.
No decide por producto ni por línea del ticket: trabaja sobre el total.
No reemplaza las promociones propias del POS ni las de la billetera.

Cómo funciona¶

sequenceDiagram
    participant POS
    participant GW as GatewayQR
    participant BC as BeneficiosCenter
    participant AUT as Autorizador DINI

    POS->>GW: 1. Intención de pago (monto, fecha, sucursal, POS, factura, CUIT/CUIL)
    rect rgba(224, 248, 72, 0.15)
    Note over GW,BC: RUTA CALIENTE — objetivo < 20 ms
    GW->>BC: 2. POST /api/v1/beneficios/resolver
    BC-->>GW: 3. Lista: un porcentaje por tipo de cliente
    end
    GW->>AUT: 4. Intención Prisma con los beneficios adjuntos
    AUT-->>GW: 5. Autorización: cuenta usada (990/991), monto final y descontado
    GW-->>POS: 6. importe_final, importe_recdesc
    Note over GW: Si el paso 2 agota el timeout,<br/>el gateway sigue en 4 sin beneficios y lo registra.

El autorizador aplica el único porcentaje que coincide con la cuenta que efectivamente pagó. El POS recibe los mismos campos que ya interpreta hoy.

Por qué es confiable¶

Velocidad por diseño. La configuración activa vive en memoria y se recarga al guardar. La ruta caliente no consulta la base. Ver Arquitectura.
Auditoría de todo. Cada consulta —aplique o no un beneficio— queda registrada con su motivo de descarte, fuera del camino de respuesta, para no frenar nunca un cobro.
El gateway nunca depende de nosotros. Si BeneficiosCenter está lento o caído, el GatewayQR agota su timeout y autoriza sin beneficios (CU-11): un cobro frenado es peor que una oferta perdida.
Corre en la infraestructura del cliente. Jar único, SQL Server, sin dependencia de nube.

Stack y arquitectura¶

Backend: Java 21 y Spring Boot 4.1, base SQL Server 2022 con migraciones Flyway, un único jar desplegable con la consola embebida. Mismo pipeline de calidad que el Sistema de Premios: cobertura JaCoCo, análisis estático y CI en cada cambio.
Consola: React con Vite y TypeScript, componentes shadcn sobre Tailwind, modo claro y oscuro, instalable como PWA.
Método de trabajo: primero se fijan contrato, invariantes y criterios de aceptación medibles con DINO y el equipo del gateway; el código se construye con TDD estricto contra esos criterios.

El producto, hoy¶

No es una idea: es un sistema construido y operativo, con entrega 1 en producción desde el 2026-09-06, entrega 2 (tablero, marca blanca, retención de auditoría) cerrada el 2026-09-30, y entrega 3 (Q2) ya cerrada: el sistema ahora también sabe qué pasó con cada pago, no solo qué se ofreció — ver Resultados, no solo ofertas más abajo.

Login de la consola

Panel de beneficios del administrador

Casos de uso cubiertos¶

Id	Situación	Resultado esperado
CU-01	Mismo porcentaje para Negocios y Gift Card.	Dos entradas en la lista, ambas con ese porcentaje.
CU-05	Ticket por debajo del monto mínimo del beneficio.	Lista vacía; se audita igual con el motivo.
CU-09	Dos beneficios vigentes coinciden en el mismo tipo de cliente.	Gana el de mayor prioridad; nunca se suman.
CU-11	BeneficiosCenter caído o lento.	El GatewayQR agota el timeout y autoriza sin beneficios.
CU-12	El Administrador publica un cambio de configuración.	Rige en la próxima consulta, sin reinicio ni despliegue.
CU-13	El Operador busca qué se ofreció en un ticket.	Filtra por fecha, sucursal o request y ve la traza completa; no puede editar.

Ver la lista completa de criterios de aceptación en Matriz de aceptación.

Resultados, no solo ofertas¶

Hasta entrega 2, BeneficiosCenter sabía qué le ofreció a cada pago. Con entrega 3 (Q2), además sabe qué pasó: el GatewayQR le avisa, después de cada cobro, si el pago se aprobó o se rechazó, con qué cuenta pagó realmente el cliente y cuánto descuento se hizo efectivo. Esa llamada nunca puede frenar ni arriesgar el cobro —llega después de que el pago ya terminó—, así que el sistema la trata como estadística, no como parte del cobro.

Eso habilita una pregunta que antes no se podía responder desde la consola: de lo que se ofreció, ¿cuánto terminó aprobado? La nueva pantalla "Resultados de pago" contesta eso con una tasa de aprobación y el descuento efectivo total, junto al Tablero existente.

Puntos cerrados con DINI durante el desarrollo¶

Confirmación de que el autorizador acepta benefits_methods_data con los códigos de cuenta 990 y 991 (ver Contrato con el autorizador).
Retención de auditoría en 365 días en línea, con purga semanal y exportación CSV como archivo previo.
Marca blanca por configuración externa, sin rebuild, para reutilizar el mismo sistema en la próxima campaña o con otro cliente.

Cierre¶

Tipre provee el sistema completo y lo pone a funcionar sobre la infraestructura de cajas que el negocio ya tiene. Terminada una campaña, el sistema queda listo para la siguiente: mismo motor, nuevo branding, sin volver a empezar.