Egy webshopos rendelés, egy digitális előfizetés és egy piactéri foglalás eltérő fizetési megoldást igényel. Saját projektjeinken keresztül mutatjuk meg, mikor jön szóba bankkártyás fizetés, Apple- vagy Google-vásárlás és mit kell a háttérben is megoldani.
„Legyen benne bankkártyás fizetés.” Egy mobilapp tervezésekor ez gyakran egyetlen sor az igénylistán. Pedig egészen mást jelent egy szerszám megrendelése, egy prémium appfunkció megvásárlása vagy egy másik felhasználó eszközének kibérlése.
A fizetési megoldást elsősorban az dönti el, mit kap a vásárló a pénzéért, hol használja azt és melyik piacon érhető el az app. Ezután érdemes szolgáltatót választani.
Röviden:
Mi alapértelmezésként Stripe-ot javaslunk, ahol ezt az áruházi szabályok lehetővé teszik. Ha áruházi vásárlás szükséges, Apple In-App Purchase-t vagy Google Play Billinget építünk be, jellemzően digitális tartalmakhoz, funkciókhoz és előfizetésekhez.
- Fizikai termék vagy az appon kívül igénybe vett fizikai szolgáltatás: például termékrendelés, kiszállítás vagy takarítás: külső fizetési szolgáltató, például Stripe, Barion vagy a webshop meglévő banki fizetése használható. Ezek után az ügyletek után nincs Apple- vagy Google-áruházi értékesítési jutalék; a fizetési szolgáltató díjával számolni kell.
- Az appban használt digitális tartalom vagy funkció: például prémium funkció vagy digitális előfizetés: főszabály szerint áruházi in-app purchase (IAP) szükséges: iOS-en Apple In-App Purchase, Androidon Google Play Billing. A célpiaci kivételeket külön ellenőrizni kell.
- Piactér, ahol a pénz egy másik felhasználóhoz kerül: a vevő fizetését és az eladó kifizetését is kezelni kell, például Stripe Connecttel. A termék fizikai vagy digitális besorolása itt is számít.
A Petadevnél dolgoztunk áruházi egyszeri vásárlásokon és automatikusan megújuló előfizetéseken, webshophoz kapcsolódó mobilos rendeléseken és Stripe Connectet használó piactéren is. Ezekből a tapasztalatokból mutatjuk meg, mit érdemes tisztázni a fejlesztés előtt.
Milyen fizetés illik az alkalmazásodhoz?
Az alábbi táblázat kiindulópont. Digitális vásárlásoknál az adott országra, áruházra és terjesztési módra vonatkozó kivételeket is ellenőrizni kell.
| Mit vásárol a felhasználó? | Példa | Milyen megoldásból érdemes kiindulni? |
|---|---|---|
| Fizikai terméket | Szerszám, élelmiszer, ruházat | Külső fizetési szolgáltató, például Stripe vagy a meglévő banki fizetés |
| Az appon kívül igénybe vett fizikai szolgáltatást | Házhozszállítás, takarítás | Külső fizetési szolgáltató |
| Az appban elérhető digitális tartalmat vagy funkciót | Prémium funkció, videótár, digitális előfizetés | Főszabály szerint áruházi in-app purchase (IAP): Apple In-App Purchase vagy Google Play Billing; a kivételek külön vizsgálandók |
| Más felhasználó fizikai tárgyát bérli | Eszközbérlő piactér | Piactéri pénzmozgásokat támogató megoldás, például Stripe Connect |
| Többféle terméket vagy szolgáltatást együtt | Személyes edzés és külön megvásárolható videótár | A tételeket külön kell besorolni; akár több fizetési folyamat is szükséges lehet |
Az Apple és a Google egyaránt külön kezeli a fizikai és a digitális vásárlásokat. A fizikai termékeket nem az áruház digitális vásárlásokhoz készült rendszerén keresztül kell értékesíteni. A részletes feltételeket az Apple fizetési szabályai és a Google Play fizetési irányelvei tartalmazzák.
Önmagában az „előfizetés” szó sem dönti el a kérdést: egy rendszeres fizikai kiszállítás és egy appban elérhető digitális tartalomcsomag eltérő kategória.
Az Apple Pay nem ugyanaz, mint az in-app purchase (IAP)
Az Apple Pay és a Google Pay fizetési megoldások, amelyekkel a vásárló a támogatott fizetési folyamatban használhatja a tárcájában tárolt fizetési módját. A kereskedő oldalán ehhez fizetési szolgáltató is kapcsolódik.
Az Apple In-App Purchase és a Google Play Billing ezzel szemben az áruházak saját vásárlási rendszerei: például digitális appfunkciók és előfizetések értékesítésére szolgálnak.
| Elnevezés | Mit jelent a tervezésnél? |
|---|---|
| Apple Pay / Google Pay | Hogyan fizet a vevő egy támogatott kereskedői fizetési folyamatban? |
| Apple In-App Purchase / Google Play Billing | Hogyan értékesítjük és kezeljük az áruház rendszerében a digitális terméket? |
Az Ostvánál például a Stripe-fizetéshez Apple Pay és Google Pay is elérhető. Ettől a bérlés nem válik áruházi digitális vásárlássá.
A technikai működésről az Apple Pay és a Google Pay hivatalos oldalán olvashatsz.
Milyen fizetéseken dolgoztunk a Petadevnél?
Az alábbiak saját projektjeinkből származó példák. A mobilos és webes tapasztalatot külön jelöljük.
| Projekt | Megvalósított fizetési megoldás |
|---|---|
| MyCalamari | A túrák in-app purchase-szel (IAP) vásárolhatók meg. A más értékesítési platformon vett túrák egyedi kóddal válthatók be az appban. |
| Egy testépítős alkalmazás és egy fejlesztés alatt álló coach app | Áruházi alkalmazáson belüli vásárlások: ezeken a projekteken összességében egyszeri vásárlással és automatikusan megújuló előfizetéssel is dolgoztunk. A coach app fizetési része elkészült, maga az alkalmazás még fejlesztés alatt áll. |
| Ostva | Stripe Connectet használó piactér, Apple Pay- és Google Pay-fizetési lehetőséggel |
| Szerszámoutlet | Az appból leadott rendelések kártyás fizetése CIB bankos fizetési felületen, böngészőbe átirányítással |
| Driveral és egy további webshop | Barion-integráció webes rendszerben |
| Weboldalas projektek | SimplePay-integráció; ezt eddig webes, nem mobilappos környezetben valósítottuk meg |
Alapértelmezésként Stripe-ot javaslunk, ahol ezt az áruházi szabályok lehetővé teszik: számunkra a szolgáltató megbízhatósága és az adott projektekhez megfelelő díjazása szól mellette. Ha a szabályok áruházi vásárlást írnak elő, Apple In-App Purchase-t vagy Google Play Billinget használunk. Meglévő webshopnál a már működő fizetési rendszerhez való kapcsolódás is fontos szempont.
Stripe, Barion, SimplePay vagy a meglévő banki fizetés?
Egy webshop mellé készülő appnál először azt nézzük meg, hogyan működik a jelenlegi rendelés és fizetés. Hol jön létre a rendelés? Melyik rendszer tartja nyilván az állapotát? Hol intézik a visszatérítést?
A Szerszámoutlet esetében az alkalmazásból leadott rendelés kártyás fizetése böngészőben megnyíló CIB-felületen történik. Ez is mobilos vásárlási folyamat, még ha a kártyás lépés nem is az alkalmazás saját képernyőjén jelenik meg. A projekt további részleteiről a webshop és mobilapp összekapcsolását bemutató cikkünkben írtunk.
Szolgáltatóválasztáskor ezeket érdemes összevetni:
- a célországokat, pénznemeket és szükséges fizetési módokat;
- a meglévő webshophoz vagy ügyviteli rendszerhez való kapcsolódást;
- az egyszeri, ismétlődő vagy piactéri fizetési igényeket;
- a vásárlás közbeni átirányítást és a visszatérés módját;
- a tranzakciós, devizaváltási és egyéb releváns díjakat;
- a visszatérítések és az ügyfélszolgálati feladatok kezelését.
A Barion és a SimplePay lehetséges megoldásként vizsgálható, de a saját tapasztalatunk ezekkel eddig webes integrációkból származik. Nem állítjuk, hogy minden apphoz ugyanaz a szolgáltató vagy ugyanaz a beépítési mód a megfelelő.
Digitális vásárlások: az előfizetés a fizetés után is feladat
Egy fizetős funkciónál vagy digitális előfizetésnél nem elég megjeleníteni a vásárlási ablakot. Az alkalmazásnak és a saját háttérrendszernek azt is tudnia kell, milyen hozzáférés jár a felhasználónak.
A Google előfizetési dokumentációja külön állapotként kezeli például az aktív, lemondott, lejárt és fizetési problémával érintett előfizetéseket. A lemondás nem feltétlenül jelent azonnali hozzáférés-megszűnést: a már kifizetett időszak még tarthat. Ezért nem elegendő egyetlen „fizetett / nem fizetett” kapcsoló. (Google: előfizetések életciklusa)
A saját projektjeinkben az áruházi és a saját rendszerben tárolt információk szükséges egyeztetését automatizáljuk. A termék tervezésekor azt is rögzíteni kell, melyik vásárlás milyen funkciót, tartalmat és időtartamot biztosít.
Mi a helyzet az EU-s alternatív fizetéssel?
Digitális termékeknél sem lehet minden országra egyetlen szabályt ráhúzni. Az EU-ban az Apple külön feltételekkel biztosít alternatív fizetési és külső ajánlatokra vezető lehetőségeket. Ezekhez üzleti feltételek, díjak és jelentési kötelezettségek is kapcsolódhatnak: a saját fizetés nem automatikusan jutalékmentes. (Apple: EU-s feltételek)
Az Apple díjazási lehetőségeiről külön írtunk az EU-s App Store-változásokat bemutató cikkünkben. A Google alternatív számlázási programjainak alkalmazhatóságát szintén célpiaconként kell ellenőrizni.
Mi ezeket az alternatív digitális fizetési lehetőségeket jelenleg vizsgáljuk; még nem hivatkozunk rájuk saját, éles projektben igazolt tapasztalatként.
Miért fontos a besorolás még az áruházi beküldés előtt?
Volt olyan projektünk, ahol a fizikai és digitális szolgáltatás értelmezése miatt több körben zajlott az áruházi ellenőrzés. Fizetéshez kapcsolódó elutasítással is találkoztunk már és sikerült rendezni az érintett eseteket. A szükséges változtatás mindig az adott terméktől függött.
Az egyik esetben reader appként alkalmazható megoldás segített. Ez azonban meghatározott tartalomfogyasztó alkalmazások kategóriája: attól, hogy egy appban videó is van, még nem válik automatikusan jogosulttá. Az Apple ehhez külön feltételeket határoz meg.
A böngészős fizetés önmagában nem oldja meg a besorolást. Digitális tartalomnál előbb az adott áruházban és piacon engedélyezett folyamatot kell kiválasztani és csak utána megtervezni az átirányítást.
Megrendelőként ezért érdemes pontosan leírni, mit vásárol az ügyfél. A „coach-előfizetés” például önmagában kevés információ: lehet mögötte személyes foglalkozás, digitális tartalomtár vagy ezek kombinációja.
Ha a digitális tartalmat az appon kívül is értékesíted, a hozzáférést is előre meg kell tervezni. A MyCalamariban a túrák in-app purchase-szel vásárolhatók meg, a partnerplatformon vett túrák pedig egyedi kóddal válthatók be. Az Apple 3.1.1-es pontja főszabály szerint tiltja a saját tartalomfeloldó mechanizmusokat, például a licenckulcsokat, a 3.1.3(b) pont viszont feltételekkel engedi a többplatformos hozzáférést. Ezért egy beváltókódos megoldást mindig az adott értékesítési modellhez kell igazítani és a beküldés előtt érdemes ellenőrizni.
Piactéri fizetés: a vásárlás és az eladó kifizetése két külön esemény
Egy piactérnél a platformnak a vásárló fizetését és az eladó vagy szolgáltató felé történő pénzmozgást is kezelnie kell. Erre készülnek az olyan megoldások, mint a Stripe Connect.
Az Ostva fejlesztésénél is ilyen összetett fizetési folyamattal dolgoztunk. A piactér megvalósításáról szóló esettanulmányban bemutatjuk a projektet; itt a tervezéshez szükséges kérdések a lényegesek:
- Mikor kérjük a fizetést és kell-e előtte másik szereplő jóváhagyása?
- Szükséges-e külön zárolás és későbbi terhelés?
- Mikor és milyen feltételekkel kapja meg a pénzt az eladó?
- Hogyan vonja le a platform a saját díját?
- Mi történik meghiúsuláskor vagy részleges visszatérítéskor?
- Milyen ügyeket tud az üzemeltető az adminfelületen kezelni?
Egy egyszerű webshopos vásárláshoz képest itt több szereplő és több üzleti állapot kapcsolódik ugyanahhoz az ügylethez. A fejlesztés terjedelmét ezek a szabályok jelentősen befolyásolják. Minden piactérnél a saját üzleti modellből kell kiindulni: ki, kinek, milyen teljesítésért fizet?
Mi történjen, ha a vevő fizetett, de nem tér vissza az appba?
A sikeres fizetést nem szabad kizárólag a visszairányításból megállapítani. A vásárló bezárhatja a böngészőt, megszakadhat a kapcsolata, vagy a visszatérés elakadhat úgy is, hogy a terhelés már megtörtént.
A Stripe ezért a szerveroldali értesítésekre épülő ellenőrzést írja le a fizetés utáni teljesítéshez. A feldolgozásnak az ismételten érkező eseményeket is kezelnie kell, hogy ugyanaz a vásárlás ne eredményezzen többszörös teljesítést. (Stripe: fizetés utáni teljesítés)
A tervezésnél külön rögzítjük, hogy a fizetés eredménye mit változtat meg: létrejön vagy teljesíthetővé válik egy rendelés, aktiválódik egy jogosultság esetleg továbbhalad egy foglalás.
Teszteléskor a sikeres vásárláson túl a megszakítást, sikertelen terhelést, ismételt próbálkozást és visszatérítést is végig kell venni. Előfizetésnél ehhez a megújulás és a hozzáférés változásai is hozzátartoznak. A teljes kiadás előtti ellenőrzésről a mobilalkalmazások tesztelését bemutató cikkünkben olvashatsz.
Mitől függ a fizetési integráció fejlesztési igénye?
A „kártyás fizetés” önmagában nem elég pontos feladat egy ajánlathoz. Többek között az számít, hogy egy meglévő webshop folyamatához kapcsolódunk-e, új digitális előfizetést építünk, vagy több szereplő között osztjuk fel a bevételt.
A költséget a fizetési módok mellett a háttérrendszer, a jogosultságkezelés, a visszatérítési szabályok, az adminisztráció és a tesztelendő esetek határozzák meg. Az általános fejlesztési ársávokat a mobilalkalmazás-fejlesztési oldalunkon találod; a fizetési részre az üzleti folyamat ismeretében tudunk becslést adni.
A Petadevnél szükség esetén a fiókok beállításának támogatását, a technikai integrációt, a tesztelést és az áruházi beküldéshez kapcsolódó munkát is intézzük. A fiókok és a projekthez tartozó hozzáférések az ügyfél tulajdonában maradnak. Az ügyfél biztosítja a szolgáltatók által kért üzleti adatokat és a saját nevében szükséges jóváhagyásokat.
Nem biztos, hogy az appodban kell-e IAP?
Írd meg, mit értékesítenél az appban és ingyenesen átnézzük, hogy Stripe, in-app purchase vagy a meglévő webshopos fizetés illik hozzá, mielőtt egy áruházi elutasítás döntene helyetted.
