Si el checkout de WooCommerce continua carregant, identifica primer si espera abans d’enviar, durant una petició o en processar la resposta. L’indicador tot sol no localitza l’error. Conserva un intent registrat i relaciona’l amb l’estat de la comanda i del pagament.
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.
Relaciona l’intent amb les comandes recents i l’estat real. Un registre checkout-draft és temporal; no demostra un enviament complet ni un càrrec. Compara mètode, hora i evidència del pagament. La referència d’estats de WooCommerce explica la distinció.
Amb clients reals, revisa les comandes i el proveïdor abans de reproduir.
Inspecciona la petició del checkout
Obre Network abans de l’intent controlat. Al checkout clàssic, inspecciona el POST que conté wc-ajax=checkout. Al bloc, identifica el POST final a la ruta de checkout de Store API, com ara /wp-json/wc/store/v1/checkout. Registra mètode i ruta: consultar dades és una altra operació.
Si encara no hi ha enviament final, comprova si queden càlculs de totals o enviament pendents. El flux documentat del bloc inclou un estat de càlcul que pot deshabilitar el botó. Diagnostica què espera abans de modificar-lo.
Exemples de rutes:
Clàssic: POST /?wc-ajax=checkout
Bloc: POST /wp-json/wc/store/v1/checkout
Registra: mètode, estat, temps, tipus i cos de resposta.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.
Què ensenyen sis respostes de prova sense connexió
Vam executar sis exemples propis amb un petit intèrpret local de respostes. Quatre portaven HTTP 200 i van conduir a quatre comprovacions diferents. Va ser un exercici didàctic sense connexió: no vam contactar amb cap botiga, client, comanda o servei de pagament. Els noms descriuen exemples, no errors mesurats a la botiga d’un client.
- Sense enviament registrat: la mostra no conté una petició final. Comprova la captura i l’estat previ a l’enviament abans d’investigar una resposta del servidor.
- Validació del checkout clàssic: HTTP 200 amb
result: failureés JSON llegible que comunica un rebuig de l’aplicació. - HTML al checkout clàssic: HTTP 200 amb una pàgina de manteniment no es pot interpretar com la resposta JSON esperada.
- Consulta d’esborrany del bloc: GET amb HTTP 200 i
status: checkout-draftdescriu dades del checkout, sense demostrar un enviament final correcte. - Resposta d’un mètode offline del bloc: POST amb HTTP 200,
status: on-holdipayment_status: successnecessita interpretació segons aquell mètode. No prova un càrrec en targeta. - Accés rebutjat: HTTP 403 continua sent un error HTTP encara que el cos sigui JSON vàlid. Llegeix l’error real i relaciona la petició abans d’atribuir-ne una causa.
Dos exemples propis amb HTTP 200:
POST clàssic: {"result":"failure"}
GET del bloc: {"status":"checkout-draft"}
Mateix estat HTTP; mètode, cos i comprovació diferents.Per repetir l’exercici, registra per separat mètode, ruta, estat HTTP i cos. Classifica la resposta abans de decidir què ha passat amb la transacció. L’intèrpret no dona per demostrat un càrrec real a partir d’aquestes mostres. Contrasta el codi de resposta del checkout clàssic i la referència de Store API amb la implementació; les extensions i versions poden canviar els detalls.
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.
Per a una avaluació de reparació del checkout, envia tipus de checkout, mètode de pagament, URL afectada i hora de l’intent. Si el proveïdor ja mostra un càrrec, consulta pagament completat amb comanda pendent abans d’autoritzar un altre intent.
Per encarregar la investigació, el dossier de diagnòstic del checkout WooCommerce per al 2027 permet ordenar els fets coneguts, les comprovacions pendents i el pas següent autoritzat.