Test y producción son sistemas separados: usan otras credenciales, cuenta comercial, webhooks, fraude y a veces métodos diferentes. Un pedido sandbox demuestra la integración básica, no que el comercio esté listo para cobrar.
No alternes modos en una tienda activa sin control. Conserva primero el estado de la transacción fallida y evita reintentos.
Registra el fallo real
Anota hora, ID de pedido, importe, moneda, método y error seguro. Busca en el panel del proveedor una transacción o intento rechazado.
No guardes tarjeta, CVV, token de wallet ni datos completos. Correlaciona mediante request ID y transaction ID.
Determina si falla antes de salir, durante autenticación, al volver o al actualizar el estado.
Confirma modo y credenciales
Verifica que WooCommerce está en live y usa claves públicas y secretas de producción pertenecientes a la misma cuenta.
Comprobación segura:
- modo seleccionado
- identificador merchant
- entorno donde se creó la clave
- estado y permisos
- ningún secret en logsRota cualquier secret expuesto. No lo muestres para demostrar que existe.
Revisa la activación comercial
El proveedor puede permitir sandbox antes de completar verificación de empresa, banco o métodos reales. Comprueba restricciones, payout holds y capacidades del entorno live.
Confirma que moneda, país y método están habilitados. JavaScript cacheado puede mostrar un método que la API rechaza.
Solo el propietario o persona autorizada debe cambiar datos legales o bancarios.
Compara dominio y HTTPS
Wallets e iframes pueden exigir registro del dominio de producción. El checkout debe usar HTTPS válido y no contener mixed content.
Revisa orígenes, redirects y return URL para el host canónico con o sin www. Que staging esté autorizado no valida producción.
Tras cambiar dominio, actualiza panel y WooCommerce conjuntamente.
Inspecciona también Content Security Policy y el SDK que carga el navegador. El entorno live puede usar hosts distintos para scripts, iframes y autenticación 3-D Secure. Una allowlist que solo contempla sandbox produce un bloqueo del navegador antes de que PHP reciba el intento.
Configura webhooks live aparte
Sandbox y live suelen tener endpoints, signing secrets e historiales distintos. Confirma que producción apunta al dominio final y recibe los eventos exigidos.
Inspecciona respuestas: 403 puede ser firewall y 500 necesita log PHP. No reutilices el secret sandbox.
Excluye únicamente la ruta documentada de caché o seguridad incompatible.
Revisa fraude y autenticación reales
Producción usa decisiones del emisor, 3-D Secure, dirección, límites y scoring. Busca el decline code y distingue rechazo del cliente de error de integración.
No debilites todas las reglas para hacer pasar una tarjeta. Prueba un pago de bajo valor autorizado e identifica la regla.
Privacidad y consentimiento pueden afectar el frame. Reproduce en el navegador implicado.
Comprueba la versión de API fijada en la cuenta y la esperada por el plugin. Una cuenta antigua o una actualización del proveedor puede devolver campos o requisitos diferentes únicamente en live. No cambies la versión global sin revisar otras integraciones que compartan la cuenta.
Comprueba la salida del servidor
Los endpoints live pueden estar bloqueados por egress, DNS, certificados CA antiguos o seguridad. Correlaciona logs de pasarela con errores PHP/cURL.
Verifica la hora del servidor: las firmas fallan si el reloj difiere. Actualiza PHP o certificados por la ruta soportada.
No desactives la validación TLS.
Verifica además que el servidor resuelve los dominios live por IPv4 e IPv6 según su conectividad real. Un registro AAAA o proxy de salida mal configurado puede afectar solo al endpoint de producción mientras sandbox continúa accesible.
Repara y prueba en vivo
Corrige la frontera demostrada: credenciales, capacidad de cuenta, dominio, webhook, firewall o autenticación. Conserva una reversión.
Ejecuta un único pago autorizado de bajo valor. Confirma un pedido, una captura, ID correcto, webhook, stock y email. Reembolsa por el proceso normal si procede.
Prueba también retorno y cancelación sin duplicar transacciones.
Repite una segunda ruta representativa solo después de conciliar la primera, por ejemplo tarjeta con 3-D Secure o el wallet principal. No declares resuelta toda la pasarela a partir de un método que evita justamente la autenticación o el callback que fallaba.
El mantenimiento recurrente debe vigilar webhooks live y hacer pruebas tras cambios de dominio, SSL, pasarela o checkout. Sandbox es útil, pero la preparación de producción necesita evidencia propia.