Saltar al contenido principal

Liquidaciones

La sección Liquidaciones (/settlements) es donde consultas cómo y cuándo se le paga a cada comercio el dinero de sus ventas. Aquí ves las corridas de liquidación que se han ejecutado, el detalle de cada ejecución por comercio y moneda, y una vista previa de lo que todavía está pendiente por liquidar.

Hoy es una pantalla de consulta

No vas a encontrar un botón para "forzar" o adelantar una liquidación desde aquí. Esta guía te explica qué información puedes revisar y cómo interpretarla.

Qué vas a encontrar en esta pantalla​

La vista está organizada en dos niveles:

  • Corridas: cada corrida agrupa el proceso de liquidación que corrió en un momento dado.
  • Ejecuciones: dentro de cada corrida, hay una ejecución por cada combinación de comercio y moneda que se liquidó. Es el nivel de detalle donde realmente ves cuánto se pagó y a dónde.

Paso 1: revisa las corridas​

Al entrar a Liquidaciones, ves el listado de corridas ejecutadas. Haz clic en una corrida para expandir sus ejecuciones.

Paso 2: revisa el detalle de una ejecución​

Cada fila de ejecución te muestra, por comercio y moneda:

CampoQué es
ComercioEl comercio al que corresponde esta ejecución.
MonedaLa moneda en la que se liquidó.
Cuenta destinoEl banco y el número de cuenta (enmascarado) a donde se envió el dinero.
La cuenta destino es una fotografía, no el dato actual

La cuenta que ves en una ejecución no se actualiza si el comercio cambia su cuenta de depósito después. Es la cuenta que estaba configurada exactamente en el momento en que esa liquidación se ejecutó, guardada de forma fija junto con la ejecución. Así, aunque pase el tiempo y el comercio actualice sus datos bancarios, el historial de liquidaciones sigue mostrando con exactitud a dónde se envió cada pago. Para entender de dónde sale este dato y cómo se configura, ve a Cuentas de depósito.

Paso 3: consulta la vista previa de lo pendiente por liquidar​

Además del historial, la pantalla incluye una vista previa: elige un comercio en el selector y vas a ver el desglose de lo que está acumulado y todavía no se ha liquidado, con tres montos:

  • Bruto — el total de las ventas que están pendientes de liquidar.
  • Comisión — lo que se descuenta por comisiones sobre esas ventas.
  • Neto — lo que efectivamente le correspondería al comercio si se liquidara en este momento.
Es una vista previa, no una promesa exacta

El neto que ves aquí es un estimado de "en este momento". Puede variar si hay ventas nuevas, ajustes o disputas antes de que la corrida realmente se ejecute.

Por qué una venta podría no estar incluida​

Dos situaciones hacen que una venta ya aprobada se excluya de la liquidación de un comercio hasta que se resuelvan:

En ambos casos, si el resultado final es favorable (la disputa se gana, o la revisión se libera), el monto correspondiente se acredita automáticamente en la siguiente corrida — no tienes que hacer nada adicional para que se incluya.

Generar el archivo bancario de dispersión​

Dentro del grupo Operaciones, la sección Dispersiones (separada de Liquidaciones) agrupa por día/semana las liquidaciones ya ejecutadas y te deja entrar al detalle de cada una. Ahí, además del botón genérico Exportar a Excel, tu plataforma tiene un segundo botón — Generar archivo de dispersión — que produce el archivo con el formato bancario específico de WUZI, listo para tu proceso de transferencia. Es el mismo archivo que puedes generar desde el catálogo de reportes en Reportería como "Archivo bancario WUZI".

Reportes TPV para impresión en terminal​

Cuando la terminal TPV solicita un reporte de liquidación por rango, Payment Nexus guarda una fotografía inmutable del detalle financiero de ese rango. Por eso:

  • Si la terminal vuelve a pedir el mismo comercio/rango/moneda, la API devuelve el reporte existente exitosamente. No se reemplaza silenciosamente por otro cálculo.
  • El botón Actualizar de la APK puede volver a consultar el mismo rango; recibirá el snapshot ya existente. Si operación necesita una versión nueva por ventas tardías o correcciones del read model, debe generarse mediante un flujo explícito de nueva versión/revisión, no sobrescribiendo el reporte anterior.
  • Los totales del encabezado, total_items y el detalle impreso deben coincidir con el snapshot guardado.

En los endpoints de impresión (/print/pages y /print/complete), cada operación puede incluir datos mínimos de tarjeta para que la APK imprima una línea como Tarjeta **** **** **** 0012:

{
  "transaction_id": "txn_ejemplo",
  "created_at": "2026-09-10T16:15:00Z",
  "pan_last4": "0012",
  "card_type": "debit",
  "card_brand": "visa"
}

pan_last4 siempre es texto de cuatro dígitos cuando existe, conservando ceros iniciales; si no hay dato confiable, se devuelve null. card_type puede ser debit, credit, prepaid o null; card_brand se devuelve normalizada o null. Nunca se expone PAN completo, track, PIN, CVV, tokens ni referencias internas del procesador. Los reportes creados antes de esta mejora pueden mostrar esos campos como null; eso es esperado y evita alterar un snapshot histórico ya auditado.

Qué sigue​