Resposta breu: l’checkout travessa JavaScript del navegador, sessió i carrit, petició al servidor, passarel· la de pagament i creació de la comanda. El mateix símptoma visible pot venir de qualsevol, així que identifica la capa que falla abans de tocar la configuració.
Protegeix primer les dades
No repeteixis el pagament amb una targeta real ni borros comandes fallits per a “ordenar”: aquests registres i l’historial de la passarel· la indiquen si hi ha hagut moviment de diners. Anota l’hora, el mètode de pagament, el dispositiu i qualsevol referència de transacció abans de canviar res.
Observa la petició que falla al navegador
Obre les eines de desenvolupador, vés a Consola i Xarxa i intenta el checkout. Un error de JavaScript en vermell apunta a un conflicte d’scripts o a una minificació trencada. La petició clau és ?wc-ajax=checkout: si retorna 500 o esgota el temps, l’error és del servidor i la seva resposta sol contenir el propi error de PHP.
Llegeix els registres de WooCommerce
Vés a WooCommerce &# 8250; Estat &# 8250; Registres pels registres de la passarel · la i errors fatals amb hora, i a Estat &# 8250; Estat del sistema per una base de dades desactualitzada, una plantilla sobrescrita antiga o un conflicte de plugins. Contrasta l’hora d’una prova fallida amb el registre per veure si la comanda es va crear, si es va intentar el pagament i on es va trencar la cadena.
Sospitosos habituals
- Memòria cau: la pàgina de checkout mai s’ ha de caixejar: una pàgina antiga porta un nonce caducat que bloqueja l’enviament. Exclou carrit, checkout i la meva- centa de la memòria cau de pàgina completa i de l’CDN.
- Optimització JS: minificar/ combinar de forma agressiva trenca els scripts de l’checkout; exclueix- los.
- Conflicte plugins: Prova-ho en staging en comptes de desactivar plugins de pagament o impostos en producció.
- Confirmació de la passarel· la: una autorització que té èxit sense confirmació deixa la comanda encallat.
Verifica el cicle complet
Usa el mode de proves de la passarel· la o una comanda controlada d’import baix i ressegueix producte carrit checkout – pagament – confirmació. Després verifica l’estat de la comanda, el moviment d’estoc, el correu de confirmació i el webhook. Un checkout només està reparat quan el cicle complet acaba de forma coherent, no quan desapareix l’error visible.
CRITERI D’INCIDENT WP REPAIR
Seqüència d’intervenció segura
El checkout és una cadena entre JavaScript, sessió, validació, passarel· la, creació de comanda, estoc i avisos. La primera transició trencada identifica la capa que cal reparar.
- Captura consola i resposta wc-ajax d’un intent controlat.
- Creua l’hora amb registres fatals i de passarel·la de WooCommerce.
- Verifica que carrit, checkout i compte s' exclouen de la memòria cau completa i CDN.
- Usa mode de prova o comanda d’import baix i registra cada canvi d’estat.
Què ha de quedar verificat
- Una comanda controlada completa producte, carrit, pagament i confirmació.
- La transacció i la comanda es referencian mútuament.
- Stock, correu i webhook són correctes i repetibles.
Fonts tècniques oficials
Aquesta guia explica el diagnòstic. Si la web està afectada ara mateix, la intervenció ha de preservar una via de recuperació i verificar el recorregut real del negoci.
Veure el servei de reparació urgent →SOBRE ESTE SÍNTOMA
Preguntes freqüents d'aquesta guia.
He de tornar a provar un checkout fallit amb una targeta real per veure si funciona?+
No, evitar repetits intents de targeta real i no eliminar les comandes fallides tampoc. Aquests registres, juntament amb el registre de transaccions de el gateway, són exactament el que li diu si els diners realment es va moure, i destruir-los elimina l'evidència que necessita per diagnosticar el fracàs.
Quina petició única haig de veure al navegador per veure on checkout realment es trenca?+
Mira la petició?wc-ajax=checkout a la pestanya Xarxa mentre intenta checkout. Si retorna un error de 500 vegades, l’error és del costat del servidor, i la seva resposta sovint conté l’error PHP subjacent directament.
Pot realment trencar el cau checkout fins i tot si el rest del lloc es carrega bé?+
Sí, i és una de les causes més comunes. La pàgina checkout mai ha de ser enviada des de la memòria cau, perquè una còpia en cau ranci porta una nonce de seguretat caducada que bloqueja la presentació, pel que cart, checkout, i les pàgines del meu compte neceswebn ser excloses de caixet de pàgina completa i el CDN per complet.
Com sé si el problema és realment corregit, versus només l’error visible que desapareix?+
Camini el cicle complet fins al final usant el mode de prova de el gateway o una comanda controlada de baix valor: producte, carro, checkout, pagament, confirmació. Després verifiqueu l’estat de la comanda, el moviment stock, el correu electrònic de confirmació, i el webhook tot completat coherentment, no només que la pàgina checkout va deixar de mostrar un error.