Les comandes duplicades i els cobraments duplicats estan relacionats, però no són iguals. Dues comandes poden apuntar a un únic pagament, una comanda pot tenir dos càrrecs, o tots dos sistemes poden estar duplicats.
Atura les proves i concilia cada transacció abans d’eliminar, reemborsar o canviar estats.
Classifica el patró
Crea una taula anonimitzada amb l’ID de comanda, import, hora, referència, ID de transacció i estat. Comprova si els productes i l’adreça coincideixen.
Patró A: dues comandes, una transacció
Patró B: una comanda, dues transaccions
Patró C: dues comandes, dues transaccions
Patró D: un cobrament i una autorització temporalConfirma al proveïdor quins pagaments estan capturats. Una retenció pendent no sempre és un segon càrrec definitiu.
Inspecciona el comportament de l’enviament
Una resposta lenta anima a tocar diverses vegades, recarregar o obrir una altra pestanya. Network pot mostrar peticions de checkout separades per segons.
El botó ha de mostrar l’estat ocupat després d’un enviament vàlid, però deshabilitar-lo només protegeix la interfície. El servidor ha de processar amb seguretat qualsevol reintent.
Revisa el mòbil i la visibilitat dels errors: el primer intent pot haver acabat sense que el client ho veiés.
Rastreja la idempotència de la passarel·la
Moltes API accepten una clau d’idempotència per retornar el resultat original en repetir, sense tornar a cobrar. Revisa els registres i les referències.
Un intent lògic ha de conservar:
- una referència de comanda
- una clau d'idempotència quan existeixi
- un ID de transacció emmagatzematNo registris secrets ni payloads complets. La clau ha de ser estable durant reintents de xarxa i diferent per a una compra realment nova.
Comprova que no es regeneri en recarregar JavaScript.
Comprova la repetició de webhooks
El proveïdor reintenta quan rep un timeout o un estat no satisfactori. El mateix esdeveniment pot arribar diverses vegades i el handler l’ha de reconèixer.
Revisa l’historial de lliurament i les notes. Si el mateix ID genera diverses preparacions, correus o canvis, corregeix la idempotència abans de reproduir-lo.
Respon ràpidament i posa en cua l’ERP o les tasques lentes. Esperar una exportació abans del 2xx convida a nous intents.
Revisa hooks personalitzats
El codi pot crear comandes en dos hooks, cridar el pagament des del navegador i el servidor, o executar-se cada vegada que s’actualitza el checkout.
Cerca wc_create_order(), crides a la passarel·la i hooks del checkout o pàgina d’agraïment. Aquesta pàgina es pot recarregar i mai no ha d’iniciar un altre cobrament.
No editis el nucli de WooCommerce. Mantén la correcció en codi versionat amb registres mínims i proves.
Examina tasques i sistemes externs
Action Scheduler pot reintentar una tasca, mentre l’ERP o una automatització reenvien la creació després d’un timeout. Compara els ID de correlació.
Timeout significa resultat desconegut, no “no ha passat res”. Abans de repetir, consulta per referència estable o utilitza una operació idempotent.
Comprova també les cues del proveïdor i els webhooks de preparació.
Concilia l’impacte
Decideix quina comanda i quin càrrec han de romandre. Reemborsa les captures duplicades mitjançant la passarel·la i afegeix notes privades que enllacin les referències.
Restaura l’estoc una sola vegada i evita una preparació doble. No enviïs la comanda a la paperera sense més: comptabilitat, proveïdor, inventari i correus divergirien.
Explica al client els fets i el termini del reemborsament sense culpar-lo per haver premut dues vegades.
Verifica la reparació
Prova un pagament normal, un doble clic deliberat, un reintent del navegador i un webhook repetit al sandbox. Cada intent lògic ha de produir una comanda, un càrrec capturat i una ruta de preparació.
Comprova que les alertes i els registres no generin efectes addicionals.
El manteniment recurrent ha de detectar comandes del mateix client i import en un interval curt, referències reutilitzades i diverses captures per comanda. La detecció complementa la idempotència, no la substitueix.