Pedido, pago y liquidación: tres historias de una misma compra

Se puede despachar un pedido pagado y aún no haber recibido la liquidación en el banco. Se puede devolver parte del dinero y conservar el hecho del pago original. Las dificultades empiezan cuando todo el ciclo de vida del pago tiene que caber en una sola etiqueta verde. Una interfaz operativa necesita tres historias vinculadas y reglas que impidan que una de ellas reescriba otra sin que nadie lo note.

Para gestionar las operaciones conviene llevar tres historias vinculadas: el pedido comercial, el intento de pago y el movimiento de fondos hacia la cuenta bancaria. Pueden mostrarse en una misma pantalla, pero no reducirse a un único interruptor de «pagado / no pagado».

Una compra, tres momentos

Ejemplo hipotético: una tienda vende un kit por 80 euros. El lunes a las 10:00 se crea el pedido. A las 10:02 el proveedor confirma el pago, pero el evento llega al sistema de la tienda a las 10:04. El martes se despacha la mercancía. Según las condiciones de nuestro contrato ficticio, los fondos quedan disponibles para liquidación el miércoles y salen en la liquidación del jueves.

El martes, el pedido tiene a la vez los estados «pagado» y «enviado», y la liquidación asociada aún no se ha realizado. No hay contradicción. El error surge si el equipo toma la ausencia del ingreso bancario como motivo para volver a cobrar los 80 euros o para exigir al comprador un nuevo pago.

Añadamos ahora un reembolso parcial de 20 euros tras el despacho. En el modelo de ejemplo, el importe pagado sigue siendo de 80 euros, el reembolso es de 20 euros y el saldo tras el reembolso es de 60 euros antes de comisiones. Sobrescribir el pago original con la cifra 60 es incómodo: desaparece el historial con el que habrá que conciliar el informe del proveedor.

El pedido tiene su propio ciclo de vida

El pedido responde a preguntas sobre la mercancía y la obligación del vendedor: creado, aceptado, en preparación, enviado, completado, cancelado. Los nombres los elige el propio negocio. Un pedido puede cancelarse después del pago, cumplirse parcialmente o pagarse en varias partes. Por eso la cancelación del pedido debe activar una revisión de las consecuencias de pago, no simplemente ocultar la fila de la lista de trabajo.

El pago responde a otra pregunta: ¿qué ocurrió con un intento concreto de pagar? En el esquema de tarjetas, la autorización y la captura pueden ser etapas separadas. Por ejemplo, la documentación de Adyen distingue autorización, capture y settlement. En otro proveedor, los nombres y el conjunto de estados pueden ser distintos.

El proveedor también puede tener un objeto aparte para todo el proceso de pago. Stripe PaymentIntent guarda el estado de ese proceso y vincula los intentos de pago. Al diseñar su sistema, es importante averiguar qué identificador designa el pedido, cuál el intento y cuál la operación financiera final.

Defina restricciones que se verifiquen automáticamente

Conviene empezar con algunas condiciones internas de integridad. Un mismo identificador de evento no debe activar el cumplimiento por segunda vez. Un reembolso confirmado conserva el vínculo con el pago original. Cada despacho tiene una confirmación de pago válida o una excepción comercial aprobada explícitamente. Los importes y las monedas se comparan según reglas establecidas, y cualquier discrepancia va a una cola separada.

No intente expresar toda la lógica con una secuencia de estados «creado → exitoso → cerrado». Imaginemos que el pedido se canceló a las 10:03 y que la confirmación del pago, generada a las 10:02, se recibió a las 10:04. El pago efectivamente se realizó y el pedido comercial efectivamente se canceló. El resultado propuesto: conservar ambos hechos, bloquear el despacho automático y abrir una tarea para una resolución acordada. El reembolso todavía debe autorizarse y ejecutarse; no puede darse por hecho solo porque se canceló el pedido.

En la pantalla del empleado, muestre el motivo de la espera: «pago confirmado, cumplimiento detenido tras la cancelación». Es más informativo que un genérico «error». Luego hacen falta un responsable y las acciones permitidas. El comprador puede recibir una explicación más breve, pero debe basarse en el mismo registro.

Qué campos salvan una investigación

• El número interno del pedido y los identificadores de todos los pagos vinculados.
• El importe y la moneda originales, los importes de cobros y reembolsos confirmados.
• El estado original del proveedor junto con su estado comprensible para el operador.
• La hora del evento en la fuente y la hora en que su sistema lo recibió.
• El número de liquidación, su composición, la fecha esperada y la confirmación bancaria cuando llegue.

También conviene separar la fecha de disponibilidad de los fondos y la del envío de la liquidación. En la documentación de Stripe sobre payouts, el calendario de transferencias se separa del plazo en que el dinero queda disponible. Para otro producto, verifique sus propias reglas, incluidos días no hábiles, horas de corte y retrasos iniciales.

La prueba de la foto vieja de los datos

La interfaz siempre muestra los datos de un momento dado. Por eso, junto al estado, son útiles la hora de la última confirmación y la fuente. Si el operador abrió la ficha hace veinte minutos, cualquier acción con dinero debe volver a comprobar el estado actual. De lo contrario, dos empleados pueden tomar uno tras otro una decisión correcta sobre una misma imagen desactualizada.

Añada a las pruebas este escenario: el primer turno crea un reembolso y el segundo, que aún ve la pantalla anterior, intenta crear otro igual. El comportamiento esperado del sistema debe definirse de antemano: mostrar la acción ya iniciada, su identificador y su estado, en lugar de crear en silencio una operación adicional.

Guarde el historial de correcciones por separado de los eventos originales. Así mañana podrá reconstruir tanto la secuencia real como lo que el empleado sabía en el momento de decidir. Esto es especialmente útil al analizar confirmaciones tardías: conocer hoy el resultado no debe distorsionar la evaluación de la acción de ayer.

Una decisión manual también deja historial

Una notificación repetida no debe crear otro despacho. Una notificación tardía no debe sobrescribir sin dejar rastro datos más recientes. Adyen describe los posibles duplicados y la necesidad de tener en cuenta la cronología de los eventos. Pruebe estos escenarios según las reglas de la API que utilice.

Por último, defina qué transiciones puede hacer manualmente un operador. En lugar de un botón «marcar como pagado», es más útil un procedimiento de revisión aparte con un enlace obligatorio a la confirmación. Conserva el motivo de la decisión, el autor y la hora. Así la excepción sigue siendo visible y verificable.

En una cola separada, deje los pagos sin pedido, los pedidos sin confirmación, los reembolsos sin revisar y las liquidaciones sin coincidencia bancaria. Cada elemento necesita su antigüedad de espera, un responsable y un siguiente paso.

Pruebe el modelo con un pedido cancelado antes de recibir la confirmación del pago. El sistema debe conservar ambos hechos, mostrar la tarea de resolución y no activar ni un nuevo cobro ni el despacho automático. Esta prueba verifica el significado de los estados mejor que un cambio de color en la interfaz.