Una reparación no termina porque desaparezca el error original. Checkout es una cadena: sesión, totales, pedido, pago, callback, stock, email y fulfilment. Un cambio puede arreglar un paso y romper otro o funcionar solo para administradores.
Crea un acta de aceptación con órdenes controladas. Concilia y limpia cada intento antes del siguiente.
Repite el fallo exacto
Usa el mismo tipo de dispositivo, invitado/cuenta, producto, dirección, envío y pago. Registra evidencias antes/después.
No cambies varias variables y declares resuelto. El síntoma long-tail original debe quedar demostrado. Tras un envío, comprueba pasarela y WooCommerce para evitar duplicados.
Define antes el resultado esperado, quién lo acepta y qué evidencia se guardará. Una prueba sin criterio puede parecer correcta aunque deje un warning, retraso o efecto secundario. Si falla el caso original, detén la batería y aplica rollback o vuelve al diagnóstico.
Prueba carrito y sesión
Añade, elimina y cambia cantidad; navega entre producto, carrito y checkout y recarga. Prueba invitado y cliente recurrente.
- carrito sobrevive cambios de página
- cupón y envío son coherentes
- otro navegador privado tiene otro carrito
- login aplica la política de fusión previstaCalienta caché pública antes de la pasada final: en frío puede ocultar reglas inseguras.
Valida totales
Usa direcciones y productos representativos para descuentos, envío, impuestos, tasas y moneda. Prueba justo debajo y encima del envío gratis.
Checkout, pedido guardado y pasarela deben coincidir. Documenta redondeos solo si son esperados y aprobados. No uses datos de clientes reales.
Incluye productos simples, variaciones y al menos una combinación que active clase fiscal o de envío especial. Prueba también quitar un cupón y cambiar dirección en la misma sesión para confirmar que los totales se recalculan y no quedan valores antiguos.
Recorre estados de pago
Prueba éxito, rechazo/cancelación y métodos asíncronos en sandbox o con importe pequeño aprobado. Confirma un objeto e ID de transacción por orden.
Inspecciona webhook y retorno por separado. Una thank-you correcta no prueba que el callback actualizase la orden. Repetir un evento sandbox no debe duplicar stock o fulfilment.
Para métodos asíncronos, observa Pending, confirmación tardía y timeout. El pedido no debe completarse antes de la evidencia financiera ni quedarse bloqueado después del callback válido. Registra el ID del evento para demostrar idempotencia.
Confirma pedido y stock
Revisa estado, notas, reducción, reservas e inventario externo. Prueba cancelación/reembolso según política.
En variaciones, confirma SKU exacto. Una venta reduce una vez y una reposición legítima queda auditada. No muevas estados de ida y vuelta.
Para virtuales/descargables, verifica acceso solo tras el estado pagado previsto, protección frente a otros usuarios y caducidad del enlace.
Verifica comunicaciones
Confirma Processing/Completed al cliente y New order al equipo. Sigue generación, aceptación SMTP e Inbox.
Abre enlaces de cuenta/pedido como destinatario. Revisa texto plano y traducciones. No incluyas información personal o credenciales en el acta.
Prueba interfaces
Comprueba primer invitado, login/reset, Mi cuenta y móvil. Los administradores suelen evitar caché y seguridad, por lo que no bastan.
Abre la lista, busca la orden y confirma una llegada a fulfilment/reporting. Prueba teclado y errores visibles, no solo el camino feliz con ratón.
Repite como usuario no administrador con permisos reales. Confirma que soporte pueda consultar sin ver datos que no necesita y que el personal de almacén reciba solo una tarea de preparación.
Confirma medición sin confundirla con finanzas
Inspecciona un purchase GA4 con ID, valor, moneda e items bajo el consentimiento elegido. Recargar confirmación no debe crear otra compra.
GA4 no siempre iguala WooCommerce por consentimiento y bloqueos. Tienda y pasarela son la verdad financiera. Etiqueta y reembolsa pruebas productivas según contabilidad.
Observa después de reabrir
Monitoriza errores PHP, webhooks, rechazos SMTP, backlog y estados anómalos durante un periodo de ventas representativo.
Registra versiones, reparación, rollback y resultados. El mantenimiento recurrente debe convertir la lista en pruebas sintéticas para que el cliente no descubra la próxima regresión.
Establece una ventana de observación y umbrales: fatals, tasa de pagos fallidos, antigüedad de cola y rechazos SMTP. Cierra la incidencia solo cuando el caso original, la regresión completa y el periodo observado cumplen los criterios.