Poszukuję informacji na temat zrealizowania komunikacji z terminalem płatniczym w celu dokonywania płatności kartami płatniczymi. W szczególności chodzi mi przesłanie kwoty płatności do terminala oraz odebranie informacji o statusie operacji (zrealizowana, odrzucona, błąd itp.).
0
0
Z tego co wiem, do takiej komunikacji używa się ISO 8583:
http://www.codeproject.com/Articles/100084/Introduction-to-ISO
Natomiast jeśli chodzi o samą komunikację karta-terminal, poczytaj o EMV.
0
Dostawca terminala dostarcza też bibliotekę do obsługi terminala (powinien Ci również udostępnić dokumentację do niej).
Jaki masz terminal i kto jest jego operatorem ?
0
Problem w tym, że operator nie jest ustalony. Przeglądając witryny dostawców takich rozwiązań (terminale płatnicze) nie znalazłem żadnych bibliotek, ani przykładowych implementacji. ISO 8583 to raczej standard komunikacji na drodze terminal płatniczy - bank, a mnie chodzi o obsługę terminala z poziomu mojej aplikacji w c# (wysłanie kwoty do terminala i odebranie statusu operacji). Rozumiem, że każdy dostawca płatności za pomocą terminala będzie posiadał własne rozwiązania oraz biblioteki i brak tutaj wspólnych standardów? Z tego względu przed wyborem operatora nic nie zdziałam?
0
Aplikacja na terminalu instalowana jest przez operatora - co za tym idzie biblioteka do komunikacji zależna jest od operatora.
Mam styczność z terminalami dostarczanymi przez PeP - ich dokumentacje znajdziesz w sieci.
0
Z tego co widzę to dostawcy terminali tworzą SDK niekoniecznie darmowe i niekoniecznie .Netowe ale tworzą.
0
Zmieniło się coś w temacie, potrzebuje komunikować się w php
0
Nie jest to standardowe rozwiązanie ale się da. Dodatkowo terminal nawet jeden model może mieć różny firmware w zależności od operatora i inny protokół, więc wybór operatora to podstawa. Dalej operator przekazuje terminal i dokumentacje protokołu, testowy zestaw kart i formularz do certyfikacji Twojej integracji, którą musisz spełnić. Często nie dostaje się drivera tylko opis protokołu i trzeba wyrzeźbić, ale to ramki dobrego i znanego RS232, a nawet jak komunikujesz się po Ethernet to po rozpakowaniu pakietów są to te same ramki protokołu co w komunikacji szeregowej. Jak co to zapraszam na profesjonalne konsultacje na priv, jeśli poważnie myślisz o realizacji.
0
somedev napisał(a):
Nie jest to standardowe rozwiązanie ale się da. Dodatkowo terminal nawet jeden model może mieć różny firmware w zależności od operatora i inny protokół, więc wybór operatora to podstawa. Dalej operator przekazuje terminal i dokumentacje protokołu, testowy zestaw kart i formularz do certyfikacji Twojej integracji, którą musisz spełnić. Często nie dostaje się drivera tylko opis protokołu i trzeba wyrzeźbić, ale to ramki dobrego i znanego RS232, a nawet jak komunikujesz się po Ethernet to po rozpakowaniu pakietów są to te same ramki protokołu co w komunikacji szeregowej. Jak co to zapraszam na profesjonalne konsultacje na priv, jeśli poważnie myślisz o realizacji.
Witam,
Jestem zainteresowany modułami do integracji terminali płatniczych PolCard i PekaO SA(jesli to coś innego) z oprogramowaniem napisanym w Delphi.
Waldemar Olesiński
[email protected]
602570420
0
Biblioteka nie zawsze jest potrzebna.
Kiedyś miałem terminal z aplikacją od eService lub ePłatności (raczej to pierwsze, ale teraz nie jestem tego pewien) i nie miałem biblioteki (może była, ale ja nie skorzystałem). Natomiast była dokumentacja opisująca, jak współpracować. Terminal wyglądał jak Elavon desk 3500 lub Ingenico Desk 3500 lub Ingenico ICT220 (ustaliłem po wyglądzie terminali na zdjęciach w Google), tak naprawdę to były dwa podobne terminale łączone ze sobą, z których jeden miał drukarkę, a terminal z drukarką podłączało się do sieci Ethernet.
Terminal stawał się urządzeniem sieciowym, dostawał adres IP, a z programem komunikował sie potokołem UDP. W takim przypadku nie ma żadnego znaczenia, w czym robi się program, ani nie ma problemu z kompatybilnością bibliotek. Miałem dokładną dokumentację opisującą komunikację.
Oprócz tego (to załatwiał pracodawca) miałem terminal testowy i fikcyjne karty płatnicze, za których pomoca mogłem wykonywac płatności, zwroty i inne czynności bez ograniczeń i bez narażania swoich ani cudzych pieniędzy. Co więcej, na tym terminalu nie było możliwe wykonanie płatności prawdziwą kartą.
Często nie dostaje się drivera tylko opis protokołu i trzeba wyrzeźbić, ale to ramki dobrego i znanego RS232, a nawet jak komunikujesz się po Ethernet to po rozpakowaniu pakietów są to te same ramki protokołu co w komunikacji szeregowej. Jak co to zapraszam na profesjonalne konsultacje na priv, jeśli poważnie myślisz o realizacji.
Dokładnie tak było w moim przypadku z tą różnicą, że to był Ethernet z wykorzystaniem UDP. Czy terminal, który miałem, miał RS232, tego nie wiem i nie miało znaczenia.
0
Jestem zainteresowany modułami do integracji terminali płatniczych PolCard i PekaO SA(jesli to coś innego) z oprogramowaniem napisanym w Delphi.
Jeżeli są potrzebne biblioteki, ale okaże się, że jak na złość, akurat nie są kompatybilne z Delphi, to jest jeszcze inne wyjście: Napisać krótki program konsolowy w języku, z którym biblioteka jest kompatybilna. Sam program byłby sterowany komendami podawanymi z klawiatury. Nie musza to być polecenia czytelne dla człwieka, mogą to być dowolne ciągi znaków wykorzystujące same litery i cyfry. Wynik operacji również byłby zamieniany na ciąg znaków i wypisywany na ekran.
Taki program można wysterować poprzez uruchomienie procesu z przekierowaniem standardowego wejścia i wyjścia. Śmiem w ciemno twierdzić, że w Delphi takie coś jest możliwe, a być może nawet z ukryciem interfejsu uruchamianego programu. W ten sposób można połączyć praktycznie dowolne dwie technologie, np. z Delphi wysterować programem napisanym w Java, w Java wysterować program napisany w C++ i tak dalej.