Bezpieczne Zakupy. specyfikacja techniczna implementacji pełnej

Wielkość: px
Rozpocząć pokaz od strony:

Download "Bezpieczne Zakupy. specyfikacja techniczna implementacji pełnej"

Transkrypt

1 Bezpieczne Zakupy specyfikacja techniczna implementacji pełnej P OL C AR D is a regis t e r e d t ra d e ma rk o f FI R S T D AT A P O L S K A S. A., FI RS T D AT A P O L S K A S. A., Al. J e roz o l i ms k i e 9 2, Wa r s z a wa, t e l. : , faks : w ww. f irs t d a ta.pl Strona 1 z 22

2 Spis treści Strona ZMIANY... 3 TERMINOLOGIA... 4 AUTORYZACJA... 5 POŁĄCZENIE POSIADACZA KARTY DO WITRYNY KONTRAHENTA... 5 AUTORYZACJA PŁATNOŚCI ZA ZAMÓWIENIE I PRZEKAZANIE KONTRAHENTOWI ODPOWIEDZI AUTORYZACYJNEJ... 7 PRZEKIEROWANIE KLIENTA, REALIZACJA ZAMÓWIENIA OBSŁUGA BŁĘDÓW DOSTĘP DO BAZY TRANSAKCJI ROZLICZENIA FORMAT PLIKU ROZLICZENIOWEGO BUDOWA PLIKU ROZLICZENIOWEGO Nagłówek Dane Format cfc, dane dla firmy rozliczeniowej (FDP) o transakcjach przeprowadzanych przy pomocy kart bankowych Format cfd, dane zwrotne z firmy rozliczeniowej (FDP) PRZYKŁADY FORMULARZ INICJUJĄCY ZAPYTANIE AUTORYZACYJNE SKRYPT DO OBSŁUGI ROZLICZEŃ ZBIÓR CFC-001.TXT (FORMAT CFC) Z ZADEKLAROWANYM SEPARATOREM (,) ZBIÓR CFC-001.TXT (FORMAT CFC) Z DOMYŚLNYM SEPARATOREM (TABULATOR) ZBIÓR CFD-001.TXT (FORMAT CFD) Z ZADEKLAROWANYM SEPARATOREM (,) ZBIÓR CFD-001.TXT (FORMAT CFD) Z DOMYŚLNYM SEPARATOREM (TABULATOR) Strona 2 z 22

3 Nr wersji Data Zmiany Zakres zmiany lipiec, Odpowiedź autoryzacyjna: 1. Nowe pole test 2. Nowe pole bin 2. Uściślenie zawartości certyfikatów SSL 3. Uściślenie formatu pól odpowiedzi autoryzacyjnej 4. Zapytanie autoryzacyjne: 1. Nowe pole client_ip 5. Obsługa błędów 6. Pozostawienie kontrahentowi tylko jednego numeru pos_id, przeniesienie mechanizmu dynamicznego przydzielania numerów pos_id do FDP września, Odpowiedź autoryzacyjna 1. Nowe pole auth_code 2. Nowe pole fraud 3. Nowe pole sequence 4. Sposób reakcji na próbę połączenia z błędnym certyfikatem SSL 5. Zmiana kodowania kraju w adresie wysyłki 2. Nowe połączenie do odczytu danych opisujących transakcję 3. Rozliczenia 1. Wyjaśnienie mechanizmu przekazania raportu CFD Postępowanie w przypadku odrzucania przez serwer kontrahenta certyfikatów Thawte lipiec, Postępowanie w przypadku błędu rozliczeń Zmiana typów kart przesyłana w odpowiedzi autoryzacyjnej listopad, Dodanie informacji n/t sposobu weryfikacji nowych certyfikatów wydanych przez Thawte (w drzewie razem z VeriSign) 2. Usunięcie informacji n/t stosowania certyfikatów PolCard_TestCA 3. Dodanie informacji o weryfikacji 2 poziomów podpisów w certyfikatach 4. Więcej szczegółów n/t przekazywania pola cc_number_hash październik, Formatowanie dokumentu marzec, Rebranding Strona 3 z 22

4 Przeznaczenie dokumentu Niniejszy dokument opisuje: 1. protokół autoryzacji transakcji dokonywanych w systemie Bezpieczne Zakupy; 2. postać zbiorów przeznaczonych do prowadzenia rozliczeń transakcji internetowych, w tym: i. przedstawiania przez Kontrahentów FDP transakcji rozliczeniowych, na które uprzednio uzyskano zgodę FDP; ii. przekazywania przez FDP informacji zwrotnej o przyjęciu bądź odrzuceniu transakcji do rozliczenia. Zakres stosowania dokumentu: Kontrahenci FDP posiadający ważną umowę w zakresie współpracy przy akceptacji kart płatniczych wraz z aneksem na usługę Bezpieczne Zakupy jako załącznik do oferty usługi Bezpieczne Zakupy. Terminologia POLCARD zarejestrowany znak towarowy w ramach którego świadczona jest usługa Bezpieczne Zakupy FDP FIRST DATA POLSKA S.A. właściciel marki POLCARD udostępniający usługę Bezpieczne Zakupy adres bankowy - adres podany przez klienta w banku, we wniosku o wydanie karty płatniczej; adres wysyłki - adres pocztowy, pod który zostaną wysłane zamówione towary. Jeśli towar jest niematerialny, to jako adres wysyłki traktowany jest adres Klienta i numer IP komputera, z którego uzyskał on połączenie do serwera Kontrahenta. Jest to adres podany przez Klienta Kontrahentowi i przekazywany przez Kontrahenta do FDP w procesie autoryzacji zamówienia; amount - całkowita wartość zamówienia Klienta, uwzględniająca wszystkie czynniki, takie jak opłaty manipulacyjne itp.; cc_number_hash/cc_hash - wynik działania jednokierunkowej funkcji skrótu na numerze karty Klienta. Kontrahent może przechowywać wartości tego pola i podejmować decyzje o dokonaniu transakcji znając historie płatności dokonanych z użyciem tej karty; pole to jest przesyłane przez FDP w tzw. odpowiedzi autoryzacyjnej i powinno być prezentowane przez kontrahenta w odpowiednim miejscu w plikach rozliczeniowych (CFC). Nie należy tego pola mylić z BINem karty. Strona 4 z 22

5 BIN Bank Identification Number numer identyfikujący bank wydawcę karty, wartość ta jest przesyłana w odpowiedzi autoryzacyjnej, może być stosowana przy okresowych promocjach dla klientów konkretnego banku. internetowy punkt handlowy - punkt w sieci Internet, w którym są lub będą dokonywane transakcje z użyciem karty płatniczej jako środka zapłaty; Klient - osoba zamierzająca zamówić u Kontrahenta towary, usługi bądź informacje, za które zapłaci kartą płatniczą - posiadacz karty; Kontrahent - instytucja prowadząca działalność gospodarczą, która podpisała z FDP umowę o współpracę w zakresie akceptowania i rozliczania transakcji dokonanych z użyciem kart płatniczych oraz aneks na usługę Internet Order Online; order_id - unikalny identyfikator zamówienia, przedstawiony Klientowi po dokonaniu transakcji (np. numer faktury VAT); pos_id - numer identyfikujący serwer Kontrahenta. Numer ten jest nadawany przez FDP. response_code - kod odpowiedzi autoryzacyjnej informujący czy wydawca karty zgodził się na realizację płatności; session_id - unikalny identyfikator zdarzenia polegającego na przejściu przeglądarki Klienta ze stron Kontrahenta na stronę autoryzacyjną FDP w celu dokonania płatności; sklep internetowy - punkt w sieci Internet, w którym są lub będą dokonywane transakcje z użyciem karty płatniczej jako środka zapłaty (inaczej: internetowy punkt handlowy); towar - dobra materialne i niematerialne, za które Klient dokonuje zapłaty kartą płatniczą Kontrahentowi; Autoryzacja Połączenie posiadacza karty do witryny kontrahenta Klient (posiadacz karty) uzyskuje połączenie zgodne z protokołem http, zabezpieczonym technologią SSL z serwerem kontrahenta. Klient zapoznaje się z ofertą kontrahenta i dokonuje wyboru towarów, które chce zamówić. Przed przejściem do autoryzacji zamówienia konieczne jest spełnienie następujących warunków, w dowolnej kolejności: klient powinien zapoznać się z końcową ceną zamawianych towarów, zawierającą wszystkie przewidywalne składniki (np. koszty wysyłki), klient powinien podać adres wysyłki, serwer kontrahenta powinien wygenerować numer session_id., serwer kontrahenta winien zidentyfikować i zapisać do własnej bazy danych adres IP komputera klienta, który Strona 5 z 22

6 dokonuje zapłaty kartą płatniczą, tego typu dana winna być udostępniana na każde żądanie FDP; Po spełnieniu tych warunków serwer kontrahenta generuje stronę HTML z formularzem odsyłającym klienta do strony autoryzacyjnej FDP. Adres pod który powinien odsyłać formularz jest następujący: https://post.polcard.com.pl/cgi-bin/autoryzacja.cgi Wewnątrz formularza powinny znajdować się niżej opisane pola: Nazwa pola Format Opis zawartości pola session_id ANC {1,1024} Jak w części terminologia. Nowa wartość tego identyfikatora powinna być generowana zawsze przed dostarczeniem klientowi formularza odsyłającego do strony autoryzacyjnej FDP order_id ANC{1,64} Unikalny identyfikator zamówienia (koszyka towarów), znany trzem stronom (klient, kontrahent, FDP), który pojawi się na potwierdzeniu sprzedaży przedstawionym przez sklep posiadaczowi karty po udanej autoryzacji i po decyzji sklepu o dokonaniu sprzedaży. Może to być numer faktury VAT, lub rachunku, który pojawi się na towarzyszącym produktowi, dokumencie papierowym. W przypadku ponownego wygenerowania session_id dla nowej autoryzacji, ten identyfikator nie ulega zmianie. pos_id ANC {1,20} Nadany przez FDP identyfikator serwera kontrahenta (identyfikator wirtualnego "punktu sprzedaży" lub "terminala"), wartość stała dla danego kontrahenta amount NUM {1,10} Wartość zamówienia uwzględniająca wszystkie przewidywalne czynniki. Kwota podana w groszach, tzn. 20 zł 34 gr powinno być zapisane jako 2034 street AN {0,40} Pierwsza linia adresu wysyłki. W większości wypadków powinna zawierać nazwę ulicy i numer lokalu street_n1 AN {0,10} Numer związany z adresem, prawie zawsze jest to numer domu street_n2 AN {0,10} Numer związany z adresem, będzie to numer mieszkania o ile numer mieszkania ma zastosowanie addr2 AN {0,40} Druga linia adresu wysyłki. addr3 AN {0,40} Trzecia linia adresu wysyłki city AN {0,40} Nazwa miasta z adresu wysyłki postcode AN {0,10} Numer kodu pocztowego z adresu wysyłki w formacie , lub jego odpowiednik dla adresów zagranicznych country AN {1,3} Kod kraju z adresu wysyłki. Kod powinien być taki, jaki stosuje się na samochodowych tablicach rejestracyjnych w danym kraju (Dla Polski="PL", dla Stanów Zjednoczonych Ameryki Pn. "USA", dla Niemiec "D" itd.) language AN {2,2} Język, w którym FDP powinien komunikować się z klientem. Możliwe wartości to: "PL" - polski, "EN" - angielski. ANC {0,40} Adres klienta test AN {1,1} Wskaźnik, czy transakcja ma być traktowana jako testowa czy jako produkcyjna. Możliwe są dwie wartości: "N" - produkcyjna, "Y" - testowa client_ip ANC{0,15} Adres IP komputera klienta Strona 6 z 22

7 Gdzie: {x,y} - pole o minimalnej długości x, maksymalnej długości y; ANC - litery małe i duże a-za-z, cyfry 0-9, następujące znaki: \/<>,.'`*, bez spacji i polskich liter; NUM - cyfry 0-9; AN - jak ANC, z dopuszczonymi spacjami. Kontrahent powinien uniemożliwić więcej niż jedną autoryzację na dany "order_id". W momencie dokonania autoryzacji transakcja z danym "order_id" powinna zostać zaznaczona jako zautoryzowana i w przypadku potrzeby autoryzacji dalszych płatności przez danego klienta powinien być generowany nowy "order_id". FDP może ograniczyć liczbę prób zapłaty z danym "order_id". Po naciśnięciu przez klienta przycisku "Zapłata kartą" nastąpi połączenie do strony autoryzacyjnej FDP. Autoryzacja płatności za zamówienie i przekazanie kontrahentowi odpowiedzi autoryzacyjnej Po połączeniu się ze stroną autoryzacyjną FDP klient (posiadacz karty) wprowadza dodatkowe dane (w tym numer karty i datę jej ważności) konieczne do uzyskania autoryzacji. Autoryzacja jest przeprowadzana przez FDP. Polega ona na skontaktowaniu się z systemem komputerowym banku, który wydał kartę i uzyskaniu odpowiedzi, czy dana płatność może być zrealizowana. Po uzyskaniu odpowiedzi od banku wydawcy FDP przesyła ją kontrahentowi. W tym celu serwer FDP nawiązuje połączenie https zabezpieczone SSL z serwerem kontrahenta wykonując operację POST. Podczas nawiązywania połączenia FDP przedstawia swój certyfikat SSL podpisany przez jeden ze znanych urzędów certyfikacyjnych. Dzięki temu kontrahent ma możliwość upewnienia się, że nadawcą komunikatu jest FDP. Połączenie następuje pod uzgodniony wcześniej z kontrahentem adres URL. Po otrzymaniu przez serwer kontrahenta połączenia pod wskazany adres URL, oprogramowanie serwera kontrahenta powinno w pierwszej kolejności zweryfikować drugą stronę połączenia upewniając się, że jest nią FDP. W tym celu serwer kontrahenta powinien żądać przedstawienia certyfikatu SSL i po jego otrzymaniu upewnić się, że weryfikacja certyfikatu zakończyła się sukcesem, a następnie sprawdzić zawartość poniższych pól certyfikatu: Pole X.509 Symbol Powinno być równe Organization S_DN_O "PolCard S.A." Locality S_DN_L "WARSZAWA" Strona 7 z 22

8 CommonName S_DN_CN "post.polcard.com.pl" Country S_DN_C "PL" Powyższy certyfikat powinien być podpisany przez: Thawte lub Verisign. Certyfikat instytucji podpisującej również należy sprawdzić (poniżej dane dla certyfikatu wydanego przez Thawte): Pole X.509 Symbol Powinno być równe Organization I_DN_O "Thawte Consulting (Pty) Ltd." CommonName I_DN_CN "Thawte SGC CA" Country I_DN_C "ZA" UWAGA! Ze względu na fakt, że powyższy certyfikat jest podpisany przez root CA Verisign, należy bezwzględnie włączyć w serwerze HTTPS weryfikację certyfikatów do 2 poziomów. W przypadku serwera Apache i modułu mod_ssl, linia taka ma postać: SSLVerifyDepth 2 Z uwagi na fakt, iż błędna weryfikacja może oznaczać próbę dokonania nadużycia, zalecane jest zakończenie połączenia bez udzielania jakiejkolwiek odpowiedzi. W wypadku błędnej weryfikacji certyfikatu kontrahent nie powinien analizować odebranych danych. Zakłada się wtedy, że FDP nie skontaktował się z kontrahentem. Serwer kontrahenta powinien w takiej sytuacji przesłać następującą odpowiedź: Content-Type: text/plain Client authentication failed Taka odpowiedź powinna być przesyłana w każdym przypadku błędnej weryfikacji certyfikatu FDP, tzn. również przy odebraniu żądania dostępu do bazy danych transakcji przez FDP, i przy przesłaniu z FDP raportu rozliczeniowego. Po pozytywnej weryfikacji certyfikatu serwer Kontrahenta powinien odczytać informacje zawarte w następujących polach: Nazwa pola Format Zawartość order_id session_id ANC{1,64} Wartość pola order_id przesłanego do FDP przy autoryzacji płatności. ANC{1,1024} Wartość pola session_id przesłanego do FDP przy autoryzacji płatnosci. Strona 8 z 22

9 Nazwa pola Format Zawartość amount response_code cc_number_hash card_type address_ok auth_code NUM{1,10} Wartość pola amount przesłanego do FDP przy autoryzacji płatności. Jednocześnie, jest to maksymalna kwota (wyrażona w groszach), do wysokości której kontrahent może wysłać informacje o dokonanej transakcji z danym session_id w celu jej rozliczenia. ANC{3,3} Kod odpowiedzi informujący, czy wydawca karty zgodził się na realizację płatności. Jeśli tej zgody nie uzyskano, FDP nie rozliczy transakcji z danym session_id. Możliwe kody to: 000 zgoda 100 odmowa ANC{1,512} Wynik działania jednokierunkowej funkcji skrótu na numerze karty klienta i numerze pos_id. Kontrahent może przechowywać wartości tego pola i podejmować decyzje o dokonaniu transakcji znając historię płatności dokonanych z użyciem tej karty. ANC{1,20} Napis określający typ karty, służy do wydrukowania szczegółów płatności na fakturze (zamiast numeru karty). Te napisy to np.:visa, ECMC, JCB, PC, PBK Styl, DC ANC{1,1} Rezultat veryfikacji adresu posiadacza karty: 0 - nie był sprawdzany 1 - adres jest OK. 2 - kod pocztowy jest poprawny test ANC{1,1} Wartość flagi test otrzymanej przez FDP w zapytaniu autoryzacyjnym. Powinna być identyczna z wartością flagi test umieszczonej przez kontrahenta w formularzu służącym do dokonania zapytania autoryzacyjnego, tzn. kontrahent powinien kontrolować czy na transakcje produkcyjne otrzymuje odpowiedzi z flagą "N" a na testowe z flagą "Y". bin fraud sequence ANC{1,16} Kod autoryzacji. Jest to kod generowany przez bank-wydawcę karty w razie zaakceptowania transakcji. Wartość tego pola powinna być później odesłana przez kontrahenta w pliku rozliczeniowym. NUM{6,6} Pierwsze 6 cyfr numeru karty, identyfikujące jednoznacznie produkt kartowy i bank-wydawcę. NUM{1,1} Wynik oceny ryzyka przeprowadzanej przez FDP. Wartości pola są następujące: 0 - Ocena ryzyka nie została przeprowadzona dla tej transakcji. 1 - Spodziewany brak ryzyka lub niskie ryzyko w ocenie FDP. 2 - Spodziewane wysokie ryzyko transakcji, nie realizuj zlecenia. Okoliczności przeprowadzenia transakcji będą wyjaśniane przez FDP. Skontaktuj się telefonicznie z FDP w celu wyjaśnienia czy transakcję można przeprowadzić. 3 - Nie realizuj transakcji - bardzo wysoki poziom ryzyka. Wartość tego pola ma charakter informacyjny i nie obliguje kontrahenta do zaniechania realizacji transakcji nawet jeśli została przesłana wartość 2 lub 3. Wiążąca jest jedynie wartość pola response_code. Usługa oceny ryzyka ma na celu zminimalizowanie strat kontrahenta związanych ze sprzedażą przez internet. NUM{6,6} Numer kolejny odpowiedzi autoryzacyjnej, nadawany przez FDP. Numeracja zaczyna się od "000000" i kończy się na "999999". Następną wartością po osiągnięciu "999999" jest znów "000000". Istnienie tego numeru ma ułatwić identyfikację transakcji poprzez stworzenie sekwencyjnego ciągu. Numer ten ma znaczenie Strona 9 z 22

10 Nazwa pola Format Zawartość wyłącznie jako ewentualna pomoc przy wyjaśnianiu pomiędzy kontrahentem a FDP historii dokonywanych transakcji. Po sprawdzeniu, ze wartości pól "session_id" i "amount" odpowiadają jednemu z realizowanych zamówień, kontrahent powinien potwierdzić fakt otrzymania odpowiedzi autoryzacyjnej, niezależnie od wartości pola "response_code". Potwierdzenie polega na odesłaniu w odpowiedzi do FDP (w tym samym połączeniu) strony HTML zawierającej parę tagów <url_redirect> i </url_redirect>, wewnątrz której powinien zawrzeć się adres, pod który FDP powinien przekierować przeglądarkę klienta (posiadacza karty). Przykładowa odpowiedź może wyglądać następująco: <html> <body> Otrzymano odpowiedź autoryzacyjną do session_id A00123 <url_redirect>https://www.sklep.pl/welcome_back.cgi</url_redirect> </body> </html> FDP udziela posiadaczowi karty odpowiedzi o powodzeniu czy nie powodzeniu autoryzacji transakcji internetowej, a następnie przekierowuje klienta na właściwą stronę. Przekierowanie klienta, realizacja zamówienia Klient zostaje przekierowany pod adres podany w potwierdzeniu odpowiedzi autoryzacyjnej. Kontrahent podejmuje decyzję o realizacji lub odrzuceniu zamówienia. Strona 10 z 22

11 Obsługa błędów W razie wystąpienia błędu w trakcie przetwarzania autoryzacji przez serwer FDP, nastąpi przekierowanie przeglądarki klienta pod adres uzgodniony z kontrahentem. Przeglądarka klienta połączy się pod w/w adres wykonując operację POST i przekazując dane dotyczące błędu w następujących polach: Nazwa pola Format Zawartość order_id session_id pos_id message err_code ANC{1,64} Wartość pola order_id przesłanego do FDP przy autoryzacji płatności ANC{1,1024} Wartość pola session_id przesłanego do FDP przy autoryzacji płatnosci. ANC{1,20} Nadany przez FDP identyfikator serwera kontrahenta (identyfikator wirtualnego "punktu sprzedaży" lub "terminala"), wartość stała dla danego kontrahenta AN{0,1024} Komunikat o błędzie w języku określonym wcześniej przez wartość pola language. ANC{1,10} Kod błędu, jeden z wymienionych w tabeli poniżej. Kody błędów - wartości pola err_code err_code Znaczenie err01 Nie uzyskano od sklepu potwierdzenia odebrania odpowiedzi autoryzacyjnej Autoryzacja płatności została wykonana przez FDP, ale nie doszło do skutku połączenie do serwera kontrahenta w celu przekazania odpowiedzi autoryzacyjnej. Jeśli autoryzacja była pozytywna, tzn. bank który wydał kartę wyraził zgodę na przeprowadzenie transakcji, to najczęściej (w zależności od banku który wydał kartę) kwota środków dostępnych na karcie zostanie zmniejszona o kwotę transakcji (na kilka dni, po których środki te zostaną odblokowane automatycznie). Nie nastąpi obciążenie konta posiadacza karty, ani płatność dla kontrahenta. err02 Nie uzyskano odpowiedzi autoryzacyjnej Nie udała się autoryzacja płatności przeprowadzana przez FDP, tzn. zapytanie do banku który wydał kartę o możliwość przeprowadzenia transakcji. Zazwyczaj przyczyną powstania tego błędu jest chwilowy wzrost obciążenia sieci autoryzacyjnych i należy ponowić próbę płatności. err03 To zapytanie było już przetwarzane Zapytanie autoryzacyjne identyfikowane przez session_id było już wcześniej przetwarzane przez FDP i uzyskana została zgoda na przeprowadzenie transakcji. Należy ponowić próbę z użyciem innej wartości session_id. err04 Zapytanie autoryzacyjne niekompletne lub niepoprawne Dane przesłane w zapytaniu autoryzacyjnym były niekompletne lub niepoprawne. Zawartość pola message wskazuje na pola których wartość była niepoprawna. err05 Nie udało się odczytać konfiguracji sklepu internetowego Przyczyną powstania tego błędu może być niewłaściwa wartość pola pos_id. err06 Nieudany zapis zapytania autoryzacyjnego Błąd wewnętrzny w systemie FDP. err07 Inna osoba dokonuje płatności. Została przekroczona dozwolona liczba osób które mogą jednocześnie dokonywać płatności. W takiej sytuacji należy ponowić próbę zapłaty za transakcję. FDP po wykryciu takiej sytuacji zwiększy limit jednoczesnych połączeń dla kontrahenta. err08 Nieustalony status połączenia ze sklepem Błąd wewnętrzny w systemie FDP. Strona 11 z 22

12 err_code Znaczenie err09 Przekroczono dozwoloną liczbę poprawek danych Dla danego session_id przekroczono dozwoloną liczbę poprawek danych wprowadzanych przez posiadacza karty, takich jak numer karty, jej data ważności, typ karty, adres posiadacza karty. Należy ponowić próbę płatności z użyciem innej wartości session_id. err10 Przekroczono maksymalną kwotę transakcji Dla danego session_id przekroczono dozwoloną liczbę poprawek danych wprowadzanych przez posiadacza karty, takich jak numer karty, jej data ważności, typ karty, adres posiadacza karty. Należy ponowić próbę płatności z użyciem innej wartości session_id. Rozliczenia Na koniec dnia, serwer FDP połączy się ze specjalną stroną kontrahenta tzw. URL pollingu w celu pobrania plików rozliczeniowych. Pliki te powinny zawierać informacje o transakcjach do rozliczenia, które zostały zaakceptowane przez kontrahenta. W szczególności może się zdarzyć, że te pliki będą zawierały inne transakcje niż lista autoryzacji wykonanych na rzecz danego Kontrahenta w danym dniu. Może tak się zdarzyć wówczas, gdy z jakichś powodów kontrahent nie wysłał zakupionego towaru w dniu autoryzacji, a robi to kilka dni później (na przykład po uzupełnieniu braków magazynowych). Kontrahent może przekazać transakcje do rozliczenia w ciągu 7 dni kalendarzowych od daty autoryzacji. W przypadku zwrotów, Kontrahent: 1. Jeżeli transakcja autoryzacyjna zakończyła się akceptacją nie musi wykonywać dodatkowej specjalnej autoryzacji dla zwrotu. Informację o zwrocie dołącza do pliku rozliczeniowego. 2. Może przysłać zwrot w czasie zwyczajowo przyjętym na akceptację zwrotów, tj.: 3 miesięcy. Limit 7-miu dni od daty autoryzacji nie obowiązuje w przypadku zwrotów, 3. Jako identyfikację transakcji, musi przyjąć od posiadacza karty numer faktury i numer sesji. Nie może przyjąć jawnego numeru karty ani jawnej daty ważności karty, Kontrahent pod znanym FDP adresowi URL umieszcza aplikację, która na zapytanie HTTP GET prześle aktualny, bieżący plik rozliczeniowy, a następnie na zapytanie HTTP POST przyjmie plik z raportem rozliczeniowym z FDP. Ten skrypt, (patrz przykład), podobnie jak skrypt przyjmujący odpowiedź autoryzacyjną z FDP, musi sprawdzić certyfikaty klienta go wywołującego, tak samo jak w przypadku autoryzacji. W połączeniu POST serwer FDP przesyła raport rozliczeniowy jako upload pliku w parametrze o nazwie clearing_report_file, zgodnie z RFC Przesłanie tego pliku jest widziane przez serwer kontrahenta tak, jak efekt działania przykładowego formularza: <FORM METHOD="POST" ACTION="www.sklep.pl/rozliczenia" ENCTYPE="multipart/form-data"> Strona 12 z 22

13 <INPUT NAME="clearing_report_file"> <INPUT TYPE="SUBMIT" VALUE="Wyslij plik rozliczeniowy"> </FORM> Plik przesłany tą metodą jest możliwy do odebrania w różny sposób, w zależności od typu serwera posiadanego przez kontrahenta. Moduł CGI.pm używany wraz z serwerem Apache udostępnia przesyłany plik jako "filehandle" przesłany w polu o nazwie clearing_report_file. Serwery IIS firmy Microsoft nie mają (lub nie wszystkie mają) zaimplementowaną tą część obsługi HTML, i konieczne może być analizowanie zawartości POST'a napisane we własnym zakresie lub zakupione od firmy zewnętrznej. W szczególności, firma Microsoft informuje na swoich stronach o (prawdopodobnie własnym) produkcie "ActiveFile", który ma za zadanie uzupełnienie tej funkcjonalności. W odpowiedzi na POST z FDP skrypt powinien odesłać potwierdzenie w następującym formacie: Content-Type: text/plain Received [pos_id,batch] Słowa pos_id i batch należy zastąpić odpowiednią wartością pos_id i batch (wartość pola Batch z nagłówka otrzymanego raportu). URL przyjmujący rezultat autoryzacji w FDP musi wykonać te samą wstępną kontrolę (tj.: powyższy skrypt aż do linii [use CGI], gdzie zaczyna się obsługa zbiorów rozliczeniowych). Proces rozliczenia jest powtarzany cyklicznie dla każdego ze zbiorów po kolei (jeden zbiór CFC - przetworzenie - jeden zbiór CFD - kolejny CFC... itd.). System przeglądania oczekujących zbiorów rozliczeniowych w FDP, będzie ponawiał GET tego URL aż do czasu, kiedy nie dostanie żadnego zbioru. Wówczas system pobierania zbiorów rozliczeniowych przechodzi do następnego URL. Jeśli kontrahent nie otrzyma raportów rozliczeniowych za dany dzień (na przykład w przypadku awarii serwera czy łącza telekomunikacyjnego) przy każdym następnym połączeniu będą ponawiane próby przetworzenia tych zbiorów. Strona 13 z 22

14 Format pliku rozliczeniowego Zbiory są plikami tekstowymi ASCII z konwencją końca linii przyjętą w MS-DOS, tj. linie zakończone są sekwencją dwóch bajtów: CR=0x0D i następującym po nim LF=0x0A. Struktura pliku rozliczeniowego Nagłówek Zbiory składają się z nagłówka, który zawiera linie z ogólnymi informacjami o kontrahencie w formie: <Słowo_kluczowe><dwukropek(tj._znak_":")><opcjonalne_spacje_lub_tab*><informacja> * w kodzie heksadecymalnym spacje - 20, tabulacje - 09 Słowa kluczowe mogą zawierać małe lub duże litery. Program analizujący nagłówek przesyłki musi robić porównanie słów kluczowych bez zwracania uwagi na "wielkość" liter (case-insensitive match). Zdefiniowane słowa kluczowe: Słowo kluczowe Tid Format Występowanie wymagane wymagane Opis Kod punktu sprzedaży klienta - - przydzielany przez FDP. Jest on równy wartości pos_id stosowanej przy autoryzacji. Rozróżnienie formatów danych finansowych, możliwe wartości to: C dla pliku CFC Separator Batch opcjonalne wymagane D dla pliku CFD (odpowiedź na rozliczenie wysyłane do FDP). Zmiana znaku separatora pól (domyślnie jest nim tabulator HT). Tutaj "informacją" jest wybierany nowy znak - jeden spośród: = Kolejny numer paczki transakcji (zbioru). Ten numer przybiera kolejne wartosci od 000 do 999 i ponownie 000 i stanowi identyfikacje paczki rozliczeniowej. Jest tym samym numerem, który pojawia się w nazwie zbioru. Nazwa opcjonalne Pełna nazwa kontrahenta FDP Adres opcjonalne Adres kontrahenta FDP Data opcjonalne Data utworzenia pliku, jeżeli nie występuje przyjmuje się datę odebrania pliku w FDP Ref opcjonalne Numer referencyjny - nadawany przez kontrahenta Liczba opcjonalne Liczba rekordów finansowych w przesyłce Suma opcjonalne Suma wartości transakcji zawartych w zbiorze Md5 opcjonalne Suma kontrolna części finansowej przesyłki (bez nagłówka) Strona 14 z 22

15 Raport z rozliczenia transakcji będzie miał taki sam separator jak zbiór przyjęty do rozliczenia. W przesyłce zwrotnej (tj. wysyłanej z FDP do klienta) mogą dodatkowo wystąpić następujące linie nagłówka: Słowo kluczowe WersjaOprogramowania Format Data TID Batch SumaRozliczenia LiczbaTransakcji KwotaUznan LiczbaUznan KwotaObciazen LiczbaObciazen KwotaOdmow LiczbaOdmow KwotaError LiczbaError KwotaUznanTestowych LiczbaUznanTestowych Opis Wersja oprogramowania systemu FDP Rozróżnienie formatów danych finansowych, wartości dopuszczalne jak dla rozliczeniowego Data przetworzenia pliku przez FDP Identyfikator punktu sprzedaży, równy wartości pos_id stosowanej przy autoryzacji. pliku Kolejny numer paczki transakcji (zbioru). Ten numer przybiera kolejne wartosci od 000 do 999 i ponownie 000 i stanowi identyfikację paczki rozliczeniowej. Jest to numer Batch zbioru rozliczeniowego cfc, którego dotyczy raport. Różnica pomiędzy sumą obciążeń i sumą uznań Ilość transakcji odpowiadająca polu Liczba w przesyłce do FDP Suma kwot transakcji w rozliczonych dobro rachunku posiadacza karty Ilość transakcji włączonych do powyższej sumy Suma kwot transakcji obciążających rachunek posiadacza karty Ilość transakcji włączonych do powyższej sumy Suma kwot transakcji nie zrealizowanych Ilość transakcji włączonych do powyższej sumy Suma kwot transakcji z "katastrofalnym" błędem obsługi (ewentualny błąd w procedurach FDP) Ilość transakcji włączonych do powyższej sumy Suma kwot transakcji testowych rozliczonych w dobro rachunku posiadacza karty Ilość transakcji testowych włączonych do powyższej sumy KwotaObciazenTestowych Suma kwot transakcji testowych obciążających rachunek posiadacza karty LiczbaObciazenTestowych Ilość transakcji testowych włączonych do powyższej sumy KwotaOdmowTestowych LiczbaOdmowTestowych Suma kwot transakcji testowych nie zrealizowanych Ilość transakcji testowych włączonych do powyższej sumy Linie nagłówka zaczynające się znakiem niewidocznym - spacją = 0x20 lub tabulatorem = 0x09, stanowią kontynuacje poprzednich linii nagłówka. Nagłówek kończy się pustą linią, czyli wystąpienie bezpośrednio po sobie dwóch znaków końca linii (z których każdy jest dwubajtową sekwencją) oznacza koniec nagłówka. Strona 15 z 22

16 Dane Wszystko, co następuje po nagłówku jest informacją finansową i ma format linii tekstu z poszczególnymi danymi oddzielonymi od siebie znakiem separatora - domyślnie tabulatora (0x09). Format dopuszcza możliwości użycia innego znaku niż znak tabulatora jako separatora pól. Nowy separator jest zdefiniowany w nagłówku. Jeżeli w linii nagłówka "separator:" jest umieszczony inny znak niż zawarty w liście legalnych separatorów, to dla programu przyjmującego przesyłkę, separatorem pozostaje znak tabulatora. Raport z przetwarzania CFD będzie miał ten sam separator który był zdefiniowany w zbiorze z transakcjami CFC. Pola opcjonalne mogą pozostać niewypełnione. Rok jest na kartach zapisywany w formie dwucyfrowej YY. Liczby YY mniejsze niż 60 oznaczają rok w XXI stuleciu, np. 09 oznacza rok Konwencja nazw zbiorów CFC-xxx.TXT CFD-xxx.TXT zbiory przychodzące do FDP (format cfc) zbiory wychodzące z FDP (format cfd) Format cfc, dane dla firmy rozliczeniowej (FDP) o transakcjach przeprowadzanych przy pomocy kart bankowych. 1. Skrót numeru karty, poprzedzony literą H bez żadnych znaków pomiędzy 2. Session_ID 3. Data transakcji (YYMMDD) 4. Kwota w groszach (tj. bez kropki/przecinka dziesiętnego oddzielającego pełne złote) 5. Wskaźnik określający rodzaj transakcji: Test/Production oraz Credit/Debit/Void - znak TC, TD, TV, PC, PD lub PV. Transakcje 'Production' mogą przesyłać jedynie punkty (sklepy), którym w FDP został nadany odpowiedni status. Transakcje z punktów, które nie mają statusu produkcyjnego, są traktowane jako transakcje testowe niezależnie od przesłanego wskaźnika P/T. Znaczenie znacznika C/V/D jest następujące: Transakcje D obciążają konto posiadacza karty, transakcje C uznają konto posiadacza karty kwotą zwrotu, transakcje V oznaczają transakcje, które były w sklepie autoryzowane, ale sklep z jakichś powodów (np.: niezgodności adresów wysyłki i posiadacza karty) nie będzie realizował zamówienia Kod Autoryzacji 7. Typ transakcji (I - Internet Order) 8. Order_ID Dostępne są przykłady: 1 Jeśli chcą Państwo dokonać zwrotu na kartę już rozliczonej transakcji, należy ją przedstawiać jako PC (odpowiednio TC dla transakcji testowych). Strona 16 z 22

17 Plik w formacie cfc z zadeklarowanym separatorem Plik w formacie cfc z domyślnym separatorem Format cfd, dane zwrotne z FDP Dane zwrotne mają ten sam format co dane przesłane do rozliczeń, z dokładnością do dwóch pól poprzedzających dane "formatu C". Wskazują one stan realizacji transakcji. Pole "Kod Autoryzacyjny" może być wypełnione przez FDP w wyniku realizacji transakcji. 1. Wskaźnik realizacji transakcji: T - transakcja przyjęta do rozliczenia, F - transakcja odrzucona, E - transakcja, w trakcie której wystąpił błąd systemu FDP (taki raport transakcji jest powodem do wszczęcia "procedury alarmowej"). 2. kod rozliczenia (patrz: możliwe kody rozliczenia) 3. Skrót numeru karty (poprzedzony litera 'H') 4. Session_ID 5. Data transakcji (YYMMDD) 6. Kwota w groszach (tj. bez kropki/przecinka dziesiętnego oddzielającego pełne złote) 7. Wskaźnik określający rodzaj transakcji: Test/Production/Credit/Debit - znak TC lub PC lub TD lub PD 8. Kod Autoryzacji 9. Typ transakcji (I dla transakcji Internetowych) 10. Order_ID Plik Plik Dostępne są przykłady: w formacie cfd z zadeklarowanym separatorem w formacie cfd z domyślnym separatorem Kody rozliczeń: Status Opis 00 OK., transakcja przyjęta do rozliczenia 01 Nie znaleziono pary session_id + pos_id + cc_hash (nie ma takiej transakcji) 02 Autoryzacja odmowna 03 Rezygnacja Kontrahenta z transakcji przyjęta przez FDP 04 Zbyt późne przedstawienie transakcji do rozliczenia 05 Kwota wyższa od kwoty autoryzacji 06 Transakcja była już rozliczona 07 Próba uznania do nierozliczonej transakcji 08 Kwota poniżej limitu dolnego transakcji Strona 17 z 22

18 Status Opis 09 Nieznany typ transakcji (nie Debit i nie Credit) 10 Brak daty autoryzacji 97 Cc_hash nie jest oznaczony jako hash (brak "H" na początku wiersza 98 Database update error. Przedstaw tę transakcję do rozliczenia później w kolejnym pliku batch. 99 Inny powód nie przyjęcia do rozliczenia, nieodwracalny Strona 18 z 22

19 Przykłady Formularz inicjujący zapytanie autoryzacyjne <FORM METHOD="POST" ACTION="https://post.polcard.com.pl/cgi-bin/autoryzacja.cgi"> <INPUT TYPE="HIDDEN" NAME="session_id" VALUE="A00123"> <INPUT TYPE="HIDDEN" NAME="order_id" VALUE="fak-43/12/98:bac"> <INPUT TYPE="HIDDEN" NAME="pos_id" VALUE="123456"> <INPUT TYPE="HIDDEN" NAME="amount" VALUE="2034"> <INPUT TYPE="HIDDEN" NAME="street" VALUE="Ostrobramska"> <INPUT TYPE="HIDDEN" NAME="street_n1" VALUE="103"> <INPUT TYPE="HIDDEN" NAME="street_n2" VALUE=""> <INPUT TYPE="HIDDEN" NAME="addr2" VALUE=""> <INPUT TYPE="HIDDEN" NAME="addr3" VALUE=""> <INPUT TYPE="HIDDEN" NAME="city" VALUE="Warszawa"> <INPUT TYPE="HIDDEN" NAME="postcode" VALUE="04-041"> <INPUT TYPE="HIDDEN" NAME="country" VALUE="PL"> <INPUT TYPE="HIDDEN" NAME="language" VALUE="PL"> <INPUT TYPE="HIDDEN" NAME=" " <INPUT TYPE="HIDDEN" NAME="test" VALUE="N"> <INPUT TYPE="SUBMIT" VALUE="Platnosc karta"> <FORM> Strona 19 z 22

20 Skrypt do obsługi rozliczeń #!/usr/bin/perl -w # kontrola certyfikatów wykonana przez warstwę SSL, jej rezultaty są dostępne w ENV unless ( $ENV{'SSL_CLIENT_VERIFY'} and ($ENV{'SSL_CLIENT_VERIFY'} eq 'SUCCESS') and ($ENV{'SSL_CLIENT_S_DN_O'} eq 'PolCard S.A.')) { and ($ENV{'SSL_CLIENT_S_DN_L'} eq 'WARSZAWA') and ($ENV{'SSL_CLIENT_S_DN_CN'} eq 'post.polcard.com.pl') and ($ENV{'SSL_CLIENT_S_DN_C'} eq 'PL') and ($ENV{'SSL_CLIENT_I_DN_O'} eq 'Thawte Consulting cc')) { and ($ENV{'SSL_CLIENT_I_DN_CN'} eq 'Thawte Server CA')) { and ($ENV{'SSL_CLIENT_I_DN_C'} eq 'ZA') exit; } else { # test czasu ważności prezentowanego certyfikatu klienta use = split / /, $ENV{'SSL_CLIENT_V_START'}; $tm = str2time("$f[1] $F[0] $F[3] $F[2] $F[4]") or exit; exit if ($tm > = split / /, $ENV{'SSL_CLIENT_V_END'}; $tm = str2time("$f[1] $F[0] $F[3] $F[2] $F[4]") or exit; exit if ($tm < time); } use CGI; $q = CGI->new; if (($filename = $q->param('clearing_report_file')) and ($filename =~ /^cfd/i)) { # w tej gałęzi, skrypt przyjmuje jeden raport CFD; tym zbiorem jest konkretnie # zawartosc parametru: CLEARING_REPORT_FILE, pozostałe parametry tego # formularza, to (duze litery sa tu użyte tylko dla wytłuszczenia): # - POS_ID - numer punktu sprzedaży (pochodzi z linii nagłówka TID zbiory CFC) # - BATCH - numer wysyłki, również pochodzi z nagłówka CFC. # Na koniec, ten skrypt musi zaznaczyć w bazach danych serwera, ze właśnie # odebrany zbiór CFD usuwa odpowiadający mu CFC z kolejki oczekujących na # wysłanie, co daje możliwość drugiej gałęzi tego skryptu, na wysłanie # kolejnego CFC przy następnym wywołaniu # poniższy tekst powinien pojawić się po zakończeniu odbierania pliku. print $q->header(-content_type => 'text/plain'); print "Received [$pos_id,$batch]\n"; # W przypadku wystąpienia błędów uniemożliwiających dalszą obslugę CFD, ta # część skryptu powinna brutalnie przerwać połączenie. } else { print $q->header(-type => "text/plain; charset=iso ", -content_transfer_encoding => "8bit"); # teraz, ten skrypt wysyła jeden, bieżący CFC. } Strona 20 z 22

Bezpieczne Zakupy. - specyfikacja techniczna implementacji uproszczonej

Bezpieczne Zakupy. - specyfikacja techniczna implementacji uproszczonej Bezpieczne Zakupy - specyfikacja techniczna implementacji uproszczonej P OL C AR D is a regis t e r e d t ra d e ma rk o f FI R S T D AT A P O L S K A S. A., FI RS T D AT A P O L S K A S. A., Al. J e roz

Bardziej szczegółowo

Specyfikacja 1.2.1. Płatności CashBill. Instrukcja podłączenia płatności elektronicznych do typowych zastosowań.

Specyfikacja 1.2.1. Płatności CashBill. Instrukcja podłączenia płatności elektronicznych do typowych zastosowań. Specyfikacja 1.2.1 Płatności CashBill Instrukcja podłączenia płatności elektronicznych do typowych zastosowań. CashBill Spółka Akcyjna ul. Rejtana 20, 41-300 Dąbrowa Górnicza Tel.: +48 032 764-18-42 Fax:

Bardziej szczegółowo

Specyfikacja instalacji usługi SMS Premium w Przelewy24.pl

Specyfikacja instalacji usługi SMS Premium w Przelewy24.pl Specyfikacja instalacji usługi SMS Premium w Przelewy24.pl wersja.2.9 data 2014-11-21 Opis usług: P24 KOD P24 KLUCZ P24 WAPA SEND SMS Strona 1 z 8 P24 KOD Przebieg transakcji Operacje po stronie Sprzedawcy

Bardziej szczegółowo

Dokumentacja smsapi wersja 1.4

Dokumentacja smsapi wersja 1.4 Dokumentacja smsapi wersja 1.4 1. Wprowadzenie Platforma smsapi została skierowana do użytkowników chcących rozbudować swoje aplikacje o system wysyłania smsów. Aplikacja ta w prosty sposób umożliwia integrację

Bardziej szczegółowo

Specyfikacja instalacji systemu Przelewy24.pl

Specyfikacja instalacji systemu Przelewy24.pl Specyfikacja instalacji systemu Przelewy24.pl Instalacja pełna wersja.2.64 data 2012-03-28 1 PRZEBIEG TRANSAKCJI... 2 2 TERMINOLOGIA... 3 3 OPROGRAMOWANIE... 3 3.1 Żądanie transakcji... 3 3.2 Odbiór wyniku

Bardziej szczegółowo

Integracja frameworku Wicket z serwisem Platnosci.pl.

Integracja frameworku Wicket z serwisem Platnosci.pl. Integracja frameworku Wicket z serwisem Platnosci.pl. Paweł Wąsowski, 157702 1. Wprowadzenie Niniejszy dokument powstał w trakcie realizacji projektu SzukamNeta.pl. Dokument zawiera praktyczne wskazówki

Bardziej szczegółowo

Implementacja mechanizmu SkyCashClick Wersja 0.1

Implementacja mechanizmu SkyCashClick Wersja 0.1 Implementacja mechanizmu SkyCashClick Wersja 0.1 SkyCash 1/6 Spis treści: 1. Opis usługi... 3 2. Osadzenie przycisku SkyCashClick... 4 2.1. Parametry transakcji... 4 2.2. Weryfikacja znacznika parametrów

Bardziej szczegółowo

Instrukcja obsługi aplikacji epay

Instrukcja obsługi aplikacji epay Instrukcja obsługi aplikacji epay Teleserwis PayTel Comp SA, Teleserwis PayTel ul. Działkowa 115a 02-234 Warszawa telefon: 58 660 10 66 faks: 58 660 10 67 email: teleserwis@paytel.pl Dział Obsługi Kontrahenta

Bardziej szczegółowo

Płatności CashBill - SOAP

Płatności CashBill - SOAP Dokumentacja techniczna 1.0 Płatności CashBill - SOAP Dokumentacja wdrożenia systemu Płatności CashBill w oparciu o komunikację według protokołu SOAP CashBill Spółka Akcyjna ul. Rejtana 20, 41-300 Dąbrowa

Bardziej szczegółowo

Struktura pliku wejściowego ipko biznes przelewy zagraniczne (MT103 / CSV)

Struktura pliku wejściowego ipko biznes przelewy zagraniczne (MT103 / CSV) Struktura pliku wejściowego ipko biznes przelewy zagraniczne (T103 / CSV) 1 Spis treści 1. Informacje ogólne... 3 2. Struktura pliku PLA/T103... 3 2.1. Opis formatu pliku... 3 2.2. Struktura pliku... 4

Bardziej szczegółowo

Opis usługi płatności masowych aktualnie zaimplementowanej u Zamawiającego

Opis usługi płatności masowych aktualnie zaimplementowanej u Zamawiającego Załącznik nr 5 do SIWZ Opis usługi płatności masowych aktualnie zaimplementowanej u Zamawiającego Zasada działania Funkcjonalność obsługi płatności masowych przychodzących oparta jest na najnowszych standardach

Bardziej szczegółowo

Przykładowa integracja systemu Transferuj.pl

Przykładowa integracja systemu Transferuj.pl Krajowy Integrator Płatności Spółka Akcyjna z siedzibą w Poznaniu, przy ul. Św. Marcin 73/6, wpisana do rejestru przedsiębiorców Krajowego Rejestru Sądowego prowadzonego przez Sąd Rejonowy Poznań Nowe

Bardziej szczegółowo

Specyfikacja Techniczna 2.0. Specyfikacja techniczna usługi dystrybucji kodów dostępowych PayCode

Specyfikacja Techniczna 2.0. Specyfikacja techniczna usługi dystrybucji kodów dostępowych PayCode Specyfikacja Techniczna 2.0 PayCode API Specyfikacja techniczna usługi dystrybucji kodów dostępowych PayCode CashBill Spółka Akcyjna ul. Rejtana 20, 41-300 Dąbrowa Górnicza Tel.: +48 032 764-18-42 Fax:

Bardziej szczegółowo

Załącznik nr 2 do Umowy Nr. o korzystanie z usługi Identyfikacji Przychodzących Płatności Masowych z dnia.

Załącznik nr 2 do Umowy Nr. o korzystanie z usługi Identyfikacji Przychodzących Płatności Masowych z dnia. Załącznik nr 2 do Umowy Nr. o korzystanie z usługi Identyfikacji Przychodzących Płatności Masowych z dnia. Informacja o strukturze pliku, przekazywanego przez Bank dla Klienta za pośrednictwem systemu

Bardziej szczegółowo

Wdrożenie modułu płatności eservice. dla systemu Zen Cart 1.3.9 1.5

Wdrożenie modułu płatności eservice. dla systemu Zen Cart 1.3.9 1.5 Wdrożenie modułu płatności eservice dla systemu Zen Cart 1.3.9 1.5 - dokumentacja techniczna Wer. 01 Warszawa, styczeń 2014 1 Spis treści: 1 Wstęp... 3 1.1 Przeznaczenie dokumentu... 3 1.2 Przygotowanie

Bardziej szczegółowo

Rozrachunki Optivum. Jak korzystać z funkcji płatności masowe?

Rozrachunki Optivum. Jak korzystać z funkcji płatności masowe? Rozrachunki Optivum Jak korzystać z funkcji płatności masowe? Program Rozrachunki Optivum umożliwia import wyciągów bankowych w formie elektronicznej. Import jest możliwy w jednym z poniższych formatów:

Bardziej szczegółowo

Struktura pliku wejściowego ipko biznes PLA/MT103

Struktura pliku wejściowego ipko biznes PLA/MT103 Struktura pliku wejściowego ipko biznes PLA/T103 1 1. Informacje ogólne Niniejszy dokument w sposób szczegółowy opisuje strukturę pliku PLA/T103, czyli standardowego formatu plików elektronicznych, za

Bardziej szczegółowo

Polecenie zapłaty w ING BankOnLine

Polecenie zapłaty w ING BankOnLine Usługa Polecenie zapłaty w ING BankOnLine (obsługa polecenia zapłaty przez Dłużnika / Płatnika) Polecenie zapłaty to wygodna, całkowicie bezpieczna i szybka forma regulowania powtarzających się płatności.

Bardziej szczegółowo

DOKUMENTACJA TECHNICZNA SMS API MT

DOKUMENTACJA TECHNICZNA SMS API MT DOKUMENTACJA TECHNICZNA SMS API MT Mobitex Telecom Sp.j., ul. Warszawska 10b, 05-119 Legionowo Strona 1 z 5 Ten dokument zawiera szczegółowe informacje odnośnie sposobu przesyłania requestów do serwerów

Bardziej szczegółowo

Zakład Usług Informatycznych OTAGO

Zakład Usług Informatycznych OTAGO Zakład Usług Informatycznych OTAGO Opis konstrukcji Wirtualnego Numeru Rachunku dotyczący płatności masowych wersja 1.4 autor: Tomasz Rosochacki Gdańsk, 2012-11-27 Spis treści 1. Wprowadzenie.... 3 2.

Bardziej szczegółowo

Struktura pliku wejściowego ipko biznes ELIXIR - O

Struktura pliku wejściowego ipko biznes ELIXIR - O Struktura pliku wejściowego ipko biznes ELIXIR - O 1 1. Informacje ogólne Niniejszy dokument w sposób szczegółowy opisuje strukturę pliku ELIXIR, czyli standardowego formatu plików elektronicznych, za

Bardziej szczegółowo

Usługa Moje faktury w ING BankOnLine

Usługa Moje faktury w ING BankOnLine Usługa Moje faktury w ING BankOnLine Usługa Moje faktury to nowoczesny sposób płatności za faktury/rachunki poprzez system bankowości internetowej ING BankOnLine. Możesz zastąpić tradycyjne papierowe faktury

Bardziej szczegółowo

Instrukcja dla użytkownika korzystającego z Usługi Moje faktury

Instrukcja dla użytkownika korzystającego z Usługi Moje faktury Instrukcja dla użytkownika korzystającego z Usługi Moje faktury Usługa Moje faktury to nowoczesny sposób płatności za faktury/rachunki poprzez system bankowości internetowej ING BankOnLine. Możesz zastąpić

Bardziej szczegółowo

Wdrożenie modułu płatności eservice. dla systemu oscommerce 2.3.x

Wdrożenie modułu płatności eservice. dla systemu oscommerce 2.3.x Wdrożenie modułu płatności eservice dla systemu oscommerce 2.3.x - dokumentacja techniczna Wer. 01 Warszawa, styczeń 2014 1 Spis treści: 1 Wstęp... 3 1.1 Przeznaczenie dokumentu... 3 1.2 Przygotowanie

Bardziej szczegółowo

Opis formatu pliku wyciągów MT940 Ver. 2007-12-05

Opis formatu pliku wyciągów MT940 Ver. 2007-12-05 Opis formatu pliku wyciągów MT940 Ver. 2007-12-05 1 Ogólne informacje o pliku wyciągów MT940 Dokument opisuje format pliku wyciągów elektronicznych MT940 używanego do importu sald i historii operacji do

Bardziej szczegółowo

Instrukcja użytkownika. Aplikacja dla Comarch ERP XL

Instrukcja użytkownika. Aplikacja dla Comarch ERP XL Instrukcja użytkownika Aplikacja dla Comarch ERP XL Instrukcja użytkownika Aplikacja dla Comarch ERP XL Wersja 1.0 Warszawa, Listopad 2015 Strona 2 z 12 Instrukcja użytkownika Aplikacja dla Comarch ERP

Bardziej szczegółowo

Podręcznik Użytkownika ING BankOnLine z funkcjonalnością Modułu Użytkowników

Podręcznik Użytkownika ING BankOnLine z funkcjonalnością Modułu Użytkowników ING BankOnLine z funkcjonalnością Modułu Użytkowników obowiązuje dla Klientów z segmentu małych firm Spis treści Podręcznik Użytkownika... 1 I. Słownik... 3 II. Udostępnienie systemu ING BankOnLine z funkcjonalnością

Bardziej szczegółowo

Języki programowania wysokiego poziomu. PHP cz.3. Formularze

Języki programowania wysokiego poziomu. PHP cz.3. Formularze Języki programowania wysokiego poziomu PHP cz.3. Formularze Formularze Sposób przesyłania danych formularza do serwera zależy od wybranej metody HTTP: Metoda GET

Bardziej szczegółowo

Wdrożenie modułu płatności eservice. dla systemu Magento 1.4 1.9

Wdrożenie modułu płatności eservice. dla systemu Magento 1.4 1.9 Wdrożenie modułu płatności eservice dla systemu Magento 1.4 1.9 - dokumentacja techniczna Wer. 01 Warszawa, styczeń 2014 1 Spis treści: 1 Wstęp... 3 1.1 Przeznaczenie dokumentu... 3 1.2 Przygotowanie do

Bardziej szczegółowo

Instrukcja użytkownika. Aplikacja dla WF-Mag

Instrukcja użytkownika. Aplikacja dla WF-Mag Instrukcja użytkownika Aplikacja dla WF-Mag Instrukcja użytkownika Aplikacja dla WF-Mag Wersja 1.0 Warszawa, Kwiecień 2015 Strona 2 z 13 Instrukcja użytkownika Aplikacja dla WF-Mag Spis treści 1. Wstęp...4

Bardziej szczegółowo

BusinessNet Opis formatu pliku eksportu wyciągów dziennych STA

BusinessNet Opis formatu pliku eksportu wyciągów dziennych STA BusinessNet Opis formatu pliku eksportu wyciągów dziennych STA Wersja 2009-09-29 BANKOWOŚĆ ELEKTRONICZNA SPIS TREŚCI 1. Opis formatu pliku STA 3 1.1 Ogólne informacje o pliku STA 3 1.1.1 Co to jest plik

Bardziej szczegółowo

Wdrożenie modułu płatności eservice. dla systemu Gekosale 1.4

Wdrożenie modułu płatności eservice. dla systemu Gekosale 1.4 Wdrożenie modułu płatności eservice dla systemu Gekosale 1.4 - dokumentacja techniczna Wer. 01 Warszawa, styczeń 2014 1 Spis treści: 1 Wstęp... 3 1.1 Przeznaczenie dokumentu... 3 1.2 Przygotowanie do integracji...

Bardziej szczegółowo

Instrukcja użytkownika. Aplikacja dla Comarch Optima

Instrukcja użytkownika. Aplikacja dla Comarch Optima Instrukcja użytkownika Aplikacja dla Comarch Optima Instrukcja użytkownika Aplikacja dla Comarch Optima Wersja 1.0 Warszawa, Sierpień 2015 Strona 2 z 12 Instrukcja użytkownika Aplikacja dla Comarch Optima

Bardziej szczegółowo

Instrukcja użytkownika. Aplikacja dla Comarch Optima

Instrukcja użytkownika. Aplikacja dla Comarch Optima Instrukcja użytkownika Aplikacja dla Comarch Optima Instrukcja użytkownika Aplikacja dla Comarch Optima Wersja 1.1 Warszawa, Luty 2016 Strona 2 z 14 Instrukcja użytkownika Aplikacja dla Comarch Optima

Bardziej szczegółowo

PODRĘCZNIK OBSŁUGI BUSINESSNET

PODRĘCZNIK OBSŁUGI BUSINESSNET PODRĘCZNIK OBSŁUGI BUSINESSNET. LOGOWANIE. AUTORYZACJA ZLECENIA. NOWY KLUCZ. PRZELEWY 5. ZLECENIA STAŁE 6. MODUŁ PRAWNY 7. DOSTĘP DO DEALINGNET 8. CERTYFIKAT KWALIFIKOWANY JAK ZALOGOWAĆ SIĘ DO BUSINESSNET

Bardziej szczegółowo

POLITYKA PRYWATNOŚCI

POLITYKA PRYWATNOŚCI POLITYKA PRYWATNOŚCI 1. Postanowienia ogólne. Niniejszy dokument stanowi politykę prywatności spółki Cyfrowe Centrum Serwisowe S.A. z siedzibą w Piasecznie, adres: ul. Puławska 40A (kod pocztowy: 05-500),

Bardziej szczegółowo

System epon Dokumentacja użytkownika

System epon Dokumentacja użytkownika System epon Dokumentacja użytkownika Prawa autorskie tego opracowania należą do MakoLab S.A. Dokument ten, jako całość, ani żadna jego część, nie może być reprodukowana lub rozpowszechniana w jakiejkolwiek

Bardziej szczegółowo

Wdrożenie modułu płatności eservice. dla systemu Virtuemart 1.1.x - 2.0.x

Wdrożenie modułu płatności eservice. dla systemu Virtuemart 1.1.x - 2.0.x Wdrożenie modułu płatności eservice dla systemu Virtuemart 1.1.x - 2.0.x - dokumentacja techniczna Wer. 01 Warszawa, styczeń 2014 1 Spis treści: 1 Wstęp... 3 1.1 Przeznaczenie dokumentu... 3 1.2 Przygotowanie

Bardziej szczegółowo

Instrukcja obsługi aplikacji Karty Pojazdów dla Dealerów Samochodowych

Instrukcja obsługi aplikacji Karty Pojazdów dla Dealerów Samochodowych Instrukcja obsługi aplikacji Karty Pojazdów dla Dealerów Samochodowych ver. 0.6 1 Instalacja 1. Proces instalacji należy rozpocząć od sprawdzenia, czy w systemie MS Windows jest zainstalowana aplikacja

Bardziej szczegółowo

Dokument opisuje sposób postępowania prowadzący do wysłania deklaracji VAT, PIT lub CIT drogą elektroniczną za pomocą funkcji systemu ADA modułu FK.

Dokument opisuje sposób postępowania prowadzący do wysłania deklaracji VAT, PIT lub CIT drogą elektroniczną za pomocą funkcji systemu ADA modułu FK. FK - EDeklaracje Dokument opisuje sposób postępowania prowadzący do wysłania deklaracji VAT, PIT lub CIT drogą elektroniczną za pomocą funkcji systemu ADA modułu FK. W założeniu przyjęto, iż użytkownik

Bardziej szczegółowo

Struktura pliku wejściowego ipko biznes ELIXIR-O

Struktura pliku wejściowego ipko biznes ELIXIR-O Struktura pliku wejściowego ipko biznes ELIXIR-O SPIS TREŚCI INFORACJE OGÓLNE... 3 STRUKTURA PLIKU... 3 STRUKTURA FORATU... 4 Przelew do ZUS... 5 Przelew do US... 6 Polecenie zapłaty... 6 Przykłady zleceń...

Bardziej szczegółowo

Wdrożenie modułu płatności eservice. dla systemu PrestaShop 1.3-1.6

Wdrożenie modułu płatności eservice. dla systemu PrestaShop 1.3-1.6 Wdrożenie modułu płatności eservice dla systemu PrestaShop 1.3-1.6 - dokumentacja techniczna Wer. 02 Warszawa, lipiec 2014 1 Spis treści: 1 Wstęp... 3 1.1 Przeznaczenie dokumentu... 3 1.2 Przygotowanie

Bardziej szczegółowo

Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP

Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP Warszawa, lipiec 2012 Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP Wersja 1.1 1 Spis treści Tabela zmian... 3 Wstęp... 4 Budowa komunikatów XML... 4 Przestrzenie nazw

Bardziej szczegółowo

WPROWADZANIE ZLECEŃ POPRZEZ STRONĘ WWW.KACZMARSKI.PL INSTRUKCJA UŻYTKOWNIKA

WPROWADZANIE ZLECEŃ POPRZEZ STRONĘ WWW.KACZMARSKI.PL INSTRUKCJA UŻYTKOWNIKA WPROWADZANIE ZLECEŃ POPRZEZ STRONĘ WWW.KACZMARSKI.PL INSTRUKCJA UŻYTKOWNIKA WSTĘP... 2 1 UWARUNKOWANIA TECHNICZNE... 2 2 UWARUNKOWANIA FORMALNE... 2 3 LOGOWANIE DO SERWISU... 2 4 WIDOK STRONY GŁÓWNEJ...

Bardziej szczegółowo

Struktura pliku wejściowego ipko biznes ELIXIR-O

Struktura pliku wejściowego ipko biznes ELIXIR-O Struktura pliku wejściowego ipko biznes ELIXIR-O SPIS TREŚCI INFORACJE OGÓLNE... 3 STRUKTURA PLIKU... 3 STRUKTURA FORATU... 4 Przelew do ZUS... 5 Przelew do US... 6 Przykłady przelewów... 6 Infolinia (pn.

Bardziej szczegółowo

Konfiguracja programu MS Outlook 2007 dla poczty w hostingu Sprint Data Center

Konfiguracja programu MS Outlook 2007 dla poczty w hostingu Sprint Data Center Konfiguracja programu MS Outlook 2007 dla poczty w hostingu Sprint Data Center Spis treści Konfiguracja Microsoft Outlook 2007... 3 Konfiguracja dla POP3... 7 Konfiguracja dla IMAP... 11 Sprawdzenie poprawności

Bardziej szczegółowo

Instrukcja importu przesyłek. z Menedżera Sprzedaży do aplikacji Webklient

Instrukcja importu przesyłek. z Menedżera Sprzedaży do aplikacji Webklient Instrukcja importu przesyłek z Menedżera Sprzedaży do aplikacji Webklient Instrukcja importu przesyłek z Menedżera Sprzedaży do aplikacji Webklient Wersja 1.0 Warszawa, Luty 2015 Strona 2 z 7 Instrukcja

Bardziej szczegółowo

Instrukcja podłączenia transakcji Premium SMS przez Sprzedawcę

Instrukcja podłączenia transakcji Premium SMS przez Sprzedawcę Instrukcja podłączenia transakcji Premium SMS przez Sprzedawcę Podłączenie transakcji Premium SMS w witrynie internetowej Sprzedawcy przebiega następująco : 1. Należy zalogować się do panelu klienta w

Bardziej szczegółowo

Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc

Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc Warszawa, 07 lutego 2013 Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc Wersja 1.4.2 1 Spis treści Tabela zmian... 3 Wstęp... 4 Budowa komunikatów XML... 4 Przestrzenie nazw (namespaces)...

Bardziej szczegółowo

"Procedura obsługi certyfikatów dla KDPW_TR (A2A)"

Procedura obsługi certyfikatów dla KDPW_TR (A2A) "Procedura obsługi certyfikatów dla KDPW_TR (A2A)" Wersja 1.0 Spis treści Dostęp do Repozytorium transakcji KDPW_TR w trybie A2A... 3 Wymagania systemowe... 4 Wniosek certyfikacyjny... 5 Status zgłoszenia

Bardziej szczegółowo

mbank CompanyNet, BRESOK Struktura zbioru importu w formacie BRESOK2

mbank CompanyNet, BRESOK Struktura zbioru importu w formacie BRESOK2 mbank CompanyNet, BRESOK Struktura zbioru importu w formacie BRESOK2 Bankowość Elektroniczna dla klientów korporacyjnych i MSP Wersja 1.0, 25-11-2013 r. 1. Opis formatu BRESOK2 Zbiór jest jednym ciągiem

Bardziej szczegółowo

Podręcznik użytkownika

Podręcznik użytkownika Podręcznik użytkownika Centrum rozliczeniowe UPS 2015 United Parcel Service of America, Inc. Nazwa UPS, marka UPS i kolor brązowy są znakami towarowymi firmy United Parcel Service of America, Inc. Wszelkie

Bardziej szczegółowo

Integracja sklepu internetowego z serwisem aukcyjnym Swistak.pl

Integracja sklepu internetowego z serwisem aukcyjnym Swistak.pl Integracja sklepu internetowego z serwisem aukcyjnym Swistak.pl email: swistak@swistak.pl Spis treści 1. Wstęp...2 2. Import oferty...2 3. Plik CSV...3 4. Przykład pliku...7 5. Aktualizacja oferty...7

Bardziej szczegółowo

REGULAMIN PRZESYŁANIA FAKTUR W FORMIE ELEKTRONICZNEJ

REGULAMIN PRZESYŁANIA FAKTUR W FORMIE ELEKTRONICZNEJ REGULAMIN PRZESYŁANIA FAKTUR W FORMIE ELEKTRONICZNEJ 1 Podstawa prawna Podstawą prawną przesyłania faktur w formie elektronicznej jest Ustawa z dnia 11 marca 2004 roku o podatku od towarów i usług (Dz.U.

Bardziej szczegółowo

Dokument zawiera specyfikację techniczną instalacji systemu płatności Przelewy24.

Dokument zawiera specyfikację techniczną instalacji systemu płatności Przelewy24. Przelewy24 Specyfikacja techniczna instalacji Data: 2014-04-04 Wersja: 3.1 Dokument zawiera specyfikację techniczną instalacji systemu płatności Przelewy24. Strona 1 z 12 1 Przebieg transakcji Operacje

Bardziej szczegółowo

Instrukcja Użytkownika Systemu Zarządzania Tożsamością Wersja. 1.0

Instrukcja Użytkownika Systemu Zarządzania Tożsamością Wersja. 1.0 Instrukcja Użytkownika Systemu Zarządzania Tożsamością Wersja. 1.0 1 SPIS TREŚCI 1. Wstęp... 3 2. Strona logowania do Systemu Zarządzania Tożsamością... 3 3. Pierwsze logowanie do systemu... 4 4. Logowanie

Bardziej szczegółowo

REGULAMIN dla konsumentów. 1 Postanowienia ogólne

REGULAMIN dla konsumentów. 1 Postanowienia ogólne REGULAMIN dla konsumentów 1 Postanowienia ogólne 1. Internetowy sklep www.matbud.pl prowadzony jest przez Kazimierz Kula prowadzącego działalność gospodarczą pod nazwą MATBUD MATERIAŁY BUDOWLANE, zarejestrowaną

Bardziej szczegółowo

REGULAMIN USŁUGI PŁATNOŚCI ELEKTRONICZNYCH

REGULAMIN USŁUGI PŁATNOŚCI ELEKTRONICZNYCH REGULAMIN USŁUGI PŁATNOŚCI ELEKTRONICZNYCH Niniejszy regulamin przeznaczony jest dla podmiotów, które zawarły z PayU umowę o korzystanie z Systemu na warunkach określonych przez PayU w Regulaminie Systemu.

Bardziej szczegółowo

Wdrożenie modułu płatności eservice dla systemu PrestaShop 1.3-1.6

Wdrożenie modułu płatności eservice dla systemu PrestaShop 1.3-1.6 Wdrożenie modułu płatności eservice dla systemu PrestaShop 1.3-1.6 Wersja 03 Styczeń 2016 Centrum Elektronicznych Usług Płatniczych eservice Sp. z o.o. Spis treści 1. Wstęp... 3 1.1. Przeznaczenie dokumentu...

Bardziej szczegółowo

Spis treści OPIS PLIKU W FORMACIE CSV Z DANYMI PPE LUB EP 1

Spis treści OPIS PLIKU W FORMACIE CSV Z DANYMI PPE LUB EP 1 O PIS PLIKU W F O R M A C I E CSV Z D A N Y M I PRZEKAZÓW PIENIĘŻNYCH L U B E K S PRESÓW PIENIĘŻNYCH D O K U M E N T A C J A T E C H N I C Z N A W E R S J A 4.0 L I P I E C 2 0 1 4 Spis treści 1. Struktura

Bardziej szczegółowo

API transakcyjne BitMarket.pl

API transakcyjne BitMarket.pl API transakcyjne BitMarket.pl Wersja 20140402 1. Sposób łączenia się z API... 2 1.1. Klucze API... 2 1.2. Podpisywanie wiadomości... 2 1.3. Parametr tonce... 2 1.4. Limity zapytań... 3 1.5. Odpowiedzi

Bardziej szczegółowo

Instrukcja do programu Do7ki 1.0

Instrukcja do programu Do7ki 1.0 Instrukcja do programu Do7ki 1.0 Program Do7ki 1.0 pozwala w prosty sposób wykorzystać dane z systemu sprzedaży Subiekt GT do generowania listów przewozowych dla firmy kurierskiej SIÓDEMKA w połączeniu

Bardziej szczegółowo

Przelewy24. Specyfikacja techniczna instalacji. Przelewy24 Specyfikacja techniczna instalacji. Data: 2014-06-03 Wersja: 3.2

Przelewy24. Specyfikacja techniczna instalacji. Przelewy24 Specyfikacja techniczna instalacji. Data: 2014-06-03 Wersja: 3.2 Przelewy24 Specyfikacja techniczna instalacji Data: 2014-06-03 Wersja: 3.2 Dokument zawiera specyfikację techniczną instalacji systemu płatności Przelewy24. Strona 1 z 15 Indeks Indeks... 2 1 Przebieg

Bardziej szczegółowo

Automater.pl zdalne tworzenie i zarządzanie transakcjami dokumentacja API wersja 0.1

Automater.pl zdalne tworzenie i zarządzanie transakcjami dokumentacja API wersja 0.1 Dokumentacja API 0.1 Automater.pl zdalne tworze i zarządza transakcjami dokumentacja API wersja 0.1 Automater sp. z o.o., ul. Belgradzka 4/42, 02-793 Warszawa 2 1. Wstęp System Automater.pl udostępnia

Bardziej szczegółowo

Internet Banking- -aktywacja usługi Bilix/Invooboll

Internet Banking- -aktywacja usługi Bilix/Invooboll Novum Bank Enterprise NOE Internet Banking- -aktywacja usługi Bilix/Invooboll Podręcznik użytkownika wersja 001 1. Jak uaktywnić usługę BILIX/Invoobill w banku BILIX to usługa ułatwiająca szybkie i wygodne

Bardziej szczegółowo

Gatesms.eu Mobilne Rozwiązania dla biznesu

Gatesms.eu Mobilne Rozwiązania dla biznesu Mobilne Rozwiązania dla biznesu SPECYFIKACJA TECHNICZNA WEB API-USSD GATESMS.EU wersja 0.9 Opracował: Gatesms.eu Spis Historia wersji dokumentu...3 Bezpieczeństwo...3 Wymagania ogólne...3 Mechanizm zabezpieczenia

Bardziej szczegółowo

Instrukcja do programu DoDHL 1.5

Instrukcja do programu DoDHL 1.5 Instrukcja do programu DoDHL 1.5 Program DoDHL 1.5 pozwala w prosty sposób wykorzystać dane z systemu sprzedaży Subiekt GT do generowania listów przewozowych dla firmy kurierskiej DHL w połączeniu z bezpłatnym

Bardziej szczegółowo

Pawel@Kasprowski.pl Języki skryptowe - PHP. PHP i bazy danych. Paweł Kasprowski. pawel@kasprowski.pl. vl07

Pawel@Kasprowski.pl Języki skryptowe - PHP. PHP i bazy danych. Paweł Kasprowski. pawel@kasprowski.pl. vl07 PHP i bazy danych Paweł Kasprowski pawel@kasprowski.pl Użycie baz danych Bazy danych używane są w 90% aplikacji PHP Najczęściej jest to MySQL Funkcje dotyczące baz danych używają języka SQL Przydaje się

Bardziej szczegółowo

SET (Secure Electronic Transaction)

SET (Secure Electronic Transaction) SET (Secure Electronic Transaction) Krzysztof Maćkowiak Wprowadzenie SET (Secure Electronic Transaction) [1] to protokół bezpiecznych transakcji elektronicznych. Jest standardem umożliwiający bezpieczne

Bardziej szczegółowo

Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP

Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP Załącznik Nr 3 KDPW_CCP Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP Wersja 1.0 Warszawa, czerwiec 2012 Spis treści Wstęp... 3 Budowa komunikatów XML... 3 Przestrzenie

Bardziej szczegółowo

1.2 Prawa dostępu - Role

1.2 Prawa dostępu - Role Portlet Użytkownik Login Uprawnienie Rola Kontekst podmiotu Okno w serwisie portalu, udostępniające konkretne usługi lub informacje, na przykład kalendarz lub wiadomości Jest to osoba korzystająca z funkcjonalności

Bardziej szczegółowo

I. Interfejs użytkownika.

I. Interfejs użytkownika. Ćwiczenia z użytkowania systemu MFG/PRO 1 I. Interfejs użytkownika. MFG/PRO w wersji eb2 umożliwia wybór użytkownikowi jednego z trzech dostępnych interfejsów graficznych: a) tekstowego (wybór z menu:

Bardziej szczegółowo

Ministerstwo Finansów

Ministerstwo Finansów Ministerstwo Finansów System e-deklaracje Instrukcja użytkownika Wersja 1.00 1/21 SPIS TREŚCI I. INFORMACJE OGÓLNE...3 WYMAGANIA NIEZBĘDNE DO SKŁADANIA DEKLARACJI ZA POMOCĄ INTERAKTYWNYCH FORMULARZY...3

Bardziej szczegółowo

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym PrestaShop (plugin dostępny w wersji ecommerce)

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym PrestaShop (plugin dostępny w wersji ecommerce) emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym PrestaShop (plugin dostępny w wersji ecommerce) Zastosowanie Rozszerzenie to dedykowane jest sklepom internetowych zbudowanym w oparciu

Bardziej szczegółowo

PODRĘCZNIK OBSŁUGI BUSINESSNET

PODRĘCZNIK OBSŁUGI BUSINESSNET PODRĘCZNIK OBSŁUGI BUSINESSNET. LOGOWANIE. AUTORYZACJA ZLECENIA. NOWY KLUCZ. PRZELEWY 5. ZLECENIA STAŁE 6. MODUŁ PRAWNY 7. DOSTĘP DO DEALINGNET 8. ANKIETA MIFID 9. CERTYFIKAT KWALIFIKOWANY JAK ZALOGOWAĆ

Bardziej szczegółowo

Rekomendacja Związku Banków Polskich dotycząca kodu dwuwymiarowego ( 2D ), umożliwiającego realizację polecenia przelewu oraz aktywację usług

Rekomendacja Związku Banków Polskich dotycząca kodu dwuwymiarowego ( 2D ), umożliwiającego realizację polecenia przelewu oraz aktywację usług Rekomendacja Związku Banków Polskich dotycząca kodu dwuwymiarowego ( 2D ), umożliwiającego realizację polecenia przelewu oraz aktywację usług bankowych na rynku polskim - wersja 1.0 Warszawa, grudzień

Bardziej szczegółowo

Dokumentacja Użytkownika Systemu. Integracja z Okazje.info, Skąpiec, Sklepy24

Dokumentacja Użytkownika Systemu. Integracja z Okazje.info, Skąpiec, Sklepy24 Dokumentacja Użytkownika Systemu Integracja z Okazje.info, Skąpiec, Sklepy24 Wersja 2016 Spis treści 1 INTEGRACJA... 3 2 REJESTRACJA... 4 2.1 OKAZJE.INFO... 4 2.2 SKĄPIEC... 4 2.3 SKLEPY24.PL... 4 3 KONFIGURACJA...

Bardziej szczegółowo

System Doładowania e-karty przez Internet (SDK) Podręcznik użytkownika

System Doładowania e-karty przez Internet (SDK) Podręcznik użytkownika System Doładowania e-karty przez Internet (SDK) Podręcznik użytkownika Strona 1 z 9 1 Portal użytkowników. Portal SDK to system umożliwiający użytkownikom tarnowskiej karty miejskiej uzyskanie informacji

Bardziej szczegółowo

Paczki przelewów w ING BankOnLine

Paczki przelewów w ING BankOnLine Paczki przelewów w ING BankOnLine Aby rozpocząć proces tworzenia paczki w usłudze ING BankOnLine naleŝy wybrać opcję Przelewy => Przelewy (1) => Paczki przelewów (2). Funkcjonalność paczek przelewów umoŝliwia

Bardziej szczegółowo

System Bankowości Internetowej ABS 24 - AUTORYZACJA za pośrednictwem kodów SMS -

System Bankowości Internetowej ABS 24 - AUTORYZACJA za pośrednictwem kodów SMS - System Bankowości Internetowej ABS 24 - AUTORYZACJA za pośrednictwem kodów SMS - Zakres usług świadczonych w ramach Systemu Bankowości Internetowej ABS 24 I Informacje o rachunku 1. Podstawowe informacje

Bardziej szczegółowo

Elektroniczna Skrzynka Podawcza

Elektroniczna Skrzynka Podawcza Elektroniczna Skrzynka Podawcza Instrukcja dla administratora Wersja 1.6.0 Przewodnik przeznaczony jest dla użytkowników, którzy administrują kontem urzędu w systemie Elektronicznej Skrzynki Podawczej.

Bardziej szczegółowo

INSTRUKCJA OBSŁUGI SERWISU ALLPAY.PL. 1. Płatności internetowe

INSTRUKCJA OBSŁUGI SERWISU ALLPAY.PL. 1. Płatności internetowe INSTRUKCJA OBSŁUGI SERWISU ALLPAY.PL 1. Płatności internetowe 1.1 Transakcje 1.2 Kody dostępu 1.3 Wypłata 2. Serwisy 2.1 Usługi sms 2.2 Transakcje sms 2.3 Wypłata 3. Pobierz 3.1 Dokumentacje 3.2 Niezbędne

Bardziej szczegółowo

Format wymiany danych za pomocą szablonu Multicash. dla posiadaczy Rachunku dla firm Plus Adm. korzystających z systemu ipkonet

Format wymiany danych za pomocą szablonu Multicash. dla posiadaczy Rachunku dla firm Plus Adm. korzystających z systemu ipkonet Format wymiany danych za pomocą szablonu Multicash dla posiadaczy Rachunku dla firm Plus Adm. korzystających z systemu ipkonet SPIS TREŚCI 1. YMAGANIA DOTYCZĄCE PLIKU... 3 2. PROADZANIE ZLECEŃ... 3 3.

Bardziej szczegółowo

Zakład Komunikacji Miejskiej w Gdańsku Sp. z o.o.

Zakład Komunikacji Miejskiej w Gdańsku Sp. z o.o. Nr post. 104/210/KW/2013 Zakład Komunikacji Miejskiej w Gdańsku Sp. z o.o. 80-252 Gdańsk, ul. Jaśkowa Dolina 2 zarejestrowana w Sądzie Rejonowym Gdańsk-Północ w Gdańsku VII Wydział Gospodarczy Krajowego

Bardziej szczegółowo

DOKUMENTACJA INTERFEJSU API - HTTPS

DOKUMENTACJA INTERFEJSU API - HTTPS DOKUMENTACJA INTERFEJSU API - HTTPS WERSJA 0.1 DATA PUBLIKACJI : 01.03.2014 SPIS TREŚCI Spis treści Wprowadzenie 1 Dostęp do usługi notowania online 2 Opis struktur danych 3 Kody błędów 5 Historia wersji

Bardziej szczegółowo

INSTRUKCJA MASOWEGO WYSTAWIANIA OFERT ZA POMOCĄ PLIKU CSV

INSTRUKCJA MASOWEGO WYSTAWIANIA OFERT ZA POMOCĄ PLIKU CSV INSTRUKCJA MASOWEGO WYSTAWIANIA OFERT ZA POMOCĄ PLIKU CSV 1. Wymiana danych za pomocą pliku CSV umożliwia jednoczesne wystawienie do 100.000 ofert sprzedaży wierzytelności. 2. Za pomocą pliku CSV można

Bardziej szczegółowo

REGULAMIN SKLEPU INTERNETOWEGO DR GIFT

REGULAMIN SKLEPU INTERNETOWEGO DR GIFT REGULAMIN SKLEPU INTERNETOWEGO DR GIFT Prosimy zapoznaj się z naszym regulaminem. Znajdziesz tu ciekawe i przydatne informacje, jak wygląda zamawianie w naszym sklepie. Wszystko napisane jest prostym i

Bardziej szczegółowo

1. Sklep internetowy Fabryka Snu działa za pośrednictwem witryny internetowej w domenie www.fabrykasnu.info.pl.

1. Sklep internetowy Fabryka Snu działa za pośrednictwem witryny internetowej w domenie www.fabrykasnu.info.pl. REGULAMIN SKLEPU 1. Sklep internetowy Fabryka Snu działa za pośrednictwem witryny internetowej w domenie www.fabrykasnu.info.pl. Składanie zamówień może się odbywać przez 24 godziny na dobę za pomocą strony

Bardziej szczegółowo

Aplikacje internetowe - laboratorium

Aplikacje internetowe - laboratorium Aplikacje internetowe - laboratorium PHP Celem ćwiczenia jest przygotowanie prostej aplikacji internetowej opartej o język PHP. Aplikacja ilustruje takie mechanizmy jak: obsługa formularzy oraz obsługa

Bardziej szczegółowo

Program dla praktyki lekarskiej

Program dla praktyki lekarskiej Program dla praktyki lekarskiej ErLab Instrukcja konfiguracji i obsługi Spis Treści 1. Wstęp... 2 2. Konfiguracja... 3 2.1. Serwer... 3 2.2. Laboratorium... 3 2.3. Punkt pobrań... 4 3. Wysyłanie skierowania...

Bardziej szczegółowo

Symfonia Faktura. Zakładanie nowej firmy. Wersja 2013

Symfonia Faktura. Zakładanie nowej firmy. Wersja 2013 Symfonia Faktura Zakładanie nowej firmy Wersja 2013 Windows jest znakiem towarowym firmy Microsoft Corporation. Adobe, Acrobat, Acrobat Reader, Acrobat Distiller są zastrzeżonymi znakami towarowymi firmy

Bardziej szczegółowo

Instrukcja instalacji skryptu Zaufane Opinie (OSTATNIA MODYFIKACJA 2014.03.31)

Instrukcja instalacji skryptu Zaufane Opinie (OSTATNIA MODYFIKACJA 2014.03.31) Instrukcja instalacji skryptu Zaufane Opinie (OSTATNIA MODYFIKACJA 2014.03.31) Szanowni Państwo, W niniejszym dokumencie zawarta została uniwersalna instrukcja instalacji skryptu. Umieszczenie na stronie

Bardziej szczegółowo

Ćwiczenie: JavaScript Cookies (3x45 minut)

Ćwiczenie: JavaScript Cookies (3x45 minut) Ćwiczenie: JavaScript Cookies (3x45 minut) Cookies niewielkie porcje danych tekstowych, które mogą być przesyłane między serwerem a przeglądarką. Przeglądarka przechowuje te dane przez określony czas.

Bardziej szczegółowo

Instrukcja pobierania i weryfikacji zaświadczeń elektronicznych w portalu internetowym Polskiej Izby Inżynierów Budownictwa

Instrukcja pobierania i weryfikacji zaświadczeń elektronicznych w portalu internetowym Polskiej Izby Inżynierów Budownictwa Instrukcja pobierania i weryfikacji zaświadczeń elektronicznych w portalu internetowym Polskiej Izby Inżynierów Budownictwa W dokumencie opisano sposób pobierania i weryfikowania zaświadczeń elektronicznych

Bardziej szczegółowo

INSTRUKCJA OBSŁUGI. 1.Rozpoczęcie procesu zamówienia.

INSTRUKCJA OBSŁUGI. 1.Rozpoczęcie procesu zamówienia. INSTRUKCJA OBSŁUGI dokonywania zamówień w sklepie internetowym urwiskowo.pl dofinansowanych z ZFŚS Spółki Karol Kania i Synowie w ramach Paczek Mikołajkowych dla Dzieci Szanowni Państwo! Niniejsza instrukcja

Bardziej szczegółowo

Comarch isklep24 Ulotka v. 5.1

Comarch isklep24 Ulotka v. 5.1 Comarch isklep24 Ulotka v. 5.1 31-864 Kraków, Al. Jana Pawła II 41g tel. (12) 681 43 00, fax (12) 687 71 00 Dział Wsparcia Klienta i Partnera: (12) 681 43 00 http://www.comarch.pl/erp/ info.erp@comarch.pl

Bardziej szczegółowo