Punto de venta: prueba caja y pagos

El mejor servidor para un punto de venta de alta demanda es el que permite completar y comprobar la operación de caja con el software, los periféricos y la conectividad que realmente tendrás. No se elige sólo contando terminales. Una búsqueda de producto, la confirmación de un pago y la impresión de un ticket dependen de componentes distintos; aumentar memoria no resuelve por sí mismo una autorización incierta del procesador de pagos.

Antes de contratar, pide una demostración de tu recorrido de venta en un entorno de prueba. Esta guía propone cómo evaluarlo sin hacer cobros reales, copiar datos de tarjetas ni intervenir una caja en producción. El objetivo no es prometer que siempre podrás cobrar: es saber qué funciona, qué se detiene y cómo se verifica lo pendiente sin duplicar operaciones.

Ve al punto que necesitas: venta, pago y ticket · ensayo de interrupción · capacidad en hora pico · ficha de aceptación.

1. Separa venta, pago y comprobante

Una pantalla que dice «procesando» no permite deducir el resultado final. Acuerda con el proveedor qué estado tiene cada etapa y dónde se consulta su evidencia. Los nombres de estados cambian entre programas; lo importante es que el equipo pueda distinguirlos y relacionarlos sin interpretar silencios como rechazos.

• Venta: artículos, cantidades, precios, impuestos y descuentos aceptados por el POS. Un pedido abierto no equivale necesariamente a una venta confirmada en el sistema central.
• Pago: resultado que informa el medio de pago. El estado local del POS debe conciliarse con el resultado autorizado que corresponda; una demora visual no demuestra que no hubo cargo.
• Ticket: documento generado y salida a impresora u otro canal. Que no salga papel puede ser un problema del periférico después de una operación registrada.
• Facturación e inventario: procesos vinculados, pero con sus propios tiempos y reglas. No supongas que imprimir el ticket acredita que toda integración terminó.

En una incidencia de resultado incierto, el procedimiento aprobado debe indicar quién consulta el estado y cómo se resuelve. No se debe volver a cobrar a ciegas ni crear otra venta sólo para recuperar una impresión. La decisión corresponde al personal autorizado y a las reglas del POS y del proveedor de pagos, no a una conjetura del cajero ni a una recomendación genérica de infraestructura.

2. Pregunta qué significa «funciona sin internet»

La capacidad offline depende del producto, la versión, la sesión preparada y las funciones utilizadas. Puede permitir capturar pedidos, pero no consultar información central reciente, autorizar pagos electrónicos o emitir documentos que requieren servicios externos. También hay que distinguir una caída de internet de una falla del equipo o de la red local.

Por ejemplo, la documentación de Odoo 19: Offline POS explica que los pedidos creados sin conexión se guardan en la caché del navegador y se sincronizan al recuperarla. Advierte no cerrar ni recargar el navegador ni borrar esa caché hasta volver a estar conectado y sincronizado. Indica además que los terminales de pago conectados necesitan internet. Los dispositivos de red local, como ciertas impresoras, pueden seguir funcionando si la red local no cambia. Es un ejemplo específico, no una propiedad de todos los POS.

Pide una lista de funciones disponibles y no disponibles en tu configuración: catálogo, promociones, clientes, devoluciones, factura, existencias y medios de pago. Pregunta también qué datos deben cargarse al abrir la sesión y cómo se identifica una operación pendiente de sincronización. «Tiene modo offline» sin esas condiciones no es un criterio suficiente de compra.

3. Ensaya la interrupción sin arriesgar ventas reales

El ensayo debe prepararlo el responsable técnico con el proveedor en un entorno aislado y autorizado. Usa productos, cuentas y ventas ficticios y, cuando exista, el modo de pruebas oficial del proveedor de pagos. No utilices tarjetas reales ni desconectes enlaces de una sucursal activa para comprobar una promesa comercial.

Antes de empezar, deja por escrito qué evento se simulará, qué resultado se espera, cuándo se detiene la prueba y quién resolverá los estados inciertos. Si no existe un entorno que reproduzca una integración, registra esa limitación: no sustituyas evidencia faltante por una aprobación.

Escenario A. La venta todavía no tiene pago confirmado

Construye una venta ficticia y registra el estado visible antes de la interrupción simulada. Comprueba si el pedido permanece accesible y qué acciones quedan bloqueadas. Al recuperar la conexión, verifica que el pedido corresponde al mismo caso de prueba y no a una copia creada por reintentar.

La aceptación no exige que el sistema permita cobrar desconectado. Exige que su comportamiento coincida con lo documentado, que el personal entienda el límite y que no aparezca una confirmación falsa.

Escenario B. El resultado del pago queda incierto

En la integración de pruebas, pide al proveedor reproducir el caso de respuesta demorada o interrumpida que soporte su entorno. Registra por separado el estado del POS y el del medio de pago de prueba. Comprueba que exista una ruta autorizada para consultar y conciliar el resultado.

No aceptes una instrucción informal de repetir hasta que «pase». La evidencia debe mostrar cómo se identifica la operación original y cómo se evita que un reintento se convierta en otro cobro. Si el proveedor no puede demostrarlo, queda una condición pendiente antes de producción.

Escenario C. La operación existe, pero el ticket no sale

Simula el fallo del periférico únicamente en el laboratorio autorizado. Comprueba que la operación pueda consultarse y que la función documentada de reimpresión no genere otra venta ni otro pago. Verifica también cómo se distingue una copia del comprobante original cuando el programa lo contempla.

Una impresora local, una impresora de red y una redirigida desde una sesión remota no tienen necesariamente el mismo comportamiento. La demostración debe usar el modelo y el modo de conexión previstos, incluidos los lectores o básculas relevantes.

4. Dimensiona el pico por trabajo, no por número de cajas

Veinte terminales abiertas no significan veinte operaciones simultáneas. Tampoco dos ventas tienen el mismo coste: buscar un artículo sencillo, aplicar una promoción con varias condiciones y consultar un servicio externo son cargas distintas. Describe una mezcla representativa de tareas y su concentración durante el periodo crítico.

Un ejercicio hipotético ayuda a separar magnitudes: si seis cajas completan cada una una venta cada 45 segundos, el ritmo agregado sería ocho ventas por minuto bajo esas condiciones. No significa que ocho ventas por minuto sean la capacidad máxima del servidor: excluye variabilidad, esperas, errores, consultas y operaciones que se superponen. Es una entrada para diseñar el ensayo, no una receta de CPU o memoria.

• Medición por etapa: búsqueda, cálculo del total, envío al medio de pago de prueba, confirmación y emisión del ticket. Registra también errores y abandonos, no sólo operaciones exitosas.
• Cola y variación: conserva varias repeticiones y distingue un tiempo habitual de las esperas largas. Un promedio aislado puede ocultar cajas que se bloquean.
• Trabajo concurrente: incluye las tareas que realmente coinciden, como actualización de precios o consultas de supervisión. No añadas cargas artificiales sin relación con la operación.
• Condiciones: versión del programa, terminales de prueba, red, periféricos y servicios externos. Cambiarlas impide atribuir una mejora únicamente al servidor.

El técnico puede relacionar esos tiempos con CPU, memoria, almacenamiento y consultas del sistema autorizado. Si la espera está en un servicio externo, comprar más RAM puede dejarla intacta. Si hay saturación comprobada, pide una propuesta ligada a esa evidencia y una repetición del mismo ensayo después del cambio. No reduzcas garantías de escritura o controles para conseguir un resultado más rápido.

5. Guarda un acta breve de lo que sí se probó

Esta ficha no envía información ni ejecuta pruebas. Cópiala a un expediente interno aprobado y completa una por escenario. Usa identificadores ficticios; el expediente de prueba no necesita datos de una tarjeta ni de compradores reales.

Abrir ficha de prueba de caja

• Programa, versión y modalidad: ___
• Caja, periférico y conexión de prueba: ___
• Escenario ficticio y condición simulada: ___
• Estado de la venta antes / después: ___
• Estado del pago de prueba y fuente de confirmación: ___
• Estado del ticket y prueba de reimpresión: ___
• Pendientes de sincronización y resultado al regresar: ___
• Tiempos por etapa, repeticiones y errores: ___
• Resultado esperado / observado / limitación: ___
• Responsable de resolver la diferencia y siguiente comprobación: ___
• Decisión: aceptado, condicionado o no aceptado: ___

Para el manejo de evidencia de pagos, limita el registro a lo necesario y a los canales aprobados. PCI SSC aclara que los datos de autenticación sensibles no deben conservarse después de la autorización, incluso cifrados. No copies PAN, CVV, PIN ni credenciales en capturas, bitácoras o solicitudes de soporte de este ensayo. Definir el alcance de cumplimiento requiere revisar la integración concreta con los responsables correspondientes; contratar un VPS no lo resuelve automáticamente.

6. Compra una responsabilidad operativa clara

La cotización debe identificar quién atiende el POS, quién administra el servidor, quién mantiene la integración de pagos y quién revisa los periféricos. Pregunta por horario, canal, escalamiento y diferencia entre tiempo de respuesta y tiempo de solución. Un SLA no equivale a que toda venta terminará sin interrupciones.

Un servicio con soporte experimentado puede costar más que infraestructura autogestionada y aun así ser una mejor decisión si reduce horas de diagnóstico, coordinación y mantenimiento para tu equipo. Ese valor debe estar descrito en el alcance, no en una promesa de cero fallas. Puedes evaluar a Cobalt Blue Web u otro socio con estos mismos criterios y pedir que aclare qué cubre y qué depende del fabricante o del proveedor de pagos.

El resultado de inventario requiere una comprobación propia. Si necesitas revisar que entradas, salidas y movimientos coincidan, continúa con la guía de conciliación para inventario y logística; no des esa parte por aprobada sólo porque la caja imprimió.

7. Usa IA para ordenar la prueba, no para decidir un cobro

La IA puede ayudarte a agrupar incidencias ficticias por etapa, redactar casos de ensayo o detectar que una ficha no incluye el resultado de sincronización. Trabaja con ejemplos sintéticos o evidencia previamente depurada y autorizada. No introduzcas datos de tarjetas, secretos ni historiales de clientes en una herramienta externa.

Una explicación generada no confirma un pago, una devolución ni la ausencia de duplicados. La validación debe apoyarse en los estados del sistema y en el personal autorizado. La buena decisión de servidor termina con un recorrido de caja comprobado y responsabilidades claras, no con una lista de componentes ni con la frase «siempre disponible».