Què importa primer: Dues ordres que semblen idèntiques no són necessàriament el mateix incident. Un pot no tenir cap intent de pagament, ambdós poden compartir un ID de transacció, o un webhook pot haver repetit una operació idempotente incorrectament.
Què indica realment aquest símptoma
L’interval de creació i la petició registres distingeixen els doble clic dels reintents del servidor i la duplicació d’integració.
Recull proves abans de canviar res
- 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.
Causes més habituals
- Presentació doble: El botó checkout està actiu o JavaScript envia dues vegades.
- Reintenta la xarxa: Un intermediari, client o integració repeteix una petició no idempotent.
- Duplicació de codi personalitzat: Un consumidor de ganxo o API crea una altra comanda.
- Ús indegut de Webhook: Un esdeveniment repetit executa la lògica de creació d’ordre en comptes d’actualitzar l’estat existent.
Seqüència segura de diagnòstic i reparació
- Feu que l’checkout submissió sigui idempotent i deshabiliti els clics repetits.
- Usa claus de transacció o idempotència úniques en integracions passarel· la.
- Corregir ganxos personalitzats per actualitzar l’ordre existent.
- Reconciliar els duplicats històrics abans de cancel· lar, reemborsar o restaurar estoc.
Com distingir entre les causes probables
No tractis Presentació doble i Reintenta la xarxa com a causes equivalents. El botó checkout roman actiu o JavaScript envia dues vegades. En canvi, un intermediari, client o integració repeteix una petició no idempotent. Per a distingir- les, useu aquestes dues comprovacions: Exporta l’ID de comanda duplicat, data i hores, client, hash del carrit i ID de transacció; i compara les sol· licituds checkout del navegador i les entregues passarel· la/webhook. Amb aquestes dades podreu decidir si convé aplicar la primera acció controlada —Faga que l’checkout submissió sigui idempotente i deshabiliteu els clics repetits — o si heu 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 eliminis els duplicats a granel. Contéen pagaments, estoc, proves fiscals i d’auditoria necessàries per decidir quin registre és autoritzat.
Com verificar la reparació
- 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.
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
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.