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

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 clienteSupermercados DINO · Córdoba

Medio de pagoDINI (Negocios y Gift Card)

IntegraciónGatewayQR de Tipre

Respuesta objetivomenos de 20 ms (p99)

El problema

Hoy un descuento por billetera QR implica tocar código en el POS y coordinar con la billetera cada vez que Marketing cambia la 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. Nunca se acumulan.

Qué incluye

API de resolución para el GatewayQR, autenticada por API key, con auditoría de cada consulta y su respuesta.
Consola web con 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.

Stack y arquitectura

Backend: Java 21 y Spring Boot 4, base SQL Server 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 18 con Vite y TypeScript, componentes shadcn sobre Tailwind, modo claro y oscuro, instalable como PWA.

Velocidad por diseño: la configuración activa vive en memoria y se recarga al guardar. La ruta caliente no consulta la base. La auditoría se escribe fuera del camino de respuesta, con virtual threads y cola acotada, así una base lenta nunca frena un cobro.

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.

BeneficiosCenter Flujo de un pago y contrato de la API

El flujo de punta a punta

Seis mensajes. BeneficiosCenter participa solo en el segundo y el tercero, y el GatewayQR sigue adelante aunque no responda.

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

Simulación: lo que manda el GatewayQR

POST /api/v1/beneficios/resolverX-Api-Key: •••• · Content-Type: application/json

{
  "requestId": "GW-20260903-000123",
  "transaction": { "datetime": "2026-09-03T18:42:10-03:00", "amount": 100000.00, "currency": "ARS" },
  "merchant":    { "branchId": "SUC-014", "posId": 7, "salesPointId": 3 },
  "invoice":     { "type": "B", "taxIdKind": "CUIL", "taxId": "27123456784", "extraCustomerTypeId": null }
}

Simulación: lo que responde BeneficiosCenter

200 OK · jueves 18:42, sucursal 14, ticket de $100.000, factura BelapsedMs: 4

{
  "requestId": "GW-20260903-000123",
  "evaluatedAt": "2026-09-03T18:42:10.084-03:00",
  "benefits": [
    { "customerTypeCode": "DINI_NEGOCIOS", "paymentMethodId": "990", "percentage": 10.0,
      "benefitId": 41, "description": "Jueves Dini Negocios 10%", "maxDiscountAmount": 15000.00 },
    { "customerTypeCode": "DINI_GIFTCARD", "paymentMethodId": "991", "percentage": 5.0,
      "benefitId": 37, "description": "Gift Card 5% todo septiembre", "maxDiscountAmount": null }
  ],
  "elapsedMs": 4
}

Sin beneficios aplicables la lista vuelve vacía con 200. Un 401 indica API key inválida; un 400 detalla el campo que falló. El GatewayQR fija un timeout corto y, si vence, continúa sin beneficios: el cobro nunca depende de nosotros.

BeneficiosCenter Consola de gestión y casos de uso

Cómo se ve la consola

Misma familia visual que el gestor del Sistema de Premios: barra lateral fija, tablas limpias, un solo color de acento que toma la marca del cliente. Para DINO la consola arranca con el lima de DINI.

Consultas hoy12.480

Con beneficio38 %

p99 respuesta6 ms

Beneficios

Nuevo beneficio

Estado	Nombre	%	Tipos de cliente	Vigencia	Franja	Sucursales	Mín.	Prio.
Activo	Jueves Dini Negocios 10%	10	Negocios	01/09 – 30/09	Jue 00–24	Todas	$ 20.000	10
Activo	Gift Card 5% todo septiembre	5	Gift Card	01/09 – 30/09	Todos los días	Todas	—	50
Programado	Aniversario 15% Córdoba centro	15	Negocios, Gift Card	10/10 – 12/10	09–21	SUC-001, 014, 022	$ 50.000	1
Inactivo	Agosto Negocios 8%	8	Negocios	01/08 – 31/08	Todos los días	Todas	$ 15.000	20

El Operador ve la misma consola con las acciones ocultas y la sección Auditoría como pantalla principal: cada consulta con su request, su respuesta, los beneficios evaluados y por qué cada uno aplicó o no.

Casos de uso

Id	Situación	Resultado esperado
CU-01	Mismo porcentaje para Negocios y Gift Card.	Dos entradas en la lista, ambas con el mismo porcentaje.
CU-02	Porcentaje distinto por tipo de cuenta.	Dos entradas, cada una con su porcentaje.
CU-03	Beneficio solo para Dini Negocios.	Una entrada, código 990. Gift Card no aparece.
CU-04	Beneficio solo para Dini Gift Card.	Una entrada, código 991.
CU-05	Ticket por debajo del monto mínimo del beneficio.	Lista vacía. Se audita igual con el motivo.
CU-06	Consulta fuera de la franja horaria o del rango de fechas.	Lista vacía. Decide la fecha y hora que manda el gateway, en zona horaria de Córdoba.
CU-07	Beneficio restringido a ciertas sucursales.	Aplica solo si la sucursal del request está en la lista.
CU-08	Factura A excluida por configuración del beneficio.	Ese beneficio no entra; los demás siguen evaluándose.
CU-09	Dos beneficios vigentes coinciden en el mismo tipo de cliente.	Gana el de mayor prioridad; a igual prioridad, el porcentaje mayor. Nunca se suman.
CU-10	Tope de descuento configurado.	La respuesta incluye el tope para que el autorizador o el POS lo respeten.
CU-11	BeneficiosCenter caído o lento.	El GatewayQR agota el timeout y autoriza sin beneficios. Queda registrado del lado del gateway.
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, POS o request y ve la traza completa. No puede editar.
CU-14	Se incorpora un nuevo tipo de cuenta DINI.	Alta en el ABM con su payment_method_id. Sin cambios de código.

Puntos a cerrar antes de construir

Son decisiones que cambian el contrato y conviene fijarlas con DINI y con el equipo del gateway antes de escribir la primera línea.

En qué campo de la intención Prisma viajan los beneficios hacia el autorizador (payment_methods_data o benefits_methods_data). La minuta lo muestra en capturas que hay que revisar con el equipo.
El GatewayQR hoy no envía tipo de factura ni CUIT/CUIL del comprador. Es un cambio chico del gateway, pero es una dependencia.
Quién hace cumplir el tope de descuento: el autorizador, el POS o ambos.
Política de retención de la auditoría y si se exporta a otro sistema.