Resposta breu: el pagament es va autoritzar en la passarel· la, però el missatge que se’ l comunica a WooCommerce mai va arribar o va ser rebutjat. La comanda es queda en “pendent de pagament” mentre els diners sí que s’ ha mogut.
Per què és pitjor que un error visible
Res sembla trencat — la botiga està online i el checkout funciona per a noves viwebs, només l’estat de la comanda és incorrecte —. Mentrestant s’ ha cobrat a clients que esperen, i això converteix un error tècnic en un problema de confiança ràpid.
On falla la confirmació
- L’endpoint de webhook/IPN és inabastable, redirigeix o retorna error.
- Un plugin de seguretat o tallafoc bloqueja les peticions servidor-a-servidor de la passarel·la.
- La URL de retorn continua apuntant a un domini de staging o antic després d’una migració: causa clàssica.
- Una capa de memòria cau intercepta l’endpoint i retorna una resposta emmagatzemada.
- La clau de signatura de la passarel· la va canviar i la validació falla.
Revisa el registre de lliuraments webhook/IPN del plafó de la passarel· la: Normalment mostrar els lliuraments fallits i l’estat HTTP que va retornar el teu web.
Concilia amb cura
- Exporta les comandes afectades amb hores i imports.
- Contesta’ls amb la llista de transaccions de la passarel·la per a saber quines es van pagar.
- Actualitza només les comandes confirmades, amb una nota explicant per què.
- Revisa l’estoc, perquè els canvis manuals d’estat poden no haver ajustat l’inventari.
Mai completeu en massa les comandes pendents sense contrastar-les amb transaccions reals: enviareu comandes impagats o ocultareu errors de pagament autèntics.
Corregeix la causa i verifica
Conciliar les comandes existents és remeiar; la reparació és restablir la via de confirmació. Fes una comanda controlada i confirma que l’estat canvia sol, que surt el correu i baixa l’estoc, i després revisa el registre de la passarel· la per lliuraments fallides en cua.
CRITERI D’INCIDENT WP REPAIR
Reconstrueix la incidència abans de corregir-la
Pendent de pagament pot significar que no hi ha hagut pagament, que el calback no va arribar o va ser rebutjat. Cal conciliar abans de canviar estats en massa.
- 1
Exporta IDs, hores, imports, monedes i referències de passarel· la.
- 2
Crúcils amb transaccions i lliuraments de webhook de la passarel·la.
- 3
Revisa URL de callback, secret de signatura, tallafoc i memòria cau.
- 4
Actualitza només comandes pagades confirmades amb nota i revisió explícita d’estoc.
Què ha de quedar verificat
- Cada comanda històrica té una decisió de pagament documentada.
- Una nova comanda controlada canvia automàticament d'estat.
- l’webhook retorna èxit i estoc/correu s' executen una sola vegada.
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 botiga es veu bé i checkout funciona per a nous clients, es pot trencar el sistema de pagament?+
Sí. Aquest problema particular deixa a la botiga amb un aspecte completament normal, ja que els pagaments van ser genuïnament autoritzats en el gateway, però el missatge dient WooCommerce sobre ell mai va arribar o va ser rebutjat, de manera que només l'estat de les ordres afectades està malament mentre que tota la resta funciona.
És segur marcar a granel totes les ordres pendents com a completes per eliminar el retard?+
No, mai fer això sense igualar cada comanda a una transacció real primer. Comandes pendents a granel-completar riscos d’enviament de productes que mai es van pagar realment, o emmascarar els errors de pagament genuïns que neceswebn maneig separat.
Quina és una raó comuna per la qual la devolució de pagaments deixa de funcionar just després d’una migració del lloc?+
El webhook o IPN callback URL registrat amb el gateway encara pot apuntar en el lloc de posada en escena o l’antic domini després de la migració. Ja que el gateway envia la seva confirmació a qualsevol URL que tingui en el fitxer, això trenca silenciosament la connexió fins que s'actualitza l’endpoint.
Després de reconciliar les ordres encallats, hi ha el problema realment arreglat?+
Reconciliar les comandes existents és la reparació, no la reparació. Confirmi que la ruta de retorn de crida en si es restableix mitjançant la col·locació d’un ordre controlat i la verificació de les actualitzacions d’estat automàticament, el correu electrònic envia, i stock disminueix, a continuació, comprovi el registre de el gateway per a qualsevol altre lliurament fallida en cua.