Abans de canviar l’estat: un client pot haver pagat encara que WooCommerce mostri la comanda com a fallida. Un timeout, un webhook rebutjat o un error fatal local poden deixar els dos sistemes desalineats. La passarel·la és la font financera per saber si els diners s’han mogut.
Concilia els diners abans de tocar la comanda
Registra ID de comanda, import, moneda, referència de la passarel·la i hora exacta. Comprova si la transacció figura capturada, autoritzada, fallida o reemborsada.
Evidència que uneix passarel·la i WooCommerce
- Historial de la transacció al proveïdor.
- Webhooks o callbacks i els seus codis de resposta.
- Notes de comanda i logs de WooCommerce.
- Canvis d’estoc i correus ja executats.
Per què “pagat” i “fallit” poden coexistir
- Error al retorn: el pagament acaba, però la redirecció final falla.
- Webhook rebutjat: WordPress no accepta o no rep l’esdeveniment.
- Error fatal local: WooCommerce falla després que la passarel·la hagi cobrat.
- Timeout: la petició local expira mentre el proveïdor completa el procés.
Repara la causa per a les ordres futures
- Concilia cada ordre afectada transacció per transacció.
- Corregeix callback, webhook o error PHP.
- Actualitza manualment només les comandes confirmades, deixant nota d’auditoria.
- Fes un pagament de prova complet després de la correcció.
Error de retorn o webhook?
Si el proveïdor mostra un cobrament correcte però falla el retorn visual, investiga routing i confirmació. Si l’esdeveniment asíncron no arriba, centra’t en el webhook. Per Stripe consulta webhook de Stripe que no actualitza la comanda; per PayPal, pagament completat però ordre sense actualitzar.
No demanis al client que torni a pagar
Fer-ho abans de revisar la transacció pot crear un càrrec duplicat. Tampoc canviïs ordres en massa sense evidència individual.
Verificació de tancament
Passarel·la i WooCommerce han de coincidir, l’estoc i els correus s’han d’haver executat una sola vegada i un nou pagament controlat ha d’actualitzar la comanda automàticament.
CRITERI D’INCIDENT WP REPAIR
Reconstrueix la incidència abans de corregir-la
Canvia l’ordre a Processament sense proves pot complir una ordre no pagada, mentre que tornar a intentar el pagament pot crear un càrrec duplicat.
- 1
Registre d'identificació de comanda, quantitat, moneda, referència passarel·la i hora exacta.
- 2
Comprova el plafó de control passarel· la per a l’estat capturat, autoritzat, fallit o reemborsat.
- 3
Coincideix amb passarel· la webhook/API registres amb WooCommerce registres i notes de comanda.
- 4
Inspecciona estoc i els efectes secundaris de correu electrònic abans de qualsevol canvi d’estat manual.
Què ha de quedar verificat
- Gateway i WooCommerce estan d'acord en l’estat de pagament final.
- Stock, el correu electrònic i els efectes secundaris de compliment passen exactament una vegada.
- Un nou pagament controlat s' actualitza automàticament.
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 canviar l'estat de la comanda a Processament si el client diu que va pagar?+
No sense proves. Canvia la comanda a Processament sense confirmar el pagament pot complir una comanda que mai va ser realment pagada, de manera que l’estat del tauler de control gateway (capturat, autoritzat, fallit o reemborsat) és la font financera de veritat, no l’estat de la comanda WooCommerce.
Està bé demanar-li al client que pagui de nou ja que la comanda mostra ha fallat?+
No, això és explícitament el que heu d’evitar. Torna a intentar el pagament abans de comprovar el gateway pot crear un càrrec duplicat, ja que el pagament original pot haver tingut èxit mentre que només la devolució de crida o el processament local ha fallat.
Quina és la diferència entre un error de pàgina de retorn i un rebuig webhook aquí?+
Un error de pàgina de retorn significa que el pagament ha tingut èxit, però la redireccionació orientada al client es va trencar, mentre que un rebuig webhook significa que la devolució del servidor al servidor gateway no ha pogut autenticar-se ni arribar a WordPress en absolut. Distingir-los requereix comprovar l'estat de l'esquitxador gateway juntament amb els registres webhook o API corresponents als registres i notes de comanda de WooCommerce.
Pot un temps d'espera durant checkout significar que el pagament mai va passar?+
No necessàriament. Un temps d’espera es descriu com inherentment ambigu, ja que la sol·licitud pot interrompre' s al costat WooCommerce mentre que el gateway completa la transacció asíncronament en segon pla, que és exactament pel que es requereix conciliar la transacció per transacció amb el gateway abans d’editar qualsevol ordre.