Una comanda pagada marcada Fallida o Cancel·lada pot aturar la preparació, retornar estoc i enviar un correu incorrecte encara que el proveïdor conservi els diners. Ho pot causar un webhook fora d’ordre, la neteja d’impagats, un timeout o una automatització.
No canviïs totes les comandes a Processant massivament. Demostra el pagament i identifica qui ha escrit l’estat.
Concilia el proveïdor i la botiga
Per a cada comanda compara l’import, la moneda, la referència i l’hora. Confirma si el proveïdor mostra Capturat, Autoritzat, Revertit, Disputat o Reemborsat.
Crea una taula sense dades de targeta ni informació completa del client.
Si el proveïdor és incert, pausa la preparació. L’etiqueta de WooCommerce no demostra per si sola el pagament.
Llegeix la cronologia de notes
Les notes privades acostumen a mostrar intents, estoc, webhooks i transicions. Llegeix-les en ordre i identifica l’últim estat correcte.
Seqüència útil:
comanda creada
pagament iniciat
pagament confirmat
estat canviat per passarel·la o tasca
efectes d'estoc, correu i logísticaCompara les zones horàries abans de concloure que han arribat desordenats.
Revisa l’ordre i els reintents de webhooks
La xarxa no garanteix l’ordre. Un esdeveniment antic “pagament fallit” pot arribar després d’una captura si el handler no comprova l’objecte actual.
Inspecciona l’historial, els ID i l’estat de l’API. Compara la data de creació amb la de lliurament i la versió actual de l’objecte. En mètodes asíncrons, defineix quins esdeveniments poden avançar o revertir i quins només informen.
No reprodueixis esdeveniments sense saber què fa la integració amb una comanda ja pagada.
Comprova la cancel·lació d’impagats
WooCommerce pot cancel·lar comandes després del període de reserva d’estoc. Si la confirmació triga més, cron cancel·la abans de rebre el pagament.
Revisa els ajustos d’inventari i Action Scheduler al voltant de la transició. Augmentar la reserva ajuda els mètodes lents, però reté l’estoc més temps.
Comprova com es retorna l’estoc i s’alliberen els cupons. Si després arriba el pagament, restaurar l’estat sense tornar a reservar pot vendre més unitats de les disponibles.
Inspecciona la passarel·la i PHP
Relaciona la transició amb registres de passarel·la, WooCommerce i PHP. Un timeout pot interpretar-se com a error encara que el proveïdor capturi després.
No tractis el timeout com un rebuig definitiu. El codi propi ha de consultar la referència estable abans de crear un altre càrrec o estat final.
Cerca processos simultanis: retorn del navegador, webhook, consulta programada i ERP. La lògica ha de tornar a consultar l’estat abans de desar, no utilitzar un objecte antic.
Troba escriptors externs
ERP, logística, subscripcions, frau i codi propi poden canviar estats. Cerca el nom de la integració i revisa hooks de pagament, cancel·lació i error.
$order = wc_get_order( $order_id );
if ( $order && $order->is_paid() ) {
// No degradar només per un esdeveniment local antic.
}És un patró defensiu; l’evidència del proveïdor i les regles comercials decideixen.
Corregeix les comandes afectades
Després de verificar la captura, restaura l’estat amb WooCommerce o l’eina oficial. Afegeix una nota amb la referència i el motiu.
Comprova si l’estoc ha tornat, s’han enviat correus o logística ha cancel·lat. Corregeix cada efecte una vegada.
Revisa el missatge rebut pel client. Després de confirmar el pagament, comunica l’estat real i el termini sense detalls interns ni un segon cobrament.
Verifica el cicle reparat
Prova èxit, rebuig, confirmació tardana i webhook repetit al sandbox. Un pagament capturat ha d’assolir l’estat correcte i no degradar-se.
Força un ordre d’esdeveniments invertit quan sigui possible. Cada efecte —estoc, correu, factura i logística— s’ha d’executar com a màxim una vegada.
El manteniment recurrent ha de comparar captures amb comandes Fallides, Cancel·lades i Pendents antigues. Alertar aquestes contradiccions evita errors de preparació i atenció.