Què importa primer: Stripe pot completar el pagament aixíncronament, mentre que WooCommerce depèn d’un esdeveniment signat per actualitzar la comanda. Un webhook perdut, retardat o rebutjat deixa els sistemes fora de sensecronització.
Què indica realment aquest símptoma
L’ID de l’esdeveniment Stripe i les notes de comanda WooCommerce connecten el pagament remot a la transició de l’estat local.
Recull proves abans de canviar res
- 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.
Causes més habituals
- Secret de signatura equivocat: L’edpoint rebutja esdeveniments vàlids d’una altra manera.
- Desajusteu del mode: Els esdeveniments en directe s’envien a un punt final de la prova o viceversa.
- Endpoint bloquejat: WAF, autenticació bàsica o manteniment impedeix el lliurament.
- Processament fatal: l’esdeveniment arriba però el codi personalitzat falla en actualitzar l’ordre.
Seqüència segura de diagnòstic i reparació
- Endpoint correcte i configuració secreta per al mode Stripe actiu.
- Resoldre el rebuig exacte del lliurament o el processament fatal.
- Repetir un esdeveniment segur fallit després de confirmar la idempotència.
- Reconciliar els pagaments històrics abans d’actualitzar manualment les comandes.
Com distingir entre les causes probables
No tractis Secret de signatura equivocat i Desajustament de mode com a causes equivalents. L’endpoint rebutja esdeveniments vàlids d’una altra manera. En canvi, els esdeveniments en directe s’ envien a un punt final de la prova o viceversa. Per distingir- les, useu aquestes dues comprovacions: Gravar la intenció de pagament Stripe, ID d’esdeveniment, ID de comanda i data i hores; i comprovar l’estat del lliurament, el cos de la resposta i l’historial de reintentació de Stripe webhook. Amb aquestes dades podreu decidir si convé aplicar la primera acció controlada —Endpoint correcte i configuració secreta per al mode Stripe actiu — o si has de conservar l’estat actual i ampliar la recerca.
En una botiga activa, reprodueix el problema amb una comanda de prova controlada i segueix el mateix recorregut de pagament, estoc, impostos i notificacions que usen els clients. No canviïs diversos components del checkout alhora, perquè destruiries l’evidència necessària per atribuir l’error. Documenta la data i hora exactes, la URL o transacció afectada, l’últim estat correcte conegut i cada canvi realitzat durant el diagnòstic. Aquest registre permet distingir una reparació reproduïble d’una desaparició temporal del símptoma.
Què no has de fer
No marqueu cada comanda pendent pagada basant- se únicament en els informes del client. Verifica la transacció Stripe individualment.
Com verificar la reparació
- 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.
Que el símptoma visible desaparegui no és suficient. Tanca la incidència només quan l’acció original que fallava, el recorregut de negoci relacionat i els registres rellevants confirmin que el problema ha desaparegut.
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.