Temat: Implementacja płatności
[od teraz używając sformułowania "Płatności" będę miał na myśli wszystkich pośredników realizowania płatności internetowych, którzy działają w znany nam sposób, tj. pośredniczą... nie będę miał tu na myśli konkretnie firmy Płatności.pl]
Robert B.:
Na pewno nie mają dostępu do mojego rachunku. Mogą znać jedynie jego numer.
W rzeczy samej. Płatności nie mają dostępu do Twojego rachunku. Dane, które posiadają, to: Numer Twojego rachunku, branża i segment w jakim działasz ( lub w jakich działasz ), obroty jakie generuje każda z Twoich stron, która implementuje Płatności, numery rachunków od Twoich klientów, a w danych przelewów przychodzących imienne i adresowe dane Twoich klientów ( w większości przypadków wypełniane automatycznie, gdy klient zleca przelew poprzez system transakcyjny banku, lub korzysta z usługi szybkiego transferu typu mTransfer ). Płatności nie muszą gromadzić większości tych danych, bo robi to za nich bank. Oni, jako właściciele rachunków, mają jednak dostęp do tych danych, podobnie jak Ty masz dostęp do danych Twojego rachunku w Twoim banku. To wszystko stanowi zestaw bardzo istotnych informacji.
Załóżmy, że znalazłeś intratną lukę w rynku. Zapełnienie tej niszy i uruchomienie internetowego biznesu gwarantuje Ci fantastyczne przychody i dostatnie życie. Pieniądze lubią ciszę, dlatego im mniej potencjalnych konkurentów wie czym się zajmujesz i jakie masz obroty, tym mniejsze zainteresowanie tym, co robisz i mniejsza szansa, że pojawi się konkurencja, która zmniejszy Twój udział w rynku i sprawi, że czar pryśnie. Skąd ktoś obcy miałby wiedzieć, na czym polega Twój interes i czy warto wogóle zwrócić wzrok w kierunku Twojej branży? No cóż, jeśli taki ktoś ( poszukujący okazji inwestycyjnych ) jest właścicielem/udziałowcem Płatności, to nie ma najmniejszego problemu, aby wyselekcjonować klientów Płatności, wybierając tych, którzy zanotowali określony obrót. To, czym się zajmuje klient, można określić na podstawie treści strony WWW klienta, która to strona korzysta z Płatności. Wykonanie tych czynności jest proste. Dodatkowo klient Płatności nie ma wpływu na to, czy Płatności takie analizy przeprowadzają oraz nie może uniemożliwić im tego.
Dane Twoich klientów, dostępne w historii operacji rachunku Płatności, na który klienci wpłacają pieniądze, mogą posłużyć do regionalnej identyfikacji popytu, lub generalnie do badania rozkładu popytu.
Opisany proces gromadzenia i przetwarzania informacji po pierwsze jest możliwy i dostępny na wyciągnięcie ręki, a po drugie sposorujesz go płacąc prowizję. Finalnie zaś, jeśli jesteś rynkowym zjawiskiem, pokazujesz na 'czym' i 'czy', oraz 'jak dobrze' można zarobić.
Podejmijmy też dodatkową kwestię: jeśli klienci dowiedzą się, że ich dane personalne przechodzą przez pośrednika, który nie ma z Twoim sklepem wiele wspólnego, to czy będą zadowoleni? Klient jest w stanie zaakceptować, że jego dane gromadzisz Ty, bo z Tobą robi interes i do niego wysyłasz Towar, nie ma tu więc żadnej tajemnicy. Niemniej klient może być poirytowany i z pewnością będzie, gdy dowie się, że jego imię, nazwisko, adres i numer rachunku są do dyspozycj pośrednika, z którym on się na nic nie umawiał. Klienci w ogólności nie wiedzą, że dokonując zapłaty poprzez Płatności, ujawniają te dane.
Robert B.:
Czy teraz wyjaśnisz po co Waszemu API dostęp do mojego konta (login, hasło) i co ono potrafi zrobić więcej niż ponad to co mogę zrobić sam po "zalogowaniu się do banku"?
Płatności to platforma zdalna. Wszystko dzieje się po stronie serwera Płatności i banków, które w tym uczestniczą. Dlatego nie mogą ( nie powinni i nie robią tego ) wymagać danych uwierzytalniających Twojego rachunku. Nie potrzebują tego, ponieważ pieniądze od Twoich klientów trafiają na ICH konta. Dopiero później, kiedy zlecisz usługę rozliczenia, przelewane są na Twój rachunek. Potrzebują więc jedynie numer Twojego rachunku. Kiedy łączysz się z płatnościami, czy to przez panel www, czy też przez dedykowane API, łączysz się zdalnie ze swoim profilem klienckim w Płatnościach.
XConnector nie jest platformą płatności. Jest częścią tego, co działa w sercu systemu płatności. Powiem o tym później.
Załóżmy, że tworzsz aplikację desktopową, której zadaniem jest zaksięgowanie wpłat klientów. Potrzebujesz zatem sposobu, aby dostać się do danych transakcji, jakie zostały odnotowane na Twoim rachunku. Na wstępie należy odrzucić pomysł, wedle którego ręcznie przepisujesz dane transakcji ze strony internetowej banku do swojej aplikacji. Jeśli będziesz miał duży ruch na rachunku, to zadanie zajmie Ci zbyt dużo czasu. Potrzebujesz zatem rozwiązania, dzięki któremu Twoja aplikacja połączy się z Twoim rachunkiem bankowym, pobierze dane transakcji, a następnie zaksięguje je ( odnotuje w systemie, że wpłata nadeszła itp. ). To wszystko musi się dziać automatycznie i zajmować możliwie najmniej czasu. Bank powinien Ci dać specjalne narzędzie, które umożliwia zdalne połączenie z rachunkiem. Niemniej z sobie znanych względów banki takiego API nie udostępniają ( jedynie bank BPH wyłamuje się z tej reguły ). Z pomocą przychodzi firma XFuture ze swoim rozwiązaniem XConnector. XConnector to podzespół dla Twojej aplikacji, któremu, po przekazaniu danych uwierzytelniających, możesz kazać połączyć się z serwerem banku i pobrać historię operacji ze wskazanego przedziału. Te dane są potrzebne, aby bank mógł rozpoznać Cię jako swojego klienta i udostępnić właściwe zasoby. Rozumiem, że możesz mieć obawy dotyczące tego, czy biblioteka XConnector wykorzysta w niepowołany sposób ( czytaj "ukradnie i prześle gdzieś dalej" ) Twoje dane uwierzytelniające i/lub dane Twoich transakcji.
Kwestia bezpieczeństwa danych jest zagadnieniem priorytetowym, jeśli zajmujemy się dostępem do danych finansowych. Ze strony podzespołu XConnector nie grozi Ci wyciek danych, ale powienienś słusznie założyć ( stosując żelazną zasadę ograniczonego zaufania, lub po prostu braku zaufania ), że każdy podzespół dostarczony Ci przez firmę trzecią, może albo zawierać szpiegowskie procedury, albo być podatnym na awarie sprokurowane przez działania hackerów, co w dalszej kolejności może prowadzić do utraty kontroli nad danymi i wyciekiem tychże. Świadomość tego zagadnienia jest powszechna w środowisku producentów oprogramowania i do czasu opracowainia mechanizmów izolacji podzespołów, problem był naprawdę poważny ( mam na myśli programy kompilowane do kodu natywnego platformy sprzętowej, zwłaszcza w systemie windows XP i wcześniejszych ). Dziś on praktycznie nie istnieje i został rozwiązany dzięki wprowadzeniu środowisk uruchomieniowych, które, dla kontenera w którym pracuje aplikacja, pozwalają jasno określić uprawnienia ( czytaj 'ograniczyć' ). Jeśli Twój program chce skorzystać ze zdalnego, usystematyzowanego dostępu do rachunku w formie API XConnector, to:
1) musi zaprosić bibliotekę do siebie ( podłącza ją dynamicznie ).
2) nie zaprasza jej do swojego pokoju, ale do specjalnego pokoju, z którego widać tylko serwer banku ( tworzy domenę aplikacji z uprawnieniami wyłącznie do komunikacji z domeną np mbank.pl )
3) musi utworzyć obiekt klasy konektora bankowego, zawarty w bibliotece XConnector. Tego obiektu nie tworzy normalnie ( poprzez operator new ), ale wykorzystuje lokalny remoting. Dokonuje tego tworząc u siebie proxy obiektu, który zostaje zdalnie utworzony w domenie aplikacji z ograniczonymi uprawnieniami. Dzięki temu kod biblioteki XConnector nie ma uprawnień, aby wykonać jakąkolwiek szkodliwą akcję, a konfiguracja uprawnień domeny daje możliwość wyłącznej komunikacji dwustronnej jedynie z serwerem banku. Każda próba wykonania/nawiązania połącznia z czymś innym, niż serwer banku, kończy się zgłoszeniem wyjątku bezpieczeństwa, który efektywnie wstrzymuje wykonywanie potencjalnego, złośliwego kodu.
Podzespół izolowany w ten sposób nie stanowi zagrożenia.
Jak to się ma do Płatności? Jak widzisz XConnector nie jest alternatywą dla Płatności. Twoi klienci nie mogą z niego skorzystać, nie widzą go. Niemniej dzięki temu, że XConnector potrafi połączyć się z Twoim rachunkiem, możesz napisac program, który księguje wpłaty od klientów bez pośrednictwa Płatności. Wystarczy, że klienci zrobią przelew na Twoje konto. Oczywiście muszą ręcznie wypełnić dane przelewu, wcześniej logując się na swój rachunek za pomocą strony www banku. Jeśli chesz im zadanie uprościć stosując automatyzację znaną z Płatności ( szybkie przelewy w stylu mTransfer ), nikt nie jest w stanie Cię powstrzymać: dzwonisz do banku i wykupujesz usługę mTransfer lub podobną. Dostaniesz od banku wskazówki dotyczące tego, jak oskryptować usługę. Finalnie zwykłe przelewy i przelewy mTransfer trafiają do Twojej historii rachunku w tej samej formie. Te dane możesz następnie odzyskać za pomocą XConnectora, który działa w sercu Twojego programu księgująco - rozliczeniowego. Twój program sam rozpoznaje wpłaty, uaktualnia bazę danych i zapala zielone światło Twoim pracownikom z magazynu i działu wysyłki. Żaden pośrednik finansowy nie konsumuje Twoich danych, dane Twoich klientów masz tylko Ty. Ile zarabiasz i jaki masz obrót : wiesz tylko Ty, nikt Cię nie szpieguje ( i to za Twoje pieniądze ). Producenci biblioteki nie mają pojęcia z jakim rachunkiem się łączysz i generalnie nie mają żadnej wiedzy na temat Twoich działań, bo biblioteka XConnector pracuje w izolowanym sandboxie.
Jeśli chcesz robić dobry biznes, musisz robić bezpieczny biznes i taki biznes możesz robić dzięki XConnector.
Jeśli masz jeszcze jakieś pytania, chętnie na nie odpowiem.
пропозиції роботи
