Un indicador que no acaba acostuma a indicar que el navegador ha enviat la compra però no ha rebut una resposta utilitzable. Pot haver-hi un error PHP, una passarel·la lenta, una petició AJAX bloquejada, una sessió trencada o JavaScript incapaç de processar la resposta.
No premis diverses vegades. Comprova primer si WooCommerce ha creat una comanda o la passarel·la ha cobrat, perquè els reintents poden duplicar-los.
Conserva un intent fallit
Anota l’hora exacta, un correu sintètic, el carret, el mètode de pagament, el navegador i el total. Utilitza un producte controlat i el mode de proves de la passarel·la quan estigui disponible.
Cerca comandes d’aquella hora, incloses Pendent de pagament, Fallida i Esborrany. Si n’existeix una, l’error s’ha produït després que WooCommerce comencés a processar.
Amb clients reals, revisa les comandes i el proveïdor abans de reproduir.
Inspecciona la petició del checkout
Obre Network, envia una vegada i localitza la petició amb wc-ajax=checkout. Ha de finalitzar amb un estat HTTP i normalment retorna JSON.
Petició: /?wc-ajax=checkout
Anota:
- codi HTTP
- temps de resposta
- tipus i cos de resposta
- redirecció o missatge de bloqueig
Un 500 apunta a PHP o servidor; un 403, al tallafoc o seguretat. Una petició pendent suggereix timeout, workers ocupats o una crida externa lenta. Un 200 amb HTML en lloc de JSON pot ser un warning, login o error emmagatzemat a la memòria cau.
Relaciona registres PHP i WooCommerce
Consulta WooCommerce > Estat > Registres i el log PHP de l’allotjament a la mateixa hora. Activa el debug temporal només si pots impedir-ne la visualització pública i la captura de dades personals.
No atribueixis el problema a qualsevol warning antic. Relaciona hora, fitxer i stack. Un error fatal a la passarel·la, els camps de checkout o una plantilla sobreescrita és una evidència més forta que un avís de cron no relacionat.
Separa la passarel·la de l’error comú
Prova de manera segura amb transferència bancària o un altre mètode offline. Si funciona i la passarel·la habitual queda carregant, revisa credencials, API, tallafoc i registre del proveïdor.
Si fallen tots els mètodes, centra’t en PHP, les sessions, WooCommerce i les personalitzacions compartides.
No canviïs una passarel·la de producció a test sense conèixer l’efecte sobre compres reals.
Revisa sessió, memòria cau i crides
Exclou Carret, Checkout i El meu compte de la memòria cau de pàgina. Confirma que les cookies WooCommerce sobreviuen entre producte, carret i pagament. Cloudflare i el connector de caché no han de servir l’estat d’un visitant a un altre.
Prova una sessió neta en una finestra privada, però conserva separadament la sessió fallida. Esborrar totes les sessions destrueix evidència i carrets actius sense demostrar la causa.
Comprova bloquejos de base de dades i workers PHP si la petició queda pendent.
Diagnostica JavaScript sense amagar el servidor
A Console comença pel primer error, no per la cascada posterior. El consentiment, l’autocompleció, Analytics o un connector de camps poden interceptar l’enviament.
Aïlla una integració sospitosa a staging o amb una prova controlada; no desactivis connectors a l’atzar a la botiga activa.
L’error JavaScript pot ser conseqüència d’HTML invàlid retornat pel servidor. Llegeix sempre la resposta abans de culpar el navegador.
Aplica la correcció mínima
Actualitza o reverteix l’únic component incompatible, corregeix l’error fatal PHP, repara l’exclusió de caché, augmenta un recurs realment esgotat o restaura la connexió amb la passarel·la.
Purga només els recursos afectats i verifica el fitxer nou com a visitant anònim. Documenta què ha canviat i com revertir-ho.
No amaguis l’indicador ni forcis una redirecció sense confirmar la comanda.
Verifica tota la transacció
Prova la compra com a convidat i usuari, en mòbil i ordinador, amb impostos, enviament, cupons, estoc, correus, estat de passarel·la i pàgina d’agraïment.
Confirma a WooCommerce i al proveïdor que hi ha exactament una comanda i un cobrament. Revisa també els intents incerts del període de la incidència.
La reparació urgent acaba quan es pot comprar i no queden transaccions dubtoses. El manteniment recurrent ha d’alertar sobre errors de checkout, webhooks i estats anòmals abans de perdre vendes.