ugrás a tartalomhoz

Internetes kártyás fizetés, elmegy, honnan tudom

vtsoftware · 2010. Május. 8. (Szo), 23.05
Üdv mindenkinek.

Egy olyan weboldal készítésével bíztak meg, amelyen a CIB Bank internetes bankkártyás fizetési szolgáltatását szeretnék használni.
Ez rendben is.

Olvasom a dokumentációt, és egy kicsit elgodolkodtató dolgot kell benne megvalósítani.
Lehet hogy tudom a megoldást, de hogy már egy ideje nem ugrik be semmi az tuti... ami pedig elsőre beugrott az háát... nem tudom, végső esetben csak. Ha nincs más.

Nos, leírom dióhéjban, lehet van aki tud megoldást, de nem nagyon ismeri ezt a dolgot. Elképzelhető hogy én nem vagyok még valamivel tisztában, de úgy tűnik a lényeges fonalat már elkaptam...

1. az áruház oldalán fizetési módot választunk, elküldjük a banki szervernek az adatokat (összeg, tranzakció azonosító, stb...)
2. átirányítás a fizetési oldalra (itt adja meg a vásároló a kártya adtokat)
3. átirányítás az áruház oldalra ahol most a lezárást küldjük el a banknak
Erre a balhéra 10 perc van.
Ha az 1. lépésben történt küldés után 10 percig a bank nem kapja meg a 3. lépésben küldendő adatokat akkor a bank automatikusan reverzálja (visszafordítja, törli) a tranzakciót és erről az árhuháznak kötelessége a vásárlót értesíteni emailben.
Ez még menne is, ha a banki szerver meghívná az áruház egyik fájlját azután a bizonyos 10 perc után.

De itt a bökkenő hogy nem "hív" az semmit...

Szóval hogy lehet 10 perc múlva mailt küldeni ha nincs "meghívva" semmi?

CRON? Mi van ha nem tudok Cront beállítani a szerveren PHP-ből?
Akkor percenként futtassak egy PHP-t és ha akció van akkor végrehajtsa? Ez nem fogja meg a szervert túlságosan?
A rendszergazdi általi fenyítést szeretném elkerülni.

Előre is köszönöm
 
1

A bank a 3. lépésben meghív

gojruht · 2010. Május. 9. (V), 01.19
A bank a 3. lépésben meghív nálad egy scriptet, ha ez elmarad, akkor kell levelet küldeni. A meghívott script rögzíti ezt, mivel gondolom db-ben mindenképpen tárolni kell a banki visszajelzéseket. Időzített feladatra mindenképpen szükséged van (legalább 10 percenkénti futásra), ami meghív egy ellenőrző scriptet, ami ellenőrzi az 1-es lépésben indított tranzakciókat (ezeket is rögzítjük ugye DB-ben) és hogy van-e zárása (bejegyzés a 3. lépésből). Ha nincs, akkor a megfelelő címre dobja a formalevelet.

Célszerű megírni az ellenőrző scriptet előre és a tárhelyed üzemeltetőjének megadni, hogy állítsa be cronba ha linuxos server, időzített feladatokba win szerveren. A rendszergazda így nem fenyít be, de ha mégis és nem állít neked cront, akkor keress másik szolgáltatót, nem kevés van. ;)
2

Van cron...

vtsoftware · 2010. Május. 9. (V), 02.33
Először is köszönöm a válaszod.
Cron-t tudok én is beállítani - Siteworx - csak PHP-ből nem tudom lehet-e.
De az alapján amit írtál, mindenképp elolvasom mégegyszer az kézikönyvet bár úgy láttam hogy én hívom meg a 3. lépésben a banki szervert, ami arra válaszol vissza... vagy te arra gondolsz mikor a fizető oldalról az áruház oldalra irányít?
Bár igaz, akkor már futtat... hmm.

De értem a megoldásod, akkor marad a Cron-os ellenőrizgetés.
Akkor hogy minél kevésbbé legyen terhelő, akkor csak egy dolgot ellenőriz pl. egy timestamp-ot adok mindhez és amelyik 10 percnél "fiatalabb" akkor annál eksün'...

Akkor az elmélet alakulgat, de az a baj hogy a titkosítással is gondom van... abban esetleg tudnál, tud-e valaki segíteni?
A szerver 403-at ad vissza már első lépésnél, mikor én küldök változókat a szervernek.
Vagy szerződés nélkül nem lehet "próbálgatni"?
3

Valószínű, hogy szerződés

Ifju · 2010. Május. 10. (H), 09.38
Valószínű, hogy szerződés nélkül nem kapsz hozzáférést a bank rendszereihez ilyen szinten.

A titkosítást többnyire kommunikációs layer szinten valósítják meg (https), bár a SOAP lehetőséget ad a tartalom titkosítására is, de szerintem bármely webservice protokollal megoldható az adatok további titkosítása, ha igény van rá.
4

(Csak zárójelben)

Ustak · 2010. Május. 10. (H), 22.41
jegyzem meg (egy oldalt újítottam fel, ahol OTP-s bankkártyás fizetés működött) hogy az adott oldal szokott adni egy "tényleg ezt akarod?" típusú utolsó oldalt a tényleges átírányítás előtt, ahol felsorolják amit vásárolsz, az összeget, és esetleg pár hasznos tudnivalót, és persze <input type="hidden"> ben az adott tranzakció adatait. No most ezt firebuggal tökéletesen meg lehet hackelni, íly módon én az eredeti weboldalon (telefonkártyás feltöltés) 1000 ft-ért akármennyit tölthettem magamnak, ugyanis az OTP semmit sem küldött vissza a ténylegesen elfogadott összegről. (És én nem vagyok Security szakember, sem gonosz Hacker/Cracker, csak egy js programozó :-))
Ezt sessionnal vagy adatbázissal még az adott bankhoz való átirányítás előtt érdemes vizsgálni (ha a Te bankod sem ad vissza semmi ilyesfajta adatot), tehát hogy az utolsó submit gomb megnyomása előtt történt e valami csalárdság a kliensen :-)
Ha nem ilyen akkor éljen, csak gondoltam szólok :-)
Üdv:
Gábor
5

hidden

Poetro · 2010. Május. 11. (K), 02.02
A weboldal van hibásan megcsinálva szerintem, mivel nem hiszem, hogy ennek hidden mezőben kellene lennie, hanem a szervernek kellene továbbítania egy megfelelő oldalra, és a tranzakció adatait pedig továbbra is session-ben kellene tárolni. Különben emlékeim szerint a tranzakció azonosítója valami metódus alapján jön létre az összeg és más paraméterek alapján, amit eléggé egyszerű ellenőrízni, hogy stimmelt-e mindkét oldalon. Ha valaki ezt elmulasztja, az az ő hibája. Legalább is ilyen emlékeim vannak CIB-es fizetés esetéről.
6

Őőő, nem úgy tudom...

vtsoftware · 2010. Május. 11. (K), 04.37
Ustak:
Azt hiszem a CIB-es rendszernél az egyik utolsó lekérdezésnél a válaszban megkapjuk az értéket, amit összehasonlítunk a elsőnek elküldöttel, ha nem egyezik akkor sztornó.
Az OTP-st nem tudom van-e benne...

Poetro:
A tranzakció azonosítót (TRID) te generálod és küldöd el az első lekérésben a szervernek, ez végigmegy az összes lépésen, evvel tudod azonosítani a tranzakciót a végén.
7

Payment Gateway

tiku I tikaszvince · 2010. Május. 11. (K), 06.40
Pár hónapja futottunk bele a paymentgateway.hu szolgáltatásába. Lényegében egy kaput biztosít, amin keresztül ugyanúgy tudsz kapcsolódni szinte bármelyik banki vagy mikropayment szolgáltatás rendszerhez. Megspórolva a fejlesztési és karbantartási időt.

nincs semmi közöm a paymentgatway.hu-hoz sem a mögötte álló BigFishez