Què passa realment: Stripe pot confirmar un pagament de manera asíncrona mentre WooCommerce depèn d’un webhook signat per actualitzar la comanda. Si aquest esdeveniment no arriba, arriba tard o es rebutja, Stripe i WordPress queden en estats diferents.
Uneix el pagament remot amb la comanda local
Necessites, com a mínim, l’ID del Payment Intent, l’ID de l’esdeveniment de Stripe, l’ID de comanda i les marques de temps. Les notes de la comanda i l’historial de lliurament del webhook permeten veure on es trenca la cadena.
Comprova el lliurament abans de tocar l’ordre
- Estat de lliurament i reintents del webhook a Stripe.
- URL de l’endpoint i coincidència entre mode live/test.
- Secret de signatura configurat al receptor.
- Logs de WooCommerce Stripe i errors fatals durant el processament.
Quatre causes que s’han de separar
- Secret incorrecte: l’endpoint rep l’esdeveniment però rebutja la firma.
- Mode barrejat: esdeveniments live arriben a una configuració de test o al revés.
- Endpoint bloquejat: WAF, autenticació bàsica o manteniment impedeixen l’entrega.
- Error en processar: el webhook arriba, però codi personalitzat falla en actualitzar la comanda.
Seqüència de reparació
- Corregeix endpoint, mode i secret segons l’entorn actiu.
- Resol el rebuig concret o l’error fatal que mostra el registre.
- Quan la idempotència estigui confirmada, reenvia un esdeveniment fallit de prova.
- Concilia pagaments antics individualment abans de canviar estats manualment.
Quan el problema és 401/403
Si Stripe registra un 401 o 403, no ho tractis com un simple problema de pagament: segueix el diagnòstic d’autenticació i tallafoc per a webhooks. Si el càrrec existeix però la comanda queda en estat incorrecte, revisa també la conciliació entre pagament completat i comanda fallida.
Evita les correccions massives
No marquis totes les comandes pendents com a pagades basant-te en informes de clients. Cada ordre s’ha de relacionar amb una transacció real de Stripe abans de canviar-ne l’estat.
Com verificar que ja funciona
Un nou pagament de prova ha d’actualitzar la comanda automàticament; tornar a enviar el mateix esdeveniment no ha de duplicar estoc, correus ni altres efectes; i Stripe i WooCommerce han de referenciar el mateix ID d’esdeveniment.
CRITERI D’INCIDENT WP REPAIR
Seqüència d’intervenció segura
l’ID de l’esdeveniment Stripe i les notes de comanda WooCommerce connecten el pagament remot a la transició de l’estat local.
- Escriu la intenció de pagar Stripe, ID d’esdeveniment, ID de comanda i data i hores.
- Comprova l’estat del lliurament, el cos de la resposta i l’historial de reintentació de Stripe webhook.
- Verifica endpoint URL, signatura de secret i alineació de mode viu/de prova.
- Inspecciona WooCommerce Stripe i registres fatal per cercar o processar errors.
Què ha de quedar verificat
- Un nou pagament de prova actualitza automàticament la comanda.
- Els esdeveniments que es repeteixen no produeixen efectes secundaris duplicats.
- Stripe lliura registres i WooCommerce notes referència al mateix esdeveniment.
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.
Puc marcar les comandes com a pagades manualment quan Stripe mostra que el pagament ha tingut èxit però WooCommerce no s'actualitza?+
Cada comanda pendent s'ha de verificar individualment contra la transacció real Stripe abans de les actualitzacions manuals, ja que marca cada comanda pendent pagada sense que es comprovin els riscos de confirmar comandes que mai van ser capturats.
És un desajust en mode viu/de prova una causa comuna, o és generalment el secret de signatura?+
Ambdós estan llistats com a causes diferents i comunes amb diferents signatures: un secret de signatura incorrecte fa que els esdeveniments d’una altra manera vàlids siguin rebutjats en el punt final, mentre que un desajustament de manera significa que els esdeveniments en viu estan sent enviats a un punt final de prova (o viceversa), de manera que comprovar l'alineació del mode en viu/de prova és un pas a part de comprovar el secret.
Si el webhook ha estat rebutjat abans, és segur reproduir-lo des del plafó de control Stripe?+
Sí, però només després de confirmar la idempotència, el que significa que la repetició no ha de crear actualitzacions de comanda duplicat o efectes secundaris. La repetició d’un esdeveniment fallit segur és part de la seqüència de reparació recomanada, feta després que el punt final i la configuració secreta s'han corregit.
L’ID de l’esdeveniment Stripe realment importa per a la resolució de problemes, o és l'ID de la comanda suficient?+
L’ID d’esdeveniment Stripe importa específicament perquè, juntament amb les notes de comanda WooCommerce, és el que connecta l’esdeveniment de pagament remot a la transició de l’estat d’ordre local, el que us permet confirmar que un esdeveniment específic va ser rebut i processat en lloc de que una ordre finalment va canviar d’estat.