Dos comandes semblants no impliquen la mateixa causa: poden provenir d’un doble clic, d’un reintent de xarxa, de codi personalitzat o d’un webhook que crea una ordre nova en lloc d’actualitzar l’existent. Primer cal veure si comparteixen o no la mateixa transacció.
Comprova si els duplicats comparteixen pagament
Exporta IDs de comanda, timestamps, client, hash del carretó i IDs de transacció. Si una ordre no té intent de pagament i l’altra sí, el problema és diferent d’un cas amb dues ordres lligades al mateix cobrament.
Evidència que separa navegador i servidor
- Peticions de checkout del navegador.
- Logs de proxy o servidor en el mateix segon.
- Lliuraments de webhooks i reintents de la passarel·la.
- Hooks personalitzats executats en crear o completar la comanda.
On comença la duplicació
- Doble enviament: el botó continua actiu o JavaScript envia dues peticions.
- Reintent de xarxa: una petició no idempotent es repeteix sense una segona acció humana.
- Codi personalitzat: un hook o consumidor d’API crea una altra ordre.
- Webhook mal utilitzat: l’esdeveniment repetit torna a crear en lloc d’actualitzar.
Fes idempotent la creació de la comanda
- Bloqueja enviaments repetits al client i mantén una clau estable de checkout.
- Usa IDs de transacció o idempotència a la integració de pagament.
- Canvia hooks personalitzats perquè actualitzin l’ordre existent.
- Concilia duplicats històrics abans de cancel·lar, reemborsar o restaurar estoc.
Doble enviament o reintent tècnic?
Dues peticions del navegador apunten al primer cas; una sola acció amb una repetició posterior de servidor o integració apunta al segon. Si també hi ha dos càrrecs, segueix la conciliació de pagaments duplicats. Si l’usuari va repetir perquè la confirmació fallava, revisa la pàgina Comanda rebuda.
No eliminis les ordres duplicades de cop
Contenen evidència de pagament, impostos, estoc i auditoria necessària per decidir quina és l’ordre autoritària.
Com demostrar que està reparat
Una única acció de client ha de crear una sola comanda; reintents i webhooks repetits no han de crear ordres ni efectes secundaris nous, i els duplicats antics han de quedar conciliats amb una decisió documentada.
CRITERI D’INCIDENT WP REPAIR
Com acotar l’error sense endevinar
l’interval de creació i la petició registres distingeixen els doble clic dels reintents del servidor i la duplicació d’integració.
Exporta l’ID de comanda duplicat, data i hores, client, hash del carrit i ID de transacció.
Compara les sol· licituds checkout del navegador i els lliuraments passarel· la/webhook.
Inspecciona els ganxos personalitzats connectats a checkout i la finalització del pagament.
Comprova si el client ha tornat a jutjar després d'un temps d'espera o una pàgina de confirmació en blanc.
Què ha de quedar verificat
- Una acció del client crea una comanda.
- l’entrega repetida de webhook no crea cap altre ordre o efecte secundari.
- Els duplicats històrics es reconcilien amb les decisions de pagament i estoc documentades.
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.
Són dues ordres idèntiques sempre el mateix incident subjacent?+
No. Una ordre duplicada pot no tenir cap intent de pagament en absolut, ambdós poden compartir el mateix ID de transacció, o un webhook pot haver repetit una operació que hauria d’haver estat idempotent, de manera que cada parell necessita la seva pròpia evidència en lloc d’una suposició general.
Com puc dir-li a un duplicat de doble clic d’un servidor o webhook reintentar?+
L’interval de creació i els registres de sol·licitud són el factor decisiu: una presentació doble normalment mostra dues peticions gairebé simultànies de la mateixa sessió del navegador, mentre que una xarxa o webhook retry mostra un buit vinculat a un temps d’espera o un lliurament repetida des de el gateway o integració en comptes del navegador del client.
Està bé esborrar les ordres duplicades una vegada que les hagi vist?+
No, això es diu com un error. Les comandes duplicats contenen pagaments, stock, proves fiscals i d’auditoria necessàries per a determinar quin registre és autoritzat, per la qual cosa han de ser reconciliats i resolts deliberadament en lloc d'eliminar-se a granel.
Pot el codi personalitzat o una integració webhook realment ser la causa arrel en comptes del botó checkout?+
Sí. Un ganxo personalitzat connectat a checkout o terminació de pagament pot crear una segona comanda, i el mal ús de webhook pot desencadenar la lògica de creació d’ordre en un esdeveniment repetit en comptes de simplement actualitzar la comanda existent, de manera que inspeccionar ganxos personalitzats i el maneig de webhook és una comprovació necessària, no només el comportament de checkout UI.