Si el cliente ha pagado y el pedido no se confirma, reparar las compras futuras y resolver los pedidos afectados son dos entregas distintas. El técnico puede haber corregido el fallo y seguir quedando una lista de cobros, estados o devoluciones por revisar. Esa lista merece un cierre propio antes de que atención al cliente, almacén y administración tomen decisiones por separado.
Esta plantilla sirve para aceptar una reparación de pagos WooCommerce con un expediente de los casos afectados. Incluye un ejemplo descargable de nueve registros de proveedor y ocho pedidos ficticios. Para investigar la causa técnica, consulta pago correcto con pedido pendiente o cliente cobrado sin pedido visible. Aquí nos centramos en qué debe quedar reconciliado, asignado y comprobado al entregar el trabajo.
Acuerda dos cierres: funcionamiento nuevo y casos anteriores
Define primero qué se ha reparado: recepción de una confirmación, persistencia del pedido, procesamiento de una tarea o sincronización de un estado. La entrega debe relacionar la causa observada, el cambio aplicado y una prueba del recorrido afectado. Que una página vuelva a cargar no resuelve toda esa cadena.
Abre después un expediente para los casos ocurridos durante la incidencia. Fija el periodo, zona horaria, proveedor, cuenta y modo de operación. Conserva las exportaciones y el momento de consulta: una confirmación tardía puede cambiar el resultado entre dos revisiones.
Puedes aceptar una corrección técnica y mantener abierto un caso histórico con responsable y siguiente decisión. También puede ocurrir lo contrario: los pedidos anteriores se han atendido manualmente y el origen del fallo sigue pendiente. Mantener visibles ambos cierres evita que una solución provisional se convierta en una entrega aparentemente completa.
Prepara un registro que conecte pedido y pago
Utiliza referencias verificables del proveedor y de la tienda. Añade moneda, importes comparables, estado observado y hora. El correo del cliente puede orientar una búsqueda, pero no sustituye una identidad de operación. Dos compras legítimas pueden compartir cliente e importe.
| Bloque | Qué conservar | Decisión que permite |
|---|---|---|
| Identidad | Referencia del pedido y del proveedor, entorno y cuenta | Localizar el mismo caso |
| Importes | Moneda, captura bruta y devoluciones por separado | Clasificar una diferencia real |
| Estado | Estado del proveedor y de WooCommerce, con hora | Distinguir cobro y proceso comercial |
| Operación | Stock, comunicaciones y preparación o envío comprobados | Evitar una segunda actuación independiente |
| Cierre | Evidencia, decisión, responsable y pendiente | Continuar o aceptar el caso con contexto |
El expediente compartido no necesita números de tarjeta, claves ni exportaciones completas de clientes. Guarda el original donde corresponda y entrega un extracto con referencias suficientes. La guía para seguir un pago sin exponer datos de tarjeta ayuda a preparar esa parte de la investigación.
Compara estados que representen lo mismo
Un importe autorizado y uno capturado no son intercambiables. Tampoco lo son un pedido pendiente, uno pagado y uno entregado. La documentación de estados de WooCommerce distingue pago y preparación o finalización del pedido. Revisa además las reglas de la pasarela y los estados personalizados de la tienda.
Compara la captura bruta con su referencia comercial y las devoluciones con sus registros correspondientes. En el objeto Charge documentado por Stripe, los importes capturado y devuelto se representan por separado. El ejemplo de esta guía adopta esa separación conceptual; no es una exportación real de Stripe ni un formato universal para pasarelas.
Conserva la moneda. El número 75 en USD y el número 75 en EUR no acreditan una coincidencia. Si necesitas una conversión, su criterio y finalidad requieren otra especificación. El ejemplo descargable utiliza unidades menores enteras y nunca suma ni convierte monedas diferentes.
Ejemplo descargable: nueve registros, ocho pedidos
Hemos construido datos ficticios con un corte a las 12:00 UTC del 20 de octubre de 2026. Ejecutamos una unión local por referencia y una clasificación de la primera diferencia aplicable. El ejercicio devuelve nueve filas: siete para revisar, una autorización sin captura y una coincidencia dentro de la muestra.
Descargar el ejemplo original: tres CSV y notas en inglés, con datos ficticios. Incluye registros del proveedor, pedidos de tienda e informe de revisión. Sirve para estudiar el expediente; no es un paquete de importación ni una herramienta para reparar pedidos.
| Caso | Lo que contiene la muestra | Clasificación |
|---|---|---|
| O101 | Captura de 120 EUR y pedido compatible | Registros alineados en la muestra |
| O102 | Captura de 80 EUR y pedido pendiente | Revisar estado comercial |
| O103 | Captura de 50 EUR sin fila de pedido | Revisar pedido ausente en la exportación |
| O104 | Dos capturas de 30 EUR para una referencia | Revisar múltiples capturas |
| O105 | Autorización, captura cero y pedido en espera | Autorización sin cobro capturado |
| O106 | Captura de 100 EUR; devolución de 20 EUR no reflejada localmente | Revisar devolución |
| O107 | Proveedor en USD y pedido en EUR | Revisar moneda |
| O108 | Captura de 65 EUR y pedido de 60 EUR | Revisar importe bruto |
| O109 | Pedido pendiente sin referencia de proveedor en el extracto | Recuperar evidencia del proveedor |
Todas las acciones automáticas del informe son «ninguna». No accedimos a una tienda, pasarela, cliente o tarjeta, ni ejecutamos cobros, devoluciones, reenvíos o cambios de stock. La coincidencia O101 solo concierne a los campos comparados: no demuestra entrega de correo, preparación, liquidación bancaria o cierre completo de una incidencia.
Lee las excepciones antes de corregirlas
O104 plantea dos capturas que deben investigarse. La regla del ejemplo espera una captura completa por pedido; una tienda con pagos fraccionados necesitaría otro modelo. El resultado no autoriza a devolver una de ellas. Primero hay que determinar qué representan y qué decisión aprueba el negocio.
O103 y O109 muestran límites de las exportaciones. La ausencia de un pedido en un archivo no demuestra que nunca existiera; la ausencia de una referencia de pago no demuestra impago. Registra la siguiente búsqueda, su responsable y la fuente que permitirá resolverla.
La clasificación informa de la primera diferencia aplicable. Un caso con dos capturas puede tener también un estado incorrecto o una comunicación repetida. La revisión debe conservar esos hallazgos adicionales. Una etiqueta inicial es una cola de investigación, no una descripción exhaustiva de todo el pedido.
Una devolución parcial no reescribe el total original
En O106, 100 EUR capturados menos 20 EUR devueltos dejan 80 EUR antes de comisiones. El pedido original sigue teniendo un total de 100 EUR. El problema de la muestra está en la devolución local ausente, no en que el total original deba cambiarse a 80.
El expediente debe conservar ambas referencias y explicar qué registro falta. Si el proveedor ya ejecutó la devolución, una corrección local no debe mover ese dinero otra vez. La decisión real requiere verificar el objeto del proveedor y utilizar el procedimiento de la integración correspondiente.
La reparación de datos de pedidos sin reescribir el historial de pagos desarrolla las precauciones sobre almacenamiento y cambios soportados. Esta plantilla añade el registro de entrega para que otra persona pueda comprobar la relación entre evidencia, decisión y resultado.
Comprueba que repetir una confirmación no repita sus efectos
La reparación debe tener una prueba adecuada al evento que falló. En un entorno preparado, acuerda cómo comprobar recepción, procesamiento y resultado. La documentación de webhooks de Stripe contempla eventos duplicados y falta de garantía de orden; esas condiciones merecen atención cuando esa integración sea la utilizada.
Antes de un reenvío real, revisa el evento existente y sus efectos. La prueba debe observar referencias de pedido, stock, comunicaciones y preparación según el alcance. Un resultado de entrega HTTP no sustituye comprobar la tarea de negocio. El ejercicio de CSV no realiza esta prueba ni acredita idempotencia.
La guía de pruebas después de reparar WooCommerce permite definir recorridos nuevos y regresiones. Incluye el método de pago, productos y condiciones que provocaron el fallo original. Mantén el resultado de esos ensayos separado del trabajo sobre los pedidos históricos.
Decide qué puede cerrarse y qué debe seguir abierto
| Entrega | Prueba requerida | Si falta evidencia |
|---|---|---|
| Corrección técnica | Recorrido afectado y resultado tras el cambio | Verificación pendiente |
| Casos históricos | Referencias conciliadas o decisión documentada por caso | Responsable y acción siguiente |
| Efectos operativos | Stock, avisos y preparación incluidos en el alcance | Dependencia explícita |
| Continuidad | Registro de cambios y control acordado de recurrencia | Seguimiento sin propietario por resolver |
Una lista sin diferencias inexplicadas puede apoyar el cierre del expediente delimitado. No convierte la intervención en una revisión contable completa ni certifica todos los sistemas de la empresa. Deja por escrito los límites y qué persona acepta cada parte.
Preguntas para revisar el presupuesto y la entrega
¿La reparación incluye resolver los pedidos anteriores?
Debe decirlo el alcance. Pide periodo, número de casos conocido, fuentes disponibles y tratamiento de excepciones. Una oferta puede cubrir restaurar las confirmaciones futuras y presupuestar aparte la revisión histórica. Compara esas partidas y el acceso necesario antes de aceptar el total.
¿Podemos dar por cerrado un pedido que requiere una decisión comercial?
Documenta la decisión aprobada, la evidencia y su responsable. Si todavía falta confirmar si se enviará, reconstruirá o devolverá una operación, conserva el caso abierto. La decisión administrativa y la ejecución comprobada tienen estados diferentes; un comentario en el ticket no acredita por sí solo que se haya completado.
¿Qué debería recibir el siguiente proveedor?
El expediente acotado, las referencias, las decisiones aplicadas, las pruebas realizadas y las dependencias pendientes. Conserva también qué cambió en la integración y qué acceso temporal debe revisarse. Así la continuidad empieza con información utilizable y no con una nueva petición al cliente para que vuelva a demostrar que pagó.
Ficha de entrega desarrollada: el caso ficticio O102
O102 enlaza el pedido pendiente con P102, una captura ficticia de 80 EUR. La clasificación local pide revisar el estado comercial. El expediente comienza con esas referencias y la hora del corte; todavía no contiene una causa demostrada ni una corrección ejecutada.
El encargo puede solicitar identificar por qué la confirmación no llegó al estado previsto y presentar el cambio propuesto. La prueba de una corrección futura debe prepararse con la integración y el entorno adecuados. Mientras tanto, el responsable de la tienda revisa el caso histórico para decidir su atención y evitar actuaciones independientes.
El campo «resultado» permanece pendiente hasta tener evidencia nueva. Si se aplica una corrección local autorizada, el registro debe conservar P102 y explicar qué se cambió, quién lo aprobó y qué efectos se comprobaron. La aceptación exige una evidencia correspondiente a cada afirmación, sin convertir la etiqueta del CSV en una autorización de envío.
En una entrega real, atención al cliente también necesita saber qué comunicación está aprobada y quién la realiza. El expediente puede identificar esa tarea sin incorporar conversaciones privadas completas. Así todos utilizan la misma referencia y el cliente recibe una respuesta coherente con la decisión tomada.
Qué hacer cuando una prueba de cierre falla
Guarda el intento, resultado observado y siguiente hipótesis. Si una confirmación funciona pero repite un aviso o un movimiento de stock, la prueba relevante sigue fallando. Evita borrar ese intento para que el informe quede limpio. Acordad la corrección y la nueva comprobación antes de cerrar el alcance.
Cuando el bloqueo sea un acceso o una dependencia externa, nombra el responsable y qué evidencia permitirá continuar. Eso permite presupuestar la fase siguiente con un problema concreto y conservar el valor de lo ya investigado.
Prepara la evaluación con un caso concreto
Reúne URL de tienda, método afectado, periodo, síntoma y referencias con datos privados retirados. La guía para pedir un diagnóstico del checkout en 2027 ayuda a ordenar el primer envío. Para reparar el checkout WooCommerce, acuerda tanto la prueba del funcionamiento nuevo como la entrega de casos anteriores.
El proceso de recuperación ecommerce explica evaluación y aprobación. Puedes solicitar una evaluación con el expediente disponible. Una buena entrega permite que técnico, tienda y atención al cliente sepan qué se ha resuelto y quién continúa con lo que falta.
Falla el aviso de pago: un caso ejecutado en WooCommerce
El ejercicio de conciliación anterior utiliza listas sintéticas. Además, el 25 de octubre de 2026 ejecutamos otro caso: un checkout nativo de WooCommerce, un pedido real dentro del laboratorio y su registro de stock, con una pasarela propia conectada por HTTP a un simulador local de pagos. El simulador registró un cargo ficticio de 39,00 €. No intervino ningún banco, tarjeta, procesador real ni dinero.
La instalación aislada utilizó WordPress 7.1.3, WooCommerce 11.2.1, PHP 8.3.36 y MariaDB 11.4.12. Chromium 152 envió el checkout. Los reintentos y las notificaciones posteriores fueron peticiones HTTP del banco de pruebas. Son siete pasos observados, no siete compras de clientes ni una validación de una pasarela comercial.
| Paso observado | Estado del pedido | Cargos simulados, total | Stock |
|---|---|---|---|
| Checkout nativo | pending |
1 | 10 |
| Repetición de petición de pasarela | pending |
1 | 10 |
| Firma incorrecta: HTTP 401 | pending |
1 | 10 |
| Aviso no disponible: HTTP 503 | pending |
1 | 10 |
| Reintento recuperado: HTTP 200 | processing |
1 | 9 |
| Aviso de pago repetido: HTTP 200 | processing |
1 | 9 |
| Aviso tardío de fallo: HTTP 200 | processing |
1 | 9 |
Lo que demuestra la traza
El primer checkout creó un pedido pendiente. El simulador guardó un cargo con una clave de idempotencia vinculada a ese pedido. Al repetir la petición de la pasarela, devolvió el cargo existente. Después enviamos un aviso con firma incorrecta, rechazado con HTTP 401, y otro correctamente firmado al que provocamos un HTTP 503. El pedido siguió pendiente y el stock permaneció en 10.
El reintento del mismo evento firmado sí pasó. El receptor llamó a payment_complete() de WooCommerce con la referencia de transacción simulada: el pedido pasó a processing y el stock bajó a 9. Repetir el aviso de pago no volvió a descontarlo. Un aviso posterior de fallo tampoco pisó el estado pagado. Al terminar había un pedido, un cargo simulado y la referencia de transacción coincidente.
Descarga la traza observada, el CSV de siete filas y las notas de alcance. El ZIP contiene referencias ficticias y resultados medidos, sin credenciales ni código ejecutable de la pasarela. La recuperación del aviso tardó 272,975 ms en esta ejecución local: es una medida del laboratorio, no una promesa de velocidad del proveedor.
Hasta dónde llega esta prueba
La firma, el tratamiento de eventos y la idempotencia se programaron para este laboratorio. No demuestran que un plugin de Stripe, PayPal u otra pasarela se comporte igual. Probamos el checkout clásico; no Checkout Blocks, 3-D Secure, devoluciones reales, procesos simultáneos, reintentos externos ni recepción de correos de clientes. Para cerrar una reparación en una tienda, falta repetir la aceptación con el sandbox de su proveedor y sus integraciones.
La implementación siguió la API de pasarelas de WooCommerce. Su guía de pedidos de prueba explica también las precauciones con pedidos e integraciones. Aquí toda la instalación fue privada, se bloqueó el envío de correo externo y, tras recoger la evidencia, retiramos sus contenedores, red y credenciales generadas.