Si el client ha pagat i la comanda no es confirma, reparar les compres futures i resoldre les comandes afectades són dos lliuraments diferents. El tècnic pot haver corregit el problema mentre queda una llista de captures, estats o devolucions per revisar. Aquella llista mereix un tancament propi abans que suport, magatzem i administració actuïn per separat.
Aquesta plantilla ajuda a acceptar una reparació de pagaments WooCommerce amb un expedient dels casos afectats. Inclou un exemple descarregable amb nou registres de proveïdor i vuit comandes fictícies. Per investigar-ne la causa, consulta pagament correcte amb comanda pendent o client cobrat sense comanda visible. Aquí definim què ha de quedar conciliat, assignat i comprovat al lliurament.
Acorda dos tancaments: funcionament nou i casos anteriors
Defineix què s’ha reparat: recepció de la confirmació, persistència de la comanda, processament d’una tasca o sincronització d’un estat. El lliurament ha de connectar causa observada, canvi aplicat i prova del recorregut afectat. Que torni a carregar una pàgina no demostra tota aquella cadena.
Obre després un expedient dels casos produïts durant la incidència. Fixa període, zona horària, proveïdor, compte i mode d’operació. Conserva exportacions i moment de consulta. Una confirmació tardana pot canviar legítimament el resultat entre dues revisions.
Pots acceptar una correcció tècnica verificada i mantenir obert un cas històric amb responsable i decisió següent. També pot passar el contrari: l’equip ha atès manualment les comandes antigues i la causa continua pendent. Mantenir visibles tots dos tancaments evita confondre una resposta provisional amb una reparació acabada.
Connecta comanda i pagament en un registre
Utilitza referències verificables de proveïdor i botiga. Afegeix moneda, imports comparables, estat observat i hora. El correu del client pot orientar una cerca, però no substitueix la identitat de l’operació. Dues compres legítimes poden compartir client i import.
| Bloc | Què conservar | Decisió que permet |
|---|---|---|
| Identitat | Referències de comanda i proveïdor, entorn i compte | Localitzar el mateix cas |
| Imports | Moneda, captura bruta i devolucions separades | Classificar una diferència real |
| Estat | Estats del proveïdor i WooCommerce, amb hora | Separar cobrament i procés comercial |
| Operació | Estoc, comunicacions i preparació o enviament comprovats | Evitar una segona actuació independent |
| Tancament | Evidència, decisió, responsable i pendent | Continuar o acceptar el cas amb context |
L’expedient compartit no necessita números de targeta, claus ni una exportació completa de clients. Conserva originals adequadament i lliura un extracte amb referències suficients. La guia per seguir pagaments sense exposar dades de targeta ajuda a preparar aquella investigació.
Compara estats que representin el mateix
Un import autoritzat i un de capturat són estats diferents. També ho són una comanda pendent, una de pagada i una de lliurada. La documentació d’estats de WooCommerce diferencia pagament i preparació o finalització. Revisa les regles de la passarel·la i els estats personalitzats de la botiga.
Compara captura bruta amb referència comercial i devolucions amb els registres corresponents. L’objecte Charge documentat per Stripe representa separadament imports capturats i retornats. L’exemple adopta aquella separació conceptual. No és una exportació real de Stripe ni un format universal de passarel·les.
Conserva la moneda. El valor 75 en USD i el valor 75 en EUR no acrediten cap coincidència. Una conversió necessita finalitat i especificació pròpies. L’exemple descarregable utilitza unitats menors enteres i mai suma ni converteix monedes diferents.
Exemple descarregable: nou registres i vuit comandes
Hem construït dades fictícies amb un tall a les 12:00 UTC del 20 d’octubre de 2026. Hem executat una unió local per referència i una classificació de la primera diferència aplicable. El resultat té nou files: set per revisar, una autorització sense captura i una coincidència dins de la mostra.
Descarrega l’exemple original: tres CSV i notes en anglès, amb dades fictícies. Inclou registres del proveïdor, comandes de botiga i informe de revisió. Són fitxes didàctiques, no fitxers d’importació ni una eina per reparar comandes.
| Cas | Què conté la mostra | Classificació |
|---|---|---|
| O101 | Captura de 120 EUR i comanda compatible | Registres alineats a la mostra |
| O102 | Captura de 80 EUR i comanda pendent | Revisar estat comercial |
| O103 | Captura de 50 EUR sense fila de comanda | Revisar comanda absent de l’exportació |
| O104 | Dues captures de 30 EUR per a una referència | Revisar múltiples captures |
| O105 | Autorització, captura zero i comanda en espera | Autorització sense cobrament capturat |
| O106 | Captura de 100 EUR; devolució de 20 EUR absent localment | Revisar devolució |
| O107 | Proveïdor en USD i comanda en EUR | Revisar moneda |
| O108 | Captura de 65 EUR i comanda de 60 EUR | Revisar import brut |
| O109 | Comanda pendent sense referència de proveïdor a l’extracte | Obtenir evidència del proveïdor |
Totes les accions automàtiques de l’informe són «cap». No hem accedit a botiga, passarel·la, client o targeta, ni executat cobraments, devolucions, reenviaments o canvis d’estoc. O101 només coincideix als camps comparats. No demostra lliurament de correu, preparació, liquidació bancària o tancament complet de la incidència.
Llegeix les excepcions abans de corregir-les
O104 presenta dues captures que cal investigar. La regla de l’exemple espera una captura completa per comanda; una botiga amb pagaments fraccionats necessita un altre model. El resultat no autoritza retornar cap registre. Primer determina què representa cadascun i quina decisió aprova el negoci.
O103 i O109 mostren els límits dels extractes. Una comanda absent d’un fitxer no demostra que mai existís; una referència de pagament absent no demostra impagament. Registra la cerca següent, qui la farà i quina font permetrà resoldre-la.
La classificació informa de la primera diferència aplicable. Un cas amb dues captures també pot tenir un estat incorrecte o comunicacions repetides. Conserva aquelles troballes durant la revisió. L’etiqueta inicial és una cua d’investigació, no un resum exhaustiu de tota la comanda.
Una devolució parcial no reescriu el total original
A O106, 100 EUR capturats menys 20 EUR retornats deixen 80 EUR abans de comissions. El total original de la comanda continua sent 100 EUR. El problema de la mostra és el registre local de devolució absent; no vol dir que calgui reescriure el total original com a 80.
L’expedient ha de conservar totes dues referències i identificar quin registre falta. Si el proveïdor ja ha executat la devolució, corregir l’evidència local no ha de tornar a moure diners. Una decisió real exigeix verificar l’objecte del proveïdor i seguir el procediment suportat de la integració.
La reparació de dades de comandes sense reescriure l’historial de pagaments desenvolupa emmagatzematge i canvis suportats. Aquesta plantilla hi afegeix el registre de lliurament perquè algú altre revisi la relació entre evidència, decisió i resultat.
Comprova que repetir una confirmació no repeteixi efectes
La reparació necessita una prova adequada a l’esdeveniment que fallava. En un entorn preparat, acorda com verificar recepció, processament i resultat. La documentació de webhooks de Stripe contempla esdeveniments duplicats i manca de garantia d’ordre, pertinents quan s’utilitza aquella integració.
Abans de qualsevol reenviament real, revisa l’esdeveniment existent i els seus efectes. Observa referències de comanda, estoc, comunicacions i preparació dins de l’abast acordat. Un resultat HTTP de lliurament no substitueix comprovar la tasca de negoci. L’exercici de CSV no fa aquesta prova ni acredita idempotència.
La guia de proves després de reparar WooCommerce ajuda a definir recorreguts nous i regressions. Inclou mètode de pagament, productes i condicions del problema original. Conserva els resultats d’aquells assajos separats de la revisió de comandes històriques.
Decideix què es pot tancar i què continua obert
| Lliurament | Evidència requerida | Si falta evidència |
|---|---|---|
| Correcció tècnica | Recorregut afectat i resultat després del canvi | Verificació pendent |
| Casos històrics | Referències conciliades o decisió documentada per cas | Responsable i acció següent |
| Efectes operatius | Estoc, avisos i preparació inclosos en l’abast | Dependència explícita |
| Continuïtat | Registre de canvis i control acordat de recurrència | Seguiment sense responsable per resoldre |
Una llista sense diferències inexplicades pot donar suport al tancament de l’expedient delimitat. No converteix l’encàrrec en una revisió comptable completa ni certifica tots els sistemes de l’empresa. Explica els límits i identifica qui accepta cada part.
Preguntes per revisar pressupost i lliurament
La reparació inclou resoldre les comandes anteriors?
L’abast ho ha d’indicar. Demana període, nombre de casos conegut, fonts disponibles i tractament d’excepcions. Una oferta pot recuperar confirmacions futures i pressupostar la revisió històrica per separat. Compara aquelles partides i els accessos necessaris abans d’acceptar el total.
Podem tancar un cas amb una decisió comercial pendent?
Documenta decisió aprovada, evidència i responsable. Si falta decidir si l’operació es prepararà, reconstruirà o retornarà, conserva el cas obert. Aprovació administrativa i execució comprovada tenen estats diferents. Un comentari al tiquet no acredita per si sol que la decisió s’hagi executat.
Què ha de rebre el proveïdor següent?
L’expedient acotat, les referències, decisions aplicades, proves fetes i dependències pendents. Inclou què ha canviat en la integració i quin accés temporal cal revisar. La continuïtat començarà amb informació útil, en comptes de tornar a demanar al client que demostri que ha pagat.
Mantén útil l’expedient després de la reparació
Assigna una persona coordinadora del registre. Suport pot conèixer la conversa amb el client, l’equip tècnic pot controlar el processament i operacions pot gestionar la preparació. Assigna qui revisa cada part perquè dos equips no actuïn independentment sobre el mateix cas pendent.
Explica què reobre un cas: un esdeveniment nou del proveïdor, una referència corregida, una captura addicional o una discrepància operativa posterior. Conserva les observacions anteriors sense substituir-les silenciosament per l’estat més recent. Un historial breu ajuda a explicar per què un cas inicialment pendent s’ha acceptat després.
Si cal monitoratge continu, encarrega’n període, fonts i responsable per separat. L’expedient puntual pot ajudar a definir aquell control, però no acredita que s’hagi instal·lat un servei automàtic de conciliació diària.
Fitxa de lliurament desenvolupada: el cas fictici O102
O102 relaciona la comanda pendent amb P102, una captura fictícia de 80 EUR. La classificació local demana revisar l’estat comercial. L’expedient comença amb aquelles referències i l’hora del tall; encara no conté una causa demostrada ni una correcció executada.
L’encàrrec pot demanar identificar per què la confirmació no ha arribat a l’estat previst i presentar el canvi proposat. La prova del funcionament futur necessita la integració i l’entorn adequats. Mentrestant, el responsable de la botiga revisa el cas històric per decidir-ne l’atenció i evitar actuacions independents.
El camp de resultat continua pendent fins que hi hagi evidència nova. Si s’aplica una correcció local autoritzada, el registre ha de conservar P102 i explicar què ha canviat, qui ho ha aprovat i quins efectes s’han comprovat. L’acceptació necessita evidència per a cada afirmació; l’etiqueta del CSV no autoritza preparar una comanda.
Suport també necessita identificar la comunicació aprovada i qui la farà. L’expedient pot assignar aquella tasca sense incloure la conversa privada sencera. Així tothom utilitza la mateixa referència i el client rep una resposta coherent amb la decisió del negoci.
Quan falla una prova de tancament
Conserva l’intent, el resultat observat i la hipòtesi següent. Si la confirmació funciona però repeteix un avís o moviment d’estoc, la comprovació pertinent continua fallant. Mantén aquell intent al registre. Acorda la correcció i la nova prova abans de tancar l’abast.
Si falta accés o una dependència externa impedeix continuar, assigna un responsable i l’evidència necessària per avançar. La fase següent es podrà estimar amb un problema concret, conservant el valor de la investigació feta.
Prepara l’avaluació amb un cas concret
Reuneix URL de botiga, mètode afectat, període, símptoma i referències amb dades privades retirades. La guia per demanar un diagnòstic del checkout el 2027 ajuda a ordenar el primer enviament. Per reparar el checkout WooCommerce, acorda tant la prova del recorregut nou com el lliurament dels casos anteriors.
El procés de recuperació ecommerce explica avaluació i aprovació. Pots sol·licitar una avaluació amb l’expedient disponible. Un bon lliurament permet que tècnic, botiga i suport sàpiguen què s’ha resolt i qui continua amb la feina pendent.
Falla l’avís de pagament: un cas executat en WooCommerce
L’exercici de conciliació anterior fa servir llistes sintètiques. A més, el 25 d’octubre de 2026 vam executar un altre cas: un checkout natiu de WooCommerce, una comanda real dins del laboratori i el seu registre d’estoc, amb una passarel·la pròpia connectada per HTTP a un simulador local de pagaments. El simulador va registrar un càrrec fictici de 39,00 €. No hi va intervenir cap banc, targeta, processador real ni diners.
La instal·lació aïllada utilitzava WordPress 7.1.3, WooCommerce 11.2.1, PHP 8.3.36 i MariaDB 11.4.12. Chromium 152 va enviar el checkout. Els reintents i les notificacions posteriors van ser peticions HTTP del banc de proves. Són set passos observats, no set compres de clients ni una validació d’una passarel·la comercial.
| Pas observat | Estat de la comanda | Càrrecs simulats, total | Estoc |
|---|---|---|---|
| Checkout natiu | pending |
1 | 10 |
| Repetició de la petició de passarel·la | pending |
1 | 10 |
| Signatura incorrecta: HTTP 401 | pending |
1 | 10 |
| Avís no disponible: HTTP 503 | pending |
1 | 10 |
| Reintent recuperat: HTTP 200 | processing |
1 | 9 |
| Avís de pagament repetit: HTTP 200 | processing |
1 | 9 |
| Avís tardà d’error: HTTP 200 | processing |
1 | 9 |
Què demostra la traça
El primer checkout va crear una comanda pendent. El simulador va desar un càrrec amb una clau d’idempotència vinculada a aquella comanda. En repetir la petició de la passarel·la, va retornar el càrrec existent. Després vam enviar un avís amb una signatura incorrecta, rebutjat amb HTTP 401, i un altre de ben signat al qual vam provocar un HTTP 503. La comanda va continuar pendent i l’estoc es va mantenir en 10.
El reintent del mateix esdeveniment signat sí que va passar. El receptor va cridar payment_complete() de WooCommerce amb la referència de transacció simulada: la comanda va passar a processing i l’estoc va baixar a 9. Repetir l’avís de pagament no el va tornar a descomptar. Un avís posterior d’error tampoc no va sobreescriure l’estat pagat. Al final hi havia una comanda, un càrrec simulat i la referència de transacció coincident.
Descarrega la traça observada, el CSV de set files i les notes d’abast. El ZIP conté referències fictícies i resultats mesurats, sense credencials ni codi executable de la passarel·la. La recuperació de l’avís va trigar 272,975 ms en aquesta execució local: és una mesura del laboratori, no una promesa de velocitat del proveïdor.
Fins on arriba aquesta prova
La signatura, el tractament d’esdeveniments i la idempotència es van programar per a aquest laboratori. No demostren que un connector de Stripe, PayPal o una altra passarel·la es comporti igual. Vam provar el checkout clàssic; no Checkout Blocks, 3-D Secure, devolucions reals, processos simultanis, reintents externs ni recepció de correus de clients. Per tancar una reparació en una botiga, cal repetir l’acceptació amb el sandbox del seu proveïdor i les seves integracions.
La implementació va seguir l’API de passarel·les de WooCommerce. La seva guia de comandes de prova explica també les precaucions amb comandes i integracions. Aquí tota la instal·lació va ser privada, es va bloquejar l’enviament de correu extern i, després de recollir l’evidència, vam retirar-ne els contenidors, la xarxa i les credencials generades.