Saturday, August 23, 2008

Dotpay - zawód

Jakiś czas temu miałem "przyjemność" zaimplementować obsługę dotpay w jednym z portali. Portal na pierwszy rzut oka, szata, oprawa, wygląda solidnie. Kiedy pisze się do obsługi odpowiedzi są bardzo konkretne jednak - tutaj plusy się kończą. Po zajrzeniu do dokumentacji na pierwszy rzut oka można mieć wrażenie, że "wszystko jest" jednak już pierwsza próba zaimplementowania czegokolwiek okazuje się, że wymaga niemal wróżbiarskich zdolności.

Domyślenie się, że pewne parametry nie są przesyłane (ale trzeba je u siebie hardcodować), do czego służy dana opcja, czy w końcu co dokłądnie wykonuje "testowanie". Kompletny brak profesjonalizmu i żenada. Jako programista spędziłem sporo czasu próbując dojść do tego - dlaczego hashe md5 nie są ze sobą zgodne - oczywiście, brak w dokumentacji. Takie rzeczy tak porządnej firmie. Na szczęście wpadłem na to co nie grało. Czy jest to jednak słuszne postępowanie w przypadku tak porządnej firmy. Dokumetnacja 2 na szynach.

6 comments:

Anonymous said...

Witam,
przyznam szczerze że jak ja implementowałem system płatności dotpay, a miało to miejsce na końcu czerwca tego roku. Żadnych problemów nie uświadczyłem, a dokumentacja przygotowana w pdf'ie jest wystarczająca (opisane są wszystkie parametry - ok 10 stron), także nie wiem w czym problem :) Nadmienie że całość zajęła mi 1 dzień, łącznie z testami.

Pozdrawiam

Johny JKJK said...

Mój problem polegał na tym, że nie zgadzał mi się skrót md5. Ten przysyłany mi przez system i ten generowany w po mojej stronie na podstawie przesłanych danych były różne. Nie wiedziałem dlaczego. Otóż nie było jasno napisane iż wartość pola PIN nie jest przysyłana, ale trzeba ją hardcodować. Innym razem zapomniałem hasła (okolice czerwca). Formularza do odzyskiwania nie widu ni słychu. Napisałem do dotpay prośbę o odzyskanie hasła. Jednak - odpowiedź brzmiała "proszę skorzystać z formularza". Formularza, którego wtedy nie było. Kolejna sprawa to brak wyjaśnienia możliwości testowania kanału SMS. Nigdzie tego nie znalazłem.

Anonymous said...

Witam ponownie,
co do parametru md5 przesyłanego metodą POST z dotpay'a, to powiem tak. Jaki miałby sens stosowania tego rozwiązania jako zabezpieczenie, jeżeli PIN zostałby przesyłany jawnie razem z kompletem innych danych ? Po to ten pin jest, zapisuję go w profilu dotpay, koduje na stałę w pliku generującym hash w swoim serwisie i porównuję go z tym od dotpay. Jak hashe są te same to wtedy wiadomo że wszystko jest ok :]

Co do liku formularza z odzyskiwaniem hasła to znajduje się zaraz pod formularzem logowania.

Natomiast co do usług SMS premium się nie wypowiadam, ponieważ z nich nie korzystam.

Pozdrawiam

Johny JKJK said...

Dzięki za odpowiedź. Nie jestem taki bystry :) jak widać. Dla mnie to był brak. Linku kiedyś nie było, a o testowaniu SMS nie znalazłem jeszcze wzmianki w dokumentacji. Pozdrawiam !

Krzysiek T. said...

Świetnie, świetnie. Właśnie zaimplementowałem obsługę płatności w Dotpay na mojej stronie. Niby wszystko chodzi dobrze, ale czasem zdarza się błąd weryfikacji MD5.

Powiem więcej - ten błąd zdarza się zawsze, jeśli w polu e-mail formularza na stronie Dotpay wpisze się polskie znaki diakrytyczne (ą, ę, etc.)

Okazuje się, że komunikat POST z potwierdzeniem płatności nie specyfikuje kodowania znaków (przynajmniej klasa Servlet w Java zgłasza to kodowanie jako null).

Do tej pory przyjmowałem, że jest to kodowanie w UTF-8. Ale czy na pewno?

jacekkobus said...

odpowiedz z dotpay jest w iso 8859-2. zwrotka jest url_encoded, po dekodowaniu przez parser php, jesli uzywamy utf8, otrzymujemy szlaczki.

trzeba zrobic konwersje iconv.