Un fallo móvil no es siempre CSS responsive. El diseño muestra controles diferentes, pero también cambian navegador, privacidad, wallets, teclado, red y almacenamiento.
Empieza con un dispositivo físico y conserva el estado del pedido y pago. Tocar repetidamente un botón congelado puede duplicar peticiones.
Describe la ruta afectada
Anota modelo, sistema, navegador, orientación, red, método de pago y paso exacto. Indica si el teclado está abierto y si existe wallet, redirección o iframe.
Compara iPhone/Safari y Android/Chrome cuando los informes no identifiquen plataforma. La emulación ayuda con layout, pero no reproduce todas las cookies, wallets o teclados.
Usa compras sintéticas y un producto controlado.
Busca controles cubiertos
Carritos fijos, chat, banner de cookies y footer pueden tapar Realizar pedido o casillas en una pantalla baja. Inspecciona con teclado abierto y zoom habitual.
/* Ayuda visual de diagnóstico, no arreglo universal */
.woocommerce-checkout #place_order {
outline: 3px solid #d00;
}Prueba foco por teclado y etiquetas de lector, además del toque. No aumentes z-index sin entender qué control debe quedar encima.
Inspecciona la validación móvil
El tipo de input determina teclado y valores. Teléfono, email o código postal pueden autocompletarse en un formato que una validación propia rechaza. El error puede aparecer fuera de la zona visible.
Usa datos sintéticos para inspeccionar el envío. Confirma que los campos ocultos de escritorio no siguen siendo obligatorios y que cambiar país actualiza provincia y código postal.
No registres direcciones ni datos de pago reales.
Captura navegador y red
Usa depuración remota o un recolector seguro que excluya datos personales. Inspecciona estado, respuesta y duración de la petición.
Una red móvil revela timeouts que el Wi-Fi rápido oculta. El throttling ayuda, pero diferencia lentitud de fallo. Optimizar imágenes no corrige una llamada de pasarela que bloquea PHP treinta segundos.
Relaciona la hora con los logs del servidor.
Separa wallets y pasarelas embebidas
Apple Pay, Google Pay e iframes de tarjeta tienen requisitos de dominio, HTTPS y navegador. Comprueba si tarjeta normal o transferencia funciona en el mismo teléfono.
Si solo falla la wallet, revisa registro de dominio, merchant, orígenes permitidos y logs. Si ningún método envía petición, vuelve a layout, validación y JavaScript.
No captures tarjetas, tokens ni payloads completos.
Revisa JavaScript y optimización
Las ramas móviles pueden iniciar sliders, direcciones o resúmenes que escritorio no ejecuta. Lee la primera excepción y su archivo.
Delay, bundles y consentimiento pueden cambiar el orden. Aísla una optimización en staging, regenera assets y repite en el dispositivo real.
No desactives todos los plugins de producción durante ventas.
Comprueba privacidad y cookies
Safari y navegadores restrictivos pueden bloquear almacenamiento cross-site o el frame de pago. Usa un único host HTTPS canónico y confirma que la sesión persiste.
El retorno del proveedor debe volver al mismo dominio. Compara navegadores internos de redes sociales con Safari o Chrome y ofrece abrir externamente cuando sea necesario.
Prueba los estados de consentimiento sin debilitar cookies esenciales.
Aplica una reparación estrecha
Corrige el problema probado: espaciado, campo oculto requerido, handler, orden, URL, cookie o dominio de pasarela. Conserva accesibilidad y seguridad.
Publica con versionado de assets para que el móvil no conserve el archivo antiguo. Verifica sesión nueva y recurrente.
Comprueba más allá del botón
Completa pedidos de invitado y cliente en la plataforma afectada, con cambios de dirección, errores, cancelación y retorno exitoso.
Confirma un pedido, un cobro, stock correcto y emails entregados. Revisa también doble toque y recuperación al volver de la wallet.
El mantenimiento recurrente debe probar dispositivos reales después de cambios de tema, consentimiento, rendimiento y pasarela. Móvil es una ruta transaccional distinta, no solo un escritorio pequeño.