Prioritat número u: si la pàgina de “Comanda rebuda” falla després del pagament, primer s’ha de saber si el cobrament i la comanda existeixen. Un 404, una pantalla en blanc o un bucle de redirecció pot fer pensar al client que ha de pagar de nou quan la transacció ja s’ha completat.
Separa conciliació financera i error de pàgina
Comprova ID de comanda, clau de l’ordre, transacció de la passarel·la i URL final. Si el pagament és correcte, no tornis a executar-lo: repara després l’endpoint, la sessió o el renderitzat.
Què comprovar a la URL de confirmació
- Que la ruta
order-receivedresolgui correctament. - Que la clau de comanda i les cookies arribin després de les redireccions.
- Que el CDN no estigui cachejant una resposta privada.
- Que no hi hagi un fatal del tema o d’un plugin durant el renderitzat.
Quatre diagnòstics diferents
- Rewrite trencat: l’endpoint no resol o acaba en 404.
- Sessió o clau perduda: la comanda existeix però el context d’accés desapareix.
- Error PHP: la ruta és correcta i falla la plantilla o un hook.
- Cache privada: el CDN serveix una resposta que no correspon a la sessió actual.
Ordre de reparació
- Concilia el pagament abans de repetir cap checkout.
- Repara rewrites, redireccions canòniques o l’error PHP concret.
- Exclou checkout, compte i confirmacions del cache de pàgina completa.
- Prova compres de convidat, usuari autenticat i pagament fallit.
Si el problema sembla de pagament
Quan l’ordre queda fallida encara que el cobrament existeixi, revisa la conciliació entre pagament completat i comanda fallida. Si tot sembla correcte però l’estoc no baixa, el problema ja és un altre flux: estoc que no es redueix després del pagament.
Què no has de debilitar
No eliminis la validació de la clau de comanda per “fer visible” la pàgina. Això pot exposar dades d’altres ordres i converteix una incidència de routing en un problema de seguretat.
Com demostrar que està resolt
La confirmació ha de carregar per al context autoritzat, l’estat del pagament i de la comanda ha de coincidir, i refrescar la pàgina no ha de crear un nou càrrec ni una nova ordre.
CRITERI D’INCIDENT WP REPAIR
Reconstrueix la incidència abans de corregir-la
La primera tasca és la conciliació financera; la segona és reparar les rutes de punts finals o l’execució de plantilles.
- 1
Grava ID de comanda, clau de comanda, transacció passarel· la i redirigir URL.
- 2
Comprova si la comanda existeix i el pagament s' ha completat malgrat l’error de pàgina.
- 3
Inspecciona l’estat de l’endpoint que falla, la cadena de redirecionament i PHP registres.
- 4
Test checkout endpoints i tema anul· lats amb memòria cau bypassed.
Què ha de quedar verificat
- La pàgina de confirmació es carrega per als contextos de convidats i comptes autoritzats.
- Pagament, comanda, estoc i correu electrònic d'acord.
- Actualitza la pàgina no crea cap altre càrrec o ordre.
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.
Si la pàgina de confirmació de la comanda ha fallat, ha fallat el pagament del client també?+
No necessàriament, i aquesta ambigüitat és el principal risc aquí. La primera tasca és la conciliació financera per a comprovar si la comanda existeix i el pagament completat malgrat l’error de pàgina, abans de tocar l’enrutament d’endpoint o el codi de plantilla.
És segur actualitzar o tornar a provar checkout quan la pàgina rebuda de la comanda mostra un error?+
Refresca després d’aquest tipus d’error corre el risc de crear un altre càrrec o ordre, que és exactament el que comprova el pas de verificació. Reconciliar l’estat del pagament primer, i confirmar com a part de la solució que la renovació de la pàgina de confirmació no desencadena un càrrec o ordre duplicat.
Podria un CDN mostrar-me la confirmació d’una altra ordre en comptes de la meva?+
Sí. Un emmagatzematge al cau CDN d’una pàgina de confirmació privada pot servir una resposta invàlida o altres detalls de comanda de la sessió, per la qual cosa les pàgines de confirmació i compte han de ser excloses de la memòria cau de pàgina completa com a part de la reparació.
Afluixar la tecla de comanda és una forma raonable d'evitar que les pàgines de confirmació es trenquin?+
No, això es descarta explícitament. Debilitar la comprovació de la clau de comanda per exposar els detalls de la comanda elimina més fàcilment la protecció que impedeix a un client veure la comanda d’un altre client, per la qual cosa la correcció ha de fer final reescriure, redirecionaments o l’error fatal plantilla en el seu lloc.