A WooCommerce pénztáránál akkor is megszakadhat a vásárlás, ha a termékoldal és a kosár látszólag jól működik. Először azt kell kiderítened, hogy technikai hiba állítja-e meg a rendelést, vagy a vásárló bizonytalanodik el a költségek, az űrlap vagy a fizetés közben. A két helyzethez más vizsgálat és más javítás tartozik.
A „nem működik a pénztár” önmagában kevés egy fejlesztőnek. Használható kiindulópont viszont, ha meg tudod mondani, milyen eszközön, milyen kosárral és melyik lépésnél jelentkezik a probléma. Az alábbi sorrenddel szűkítheted a lehetséges okokat anélkül, hogy találomra kezdenél bővítményeket cserélni.
WooCommerce pénztár hiba vagy félbehagyott vásárlás?
A kosárelhagyás nem bizonyít technikai hibát. Lehet, hogy a látogató csak a szállítás díját nézte meg, később akar rendelni, vagy más ajánlattal hasonlítja össze az árat. Ugyanakkor egy láthatatlan hibától is eltűnhet úgy, hogy nem ír az ügyfélszolgálatnak.
Válaszd külön a pénztár megnyitását, az adatok kitöltését, a fizetési mód kiválasztását és a rendelés elküldését. Ha használsz megfelelően beállított analitikát, ezekhez kapcsolódó események segíthetnek megtalálni a visszaesés helyét. Az esemény hiánya azonban mérési hibát vagy eltérő hozzájárulási állapotot is jelenthet; egyeztesd a képet a webshop rendeléseivel és a fizetési szolgáltató adataival.
Jegyezd fel az első ismert előfordulást és az azt megelőző változásokat. Bővítményfrissítés, új kuponszabály, szállítási zóna módosítása és új gyorsítótár-beállítás egyaránt adhat nyomot. Az időbeli egybeesés vizsgálandó összefüggés, önmagában még nem bizonyítja az okot.
Először azonosítsd a pénztár típusát
A WooCommerce pénztára lehet klasszikus, rövidkódos megoldás vagy blokkos pénztár. A látogató ebből keveset érzékel, a kapcsolódó bővítmények és egyedi módosítások működését viszont érdemben befolyásolja. Az oldalszerkesztőben ellenőrizhető, hogy Pénztár blokk vagy rövidkód szerepel-e a kijelölt oldalon.
Egy fizetési modul vagy egyedi pénztármező attól még nem feltétlenül működik mindkét változattal, hogy általában WooCommerce-kompatibilisnek nevezik. Az adott bővítmény dokumentációjában külön keresd a pénztártípus támogatását. A WooCommerce blokkos pénztárának fejlesztői útmutatója is külön kezeli ezt a kompatibilitást.
Hibakeresés közben ne válts automatikusan másik pénztártípusra: ezzel a számlázási mezők, a csomagpontválasztó vagy egy fizetési lehetőség is megváltozhat. Előbb rögzítsd a jelenlegi összeállítást. Ha a gond egy saját funkcióhoz kapcsolódik, az egyedi WooCommerce-bővítmény indokoltságáról szóló cikkünk segít tisztázni, mikor kell valóban fejlesztés, és mikor elegendő egy meglévő modul helyes beállítása.
A tünet alapján válaszd ki a következő vizsgálatot
Nem jelenik meg a fizetés vagy a szállítás
Ugyanazzal a termékkel, címmel és végösszeggel próbáld megismételni a hibát. Egy szállítási mód elérhetősége függhet az országtól, irányítószámtól, tömegtől vagy termékhez rendelt szállítási osztálytól. A fizetésnél összegkorlát, pénznem vagy a szállítási móddal való összerendelés is számíthat. Ezeket a saját modulod szabályai alapján ellenőrizd.
Hasznos ellenpróba egy egyszerű kosár, majd ugyanannak a kosárnak a módosítása egyetlen feltételben. Például először egy belföldi cím, utána egy másik szállítási zónába tartozó cím következzen. Ha mindent egyszerre változtatsz meg, a sikeres rendelésből sem fog kiderülni, melyik feltétel okozta az eltérést.
A fizetési oldal után nincs egyértelmű eredmény
A bankkártyás fizetés és a webshop rendelésállapota két külön ellenőrzési pont. Nézd meg, létrejött-e rendelés, milyen állapotban van, és található-e hozzá tranzakció a fizetési szolgáltatónál. A visszatérő oldal megjelenése mellett a szolgáltató szerveres értesítésének feldolgozása is fontos lehet.
Ha a vásárló terhelést lát, ne kérd automatikusan újabb fizetésre. Előbb azonosítsd a tranzakciót és a hozzá tartozó rendelést. A szükséges ellenőrzéshez ne kérj teljes bankkártyaadatot; rendelésazonosító, időpont és a szolgáltató által adott biztonságos hivatkozási azonosító alapján indulj el.
Ha a rendelés és a fizetés rendben van, de a számla nem készül el, már egy kapcsolódó folyamatot kell vizsgálni. Billingót használó webshopnál a számlázási integráció ellenőrzési szempontjai segíthetnek különválasztani ezt a pénztár hibájától.
A gomb után csak forog a betöltésjelző
A folyamatos betöltésből nem derül ki, hogy a böngésző, egy külső szolgáltatás vagy a szerver akadt-e el. A fejlesztőnek a böngésző hálózati hibája, a kérés időpontja és az ugyanekkor keletkezett szervernapló adhat használható bizonyítékot. A klasszikus és a blokkos pénztár eltérő kéréseket használ, ezért fontos az előző azonosítás.
A WooCommerce betöltésjelzővel kapcsolatos hibakeresési útmutatója szerint az ismételt rendelésküldés előtt a rendeléslistát is ellenőrizni kell: a rendelés már létrejöhetett. Naplórészlet megosztásakor takard ki a személyes adatokat és a hozzáférési kulcsokat.
Mobilon a hibaüzenet is része a működésnek
Próbáld ki a pénztárt valódi telefonon, megjelenő billentyűzettel és automatikus címkitöltéssel. Figyeld meg, látszik-e a következő mező, elérhető-e a fizetési gomb, és nem takarja-e ki a csomagpontválasztót egy lebegő elem. Egy keskenyre húzott asztali böngésző önmagában nem mutat meg minden mobilos akadályt.
A „Hibás adat” helyett a figyelmeztetés nevezze meg a mezőt és a javítás módját. Például: „Az irányítószámot négy számjeggyel add meg.” Az üzenet akkor hasznos, ha a vásárló meg is találja; ne csak piros keret jelezze a problémát. A W3C űrlap-visszajelzési útmutatója világos, a kapcsolódó mezőhöz köthető hibajelzést javasol.
A kötelező mezők számát is gondold végig. Egy cégadat vagy telefonszám lehet szükséges valamelyik rendelési módhoz, de az indokolatlanul mindenkitől bekért adat akadályt teremthet. A mezők elhagyását a számlázás és a kiszállítás igényeivel együtt vizsgáld; a rövidebb űrlap nem ér semmit, ha utána kézzel kell hiányzó adatokat beszerezni.
Cache, bővítményütközés és HPOS: három külön kérdés
A gyorsítótár, vagyis a cache, korábban elkészített választ szolgálhat ki új számítás helyett. Ez hasznos a tartalmi oldalakon, a személyes kosár és pénztár azonban nem kezelhető egyszerű, mindenkinek azonos oldalként. A WooCommerce cache-beállítási dokumentációja alapján a kosár, pénztár és fiókoldal kizárásait a használt gyorsítótárrétegekben is ellenőrizni kell.
Bővítményütközést tesztkörnyezetben keress. A működő boltban találomra kikapcsolt modul eltüntetheti a fizetést vagy a szállítást. Egy elkülönített másolatban változtass egyszerre egy dolgon, és jegyezd fel, melyik összeállításnál tűnik el, majd jelenik meg újra a hiba. A puszta kikapcsolás utáni egyetlen sikeres próba még gyenge bizonyíték.
A HPOS a WooCommerce rendelési adatainak tárolását érinti; nem a pénztár megjelenési típusa. A hivatalos HPOS-dokumentáció alapján a kapcsolódó bővítmények kompatibilitása és az adatok szinkronizálása külön ellenőrzést igényelhet. Ne kapcsold át próbaképpen az éles rendeléstárolást, és ne kezeld általános pénztárjavító kapcsolóként.
Így adj át ellenőrizhető hibajegyet
Egy szemléltető helyzetben a pénztár csak mobilon, csomagpontos szállítás és kupon együttes választásakor akad el. Ez nem igazolt ügyféleset, hanem példa arra, miért értékes a pontos körülménylista. A „néha rossz” jelzés helyett a fejlesztő ilyen leírásból már célzott próbát tud készíteni:
- A hiba időpontja, böngészője és eszköze, személyes adat nélküli képernyőképpel.
- A kosár termékei, változatai, mennyisége és az alkalmazott kupon.
- A szállítási zóna, a fizetési mód és a hiba megismétlésének lépései.
- Az elvárt működés, a tényleges eredmény és az esetleg létrejött rendelés azonosítója.
- A legutóbbi változtatások és az addigi ellenpróbák eredménye.
A tesztfizetéseket elkülönített környezetben, a szolgáltató tesztmódjával végezd. A tesztrendelés levelet, készletváltozást vagy számlázási műveletet is indíthat, ezért a kapcsolódó rendszereket előre kezeld. A javítás után ugyanazt a hibás esetet és egy korábban működő rendelési útvonalat is próbálj újra.
A javítás eredményét először a megismételhető hiba megszűnése igazolja. A vásárlási arány változását később, megfelelő mérés mellett lehet értékelni; egy technikai javításból önmagában nem következik garantált bevételnövekedés. A pénztár és a kapcsolódó rendszerek fejlesztése a webshopfejlesztési munkáink része.
Ha elakad a hibakeresés, írd meg nekünk a pénztár hibáját és az eddigi próbák eredményét. Ezek alapján először azt tudjuk tisztázni, milyen célzott vizsgálatra van szükség.