Cuando una tienda empieza a rechazar pagos, el fallo suele parecer de la pasarela, pero muchas veces está en otro punto del flujo: credenciales caducadas, webhooks sin respuesta, caché agresiva, conflictos de plugins, SSL mal resuelto o límites del servidor. El resultado es el mismo: pedidos bloqueados, cobros inciertos y una incidencia que necesita diagnóstico rápido, sin tocar ventas reales.
Si tu API de pagos falla en WooCommerce, no asumas que el problema está en la pasarela: puede venir de credenciales, webhooks, caché, plugins, SSL o del servidor. La forma más rápida de resolverlo es seguir un diagnóstico ordenado, revisar logs y validar la integración en sandbox antes de escalar a soporte.
Resumen del proceso
- Comprueba si el error aparece en WooCommerce, en el navegador o en la pasarela.
- Reproduce el cobro en sandbox o modo prueba para no tocar pedidos reales.
- Revisa logs de WooCommerce, consola del navegador y eventos de la pasarela.
- Mapea el error con su causa probable y aplica la solución rápida correcta.
- Escala con evidencias si el fallo viene de Stripe, PayPal, Redsys o Mercado Pago.
| Señal que ves |
Qué suele indicar |
Qué hacer primero |
| Checkout roto o botón que no responde |
Conflicto de JavaScript, caché o tema |
Revisa consola, desactiva minificación y prueba con tema limpio |
| Pedido creado pero no cambia de estado |
Webhook ausente, retrasado o inválido |
Mira eventos de la pasarela y el log de WooCommerce |
| Error 401 o 403 |
Credenciales, permisos o entorno incorrecto |
Valida claves API, OAuth y modo test o live |
| Error 500, 502 o 503 |
Servidor, proxy, timeout o firewall |
Revisa logs del hosting y tiempo de respuesta |
Comprueba dónde falla y acota la causa
La primera tarea es separar el fallo por capa: WooCommerce, navegador, webhook, pasarela o servidor. Esa separación ahorra tiempo porque cada capa rompe de una forma distinta. Un error visible en pantalla no significa lo mismo que un pedido pagado sin confirmación.
Mira el punto exacto del bloqueo
En WooCommerce, entra en el pedido afectado y revisa el estado. Si el pedido se crea pero no pasa de "Pendiente" o "Fallido", el problema suele estar en la confirmación del pago o en el webhook.
Si el checkout no termina ni redirige, el fallo suele vivir antes, en la página de pago, en un script roto o en una validación que no llega a ejecutarse. Lo que omiten muchas guías sobre este punto es que dos fallos parecidos pueden venir de sitios muy distintos.
Un caso habitual: el cliente pulsa pagar, la página se queda pensando y no aparece ningún cargo. En ese escenario, muchas veces el problema no está en Stripe o PayPal, sino en un plugin de caché que bloquea scripts del checkout.
La frase más útil en este punto es esta: si el pedido no cambia de estado, piensa en webhook; si el checkout se rompe, piensa en frontend o servidor.
Diferencia 4xx, 5xx y validación
Los errores 4xx apuntan a algo que el sistema no acepta de entrada. Puede ser una clave mal puesta, un token caducado o un dato inválido. Los 5xx apuntan más a servidor, disponibilidad o tiempo de respuesta.
Si ves un 401 o un 403, la investigación empieza por credenciales y permisos. Si ves un 502 o un 503, toca mirar hosting, proxy, firewall o caídas de la propia pasarela.
Reproduce el fallo en sandbox sin tocar pedidos reales
La forma más segura de diagnosticar una API de pagos es repetir el fallo en modo prueba. Así no arriesgas pedidos reales y puedes ver si el error vive en la integración o solo en producción. Este paso suele tardar entre 10 y 20 minutos si la pasarela ya tiene sandbox activo.
Activa el modo prueba
En el plugin de pago, cambia a entorno de pruebas o sandbox. Usa claves de test, no las de producción. Si el plugin mezcla entornos, el error suele estar ahí mismo.
Haz una compra de importe bajo y guarda cada resultado. Mira si el cobro se autoriza, si aparece el evento en la pasarela y si WooCommerce cambia el estado del pedido.
Un entorno de prueba bien montado se parece a una maqueta de tienda: no vende, pero enseña dónde se atasca todo.
Compara prueba y producción
Si falla en sandbox y en producción, el problema suele ser credenciales, configuración del plugin o validación de datos. Si solo falla en producción, mira SSL/TLS, firewall, DNS, reglas del hosting o webhooks bloqueados.
La mayoría de artículos dice que el sandbox sirve para "probar". Lo que no mencionan es que también sirve para descartar falsos culpables, algo muy útil cuando el equipo está mirando la pasarela equivocada.
Flujo de diagnóstico en 4 capas
1. Checkout: revisa si la página carga y el botón responde.
2. WooCommerce: revisa estado del pedido y logs del plugin.
3. Pasarela: comprueba webhook, eventos y credenciales.
4. Servidor: mira SSL/TLS, cURL, firewall y tiempos de respuesta.
Lee los logs que de verdad aclaran el fallo
Los logs son la prueba más útil para dejar de adivinar. El más frecuente en este punto es revisar solo el mensaje visible y olvidar el registro técnico, que suele decir la verdad completa. En 5 a 15 minutos puedes encontrar pistas claras si sabes dónde mirar.
Revisa WooCommerce y el navegador
En WooCommerce, entra en Estado > Registros y abre el archivo del plugin de pago. Busca mensajes con hora exacta, respuesta de la API, errores de autenticación y avisos de webhook.
En el navegador, abre la consola. Si ves errores de JavaScript, CORS o contenido mixto, el checkout puede romperse antes de llegar a la pasarela. Eso pasa mucho cuando el SSL/TLS está mal cerrado o algún plugin toca scripts.
La evidencia visual ayuda mucho aquí. En la captura del navegador se ve enseguida si un script del pago no carga o si la petición se bloquea.
Una consola limpia no descarta nada. Solo significa que todavía no has abierto el punto correcto.
Revisa eventos de la pasarela
Stripe, PayPal, Redsys y Mercado Pago guardan eventos con marcas de tiempo y estados. Ese registro te dice si la pasarela recibió la petición, si la procesó y si devolvió una respuesta útil.
Stripe suele mostrar event ID y request ID. PayPal suele ayudar con transaction ID y webhook ID. Redsys exige revisar firma, terminal y código de respuesta. Mercado Pago deja trazas del payment ID y la notificación recibida.
Usa esta matriz para pasar de síntoma a causa
Esta matriz convierte el síntoma en una pista concreta. Si el checkout falla, no hace falta probar todo a ciegas. Puedes ir directo al grupo correcto de causas y ahorrar mucho tiempo.
Síntoma, causa y acción
| Síntoma |
Causa probable |
Acción rápida |
| Error 401 o 403 |
Credenciales, OAuth o permisos |
Revisa claves, entorno y firma |
| Pedido cobrado pero sin actualizar |
Webhook caído o mal suscrito |
Valida URL, firma y eventos |
| Checkout no carga |
JS roto, caché o tema |
Desactiva minificación y prueba tema limpio |
| Tiempo de espera o corte |
Servidor, firewall o latencia |
Revisa hosting, cURL y SSL/TLS |
| Pago rechazado sin explicación |
3D Secure, antifraude o datos inválidos |
Comprueba PSD2, tarjetas y datos del cliente |
Qué apunta a credenciales
Si el error aparece al autenticar, casi siempre hay una clave mal copiada, una clave del entorno equivocado o un permiso que faltaba. También pasa cuando se usa producción con claves de test, o al revés.
En Stripe y PayPal, este tipo de error suele salir rápido. En Redsys y Mercado Pago, la firma o el token pueden estar bien un día y mal al siguiente si se cambió algo en el panel.
Qué apunta a webhooks
Si la pasarela cobra, pero WooCommerce no mueve el pedido, el webhook es el primer sospechoso. Eso suele pasar cuando la URL cambió, la firma no coincide o un plugin bloquea la llamada entrante.
Un webhook inválido puede quedar en cola y parecer “medio vivo”. Esa trampa confunde mucho, porque el panel de la pasarela muestra el evento, pero la tienda sigue igual.
La diferencia entre un pago aceptado y un pedido confirmado casi siempre la marca un webhook bien resuelto.
Revisa claves, SSL y seguridad del servidor
Las claves API y el certificado SSL/TLS no son trámites decorativos. Son la puerta de entrada y el sello de confianza. Si algo falla ahí, la API de pagos empieza a comportarse como una puerta que no abre bien.
Valida credenciales y entorno
Comprueba que usas claves correctas para el entorno correcto. Test y producción no se mezclan. Si se cruzan, el error suele ser inmediato y muy claro.
Revisa también autenticación OAuth si la pasarela la usa. Un token caducado o mal renovado rompe la comunicación y deja mensajes que parecen más confusos de lo que son.
Un token caducado se parece a una llave vieja: encaja casi bien, pero no abre la puerta.
Comprueba SSL/TLS y firewall
El certificado debe estar activo, válido y bien encadenado. Si el servidor presenta un SSL mal configurado, algunas llamadas salientes fallan o la pasarela rechaza la respuesta.
También conviene revisar firewall, ModSecurity y reglas del hosting. Un bloqueo de cURL o una IP filtrada puede cortar la comunicación sin que WooCommerce muestre una explicación clara.
Escala con pruebas útiles para el soporte
El soporte responde mucho mejor cuando recibe pruebas concretas. Un ticket con hora, ID de evento y captura avanza. Un mensaje genérico suele ir al fondo de la cola. En 10 minutos puedes preparar un paquete de evidencias sólido.
Qué enviar a stripe, PayPal y redsys
Envía siempre el ID del pedido de WooCommerce, el ID de transacción o evento, la hora exacta y una captura del error. Añade también el log del plugin y si el fallo ocurrió en test o en live.
Para Stripe, adjunta event ID, request ID, estado del webhook y entorno. Stripe suele resolver más rápido cuando ve el rastro completo del evento.
Para PayPal, envía transaction ID, webhook ID, país de la cuenta y si el pago pasó por redirección o por botón directo. PayPal suele necesitar contexto para distinguir problema de cuenta y problema de integración.
Para Redsys, añade número de pedido, firma, terminal, código de respuesta y captura del retorno. En Redsys, ese detalle ahorra muchas vueltas.
Para Mercado Pago, incluye payment ID, status, access token usado y notificación recibida. Si el pago entra pero no confirma, esa información es la que separa un webhook roto de una configuración mala.
La evidencia manda más que la intuición. Un buen ticket suele ahorrar horas de ida y vuelta.
Cómo redactar el caso
Escribe primero el síntoma. Después añade qué cambió antes del fallo. Cierra con lo que ya has probado. Así el soporte no pierde tiempo pidiendo datos que ya deberías tener.
Un caso concreto anónimo: una tienda veía cobros aceptados en PayPal, pero WooCommerce seguía dejando pedidos en espera. El soporte pidió el webhook ID, la URL de retorno y el log. Con eso se vio que el webhook apuntaba a una URL antigua tras cambiar de dominio.
Evita que el cobro vuelva a romperse
La forma más eficaz de evitar recaídas es vigilar cambios, logs y webhooks con una rutina simple. Si actualizas WordPress, WooCommerce o el plugin de pago, prueba el checkout el mismo día. Ese hábito detecta fallos antes de que los vea el cliente.
Revisión mensual mínima
Revisa que las claves sigan activas, que los webhooks respondan y que el SSL/TLS siga válido. Comprueba también que la caché no esté tocando scripts del checkout y que el hosting no haya cambiado límites de PHP o firewall.
Si trabajas con Mantenimiento WordPress, guarda una copia antes de cambios y anota fecha, hora y plugin afectado. Esa trazabilidad vale oro cuando un fallo aparece dos semanas después.
Un histórico corto pero limpio vale más que diez capturas sueltas.
Qué registrar tras cada cambio
Anota la versión de WordPress, WooCommerce, el plugin de pago y el tema. Añade también si hubo cambio en caché, seguridad, dominio o servidor. Cuando vuelva el problema, podrás comparar sin empezar de cero.
Los datos apuntan a que muchas incidencias se repiten tras actualizaciones pequeñas, no grandes. Por eso conviene probar siempre el checkout después de cada cambio relevante.
Este método no aplica si el problema no está ligado a cobros en WooCommerce, o si la web no usa una pasarela con API. Tampoco sirve cuando el problema es comercial, como falta de ventas, y no técnico. Si el pago ya funciona pero nadie compra, hace falta otra revisión distinta.
Preguntas frecuentes sobre la API de pagos
¿Por qué un pago falla en WooCommerce aunque la tienda parezca correcta?
Porque el fallo puede estar antes o después de la pasarela. WooCommerce, el tema, la caché o un plugin de seguridad pueden romper el checkout sin tocar Stripe o PayPal. Si el pedido ni siquiera se crea, mira frontend y servidor. Si se crea pero no se confirma, mira webhook y logs.
¿Qué significa un error 401 o 403 en una API de pagos?
Significa problema de autenticación o permisos. Suele salir por claves API mal copiadas, entorno equivocado o token caducado. En Stripe, PayPal o Mercado Pago, este error casi siempre apunta a credenciales. Si aparece de golpe tras un cambio, revisa primero la configuración reciente.
¿Cómo sé si el problema está en el webhook?
Si la pasarela cobra, pero WooCommerce no cambia el estado del pedido, el webhook es el principal sospechoso. Revisa si la URL recibe eventos, si la firma coincide y si el panel de la pasarela marca intentos fallidos. Un webhook mal apuntado deja la tienda desfasada aunque el cobro exista.
¿Debo cambiar las claves API cuando falla el pago?
No, no al principio. Cambiarlas sin revisar logs puede ocultar la causa real y crear otro fallo más. Primero valida si el error viene de webhooks, SSL/TLS, caché o servidor. Solo cambia claves cuando ya tengas claro que el problema está en autenticación o en entorno.
¿Qué pruebas sirven más: sandbox o producción?
Sandbox sirve para aislar la integración; producción confirma el entorno real. Si el error aparece en ambos, la causa suele ser credenciales, configuración o plugin. Si solo sale en producción, revisa firewall, DNS, SSL/TLS y webhooks. Una prueba repetida en sandbox ahorra errores caros.
¿Qué logs necesito para escalar un problema de pagos?
Necesitas el log de WooCommerce, la consola del navegador, el ID de transacción y el evento o webhook de la pasarela. Con Stripe, PayPal, Redsys o Mercado Pago, añade hora exacta y si la prueba fue en test o live. Sin esos datos, el soporte suele pedirte volver al principio.
¿Cuándo conviene parar y pedir ayuda técnica?
Conviene parar cuando ya has aislado la capa afectada y el fallo sigue sin resolverse. Si ves errores 5xx, caídas intermitentes, conflictos con seguridad o firmas de webhook que no cuadran, el tiempo se pierde rápido. En ese punto, un diagnóstico con acceso a logs y hosting suele resolver antes que seguir probando a ciegas.
Qué hacer si el cobro sigue fallando mañana
Si el cobro sigue fallando mañana, repite el diagnóstico con tres datos fijos: hora, error exacto e ID del pedido. Con eso podrás comparar si el fallo cambió o sigue igual. Esa comparación simple evita que cada intento parezca un caso nuevo.
También conviene revisar si hubo cambios en plugins, tema, caché, certificado o servidor durante las últimas 24 horas. Ahí suele estar la pista que nadie miró al principio.
La regla práctica es simple: primero aislar, luego probar, después escalar. Si se hace al revés, el soporte tarda más y la tienda pierde más tiempo.
