Què importa primer: Els clients poden ser cobrats dues vegades quan checkout es torna a enviar, un temps d’espera alenta un altre intent, o la lògica de reintentar personalitzada manca d’imdempotència.
Què indica realment aquest símptoma
L’estat de la comanda WooCommerce per si mateix no pot provar el nombre de captures. Els registres de transaccions Gateway, les claus d’idempotència i data i hores són decisius.
Recull proves abans de canviar res
- Recollir tots els càrrecs, autoritzacions i referències de retorn de passarel· la.
- Càrregues de mapes a comandes WooCommerce, checkout sessions i intents del client.
- Revisa el temps d’espera, reintentar i webhook registres al voltant de l’incident.
- Deshabilita el camí de pagament fallat si la càrrega duplicada està en curs.
Causes més habituals
- Torneu a provar amb el client: El primer pagament completat sense una pàgina de confirmació utilitzable.
- Gateway/client retent: Una petició es va repetir sense una clau d’impotència.
- Webhook i carrera de retorn: Dues rutes de codi capturen o finalitzen el pagament.
- Codi de pagament personalitzat: Les trucades d’integració capturen més d’una vegada.
Seqüència segura de diagnòstic i reparació
- Contenir el problema i comunicar-se amb els clients afectats.
- Reemborsament confirmat captures duplicades d’acord amb passarel·la i procés de negoci.
- Implementar la idempotència i una via de pagament-completament autoritzada.
- Prova el temps d’espera i els escenaris repetitius, no només el camí feliç.
Com distingir entre les causes probables
No tractis Torneu a provar amb el client i Gateway/client retent com a causes equivalents. El primer pagament completat sense una pàgina de confirmació utilitzable. En canvi, una petició es va repetir sense una clau d’idempotència. Per a distingir- les, useu aquestes dues comprovacions: Recollir tots els càrrecs, autoritzacions i referències de devolució de passarel· la; i càrregues de mapes a comandes WooCommerce, checkout sessions i intents del client. Amb aquestes dades podreu decidir si convé aplicar la primera acció controlada -contenir el problema i comunicar-se amb els clients afectats- o si has de conservar l’estat actual i ampliar la investigació.
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 reemborsar des de WooCommerce fins que sàpiga si el passarel·la admet i va registrar aquest reemborsament; altrament, els registres poden diferir més.
Com verificar la reparació
- Cada checkout sessió pot produir com a màxim un pagament capturat.
- Gateway i els registres de reemborsament de comandes coincideixen.
- Els temps d’espera i les trucades de retorn duplicats romanen segurs i idempotents.
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’estat de la comanda WooCommerce per si mateix no pot provar el nombre de captures. Els registres de transaccions Gateway, les claus d’idempotència i data i hores són decisius.
- Recollir tots els càrrecs, autoritzacions i referències de retorn de passarel· la.
- Càrregues de mapes a comandes WooCommerce, checkout sessions i intents del client.
- Revisa el temps d'espera, reintentar i webhook registres al voltant de l’incident.
- Deshabilita el camí de pagament fallat si la càrrega duplicada està en curs.
Què ha de quedar verificat
- Cada checkout sessió pot produir com a màxim un pagament capturat.
- Gateway i els registres de reemborsament de comandes coincideixen.
- Els temps d'espera i les trucades de retorn duplicats romanen segurs i idempotents.
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.
Pot l'estat de la comanda WooCommerce dir-me quantes vegades un client va ser cobrat realment?+
No. L’estat de la comanda per si mateix no pot provar el nombre de captures; els registres de transaccions gateway, les claus d’idempotència i les marques de temps són la prova decisiva per a determinar si un client va ser acusat una o diverses vegades.
He d'emetre un reemborsament directament des de WooCommerce tan aviat com localitzi una càrrega duplicada?+
No fins que confirmi que el gateway realment suporta i ha registrat aquest reemborsament. El reemborsament de WooCommerce sense aquest xec pot causar que el gateway i ordenar registres diverixin encara més en lloc de reconciliar-los.
Si els càrrecs duplicats estan succeint activament en aquest moment, quin és el primer moviment?+
Deshabilita la ruta de pagament fallat immediatament si la càrrega duplicada està en curs, abans de treballar a través de l’anàlisi de causa arrel. Comptar amb dany actiu als clients té prioritat sobre diagnosticar si es tracta d’un retent de client, un retent de gateway, o una carrera entre webhook i el maneig de pàgina de retorn.
Prova només el flux checkout exitós captura aquest tipus d’error?+
No. La guia requereix específicament provar els escenaris de temps fora i repetitiu, no només el camí feliç, ja que els pagaments duplicats normalment sorgeixen de les condicions de reintento i carrera que mai apareixen quan tot es completa en el primer intent.