Akadozik a checkout? A 6 leggyakoribb WooCommerce fizetési hiba

A magyar webshopok jellemzően Bariont, SimplePay-t vagy Stripe-ot használnak, és mindhármat meglepően könnyű félrekonfigurálni. A leggyakoribb bakik:

• Tesztkulcs élesben (vagy fordítva): élesítés után bent maradt a tesztkörnyezet (sandbox) kulcsa, és a valódi kártyákat elutasítja a rendszer.
• Rossz visszairányítási (redirect/callback) URL: a vevő fizet, de nem érkezik vissza a köszönőoldalra, hanem hibaoldalra vagy 404-re fut.
• Időtúllépés (timeout): a kapu vár a szerveredre, a szervered lassan válaszol, a tranzakció elhasal.

Onnan ismered fel, hogy a vevő átjut a fizetési oldalra, de a rendelés soha nem vált feldolgozás alatti státuszra — vagy már az átirányításnál hibát kap. Az első lépés mindig a kapu saját adminfelülete: a Barion, a SimplePay és a Stripe is tranzakciószinten naplóz, ott látod, melyik lépésnél szakadt meg a folyamat. A WooCommerce oldalán kapcsold be a fizetési plugin naplózását (WooCommerce → Állapot → Naplók), és futtass egy teszttranzakciót.

A gyorsítótár (cache) a webshop legjobb barátja a termékoldalakon, és a legrosszabb ellensége a kosárnál meg a checkoutnál. Ha bármelyik cache-réteg — cache-plugin, szerveroldali cache, CDN — HTML-t tárol el a checkout oldalról, abból session-ütközés lesz: a vevő üres kosarat lát, pedig most rakott bele terméket, rosszabb esetben valaki más kosarát kapja meg.

A másik tipikus tünet a lejárt biztonsági token (nonce): a WooCommerce minden checkout-beküldést időkorlátos tokennel véd, és ha az oldal egy órákkal korábbi, cache-elt változatból jön, a token már érvénytelen. Az eredmény egy semmitmondó checkout-hibaüzenet a beküldésnél — teljesen szórványosan, az egyik vevőnél igen, a másiknál nem, reprodukálni szinte lehetetlen. Ha „néha nem megy a fizetés” jellegű panaszokat kapsz, a cache legyen az első gyanúsított.

A checkout a webshopod legösszetettebb oldala JavaScript szempontjából: a mezővalidáció, a szállítási módok frissítése és a fizetési kapu beágyazott mezői mind JS-ből mennek. Elég egy hibásan megírt popup-plugin, egy marketingpixel vagy egy túlbuzgó script-optimalizáló, és az egész lánc megáll.

Ezt hívom néma halálnak: a vevő rákattint a megrendelés gombra, és nem történik semmi. Se hibaüzenet, se szerveroldali napló — a kérés el sem indult, mert egy konzolhiba (console error) korábban megölte a scriptet. A felismeréshez nyisd meg a böngésző fejlesztői konzolját (F12), menj végig a checkouton, és figyeld a piros sorokat. Külön gyanúsak a JS-késleltető „gyorsító” pluginok: ha a jQuery-t vagy a checkout scriptjét is késleltetik, pont a fizetést törik el. A megoldás iránya: a checkout kizárása az optimalizálóból, makacsabb konfliktusnál pedig plugin-felezéses hibakeresés — lehetőleg staging környezetben, nem az éles boltban.

Ha a szállítási díjat élőben kérdezed le egy futárszolgálat vagy csomagpont-szolgáltató API-jából, a checkout minden frissítése — irányítószám beírása, szállítási mód váltása — megvárja a külső rendszer válaszát. Ez jó napokon fél másodperc, rossz napokon öt. A vevő közben egy pörgő ikont bámul, és okkal hiszi azt, hogy lefagyott az oldal.

A durvább eset, amikor a külső API időtúllépéssel elhal: ilyenkor a szállítási módok meg sem jelennek, és fizikailag lehetetlen rendelni. Felismerni a böngésző Network füléből lehet — ha az update_order_review kérés rendszeresen több másodpercig fut, megvan a tettes. A megoldás iránya: a lekért díjak átmeneti tárolása (transient cache), fix díjtáblázat mindenhol, ahol a valós idejű lekérdezés nem muszáj, és értelmes timeout tartalékdíjjal, hogy egy API-leállás ne állítsa meg a boltot.

Ez a legalattomosabb hiba a hatból, mert a vevő oldaláról minden működött: fizetett, a pénzt levonták. Csak a visszajelzés — a webhook vagy IPN-hívás, amivel a kapu értesíti a webshopot a sikeres fizetésről — nem ért célba. Az okok jellemzően: rossz webhook-URL, a szerver épp 500-as hibát adott, vagy egy biztonsági plugin, illetve tűzfal (WAF) blokkolta a kapu hívását.

Az eredmény dupla kár: a rendelés fizetésre váró státuszban ragad, a vevő nem kap visszaigazolást, te pedig nem indítod el a teljesítést. Ha sokáig senki nem veszi észre, a WooCommerce a készletfoglalási idő lejártakor automatikusan le is mondhatja a rendelést. Az árulkodó jel egyértelmű: a kapu adminfelületén sikeres a tranzakció, a WooCommerce-ben ugyanaz a rendelés fizetésre vár. Ez a párosítás sosem „majd magától frissül” — ez mindig hiba, és a kapu felülete jellemzően a webhook-kézbesítések állapotát is mutatja, onnan érdemes visszafejteni.

A legtöbb webshopban a forgalom nagyobbik fele ma már mobilról jön, a checkoutot mégis szinte mindenki desktopon nézi meg utoljára. A tipikus mobilgyilkosok:

• Láthatatlan validációs hiba: a „kötelező mező hiányzik” üzenet a képernyő tetején jelenik meg, a vevő pedig lent áll a gombnál — csak annyit lát, hogy nem működik.
• Rossz billentyűzet: a telefonszám-mezőnél teljes billentyűzet jön fel numerikus helyett, az e-mail-mezőnél nincs kéznél a kukac.
• Apró kattintási célpontok: ÁSZF-checkbox, amit ujjal nem lehet eltalálni.
• Eltört automatikus kitöltés (autofill): a böngésző kitöltené az adatokat, de a mezők rossz attribútumai miatt összekeveri őket.

Ez ugyanúgy elveszett rendelés, mint egy szerverhiba, csak nehezebb észrevenni. Az analitika megmutatja: ha a mobilos checkout-elhagyás jelentősen magasabb a desktoposnál, ott gond van. A megoldás iránya: helyes inputmode és autocomplete attribútumok, automatikus görgetés a hibaüzenethez, nagyobb gombok, és minden mező kigyomlálása, ami a rendeléshez nem feltétlenül kell.

Nem kell fejlesztőnek lenned ahhoz, hogy az esetek nagy részét magad kiszúrd. Ez az a rutin, amit havonta egyszer érdemes végigvinni:

1. 01Tesztrendelés élesben: vidd végig a teljes folyamatot valódi fizetéssel egy kis összegű terméken, és utánvéttel is — desktopon és a saját telefonodon egyaránt.
2. 02Böngészőkonzol nyitva (F12): a checkout közben minden piros hiba potenciális rendelésgyilkos, akkor is, ha látszólag működik az oldal.
3. 03Fizetési kapu naplója: nézd át az elmúlt hónap sikertelen tranzakcióit — a minta (mindig ugyanannál a lépésnél szakad meg?) többet mond bármilyen találgatásnál.
4. 04Rendelésstátuszok: szűrj „fizetésre vár” és „tartásban” státuszú rendelésekre, és vesd össze őket a kapu tranzakciólistájával.
5. 05WooCommerce-naplók: a WooCommerce → Állapot → Naplók alatt nézd át a végzetes hibákat (fatal error) és a fizetési plugin bejegyzéseit.

A közös pont a hat hibában: egyik sem látványos. Nem fehér képernyő, nem leállt oldal — csendben szivárgó rendelések, amiket csak akkor veszel észre, ha célzottan keresed őket. Ha a fenti listán elakadsz, vagy találsz valamit, de nem tudod, hova nyúlj, WooCommerce-fejlesztéssel és -mentéssel pont ilyen problémákat oldok meg nap mint nap — az auditom pedig többek között pontosan ezt a checkout-átvilágítást végzi el a webshopodon.