Conciliar pedidos y banco: cómo detectar cobros que tu tienda cree tener y no tienes

El back-office dice «Pago aceptado» y el pedido sale hacia el almacén. Es lo normal, y casi siempre es verdad. Pero ese estado lo escribe tu tienda, no tu banco: es lo que la tienda cree que ha pasado. El dinero lo confirman otros dos sitios, el panel de la pasarela y el extracto bancario, y si nadie los compara con los pedidos, un desajuste puede durar meses.

No hablamos de una rareza teórica. Hemos visto tiendas con pedidos «pagados» cuyo dinero había ido a la cuenta de otro, tiendas con dos pedidos por cada cobro y tiendas con cobros que nunca llegaron a convertirse en pedido. En todos los casos, una conciliación semanal lo habría detectado en días.

Por qué pedidos, pasarela y banco dejan de cuadrar

Desvío de pagos

Es el caso más grave. Alguien con acceso a los ficheros de la tienda —por una contraseña de FTP robada o por un módulo vulnerable— modifica el módulo de pago para que el cliente pague en una pasarela del atacante. El pedido se crea con el nombre del módulo legítimo, el estado es el de siempre y en el back-office todo parece normal. Solo hay una diferencia: en el panel de tu pasarela esa operación no existe.

La variante sencilla es cambiar el IBAN de la transferencia bancaria en la configuración. El cliente paga, el pedido queda pendiente, el cliente insiste en que pagó, y tú no encuentras el ingreso.

Notificaciones duplicadas o perdidas

La pasarela avisa a tu tienda de que el pago se ha completado mediante una notificación (IPN, webhook o la vuelta del cliente a la tienda). Si llegan dos a la vez, puedes acabar con dos pedidos para un solo cobro, cada uno con su factura y su stock descontado. Si no llega ninguna, tienes el caso contrario: un cobro sin pedido, y un cliente que ha pagado y no recibe nada.

Cambios a mano y devoluciones fuera de la tienda

• Un empleado marca como pagado un pedido de transferencia antes de ver el ingreso.
• Se hace un reembolso desde el panel de la pasarela y el pedido sigue como pagado.
• Llega un contracargo y el pedido no se entera.

Liquidaciones que no son pedidos

Las pasarelas no ingresan pedido a pedido: liquidan en lotes y descuentan comisiones, devoluciones y contracargos. Por eso no se puede conciliar el banco directamente contra los pedidos; hace falta el paso intermedio de la pasarela.

Las dos cuadraturas que hay que hacer

Conciliar es cruzar tres fuentes en dos pasos:

1. Pedidos ↔ operaciones de la pasarela. Cada pedido pagado con tarjeta, Bizum o PayPal tiene que tener su operación en el panel, con el mismo importe. Y cada operación cobrada tiene que tener su pedido.
2. Operaciones ↔ abonos en el banco. La suma de las operaciones de un periodo, menos comisiones, devoluciones y contracargos, tiene que ser lo que la pasarela te ha ingresado.

El primer paso es el que encuentra desvíos y duplicados. El segundo encuentra comisiones inesperadas, retenciones y liquidaciones que no llegan.

La conciliación semanal, paso a paso

1. Exporta los pedidos pagados de la semana con referencia, importe total, módulo de pago y número de operación. En PrestaShop ese número suele estar en el pago del pedido (la tabla ps_order_payment, campo transaction_id), aunque algunos módulos lo guardan en tablas propias.
2. Exporta las operaciones del panel de cada pasarela del mismo periodo, con su número, importe y estado.
3. Cruza por número de operación, no por importe. Dos pedidos de 49,90 € cruzados por importe se dan por buenos aunque uno sea falso.
4. Saca tres listas: pedidos sin operación, operaciones sin pedido e importes que no coinciden.
5. Cuadra las liquidaciones de la pasarela con los abonos del extracto.
6. Apunta qué has hecho con cada diferencia. Una diferencia sin explicar la semana que viene ya no la recordará nadie.

Transferencias, contra reembolso y Bizum manual

En los métodos sin notificación automática, el pedido pasa a pagado porque una persona lo decide. La regla es simple: solo se marca como pagado con el extracto delante, nunca porque el cliente envíe una captura del justificante, que se falsifica en un minuto. Y revisa de vez en cuando que el IBAN que muestra tu tienda en la confirmación del pedido y en los emails es el tuyo.

Señales de que algo se está desviando

• Números de operación con una forma distinta a los habituales de esa pasarela.
• Una pasarela que cobra menos en liquidaciones que lo que dicen los pedidos.
• Clientes que dicen haber pagado y cuyo pago no aparece en ningún panel.
• Ficheros del módulo de pago con una fecha de modificación que no coincide con ninguna actualización.
• Cambios en la configuración de las pasarelas que nadie del equipo recuerda haber hecho.

Por qué esto también va de mantener la tienda al día

El desvío de pagos necesita escribir en tu servidor. Las vías más habituales son credenciales de FTP o del panel de hosting robadas y módulos con vulnerabilidades conocidas que nadie actualizó. Una tienda con PrestaShop, PHP y módulos al día, con las cuentas de acceso revisadas, se lo pone mucho más difícil al atacante. La conciliación detecta el problema; la actualización reduce las veces que llega a pasar.

Checklist

• Conciliación pedidos ↔ pasarela cada semana, por número de operación.
• Conciliación pasarela ↔ banco en cada liquidación.
• Transferencias marcadas como pagadas solo con el extracto.
• Revisión periódica del IBAN y de las claves de las pasarelas en la configuración.
• Aviso cuando cambien los ficheros de los módulos de pago.
• Registro de cada diferencia y de su resolución.

Cómo resolverlo en PrestaShop

RKR Order Guard evita los pedidos duplicados cuando dos notificaciones de la pasarela llegan a la vez y revisa el histórico para encontrar los que ya tienes, clasificándolos según haya uno o dos cobros: el sobrante pasa a Cancelado y su stock vuelve, y las devoluciones las decide una persona. Además vigila los pagos desviados en dos capas: comprueba el número de operación de cada pedido (por firma en Redsys, por la forma del identificador en PayPal, PayPlug y Stripe) y guarda la huella de los ficheros de tus módulos de pago para avisarte si cambian sin una actualización. El aviso sale en la ficha del pedido, donde está quien lo va a enviar. RKR Security Alert completa la vigilancia: guarda una foto de la configuración, los módulos y los empleados, marca como críticos los cambios en las pasarelas de pago aunque se hagan por SQL directo y te avisa por Telegram.