OTP simple pay-hez van szükség backendre?
válasza:1. Hogy tervezed meghívni az api-t kulcs nélkül? Szerinted azt csak úgy hívogathatja mindenki, az meg majd kitalálja magátol kinek a számlájára kell jóváíírni a pénzt? Mert héát akkor a saját kulcsod bizony kikerül mindenkinek...
2. ha nem tárolod db-ben a tranzakciókat, akkor hogy fogod előkeresni Kiss Pistike tranzakcióját aki átaírta a devtoolsban 100ezerre az összeget és most sír hogy de hát ő amúgy nem akart annyit fizetni. Meg sorolhatnám mennyi problémát szül még hogy nincs semmi logod.. Persze értem a simplepay paneljén meg lehet nézni, de azt hogy párosítod össze a felhasználóiddal hogy melyik tranzakció kihez tartozik.. (Nincs erre valami jogszabály hogy x ideig tárolni kell saját oldalon is? Mert nem lepődnék meg ha van.)
3. Hogy fogod tudni hogy sikeres, vagy sikertelen volt a tranzakció?
sőt ezt a lépést ki sem lehet hagyni.. A otp rendszere küld egy ipn üzenetet amire !válaszolni kell. Ugye ez egy statikus oldallal nem fog menni.
4. Miután elkészült a fejlesztés ráadásul a simplepaynél ellenőrzik is (nem a forráskódot) és bizonyos feltételeknek meg kell felelnie. Szerintem az ilyen hackelést észreveszik, még ha meg is oldanád valahogy.
válasza:"OTP simple pay-hez van szükség backendre?"
Igen.
"Egy olyan honlapba kéne integrálnom adományozási lehetőséget ahol csak frontent JS elérhető. Csak annyi kell hogy lehessen egy x összeggel támogatni."
Ha csak annyi kell akkor elég egy számlaszám megadása esetleg közleménybe, hogy adomány. Vagy lehet egyéb megoldásokat (is) PayPal, Patreon, GoFundMe ...
"A dokumentáció alapján nekem olybá tűnik hogy elég meghívnom az API-jukat, a visszakapott URL-re redirectelni, végbemegy a fizetés és utána ők visszaredirectelnek rám, ami lehet egy statikus oldal."[...]
Nem tudom hogy nézted, vagy mit néztél, de én ránéztem : [link]
A "Dokumentáció, normál fizetések: Magyar" 42.ik oldaltől ír egy "PHP mintakód (SDK)"-od, leírást róla.
"Van bármi security kockázat egy teljesen frontend alapú megvalósításban?"
Ha ez felmerül egyáltalán, de már úgy önmagában is, túl veszélyes hogy egymagad ilyenbe belefogj. Ha hibásan integrálod, félreérted a dokumentációt (mint például most is) akkor könnyen sebezhetővé teheted a weboldalt a hackerek számára, így adatok, például a felhasználók banki adatai, könnyen kiszivároghatnak ...
CORS, referel header stb. kliens oldalon kijátszható, aláhamisítható ...
Másodiknak:
1. Az api kulcs miatt biztos hogy kell csak röptében átolvasva nem láttam hogy megkövetelik-e.
2. Ezek teljesen jogosak egy webshopban de nálunk tényleg csak szó szerint annyi kéne amit egy mezei átutalás is megoldana viszont, a könnyebb folyamat miatt a bankkártyás megoldást szeretnék. Amúgy ha van backended Pistike akkor is áttudja írni az összeget, a szervernek is el kell postolnod, de ez semmiben nem más mintha eleve ennyit írt volna be. Adományozás lévén, bármilyen összeg elfogadható.
3. Számomra nem releváns, nem kell ellenszolgáltatást nyújtani. A fizető pedig tudja. Viszont az észrevétel jogos, nem tudtam hogy az ipn-re kötelező válaszolni.
Harmadiknak:
Csak átfutottam a doksit, nem vettem észre hogy api kulcsot kérnének amin meg is lepődtem. Azt leszámítva a mi esetünkben (egy sima bármilyen összegű adományozás) nem élnek az általad írt kockázatok. Nem kezelünk felhasználói banki adatokat, azt a simple pay oldala végzi. Volt egy gyors feltételezésem hogyha nem kell api kulcs, akkor elméletileg nincs akadálya egy teljesen frontend alapú megoldásnak, hisz csak egy összeget küldök egy azonosítóra, semmiben nem más mint egy utalás, a hitelesítést a simple pay végzi.
Alapvetően nekem is az volt a feltételezésem hogy nem megoldható backend nélkül, de double checkelni akartam hátha akik már használták tudnak valami legit workaroundot. Köszönöm a megerősítést.
válasza:"Csak átfutottam a doksit, nem vettem észre hogy api kulcsot kérnének amin meg is lepődtem."
Ha csak a tartalom jegyzéket futottad volna végig, ott is csak a főcímeket akkor láttad volna, hogy "PHP SDK"
Vagy ha csak a "Rövid összefoglalás" című résztnek csak az elejét, ha olvastad volna is láttad volna.
"mi esetünkben (egy sima bármilyen összegű adományozás) nem élnek az általad írt kockázatok. "[...]
De élnek, ha hibásan implenetálod élnek azon dolgok amiket leírtam.
Az utalás esetében a weboldaltól teljesen függetlenül működik, ha csak egy papírra kinyomtatom vagy kézzel kiírom a számlaszámot, a közleményt és az alapján indítom az utalást. Az oldalt pedig le is dos-olhatják, le is törlhetik, meg is semmisíthetik, az utalás akkor is végbe tud menni.
Ha pedig a weboldalon kezdetményezel tranzakciót , akkor a weboldal aktív résztvevője, REST API-n keresztül, függetlenül attól, hogy milyen materiális vagy materializálatlan/absztakt dolog alapja szolgáltatja és a felhasználó vagy az oldal üzemletetője határozza meg a fizetési összeget. Ezen felül meg kell felelniük bizonyos, technikai, jogi és szabályozási követelményeknek (pl. PCI DSS). Ha a laikus nem ismeri ezeket a követelményeket, akkor a weboldal üzemeltetője jogi problémákba ütközhet.
Ha nincs pénz hozzáértőre aki megcsinálná, és itt kell kérdezgetni, akkor egyébként nem tudom, hogy van e pénz erre a szolgáltatásra. Most nem tudom az összeget, de évekkel ezelőtt 50 ezret kellett fizetni a banknak, hogy a bank engedje weboldalnak, hogy rendelkezzen ilyen fizetési átjáróval.
válasza:Ha a backendről hívod a rest amit. Pistike semmit nem tud átírni.. az már régen rossz lenne.
Mellesleg adományozni kártyás fizetéssel csak simán jogellenes. Minimum valami virtuális terméket (lásd foodora wolt virtuális kajái) kell adnod ami után adóznod kell. Ez egy FIZETÉSI mód. Ha támogatást akarsz ott vannak az erre való szolgáltatások amit a 3as írt. De megjegyezném hogy 200ezer nettó felett azok is adókötelesek.
Kapcsolódó kérdések:
Minden jog fenntartva © 2025, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!