Si en prémer-lo no apareix cap indicador, missatge ni petició de xarxa, l’error normalment es produeix al navegador abans que WooCommerce rebi les dades. Pot haver-hi una capa invisible, un botó deshabilitat, validació oculta, una excepció JavaScript o codi que cancel·la el submit.
Comprova què produeix realment el clic abans de canviar el servidor o la passarel·la.
Defineix què significa “no fa res”
Prova una vegada en una finestra privada. Anota si canvia el botó, la pàgina salta cap a un camp, apareix un error a Console o Network envia el checkout.
Revisa també les comandes recents i el panell de la passarel·la. Un client pot dir “res” encara que la pàgina hagi fallat després del cobrament.
Protegeix contra duplicats abans de demanar un altre intent.
Comprova si el botó rep el clic
Inspecciona l’element. Ha d’estar visible, habilitat i dins del formulari. Utilitza el selector per descobrir si un bàner de galetes, una màscara, un xat o una capa transparent queda al damunt.
/* Només per a diagnòstic local o staging */
.capa-sospitosa {
outline: 3px solid red;
pointer-events: none;
}No deixis aquest CSS a producció: pot inutilitzar controls de consentiment o accessibilitat.
Llegeix el primer error del navegador
Obre Console, recarrega i prem una vegada. Investiga el primer error nou; els següents poden ser-ne conseqüències.
Les fonts habituals són connectors de camps, el tema, l’autocompleció, el consentiment o JavaScript comprimit. Un objecte indefinit, un error de jQuery o un script bloquejat és una pista millor que desactivar-ho tot.
Comprova CSP i les extensions del navegador. Repeteix amb un perfil net abans de modificar la botiga.
Inspecciona camps i validació
WooCommerce pot impedir l’enviament per un camp obligatori mentre el CSS amaga l’avís o el desplaçament. Cerca aria-invalid="true" i contenidors d’error a la part superior.
Els camps propis necessiten un nom únic, un valor vàlid i la mateixa validació al servidor. Prova adreces, telèfons i codis postals corresponents al país seleccionat.
No eliminis globalment la validació només per superar una prova.
Confirma l’esdeveniment i la petició
Filtra checkout a Network i prem. Si no surt cap petició, el problema continua al layout, JavaScript o validació. Si existeix i retorna error, analitza’n l’estat i el cos: ja no és un error del botó.
Cerca handlers que cridin preventDefault() sense reprendre el checkout. Revisa condicions segons el mètode de pagament, l’acceptació de termes o els camps dinàmics.
Comprova que no hi hagi dos formularis amb el mateix ID.
Aïlla la integració responsable
Reprodueix el disseny a staging amb el mateix tema, tipus de checkout i dades pertinents. Desactiva primer la combinació de scripts si n’amaga l’origen i prova després una integració cada vegada.
Canviar temporalment a un tema estàndard pot demostrar que hi intervé, però no és la reparació final. Localitza la plantilla, el selector o l’script concret.
Conserva evidències i una via de reversió de cada prova.
Repara sense debilitar el checkout
Corregeix el selector, handler, z-index, marcatge invàlid o ordre de càrrega. Restaura els controls de consentiment, frau i pagament que hagis aïllat.
No utilitzis snippets que habilitin contínuament el botó: poden permetre comandes incompletes o múltiples.
Purga només la caché del recurs afectat i confirma que el fitxer corregit arriba a un visitant sense sessió.
Verifica totes les rutes del client
Prova convidat i compte, cada mètode actiu, pulsació mòbil, teclat, termes i errors de validació. Una comanda vàlida s’ha de crear una vegada, reduir l’estoc una vegada i generar una transacció coincident.
Comprova que el doble clic, tornar enrere i canviar de mètode no dupliquen accions.
En manteniment recurrent monitoritza errors front-end i executa un checkout de baix risc després d’actualitzacions de tema, WooCommerce, passarel·la o optimització. Així el client no es converteix en el sistema d’alerta.