Cambios FISERV · 11 y 12 de noviembre de 2026

Resumen

Cambios

Antes

Con MODELO=FISERV, UltraHost solo aceptaba identificación de compra, compra y sincronización de pinpad. Cualquier otra operación respondía Operacion no implementada para modelo FISERV.

Consultas

Anulación de compra

• Control de tarjeta: la tarjeta leída debe coincidir con la de la compra original en emisor y últimos 4 dígitos, como en POSDINO (pos_cara.cpp:361-370). Si no coincide, error 241. Si la compra original no tiene guardados los últimos 4, no se controla.
• Manda la autorización: una anulación que FISERV aprueba queda aprobada, responda lo que responda el chip al Y03. No se reversa.
• Importe: debe ser el total de la compra original. No se aceptan anulaciones parciales ni un cashback distinto.
• Sin Y07: en el manual FISERV, Y07 es "mostrar mensaje y leer tecla", no un advice.

Robustez

• Identificación pendiente: la lectura se graba con iNroMensaje=124 y pasa a 120 recién cuando la lectura se completa. Una identificación incompleta o fallida nunca habilita una anulación (error 270). Las filas de error de la identificación también se graban con 124.
• Borrado de identificaciones previas: ocurre recién después del control de tarjeta, y si falla corta con error 137.
• Host caído: el POS recibe 28, el chip recibe Y03 con CRE 02, ORH 0 y RCP N, y la reversa sale cuando el host vuelve.
• Sincro dentro de la anulación: si falla, el POS sigue recibiendo el idtrxtipre de la compra original.
• Log: dice si falló el control de emisor o el de últimos 4 dígitos, sin mostrar dígitos.
• Compra por chip sin respuesta del autorizador: el Y03 lleva RCP N, alineado con POSDINO (pos_ppfd.cpp:4267).

Reutilización de PRISMA

La lógica sin pinpad de PRISMA se extrajo a funciones que ahora usan los dos modelos: ValidarOriginalAnulacion, AutorizarAnulacionCompra, ArmarRespuestaAnulacionAprobada, ConsultaOperacion_SinPinPad y ConsultaUltOps_SinPinPad. FISERV agrega solo lo que depende del pinpad. Una revisión estática línea por línea confirmó que PRISMA hace exactamente lo mismo que antes.

Formato de los requests

Es el mismo JSON que manda el POS a APIDRIVER. Las respuestas del pinpad (datosPinPad) las agrega APIDRIVER, no el POS.

Consulta de operación

{
  "datosPos":  { "sucursal": 101, "nroPos": 1, "nroTicket": 9999 },
  "datosHost": { "idtrxtipre": 4321 }
}

Últimas operaciones

{ "datosPos": { "sucursal": 101, "nroPos": 1 } }

Anulación (los dos pasos, con el mismo ticket de la anulación)

{
  "datosPos":  { "sucursal": 101, "nroPos": 1, "nroTicket": 5001,
                 "importe": "100.00", "importe_cashback": "0.00", "documento": "12345678" },
  "datosHost": { "idtrxtipre": 4321 }
}

En el paso 1, idtrxtipre es el de la compra a anular. En el paso 2 se manda el que devolvió la identificación.

Pruebas

Simulación local, sin QA ni pinpad real: UltraHost en consola contra la base local UltraHost_Homologaciones, el simulador de autorizador FirstData en 127.0.0.1:28200 y un script Python que hace de APIDRIVER y de pinpad con datos de tarjeta sintéticos. Está en C:\Work\AI\FISERV\sim_fiserv\.

Revisiones

Pendientes

• Pinpad real en QA: sobre todo una anulación por chip.
• Límite de intentos de identificación: decisión de negocio. Hoy quien conozca un idtrxtipre puede probar finales de tarjeta sin límite.
• Doble anulación simultánea: se bloquea en las pruebas (6 rondas), pero no está demostrado que el bloqueo sea atómico.
• V04 con pinpad real: ver el Anexo B.
• Mensajes de Y0E: hoy dicen solo el número. Ver el Anexo A.
• Código 124: la marca de pendiente reutiliza el número de posOp_PERMITEEXTRACCION. Se aceptó así.

Anexo A · Errores que recibe el POS

Todos llegan en datosHost.codigo_resultado y mensaje_resultado. Ante cualquier código distinto de 0, APIDRIVER manda Y06 para liberar el pinpad.

A.1 · El pinpad responde Y0E

Código al POS = 1000 + código del pinpad. Mensaje: ERROR EN PINPAD (NN). El código extendido (CEX) solo va al log.

A.2 · Errores que genera APIDRIVER (YEE)

Código 99, con el texto que manda APIDRIVER:

A.3 · Otras respuestas del pinpad

A.4 · Anulación

Respuestas al Y03 que no son error: después de que FISERV aprobó, cualquier respuesta (Z3, Y0E, YEE, Y06 o vacía) deja la operación aprobada. Si el host rechazó, el POS recibe el código del host y no el del pinpad.

A.5 · Errores propios de APIDRIVER

Anexo B · Bloque de claves del Y02 en V04

La tabla de campos del manual es igual en V02 y V04: PMK(1) LWK(1) WKP(1..48) <FS> WKD(1..48) <FS>.

• Especificación: los dos son válidos según la tabla. El código se aparta del ejemplo, no de la especificación, y varios ejemplos del manual están mal armados (les falta WKD y el segundo <FS>).
• V02: este formato ya funciona con el pinpad real (compras por chip en QA).
• V04: nunca se probó con el pinpad real. Si el Y02 responde Y0E, el ajuste a NN cuando no hay claves es de una línea en ComandoY02.