Turbūt daugelis elektroninių parduotuvių šiuo metu turi integruotus elektroninius mokėjimus. Pabandysiu pateikti nuoseklią seką būtiną realizuojant mokėjimus . Visų pirma pateikiu seką būtiną sertifikatų generavimui.

Norint pradėti realizaciją mums būtina susigeneruoti sertifikatą ir privatų raktą.
Taigi pradedam:

openssl req -new -out cert_request.pem -keyout private_key.pem

Generacijos metu reikės įvesti informaciją, kaip elektroninio pašto adresas kompanijos pavadinimas ir t.t. Iš esmės vienintelė bankui rūpima informacija - tai elektroninio pašto adresas. Po šios operacijos bus sugeneruoti du failai:

  • cert_request.pem
  • private_key.pem

Pirmasis failas tai mūsų viešas raktas, kurio informaciją galime peržiūrėti komanda:

openssl req -text -noout -in cert_request.pem

Antrasis bus naudojamas susigeneruoti parduotuvės sertifikatą. Tačiau dabartinis privatus raktas yra apsaugotas slaptažodžiu, o mums reikia privataus rakto neapsaugoto slaptažodžiu. Taigi susigeneruojam privatų raktą neapsaugotą slaptažodžiu, kuris bus naudojamas taip ogo parduotuvės siunčiamiems duomenimis pasirašyti.

openssl rsa -in private_key.pem -out new_private_key.pem

Šio proceso metu reikės įvesti anksčiau įvestą slaptažodį, kuris buvo panaudotas generuojant privatų raktą pirmąja komanda. Taigi kai turime privatų raktą neapsaugotą slaptažodžiu galime sugeneruoti parduotuvės sertifikatą:

openssl req -new -x509 -days 720 -key new_private_key.pem -out rsa_new.crt

Bus sugeneruotas naujas failas rsa_new.crt tai ir bus mūsų sertifikatas. Kuris sutarties pasirašymo metu yra siunčiamas bankui. Bankas visus siunčiamus mūsų pranešimas patikrina remiantis šiuo sertifikatu.
Kai turim parduotuvės sertifikatą galime judėti toliau. Standartiškai testuojant bankas duoda kažkokį savo sertifikatą. Šiuo atveju kadangi jo neturim susigeneruojam jį tokia pat tvarka kaip ir generavom parduotuvės sertifikatą.

openssl req -new -out cert_request.pem -keyout private_key.pem
openssl rsa -in private_key.pem -out new_private_key.pem
openssl req -new -x509 -days 720 -key new_private_key.pem -out rsa_new.crt

Kad būtų aiškiau pasidariau tokią katalogų struktūrą:

Kai turime sertifikatus atitinkamuose kataloguose crtshop - parduotuvės sertifikatas, crt - tariamo banko sertifikatas. Galime pradėti realizaciją. Realizacija iš esmės nėra sudėtinga. Visas veiksmas vyksta daugmaž tokia tvarka:

  • parduotuvė siunčia pranešimą pasirašytu savo slaptuoju raktu. Pranešimą standartiškai sudaro VK_MAC reikšmė. Ši reikšmė sudaroma iš pirkinio informacijos ir užkoduojama parduotuvės slaptuoju raktu;
  • bankas gavęs pranešimą patikrina pranešimo autentiškumą su parduotuvės sertifikatu ir sulygina gautą reikšmę su VK_MAC reikšme;
  • vyksta veiksmai banko sistemoje;
  • bankas grąžina atsakymą pasirašytą savo privačiu raktu. Parduotuvė patikrina pranešimo autentiškumą naudodamasi banko sertifikatu.
  • Taigi visas mechanizmas gan paprastas.
    Kadangi pagrindinė problema susijusi su testavimu, kuris įmanomas tik kai bankas įjungia sąsaja. Sukūriau šiokį tokį frameworką testavimui. Iš esmės jo veikimas identiškas bankų veikimui.
    index. failas sugeneruoja parduotuvės užklausą bankui.
    server. patikrina ar atėję parametrai buvo pasirašyti parduotuvės
    verify. ar atsakymas atėjo iš serverio.

    Iš esmės dabar turėtų eiti kodo dalis, bet jo pastinimas manyčiau būtų netikslingas - tai pateikiu realizuotą sistemą, kurią galite parsisiųsti iš čia

    Realizacija nėra sudėtinga, kai žinai ką reikia daryti. Pateiktame pavyzdyje realizacija pritaikyta bankui, bet bankui viskas vyksta taip pat. Kodas gal ir nėra idealiai švarus, tačiau man ir tokio būtų užtekę, kai ieškojau informacijos apie realizaciją. Trumpai tariant gal pravers kam nors. :)

    Panašūs straipsniai


    “Banklink - realizuojam SEB ir Hanza bankams” komentarų: 17

    1. Žilvinas Sadauskas

      Ko gero pats naudingiausias pixelio straipsnis :)

    2. sergej

      Geras. Seniai norėjau parašyti ką nors apie ką nors su kuo tiesiogiai dirbų. Įdomu ar man leis tai padaryti. Paklausiu šiandien :)

    3. Paulius

      Sampo, Snoras ir kiti Lietuvos bankai naudoja IBPAY sistemą, kurios naudojimas yra praktiškai analogiškas Hanzai ir SEB’ui.
      Specifikaciją galima pasiimti pvz iš Sampo banko: http://www.sampo.lt/files/SAMPO_CLICKprogramuotojamsV12.LT.pdf

      Reiktų atkreipti dėmesį į tai, jog yra skirtingi pranešimų kodai, siunčiami iš banko, kurių vienas grąžina į parduotuvę patį vartotoją (pirkėją). Kadangi dažniausiai vartotojas bus nukreipiamas į tą patį skriptą, kuris apdoroja mokėjimus, mes galbūt norėsime vartotoją persiųsti į tam tikrą kitą puslapį. Tam naudoti Location header’io negalima, kadangi bankui būtinas HTTP 200 atsakymas. Sprendimas būtų vartotoją nukreipti JS’o pagalba.

      Be to, dauguma bankų siunčia pranešimus windows-1257 koduote (žinoma, to paties tikisi ir ši e-parduotuvės), todėl jei naudojate UTF’ą, pasikonvertuokit siunčiamus duomenis :)

    4. elt.lt » Blog Archive » Apžvalga. Šiandien aš skaičiau… #78

      […] internetu. Jei jums įdomu, kaip veikia atsiskaitymas su banku e-parduotuvėje, čia rasite programinį bankinių atsiskaitymų internetu scenarijų ir realizacijos aprašymą. Susigaudyti toje „agra-kadabra” gali tik „išgėrę” arba… […]

    5. Giedrius

      Pirmasis pixel.lt straipsnis vertas dėmesio.

    6. Patrio

      To Giedrius, keistas tu kazkoks zmogus bent skaitei visus straipsnius? Kad tavo sritis siaura ir tu siauru paziuriu nereiskia kad pixelyje nera vertu demesio straipsniu.

    7. Edmundas

      Šiaip toje klasėje pamačiau, kad yra VK_CURRENCY. Ar neturėtų būti VK_CURR? Pataisykit, jei klystu. :)

    8. Žilvinas

      Taip, VK_CURR ( hansa, seb, sampo, snoras, parx,dnb nord, siauliu), tiesiog CUR (nordea).
      Beje nordea tokie labai norintys issiskirti ar kazkokia visai kitokia sistema turi ir jiem duomenis reikia perduoti ne windows-1257, o ISO-8859-1 :)

    9. Andrius

      Kadangi Sampo pasikeite i Danske, tai ir auksciau buvusi ( http://www.sampo.lt/files/SAMPO_CLICKprogramuotojamsV12.LT.pdf ) nuoroda nebeveikia. Nauja nuoroda - http://www.danskebankas.lt/verslo/elprekyba ir is cia galima parsisiusti trim kalbom

    10. Donatas

      Hey, kadangi senas ganėtinai čia postas tai ir neber projekto parsisiuntimo, gal turit kas išsisaugojęs ar patalpinęs kur nors šį projektą? Bučiau labai dėkingas. Taip pat padėtų ir kiti pavyzdžiai būtent siunčiant užklausas bankui. (raktus sugeneruot pavyko).

    11. Vaidas

      sveiki, gal galite pasidalinti ta “bank link” sistema? nes linkas (http://pixel.lt/wp-content/uploads/2008/04/banklinktgz.gz) neveikia

    12. Martynas

      Mane taip pat domintu tas banklinko pvz parsisiuntimas.

    13. Meff

      Pritariu Donatui ir Vaidui. Man irgi labai praverstų realizacija :-)

    14. Meff

      … perskaičiau, kad HDD nulinko… Matyt dėl to ir neveikia kodo linkas.

    15. remdex

      Veikiantis linkas :). Sitoj realizacijoj reikia pakeisti pagal “7. Edmundas” komentarą tą vieną vietą :)

      http://remdex.info/banklink.tgz

    16. Liutukas

      Šiame protokole aprašytas tik GET metodas. Nors visi bankai reikalauja POST motodo ir tik nedaugelis patarnauja GET metodą.
      Ir dar pastebėjau, kad perduodant GET metodu pasigadina duomenys. Nes bankai neteisingai apdoroja gautus duomenis pagal url_encode. Ta pastebėjau, kai bankas savo sistemoje pasidarė URL peradresavimą.
      GET metodu nevaldomai sistemos branduolys padaro url_decode, o POST metodu jau viskas veikia manual rėžimu. Tad vis labiau bankai reikalauja GET rėžimo atsisakyti ir visiems pereiti prie POST.

    17. remdex

      Paprastas projektukas, kuris padės visiems, kam reikia atlikti testavimus su bank linkais. Projektas buvo sukurtas, nes bankai iki šiol neturi normalaus testavimo režimo. O čia projektas atstoją banką, taigi galite išsitestuoti savo realizaciją neatlikinėdami pavedimų. Šiuo metu padariau tris Swedbank, Šiaulių Banką, SEB.
      http://test-pay.com/lit

    Rašyti komentarą

    Jūs privalote prisijungti jeigu norite rašyti komentarą.