OTP-s fizetési kapcsolat

Fejlesztés

Sziasztok!

Próbálom feléleszteni az OTP-s fizetési kapcsolatot SOAP-on keresztül PHP-vel, de nem akarja az igazságot, egyelőre a teszt-shoppal megyek.

Ha ez a kód: 


    $ws = new SoapClient('https://www.otpbankdirekt.hu/mwaccesspublic/mwaccess', array(
      'exceptions' => TRUE,
      'local_cert' => '#02299991.privKey.pem',
      'encoding'=>'ISO-8859-2',
    ));

Akkor ez a hibaüzenet (a kulcs teljes elérési úttal, helyesen van megadva):

Warning: SoapClient::SoapClient() [soapclient.soapclient]: Unable to set local cert chain file `#02299991.privKey.pem'; Check that your cafile/capath settings include details of your certificate and its issuer
Warning: SoapClient::SoapClient() [soapclient.soapclient]: failed to create an SSL handle
Warning: SoapClient::SoapClient() [soapclient.soapclient]: Failed to enable crypto
Warning: SoapClient::SoapClient(https://www.otpbankdirekt.hu/mwaccesspublic/mwaccess) [soapclient.soapclient]: failed to open stream: operation failed
Warning: SoapClient::SoapClient() [soapclient.soapclient]: I/O warning : failed to load external entity "https://www.otpbankdirekt.hu/mwaccesspublic/mwaccess"

Ha kihagyom a „local_cert” kulcsot a fenti kódrészletből, akkor a hibaüzenet:

Warning: SoapClient::SoapClient(https://www.otpbankdirekt.hu/mwaccesspublic/mwaccess) [soapclient.soapclient]: failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden
Warning: SoapClient::SoapClient() [soapclient.soapclient]: I/O warning : failed to load external entity "https://www.otpbankdirekt.hu/mwaccesspublic/mwaccess"

Mondjuk az is fura, hogy több gépen többféle rendszerrel beüzemeltem a OTP-től letölthetp SimpleShopot, de a webdemo a fizetésnél tesztkártyákkal „A megadott kártyaadatok alapján a terhelés nem hajtható végre.” hibaüzenetet kapok (POS kód: 064, hibakód: BASE24_87), és még egy tesztvásárlást sem sikerült végrehajtanom, miközben a ping megy és a tranzakciólistából látom, hogy másnak működik az elérés. A fenti hibakódokról viszont mélyen hallgat minden dokumentáció.

Van valami ötletetek, hogy mi lehet a gond?

  • 27381 megtekintés

( denton | 2013. 06. 20., cs – 00:29 )

próbáld inkább beüzemelni azt a gány szart amit ők adnak hozzá és azt ültessed át a saját rendszeredbe.

Az egész otp sdk olyan mint amit a kutya seggéből rángattak volna ki. kár próbálkoznod szép kódot alkotni belőle.

kb. 4 évvel ezelőtt jött szembe ez a téma, akkor C++ ban írtam meg gSOAP alapokon, működött, pár helyen kellett csak belenyúlni a gSOAP kódjába az XML névterek kezelésénél. Ideértve a kártyaregisztrációt és a már regisztrált kártyával a kétszereplős tranzakciót is.

Az a baj, hogy az sem működik, az dobja a témaindító hozzászólás végén jelzett hibát. Jobban örülnék, ha azt tudnám beüzemelni a rendelkezésre álló idő rövidsége miatt, viszont később majd szeretnék egy saját, teljesen SOAP alapú implementációt.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

( vl v | 2013. 06. 20., cs – 01:19 )

Ötlet nincs, de van nálam POS kommunikációs doksi, úgyhogy azt el tudom árulni, hogy a POS kód 064 azt jelenti, hogy "Bad track information", ami vélhetően a kártyáról beküldött "mágneskód" tartalmára vonatkozik. Azaz ha tippelnem kéne, azt mondanám, hogy a tesztkártya adattartalma invalid.

Az a baj, hogy az elmúlt napokban kb. 50-szer próbáltam teljes véletlen időpontokban, akár hajnali kettőkor is, de sohasem működött. Próbáltam Windowson és Linuxon, eltérő gépeken, de semelyik fizetési módban sem jártam sikerrel.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

( treddy | 2013. 06. 20., cs – 09:45 )

A privát kulcsot nem nem kell a soap hívásba beletenni. Az csak az átküldendő adat kódolására szolgál, nem az authentikációra.
Soap példányosításnál a WSDL útvonala helyesen: https://www.otpbankdirekt.hu/mwaccesspublic/mwaccess?WSDL

Amire figyelni kell, hogy a webservice-t csak szinkron módban engedik használni, emiatt saját megvalósításnál (nem az általuk adott simpleshop) trükközni kell. A simpleshop apache+php esetén csak akkor működik ha a php modulként fut.
A tesztkártyák adatait az utóbbi időben folyamatosan változtatják.

Az Apache+PHP gondba én is belefutottam, amikor a CGI módban futtatott PHP tudott pingelni és tranzakció-listát lekérdezni, de fizetésnél mindig timeout-ba futott.
Mi lehet ennek az oka és ki lehet játszani valahogy?

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

Az alapveto problema az, hogy Neked FOLYAMATOS kapcsolatot kell fenntartanod az OTP szerverrel, a SOAP valasz akkor jon meg, ha az ugyfel fizetett. Innentol kezdve az egesznek hatterben kell futnia, erre jo a fastcgi_finish_request(). Ha nem igy csinalod, akkor folyamatos szivas lesz.

Szerintem az a koncepciója Jánosnak, hogy a PHP kérésen belülről elindítod a SOAP kérést, majd nem várod meg a választ, hanem visszaszólsz a browsernek, hogy "kész". Ezután a PHP fut tovább a szerver oldalon, megvárja a SOAP választ, majd berakja valami adatbázisba. A browserben futó valami meg időnként új kérések formájában megpróbálja megtudni az eredményt, amit nyilván az adatbázisból kéne kiolvasnia a másik PHP kérésnek.

Azt ertem, csak engem nem PHP-specifikus megoldas erdkeelt volna. Nekem a Rails app folyamatosan fut a hatterben, tehat ha leforkolok egy szalat vagy valami hattertaszkot, ami pendingel, es tovabblepek, az akar mukodhet is, csak ezert akartam tudni, hogy a SOAP hogy mukodik ezen a szinten.

Raadasul asszem Rubynal van valami default timeout is a kereseken...
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

„Az alapveto problema az, hogy Neked FOLYAMATOS kapcsolatot kell fenntartanod az OTP szerverrel, a SOAP valasz akkor jon meg, ha az ugyfel fizetett. Innentol kezdve az egesznek hatterben kell futnia”

És ez nem oldható meg CGI módban futtatott PHP-vel?

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

Köszönöm, hogy szóltál, valóban érvénytelen az a tesztkártya, amit a dokumentációban írnak. Nem értem, hogy mire jó ez a variálás illetve miért nem lehet ezeket nyilvánosan közzétenni.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

( zolej v | 2013. 06. 20., cs – 11:33 )

Egyáltalán nem vagyok nagy php guru, de nekem ez volt az OTPvel az első esetem. Én ki tudtam venni mindent a doksiból, ha nem értettem valamit, tanultam.
PHP alapon csináltam, teszt cert (szintén...991) illetve tesztkártyával működik. Belefutottam én is a modul/cgi problémába, de már megy szépen. Jelenleg a hivatalos kulcs érkezésére várunk.

( BandiG v | 2013. 06. 20., cs – 12:01 )

OFF: az meg mindig ugy van, hogy az OTP eltarolja a kartyaadatokat es kesobb a kereskedovel egyuttmukodve penzt emelhet le?

Attol tartok, nem egeszen erted a banki rendszer mukodeset. Kb _barmilyen_ kartyaszolgaltatonal meg tudod csinalni, hogy az elso tranzakciora hivatkozva tovabbi penzt huzol le a kartyarol a kartyaadatok ismerete nelkul. A CVV-t es tarsait eleve nem tarolhatja el semmilyen PCI-DSS compliant szolgaltato.

Amit en tudok a dologrol, ennel pontosabbat egy fizetesi szolgaltato tudna mondani (be kellene tamadni a kerdessel az Escaliont pl.):

A dolog valahogy ugy mukodik, hogy van a PSP, aki az acquirer bankkal all kapcsolatban. (Ez esetben mindketto az OTP) Az acquirer bank pedig az issuer banktol (kibocsajto) huzza le a penzt, a Mastercard/Visa pedig az elszamolast vegzi. Namost az, hogy Te huzhatsz-e le pl. CVV nelkul penzt vagy sem, stb. attol fugg, hogy az issuer bank mit enged meg. Siman lehetzhet (technikailag) olyan issuer bank, amely pl. csak kartyaszammal enged terhelni vagy lejart kartyat enged terhelni, stb. A PSP-t hasznalo szolgaltatonak altalaban van egy merchant ID-je (MID) es ezzel mennek a terhelesek.

Konkret pelda egy PSP API-val: a merchant kuld egy PreAuth kerest a PSP-hez ("belockoja a penzt") kartyaadatokkal, CVV-vel, mindennel. Visszakap egy tranzakcio azonositot. Ket hettel kesobb kuld egy capture-t ("lehuzza a penzt") es abban mar csak a preauth tranzakcio azonositojat es az osszeget kuldi, itt mar nincs szuksege a kartya adatokra. (Ez persze nem egy OTP-szintu API, hanem egy rendes merchant API, ahol a sajat oldaladon kered be a kartya adatokat.)

Visszaelesek eseten Card Not Present tranzakcioknal letezik egy un. chargeback mechanizmus, ahol Te mint card holder bemesz az issuer bankodhoz es megmondod, hogy az a tranzakcio fraud volt, kered vissza a penzt. Hacsak nincs a merchantnal valami alairt papir, hogy Te marpedig tenyleg megrendelted a szolgaltatast, szo nelkul jon vissza a penz. Europaban ehhez szoktak kerni egy rendorsegi jegyzokonyvet vagy hasonlot, amerikaban viszont ez egeszen hetkoznapi dolog.

Osszefoglalva: ha az atlag ember tudna, hogy mennyire nem biztonsagos a kartyas fizetes es az osszes resztvevo (bankok, kartyatarsasagok) mennyire csak arra mennek ra, hogy a sajat segguket vedjek, visszaterne mindenki a keszpenzes fizetesre.

( nevergone v | 2013. 08. 12., h – 16:18 )

Időközben be kell üzemelve az OTP-s cucc PHP 5.3 alá (mod_php), már el is felejtettem az egészet, viszont most szóltak, hogy valami nem oké: Internet Explorer alatt nem lehet vásárolni, mert nem irányít át a böngésző a bank oldalára (háromszereplős téma), FF és Chrome alatt tökéletes.
Elkezdtem megkeresni a hibát és azt találtam, hogy az OTP-s cuccon belüli SOAP hívással van a gond. Ha azt kiszedem, akkor minden böngésző alatt átdob, viszont akkor nyilván nem működik, mert a háttér-kommunikáció nem megy végbe.
Találkoztatok már ilyen hibával? Elég wtf fejem lett tőle, nem számítottam rá.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

Mibe fogadjunk, hogy az oldalatok SSL-el megy es a mintapeldaban hasznalatos atiranyitasi modot hasznaljatok? 

header('Location: valami');
header('Content-Length: 0');
header('Connection: close');

Ilyenkor ugyanis az van, hogy az Internet Explorer megvarja az SSL close uzenetet is, amit a webszerver meg nem fog elkuldeni addig, amig a PHP program fut.

Ha ez az eset all fent, akkor az EGYETLEN megoldas az, hogy a SOAP hivast a hatterben bonyolitjatok le (pl. fastcgi_finish_request-el) es a frontend hivast hagyjatok veget erni.

Update: szivathatjatok magatokat a pollozassal is, de azt nem ajanlom.

A dolog még ennél is rejtélyesebb.
Egyelőre nincs SSL, valami más gond lesz itt. Miután kiderült, hogy IE alatt nem működik az átirányítás, megnéztem az OTP-s teszt csodaprogramot (otpwebshop/web_demo/fiz3_form.php?func=fiz3) a fejlesztői gépemen (Linux, Apache, mod_php) és ott is ugyanez a hiba: FF és Chrome alatt működik, IE alatt pedig nem irányít át. Többen megpróbálták különféle IE verziókkal, nem használt.
És itt jött egy ötlet: Nem lehet, hogy az OTP ennyire hibás valamit adjon ki. Honnan is van nekem ez az OTP-s teszt csodaprogram? Onnan, hogy feltelepítettem Windowsra a letölthető cuccukat. Előzőleg nem volt a Windows-os gépen sem Apache, sem PHP. Megpróbáltam a demó programot az OTP-s Apache és PHP környezetben, működik, IE alatt is átirányít.
Az Windows alatt is mod_php van, PHP 5.2.0
Fogtam onnan a php.ini-t, lecseréltem vele a Linuxosat, Apache restart, az átirányítás nem működik.

Valami ötlet?

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

Próbálkoztam mindenféle konfigot összehasonlítani, de érdemben nem jutottam közelebb. Mivel egyre jobban bosszantott a dolog, az idő pedig sürgetett, felhívtam az OTP-s kontaktot, hátha tud mondani valami értelmeset.

A megoldás… a megoldás… a megoldás: a2dismod deflate

Bye, bye mod_deflate Apache modul… és működik.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

Ki lehet kapcsolni azt, csak máshogy:

„I've successfully disabled DEFLATE for the virtual site using SetEnv no-gzip 1:”

http://serverfault.com/questions/276131/apache-disable-deflate-module-o…

Használt keresőkifejezés: „apache deflate virtualhost disable”

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)