Informe técnico unificado

1. Conclusión ejecutiva

Dictamen técnico: no se encontró evidencia de una falla específica del software del POS 135 que provoque los pagos no aprobados. Cuando el pago existe, el POS 135 completa la operación con tiempos normales. En los casos analizados, el POS envió la solicitud, el Gateway la recibió y Mercado Pago aceptó la publicación de la orden QR; El Gateway continuó consultando a Mercado Pago durante casi tres minutos por cada intento y, aun así, nunca apareció un payment asociado.

La interpretación compatible con la evidencia es que el cliente no completó el pago, o que el ecosistema Mercado Pago/billetera no creó, vinculó o informó ese pago al autorizador. Desde los logs disponibles ambas situaciones producen el mismo resultado: payments=[], sin paymentid, pagador ni billetera de origen. Por eso no es posible distinguirlas de manera concluyente con la información actual.

Alcance de la trazabilidad disponible: el Gateway dejó evidencia suficiente de que consultó reiteradamente la merchant order durante aproximadamente tres minutos y que, dentro de esa ventana, no existía un pago asociado. Los logs analizados no permiten asegurar qué ocurrió después de cerrar esa ventana: un eventual pago tardío requeriría una conciliación posterior.

Aclaración importante: tampoco corresponde afirmar que Mercado Pago “rechazó” esos pagos. No hay un pago con rechazo financiero: hay una orden QR creada sin pago asociado. El estado local REFUND_DENEGADO / CANCELADO_NOEXISTE_EN_MP describe ese no-pago, aunque su nombre pueda inducir a error.

Sí existen aspectos de software para mejorar —principalmente la desalineación de timeouts, las consultas repetitivas y la forma de contabilizar los reintentos—, pero esos aspectos amplifican la demora y pueden distorsionar las métricas por intento; no explican ni demuestran la ausencia inicial del payment. Que cada nuevo intento tenga un idTrx diferente es correcto.

Tasa global julio97,61%107.310 pagos existentes / 109.938 cierres

Sucursal 807 julio95,50%Última de 28 sucursales

POS 135 julio94,72%718 aprobados / 40 no-pagos

Caso 24/07 POS13585,11%40 OK / 47 contextos MDEP

Fundamento estadístico: POS135 es el peor POS mensual entre los de volumen significativo, pero su diferencia contra POS133/134 no es estadísticamente concluyente (p=0,194). La anomalía más sólida es de sucursal807 completa frente al resto (p=0,00000030). Esto favorece investigar primero factores compartidos de sucursal, operatoria, clientela, conectividad o flujo de billeteras, no atribuir el problema al binario del POS135.

PROBADO

El Gateway recibe los POST.
Mercado Pago crea las órdenes QR: HTTP 204.
Los casos fallidos terminan con payments=[].
La búsqueda final devuelve results=[].

PROBABLE

Efecto compartido de sucursal.
Abandono o falla previa a crear el payment.
Timeouts y reintentos amplifican los registros.
Problemas de operatoria o conectividad del cliente.

NO DEMOSTRADO

Rechazo financiero de Mercado Pago.
Falla exclusiva del software POS135.
Incompatibilidad de una billetera específica.
Fraude intencional.

2. Flujo técnico observado

POSObtiene idTrx y envía pago

→

GatewayGuarda PAGO_ENVIADO

→

Mercado PagoPUT orden QR
HTTP 204

→

Merchant orderopened / payment_required
payments=[]

→

GatewayConsulta hasta 180 s

→

CancelaciónBusca external_reference
results=[]

→

Estado localREFUND_DENEGADO

Desajuste temporal: el Gateway mantiene postPayment() activo aproximadamente 180 segundos; el POS abandona la espera cerca de los 90 segundos y comienza consultas GET. Esto no crea el problema de pago inexistente, pero aumenta espera, consultas y reintentos.

Componente	Comportamiento	Impacto
Gateway	Loop de espera hasta 180.000 ms	POST largo y ocupación de thread HTTP
POS	Timeout aproximado de 90 s	Pasa a consultas de estado mientras el POST sigue activo
POS modificado	Reconoce REFUND_DENEGADO como terminal	Evita seguir consultando luego del no-pago
Reintento	Cada intento sucesivo utiliza correctamente un nuevo idTrx dentro del mismo contexto MDEP	No es una falla; exige separar métricas por intento técnico y por contexto comercial

3. Reconstrucción del caso testigo — $2.029

POS135, sucursal807, un único contexto MDEP ADD:PAGO QR contuvo tres intentos técnicos sucesivos, cada uno identificado correctamente con un idTrx diferente. El reloj POS estaba aproximadamente 53–58 segundos desplazado respecto del Gateway; las correlaciones se realizaron por idTrx, no por igualdad exacta de hora.

idTrx	POST Gateway	PUT QR	IPN merchant order	Consultas internas	Cierre
2025763	20:24:22	HTTP 204	20:24:23; payments=[]	33	20:27:28 REFUND_DENEGADO
2025808	20:27:43	HTTP 204	20:28:46; payments=[]	26	20:30:52 REFUND_DENEGADO
2025851	20:31:17	HTTP 204	20:32:20; payments=[]	26	20:34:25 REFUND_DENEGADO

Orden publicada. Las tres llamadas QR_PAGO respondieron HTTP 204 en menos de un segundo.

IPN recibido. Informó merchant order válida, pero sin payments.

Espera. El Gateway consultó repetidamente la orden durante casi tres minutos por intento: 33 consultas entre 20:24:29 y 20:27:27; 26 entre 20:28:01 y 20:30:51; y 26 entre 20:31:35 y 20:34:24. Nunca apareció paymentid, payer ni originwalletid.

Timeout. Cada POST terminó HTTP 400 aproximadamente a los 182,5 segundos.

Verificación final. La búsqueda por external_reference devolvió results=[].

Clasificación. El scheduler grabó REFUND_DENEGADO / CANCELADO_NOEXISTE_EN_MP.

Conclusión del caso: durante la ventana observada no se recibió una aprobación. Tras casi tres minutos de consultas, Mercado Pago seguía sin informar un payment para ninguno de los tres external_reference. Los logs relevados no determinan si pudo aparecer un pago tardío después del cierre. El archivo GatewayMP.log.2026-07-24.9 rota antes del cierre del tercer intento; su REFUND_DENEGADO se encuentra en .10.

4. Comparación operativa del 24/07/2026

Ranking homogéneo por idTrx POST único. Se excluyen las consultas GET del denominador.

Sucursal	POS	POST/idTrx	OK	No-pago	Aprobación	GET excluidos	Mediana OK (s)	P90 OK (s)
807	133	18	18	0	100.00%	79	23.05	51.57
40	14	112	111	1	99.11%	487	20.19	58.33
40	17	75	74	1	98.67%	330	20.34	47.85
40	19	113	111	2	98.23%	488	19.91	58.80
40	16	88	85	3	96.59%	414	19.91	48.21
40	15	112	108	4	96.43%	504	19.70	49.63
807	134	44	42	2	95.45%	194	19.76	41.64
40	18	59	54	5	91.53%	431	25.57	73.80
40	20	89	81	8	91.01%	640	25.37	65.28
807	135	53	40	13	75.47%	527	20.23	37.94

Sucursal4096,30%624/648; 3.294 GET excluidos

Sucursal807 bruto86,96%100/115; 800 GET excluidos

Sucursal807 por contexto91,74%100/109 contextos ajustados

POS135 por contexto85,11%40/47; siete contextos sin aprobación

POS135 hizo 527 GET para 53 POST: 9,94 consultas por solicitud.
Sucursal40 promedió 5,08 GET por POST.
Los pagos que sí aprobaron en POS135 no fueron lentos: mediana 20,23 s y P90 37,94 s.
Por lo tanto, el problema diario fue de conversión a payment, no de latencia de los aprobados.

5. Resumen transaccional de julio

Estados recibidos

Estado	Acción interpretada	Cantidad	Uso en tasa
PAGO_APROBADO	Pago existente y aprobado	107.295	Numerador
REFUND_APROBADO	Pago existió y luego fue devuelto	15	Numerador
REFUND_DENEGADO	CANCELADO_NOEXISTE_EN_MP	2.628	Denominador / no-pago
OBTENCIONIDTRX	Estado no terminal	45	Excluido
PAGO_ENVIADO	Estado no terminal	6	Excluido
Total terminal		109.938	Tasa global 97,61%

POS con menor aprobación — n ≥ 100

#	Sucursal	POS	Pagos existentes	No-pagos	Total	Aprobación	IC 95%
1	807	135	718	40	758	94,72%	92,89%–96,10%
2	12	147	109	6	115	94,78%	89,08%–97,59%
3	52	256	110	6	116	94,83%	89,17%–97,61%
4	50	72	483	23	506	95,45%	93,27%–96,95%
5	807	133	253	12	265	95,47%	92,25%–97,39%
6	802	87	107	5	112	95,54%	89,97%–98,08%
7	3	181	399	18	417	95,68%	93,28%–97,25%
8	12	148	333	15	348	95,69%	93,01%–97,37%
9	50	73	460	20	480	95,83%	93,65%–97,29%
10	48	89	783	34	817	95,84%	94,24%–97,01%
11	52	251	260	11	271	95,94%	92,88%–97,72%
12	40	20	1.286	54	1.340	95,97%	94,78%–96,90%
13	7	79	411	17	428	96,03%	93,73%–97,51%
14	14	211	583	24	607	96,05%	94,18%–97,33%
15	806	184	443	17	460	96,30%	94,16%–97,68%
16	22	172	678	26	704	96,31%	94,64%–97,47%
17	22	174	370	14	384	96,35%	93,97%–97,82%
18	807	134	641	24	665	96,39%	94,69%–97,56%
19	5	221	107	4	111	96,40%	91,10%–98,59%
20	37	98	430	16	446	96,41%	94,25%–97,78%

Sucursales con menor aprobación

#	Sucursal	POS relevados	Pagos existentes	No-pagos	Total	Aprobación
1	807	3	1.612	76	1.688	95,50%
2	22	4	1.885	66	1.951	96,62%
3	48	5	2.585	87	2.672	96,74%
4	806	3	1.200	40	1.240	96,77%
5	50	8	3.376	109	3.485	96,87%
6	12	5	2.322	72	2.394	96,99%
7	37	9	3.195	98	3.293	97,02%
8	13	4	1.467	44	1.511	97,09%
9	55	6	3.823	113	3.936	97,13%
10	802	4	1.111	32	1.143	97,20%
11	7	4	3.059	87	3.146	97,23%
12	14	3	1.883	51	1.934	97,36%

Detalle sucursal807

POS	Pagos existentes	No-pagos	Total	Aprobación
135	718	40	758	94,72%
133	253	12	265	95,47%
134	641	24	665	96,39%
Total	1.612	76	1.688	95,50%

POS135 frente a todo el resto: 94,72% vs 97,63%; Fisher p=0,0000061.
POS135 frente a POS133+134: 94,72% vs 96,13%; Fisher p=0,194. No alcanza para afirmar una falla exclusiva del POS135.
Sucursal807 frente al resto: 95,50% vs 97,64%; Fisher p=0,00000030. El efecto de sucursal es fuerte.

Límite del dataset mensual: no contiene idTrx, fecha/hora ni contexto MDEP. No permite deduplicar reintentos técnicos. La tasa mensual es por registros transaccionales, no por clientes, tickets o intentos humanos únicos.

6. Evaluación causal

Hipótesis	Evidencia a favor	Evidencia en contra / límite	Prioridad
Efecto sucursal / operatoria / clientela	Sucursal807 completa es la peor; diferencia significativa	Falta segmentar por cajero, hora y contexto	ALTA
Abandono o falla de billetera antes de crear payment	payments=[], payer y originwallet nulos	Sin payment no puede identificarse la billetera	ALTA
Timeout desalineado y métrica por intento	El POS abandona el POST cerca de 90 s mientras el Gateway continúa hasta 180 s; un mismo contexto MDEP puede contener intentos sucesivos, cada uno con su idTrx	Usar un idTrx distinto por intento es correcto; sólo puede aumentar la demora y distorsionar comparaciones si se mezclan intentos con contextos	ALTA
Falla exclusiva POS135	Peor tasa bruta mensual	No difiere significativamente de sus pares 807	MEDIA
Billeteras externas incompatibles	Posible falla previa al payment	POS135 tiene aprobaciones interoperables; fallos sin wallet identificable	MEDIA
Numeración CAEA repetida	Defecto real de trazabilidad	Gateway correlaciona por external_reference=idTrx	DESCARTADA COMO CAUSA QR
Host HTTP o pérdida POS→Gateway	Hipótesis original	Los POST llegaron y los PUT QR respondieron 204	DESCARTADA EN EL CASO
Fraude	Posible intento de mostrar comprobante falso	No hay payer, identidad ni liberación de mercadería sin OK	NO DEMOSTRADA

Interpretación recomendada: no reportar estos eventos como “Mercado Pago rechazó”. Clasificarlos como “orden QR creada sin payment asociado”.

7. Plan de acción para Tecnología y Desarrollo

Prioridad 1 — observabilidad y semántica

Agregar un payment_context_id estable por MDEP/ticket y un attempt_number por idTrx.
Diferenciar métricas: orden creada, payment creado, aprobado, no encontrado, cancelado y refund real.
Exponer al POS un estado semántico PAGO_NO_ENCONTRADO; mantener REFUND_DENEGADO sólo por compatibilidad interna.
Registrar sucursal, POS, cajero, versión POS, timestamps POS/Gateway, merchantorderid, paymentid y originwallet cuando exista.
Agregar una conciliación diferida de merchant orders cerradas sin payment, por ejemplo a +5, +15 y +60 minutos, para detectar pagos tardíos y prevenir diferencias de caja.

Prioridad 2 — alinear timeouts

Evitar que el endpoint POST permanezca bloqueado 180 s. Alternativa recomendada: devolver aceptación temprana y resolver por polling/callback.
Si se conserva el modelo sincrónico, el timeout del POS debe ser mayor que el del Gateway y existir un único responsable del polling.
Registrar si el siguiente intento fue iniciado por el cajero o automáticamente. Si actualmente es automático, solicitar confirmación antes de iniciar otro intento con un nuevo idTrx.

Prioridad 3 — prueba controlada

Ejecutar pagos identificados en POS133, 134 y 135 usando Mercado Pago, MODO, Naranja X, Personal Pay y dos apps bancarias.
Registrar escaneo, pantalla mostrada, confirmación, paymentid, IPN y resultado final.
Repetir en distintas ubicaciones del local para separar conectividad celular de software.
Comparar versiones POS sobre el mismo hardware y profile.

Prioridad 4 — control operativo y fraude

Analizar tasa por cajero, franja horaria e importe.
Auditar tickets o mercadería liberada sin PAGO_APROBADO.
Consultar video solamente en operaciones con override o diferencia económica; no usar REFUND_DENEGADO como indicador automático de fraude.

Criterio de cierre: contar contextos únicos, identificar si el cliente llegó a crear payment y reducir la diferencia de sucursal807 frente al promedio sin aumentar cobros duplicados.

8. Fuentes y trazabilidad

C:\Work\AI\pcpos20251021L\.soporte\fullday\GatewayMP.log.2026-07-24.0..11 — jornada completa Gateway.
C:\Work\AI\pcpos20251021L\.soporte\fullday\ee — extracto parcial del caso $2.029.
C:\Work\AI\pcpos20251021L\.soporte\SUC0807_EXTRACT — logs POS134/POS135.
C:\Work\AI\pcpos20251021L\.soporte\suc40\EXTRACT — logs POS sucursal40.
C:\Work\AI\pcpos20251021L\.soporte\GatewayMP-JH8-main.zip — código del autorizador.
C:\Users\Usuario\.codex\attachments\79dc01f0-063a-4a94-97d3-64dab3b92a2f\pasted-text.txt — agregado mensual de julio.
Informes auxiliares: QRGLOBAL.HTML, QRRANK.HTML y QRJULIO.HTML.

Definición de tasa mensual: (PAGO_APROBADO + REFUND_APROBADO) / (PAGO_APROBADO + REFUND_APROBADO + REFUND_DENEGADO). Estados no terminales excluidos.