Miért épülnek a Billingo Webshop integrációk teljes Billingo SDK-ra?

A Billingo WooCommerce bővítmény nem közvetlenül, “nyers” API-hívásokkal kommunikál a Billingo rendszerrel, hanem egy teljes Billingo SDK-n keresztül.

Ez azt jelenti, hogy a pluginben megtalálható:

  • a Billingo API végpontjainak egységes kezelése,

  • a kérés–válasz logika,

  • az authentikáció és tokenkezelés,

  • a hibakezelés és validációk,

  • valamint a típusos adatmodellek (DTO-k).

Ennek több fontos előnye van:

  1. Tiszta, átlátható modul-kód

    • A WooCommerce-specifikus rész csak azt „mondja meg”, mit kell csinálni (számla generálása, sztornó, szállítólevél, stb.).

    • A hogyan (endpoint, header, token, JSON-kezelés, hibakódok) az SDK-ban történik.

    • A plugin kódja így rövidebb, könnyebben olvasható és karbantartható.

  2. Egységes hibakezelés és stabilitás

    • Az SDK ugyanúgy kezeli az olyan helyzeteket, mint:

      • hibás authentikáció,

      • lejárt token,

      • API változás miatti szerverhiba,

      • hálózati hiba, time-out, rate limit.

    • A hibák egységes exception-ökön keresztül érkeznek, így a plugin logikája egyszerűen kezelheti őket.

  3. Könnyebb verziókövetés és API-változások kezelése

    • Ha a Billingo API változik (új mezők, új endpoint, módosuló payload), akkor elég az SDK rétegben javítani.

    • A WooCommerce modul legtöbbször módosítás nélkül működőképes marad.

    • Ez csökkenti a frissítési hibalehetőségeket.

  4. Típusos, jól dokumentált adatmodellek

    • Az SDK típusos objektumokkal (DTO-kkal) dolgozik, nem nyers tömbökkel.

    • Ez jobb IDE támogatást ad (autocomplete, phpStorm hint), és csökkenti a „elírt mezőnevű tömb index” jellegű hibákat.

  5. Új funkciók gyorsabb fejlesztése

    • Ha új funkciót szeretnénk (pl. proformák, díjbekérők, jóváíró számlák, tételek részletesebb kezelése), azt elsősorban az SDK-ban vezetjük be.

    • A plugin oldalon csak “össze kell kötni” az új SDK-funkciót a WooCommerce eseményekkel (státuszváltás, rendelés mentése, manuális gomb, stb.).


Hogyan fejleszthető tovább – tipikus lépések

Ha új Billingo-funkciót szeretnénk beépíteni a WooCommerce bővítménybe, a folyamat nagy vonalakban így néz ki:

  1. SDK bővítése

    • Hozzáadjuk az új Billingo endpoint kezelését az SDK-hoz:

      • új service osztály vagy meglévő service bővítése (pl. DocumentsService, ClientsService),

      • új metódus (pl. createProforma(), sendDocumentByEmail(), stb.),

      • szükséges DTO-k (request/response objektumok),
        unit tesztek az új endpointokra (ajánlott).

  2. Plugin logika összekötése az SDK-val

    • A WooCommerce modulban a megfelelő ponton (hook, cron, admin action):

      • meghívjuk az SDK metódust,

      • feldolgozzuk a választ (számla ID, link, státusz),

      • eltároljuk az eredményt (order meta, log, stb.),

      • hiba esetén felhasználóbarát üzenetet jelenítünk meg.

  3. Példák: (létező funkció alapján)

    • „Rendelés processing státuszba lép → Billingo számla generálása”.

    • „Admin gomb megnyomása → számla újraküldése e-mailben Billingóból”.

  4. Beállítások & admin UI frissítése

    • Ha az új funkció igényel konfigurációt (pl. külön számlatömb, jogcím, fizetési mód mapping), akkor:

      • új beállítás mezők a plugin admin felületén,

      • validáció (kötelező mezők, típusellenőrzés),

  5. Visszafelé kompatibilitás & migráció

    • Az SDK-val könnyebb verziókat kezelni:

    • Szükség esetén:

      • régi mezők támogatása (deprecated, de még működő),

      • átmeneti réteg két API verzió között.

  6. Tesztelés

    • SDK-szinten: endpoint tesztek (lehetőleg automata).

    • WooCommerce szinten:

      • test webshopban próbarendelések,

      • különböző fizetési módok, státuszok,

      • többnyelvűség / több valuta (ha releváns).


Mit jelent ez a gyakorlatban fejlesztőknek?

  • Ha Billingo API-val kapcsolatos fejlesztésed van, először az SDK réteget nézd:

    • van-e már rá metódus?

    • ha nincs, ott érdemes hozzáadni.

  • A WooCommerce modulban ne írj közvetlen HTTP hívásokat:

    • ne használj új Guzzle/cURL kódot,

    • ne dekódolj közvetlenül JSON-t,

    • mindig az SDK-t használd belső „kapunak” a Billingo felé.

Így a modul:

  • hosszú távon stabilabb,

  • könnyebben továbbfejleszthető,

  • jobban tesztelhető,

  • és api-változásoknál is kezelhetőbb marad.

Kapcsolódó cikkek

Oldal tetejére