FluentCart 1.3.4: csomagtermékek, Stripe Hosted Checkout és további fejlesztések

Ha WooCommerce után valami karcsúbb, „builder-barátabb” checkout motoron gondolkodsz, a FluentCartot valószínűleg már nézegetted. A 1.3.4-es verzió azért érdekes, mert nem a csillogó UI-trükkök irányába mentek, hanem pont azokra a részekre feküdtek rá, amik éles boltban, napi forgalomnál szoktak fájni: előfizetések logikája, fizetési kapuk következetessége, checkout rugalmassága, és a kicsi edge case-ek, amikből support ticket lesz.

Na, nézzük meg, mi változott a 1.3.4-ben, és fejlesztői szemmel miért számít ez a gyakorlatban.

Csomagtermékek (Product Bundles): végre natívan

A csomagtermék (bundle) az a funkció, amit mindenki kér, amint elkezd ténylegesen katalógusban gondolkodni. A valóságban ritkán adsz el mindent „egyedül”: van starter kit, upgrade csomag, szolgáltatás + sablon, licenc + kiegészítő, stb.

A FluentCart 1.3.4-ben a bundle lényege nem az, hogy „egy termék alatt listázunk több dolgot”, hanem hogy a csomagban lévő tételek a háttérben megőrzik a saját identitásukat. Ez azért király, mert így a riportok, a letöltések, a licencelés (ha használsz ilyet), és a későbbi upgrade logikák nem esnek szét.

• AOV növelés anélkül, hogy kupon-mágia vagy törékeny upsell flow kellene
• Kiszámítható fulfillment: a csomag elemei külön „tudják magukról”, hogy mik
• Kevesebb egyedi fejlesztés: kevesebb „összedrótozás” termékek között

Előfizetések és kuponok: 100% recurring discount

Az előző körös fejlesztések után (1.3.2) mostanra lett igazán kerek az a sztori, hogy előfizetéshez ismétlődő kedvezményt adhatsz. A 1.3.4 egyik „apró sor a changelogban, de nagy hatás” jellegű fejlesztése: támogatja a 100% recurring discountot.

Ez elsőre úgy hangzik, hogy „jó, de ki ad ingyen előfizetést?”, aztán amikor SaaS/membership jellegű modelleket építesz, hirtelen nagyon is valós igény lesz.

• belsős csapat / tesztelők „előfizetése” számlázás nélkül
• szponzorált tagság, ahol a user nem fizet, mégis előfizetésként fut
• partner/influencer program, ahol a megújítások is 0 Ft-osak
• trial jellegű konstrukciók, amik manuálisan konvertálódnak fizetősre

Fizetések: Razorpay, Stripe metaadatok és Hosted Checkout

Razorpay (one-time payments)

A 1.3.4 hozott Razorpay támogatást egyszeri fizetésekhez. Ez tipikusan akkor jön képbe, ha nem Stripe-központú piacra dolgozol (pl. India, Dél-Ázsia), vagy ügynökségként olyan ügyfelet kapsz, akinél a lokális gateway az elvárás.

Stripe: order reference + item info a metadata mezőben

A Stripe-os élet egyik klasszikus fájdalma: a Stripe dashboardban ott van egy fizetés, de az admin csapatnak/fejlesztőnek külön köröket kell futnia, hogy ez melyik rendelés volt a webshopban. A FluentCart most order reference-et és item-szintű információt is beír a Stripe metadata részébe.

• gyorsabb egyeztetés Stripe ↔ FluentCart rendelések között
• vitás eseteknél/dispute-nál kevesebb vakrepülés
• refundnál azonnal látszik, mi volt a kosárban
• automatizálásoknál (webhook/Stripe workflow) több kontextus áll rendelkezésre

Stripe Hosted Checkout

A FluentCart eddig is tolta a testreszabható checkout block irányt, most viszont bekerült a Stripe Hosted Checkout is. Ez egy nagyon jó „kétsebességes” megközelítés: ha design-kontroll kell, maradsz az on-site checkoutnál; ha compliance/egyszerűség/Stripe-optimalizált UX kell, akkor átküldöd a usert a Stripe által kezelt oldalra.

• PCI/compliance fókuszú projektek
• nemzetközi boltok, ahol régiós szabályozásokba bele lehet futni
• nagyobb forgalom, ahol a Stripe saját UX-e és kockázatkezelése előny
• csapatok, akik csökkentenék az on-site payment hibalehetőséget

PayPal: kerekítések, endpointok, subscription stabilitás

PayPalnál a „minden működik, amíg nem” jellegű hibák szoktak a legdrágábbak lenni. A 1.3.4 több PayPal-fixet is hoz egyben: shipping flag (NO_SHIPPING) körüli anomáliák, összeg-precizitás/kerekítés miatti eltérések, és PayPal plan API endpoint következetlenségek. Ezek együtt tipikusan kevesebb sikertelen checkoutot és stabilabb megújításokat jelentenek.

Pénznemek: jött a Ghanaian Cedi (GH₵)

Nem a leggyakoribb igény magyar projekteknél, de a FluentCart iránya látszik: a pénznem-kezelést és a régiós felkészültséget komolyan veszik. A 1.3.4-ben bekerült a Ghanaian Cedi (GH₵) natív támogatása, ami azért fontos, mert pénznemnél nem csak a szimbólum számít: gateway kompatibilitás, riportok, könyvelés, kerekítés – minden ráépül.

Checkout finomhangolás: hookok, Gutenberg variációk, Divi 5

Checkout gombszöveg testreszabása hookokkal

Fejlesztői oldalról egy apróság, mégis rengeteget dob a „funnel polish”-on: bővített hookokkal már a checkout gomb felirata is testreszabható. Ez jó lokalizációhoz, A/B jellegű szövegtesztekhez, vagy akár kontextusfüggő CTA-khoz (pl. „Előfizetek”, „Foglalok időpontot”, „Letöltöm”).

Gutenberg: variációk megjelenítési hibáinak javítása

Termékvariációknál (kép + szöveg) több builder/theme kombóban szokott előjönni, hogy az editorban vagy frontenden „furán” renderel. A 1.3.4-ben a variációk Gutenberg alatti megjelenítése kapott javításokat, ami főleg mobilon és vizuális termékeknél fontos.

Divi 5 kompatibilitás

A Divi még mindig masszívan jelen van ügynökségi projekteknél, és ha egy eCommerce plugin összeakad a builderrel, abból gyorsan „nem ezt választjuk” lesz. A 1.3.4-ben a Divi 5-tel kapcsolatos konfliktusokat javították.

Order bumps + B2B checkout: a valós élet apró, de kritikus pontjai

Order bump előfizetéses termékekkel

Az order bump akkor jó, ha megbízható. Előfizetéses termékek mellett viszont könnyű elcsúszni: rossz összeg, rossz renewal logika, zavaros order summary. A 1.3.4-ben ezt a kombinációt rendbe rakták, ami AOV-növelő flowknál elég fontos.

Cégnév mező kezelése checkoutnál

B2B checkoutnál a cégnév nem „nice to have”, hanem számlázás/ÁFA/folyamatok alapja. A 1.3.4-ben a cégnév mező megjelenítése és kezelése is javítva lett a checkoutban.

Automatikus WordPress user létrehozás vásárláskor

Digitális termék, membership, előfizetés, kurzus: mind ugyanabba a problémába fut bele – a vásárlás után account kell. A FluentCart most már képes checkout közben WordPress usert létrehozni, amikor ennek van értelme. Ez kivesz egy csomó utólagos automatizálást (Zapier/Make/egyedi kód), és gyorsabb hozzáférést ad a vevőnek.

Biztonság és adatminőség: Turnstile, pontosabb riportok, stabilabb letöltések

Cloudflare Turnstile (invisible CAPTCHA)

Spam rendelések és botok ellen a klasszikus CAPTCHA sokszor UX-romboló. A 1.3.4-ben jött a Cloudflare Turnstile támogatás, ráadásul „invisible” megközelítéssel. A lényeg: védelem úgy, hogy a vásárló nem puzzle-özik a checkout közepén.

Customer „last purchase date” számítás javítva

CRM/automatizálás oldalon a „last purchase date” tipikusan trigger alap. Ha rosszul számolódik, borulhat szegmentálás, retention kampány, vagy akár VIP logika. A 1.3.4-ben ezt pontosították.

Letöltések és fájlkezelés: validáció, S3, hibák kezelése

Digitális termékeknél a letöltés a „moment of truth”. A frissítés több helyen stabilizál: objektum-alapú download kezelés rendelésekhez, üres fájlok megjelenési hibáinak javítása, S3 validáció finomítás, és általában biztonságosabb hibakezelés hiányzó/invalid fájlokra.

Offline fizetések: email értesítések

Banki utalás, díjbekérő, „majd fizetjük” jellegű B2B: offline fizetésnél a legnagyobb gond a bizonytalanság. A 1.3.4-ben már az offline paymentekhez is mennek email értesítések, így a vevő és az admin oldal is egyértelmű visszajelzést kap.

Subscription retention és cohort riportok

Ha előfizetésből élsz, nem az a kérdés, hány aktív előfizetésed van ma, hanem hogy hol esik ki a user, és melyik időszakban szerzett cohort tart ki jobban. A 1.3.4 behozta a retention és cohort riportokat, amivel már nem csak „bevétel grafikon” szinten látsz, hanem viselkedés mintázatokat is tudsz nézni.

Fejlesztői oldal: több hook, jobb fordítások

A FluentCart továbbra is abba az irányba megy, hogy ne kelljen core-t felülírni, ha egyedi checkout viselkedést vagy fizetési flow-t akarsz. A 1.3.4-ben új/fejlesztett hookok és modul bővítések érkeztek, plusz több helyen javultak a fordítások (nem csak „szövegcsere”, hanem következetesebb UI).

Egyben nézve: miért fontos a 1.3.4?

A 1.3.4 nem „még egy release note”, hanem egy elég egyértelmű jelzés: a FluentCart a valós boltos működés felé érik. Csomagtermékekkel nő a katalógus rugalmassága, a fizetési réteg tisztább és régióbarátabb (Razorpay, Stripe metadata, Hosted Checkout), az előfizetés/kupon logika kevésbé merev, és közben olyan részletek is rendbe lettek téve, amik napi üzemnél kifejezetten drágák tudnak lenni (letöltések, PayPal rounding, offline payment kommunikáció, botvédelem).

Kisebb, de hasznos javítások

• Dupla order confirmation email küldésének javítása (ne menjen ki kétszer ugyanarra a vásárlásra)
• PayPal plan API endpoint hibák javítása