A legutóbbi projektünk kapcsán egy számunkra teljesen új funkció fejlesztésével bízták meg csapatunkat. Az alkalmazásba szükségessé vált egy fizetési modul integrációja, mellyel a felhasználók bankkártyával tudnak egyszerű tranzakciókat lebonyolítani, illetve havi előfizetést is intézni. Ez a feladat elsőre elég komplexnek tűnt, és kicsit félve is álltunk neki, azonban a későbbiekben világgossá vált, hogy maga az implementáció mégsem egy rakétatudomány. ?
A feladat megoldásának első körben irodalomkutatással álltunk neki, felderítettük a terepet, hogy milyen lehetőségeink vannak, és egyeztettünk sokat a megrendelők preferenciáiról. Ennek eredményeképpen esett a választás a Braintree-re.
Felmerülhet a kérdés, hogy miért is van szükség nekünk egy third-party alkalmazás használatára annak érdekében, hogy a fizetési funkciókat megvalósítsuk. A kérdés megválaszolására nem kell sokat böngészni, mert elég hamar szembe találkozunk a PCI DSS (The Payment Card Industry Data Security Standard) irányelvekkel, amelyek komoly előírásokat fogalmaznak meg az egyes kártyaadatok tárolására. Ahhoz, hogy ezeket saját rendszerben tudjuk tárolni, teljesíteni kell a szabványban megfogalmazott irányelveket. De miért is jó a Braintree? Mert nem nekünk kell ezeknek a szigorú és viszonylag nehezen teljesíthető előírásoknak megfelelni, hanem a Braintree ezt megteszi helyettünk. Mit is jelent ez a gyakorlatban? Mi nem férünk hozzá semmilyen olyan kártyaadathoz, amivel bármilyen módon is azonosítható lenne a felhasználó vagy a bankkártya. Csupán olyan információkhoz, amivel ezek nem egyértelműen azonosíthatók (például: a kártya utolsó számjegye, milyen kártyaszolgáltatóhoz tartozik a kártya, mikor jár le a kártya, stb.)
Technikai oldalról fontos szempont volt számunkra, hogy az általunk használt technológiákba egyszerűen és könnyen használható legyen. Mivel főleg Java és Angular/React stack-ben dolgozunk, így mindenképp szükségét éreztük, hogy valamilyen Java library-t és Javascript alapú scriptgyűjtemény rendelkezésre álljon. Kliensoldalon ezt a Braintree saját, úgynevezett Drop-in UI megoldása biztosítja. Java oldalon szintén elérhető olyan library, aminek használata nagyban megkönnyíti a későbbi funkciók implementációját. Természetesen a szerveroldalon nem csak Java-hoz léteznek megoldások, hanem PHP, NodeJS vagy akár .NET nyelvekhez is.
Miután sikeresen beillesztettük az egyes komponenseket, ki-ki a saját részéhez, tehát HelloWorld szinten minden működött ?, rátértünk a tényleges funkciók megvalósítására. Ehhez azonban meg kellett értenünk a Braintree alapvető működését. A működés az ún. nonce érték ide-oda küldésével valósul meg. Ez a nonce egy egyszer használatos azonosító, amivel egy adott felhasználó kártyaadatát feleltetjük meg. Ezt a nonce értéket maga a Braintree állítja elő, ezzel biztosítva azt, hogy ne férjünk hozzá a tényleges kártyaadatokhoz.
Az alábbi ábrán látható, hogy hogyan is áll elő a nonce, milyen kommunikációk valósulnak meg.
- A kliensoldal kér egy ún. client tokent, amivel inicializálja saját komponensét.
- A szerveroldal előállítja a client tokent a kliens számára.
- Miután a kliensoldal inicializálta magát, a felhasználó megadja a kártyaadatait és jóváhagyja, ezt követően a Braintree saját szerveroldali része előállítja számunkra a nonce-ot.
- A kliens a kapott nonce-ot továbbítja a saját szerveroldali alkalmazásunk felé.
- A saját szerveroldali alkalmazásunk ezt a nonce-ot felhasználva különböző funkciókat végez el a Braintree szerverrel (például: egyszerű tranzakciót indíthatunk).
A folyamatból jól látható, hogy végig rejtve marad a mi rendszerünk előtt, hogy a felhasználó milyen bankkártya adatokat ad meg. Ezt követően az már a mi feladatunk marad, hogy milyen struktúrában és milyen módon kezeljük le, hogy milyen tranzakciók történtek, amelyek hatással vannak az alkalmazásunk működésére, milyen előfizetések vannak, ésatöbbi.
Ahhoz, hogy a Braintree funkcióit magabiztosan tudjuk használni, szükség van pár alapfogalom, alapdefiníció megismerésére. Az egyik fontos fogalom a vault fogalma. Ez igazából a user-tár. A vaultban létrehozhatunk felhasználókat, akikhez különböző kártyákat, fizetési módokat adhatunk meg, számlázási címet, stb. (Igen, a Braintree lehetőséget biztosít a kártyás fizetés mellett PayPal, ApplePay és még pár más fizetési mód kezelésére is, ezeket mi azonban a projekt során nem használtuk). A felhasználók létrehozása a vaultban azért fontos, mert ezzel nagyban segítjük az esetleges későbbi fizetési történet nyomkövetését, esetleges utólagos beavatkozást az előfizetésekbe, vagy akár visszautalni a tévesen fizetett összegeket. Mint említettem, a vaultban tárolt felhasználókhoz rendelhetünk fizetési módokat. Ez tulajdonképpen azt jelenti, hogy a kliens oldaltól kapott nonce-ból (ugye, ami egyszer használatos) egy olyan azonosítót generálunk, amire a későbbiekben a megfelelő felhasználón keresztül hivatkozhatunk, ez az azonosító a payment method token. Sokszor szükség van arra, hogy a letárolt fizetési módokhoz olyan azonosítót generáljunk, amivel a kliensoldal képes dolgozni, tipikusan azokban az esetekben, amikor egy adott nonce-t fel kell dúsítani plusz információkkal. Mit is jelent ez? Például, ha kétfaktoros hitelesítés kell (SCA implementáció, lásd linkek) egy, már letárolt kártyára. Ebben az esetben nem szükséges újra bekérni a kártyaadatokat, hanem a már letárolt payment method token-ből generált payment method nonce-on keresztül az adott kártya adataihoz új információkat „rögzítünk”.
Most, ha nem is a legmélyebben, de tisztáztuk a működés alapfogalmait, rátérhetünk kicsit mélyebben magára arra a funkcionalitásra, amiért az egészet használjuk. A legegyszerűbb fizetési esemény, amikor valamilyen egyszeri tranzakciót szeretnénk végrehajtani. Ebben az esetben a felhasználó megadja a kártyaadatait (vagy a korábban letárolt kártyaadatait használjuk), ha szükséges, kétfaktoros hitelesítést kérünk, majd sikeres hitelesítést követően a megadott összeggel tranzakciót indítunk. Maga a tranzakcióindítás a saját szerveroldali alkalmazásunk és a Braintree szerver között történik. A kliensoldalra a tranzakció végrehajtásnak sikeressége jut vissza. Ehhez a funkcióhoz mindössze a Transaction.sale() metódus megfelelő paraméterezése szükséges.
Az egyszeri tranzakciók mellett szükséges volt ismétlődő fizetéseket, ún. recurring billing-et megvalósítani. Ehhez már ismernünk kell azokat fogalmakat, mint plan, subscription, addon, discount. Maga az előfizetés egy plan-hez tartozik. A plan defniálja magát a csomagot, amire a felhasználó előfizet. Mi az előfizetés ciklusa, mennyibe kerül, van-e próbaidőszak, és ha igen, akkor annak mi a konfigurációja, stb. Amikor egy előfizetés létrejön, az a subscription. A subsciptionhöz tartozik egy plan, ami meghatározza, hogy mikor kell a következő fizetést indítani, mikor jár le és minden olyan információt, ami szükséges ahhoz, hogy ez automatikus legyen. Amikor egy subscription-t létrehozunk, akkor lehetőségünk van addon-okat, azaz kiegészítő elemeket hozzáadni, mint például plusz kredit, vagy discount-ot, azaz kedvezményt. Ezeket a subscription létrehozása során tudjuk megadni. A mi alkalmazásunkban kizárólag a feliratkozás során használjuk ezt, mert olyan előfizetési modell van a rendszerünkben, ahol kötelezően egy egyenlegfeltöltést is el kell végezni, így magát az egyszeri egyenlegfeltöltést addon-ként adjuk meg a feliratkozás során, így csak egy tranzakcióra lesz szükség a kártyán.
A subscription létrehozásával bekonfiguráltuk az automatizmust, amellyel a megadott ciklusokban a kártyaterhelés megtörténik. Arra, hogy az alkalmazásunk is értesüljön ezekről az automata eseményekről, lehetőséget biztosít a Braintree webhook-ok formájában. A Braintree beállításai közt definiálhatjuk, hogy milyen eseményekről szeretnénk egy publikus végpontra történő POST kéréssel információt kapni. Ilyen esemény például, ha egy subscriptionre az új ciklus kezdetén terhelés történik, aktív állapotba kerül, stb. A mi esetünkben, mi minden eseményről kérünk értesítést annak érdekében, hogy lássuk, mi történik a Braintree automatizmusok során, azonban ezekből az eseményekből csak párat használunk olyan módon, hogy a rendszerünkre hatással legyen. Például a sikeres terhelés ilyen, hiszen erről számlát kell kiállítanunk, így ennek az eseménynek a beérkezése váltja ki az aktuális havidíjhoz tartozó számla kiállításának a folyamatát.
Összefoglalva a Braintree-vel szerzett tapasztalatokat, egyértelműen kijelenthető, hogy hatalmas segítséget nyújt a fizetési szolgáltatások integrációja kapcsán. Jól dokumentált, könnyen használható, és egy olyan kliensoldali irányítópult áll rendelkezésre, ahol könnyen elvégezhetőek az egyes speciális beállítások, és az esetleges adatmódosítások. Innentől kezdve a fejlesztők feladata, hogy a saját rendszerükben milyen módon használják, tárolják és kezelik az egyes tranzakciókhoz, előfizetésekhez tartozó adatokat, és milyen üzleti logikában használják azt fel.
Bízom benne, hogy a fentebb leírtak jó áttekintést adtak ahhoz, hogy a jövőben Ti is magabiztosan tudjatok fizetési szolgáltatást integrálni a saját alkalmazásotokhoz Braintree használatával.
Linkek:
- Braintree Sandbox: https://sandbox.braintreegateway.com
- Developer Docs: http://developers.braintreepayments.com
- PCI Compliance Guide: https://www.pcicomplianceguide.org
PSD2 understanding: https://www.braintreepayments.com/blog/understanding-and-preparing-for-psd2-strong-customer-authentication/
