[biblioteki][płatności online] Gotowa implementacja Transferuj.pl, Gotowa implementacja rozwiązań płatniczych Transferuj.pl Opcje

[KIPSA]

Dzień dobry,

Gdyby ktokolwiek szukał gotowych klas / bibliotek do implementacji systemu płatności we własnym rozwiązaniu, to z radością informujemy, że system płatności Transferuj.pl wyszedł na przeciw oczekiwaniom i udostępnił całą bibliotekę, z której można wybierać gotowe rozwiązania do implementacji dowolnych form płatności w systemach ecommerce:

https://github.com/tpaycom/transferuj

Dokumentacje techniczne i inne przykłady dla standardowego systemu są dostępne do pobrania tutaj: https://transferuj.pl/dokumentacje
Dla pozostałych niestandardowych systemów dokumentacje są dostępne na indywidualne żądanie, ponieważ są to systemy dla osób, które wiedzą, czego chcą.

Zachęcamy do testowania i feedbacku. W razie uwag prosimy o komentarz na forum lub na github.

Mamy nadzieję, że oszczędzi to Developerom dużo cennego czasu.

[KIPSA]

Dziękujemy za komentarze. Na wstępie chcielibyśmy zaznaczyć, że istnieje 10 różnych sposobów implementacji płatności i implementując płatności w dowolnym serwisie w 99,9% należy wybrać jeden sposób i jedno rozwiązanie, a nie wszystkie.

Chcielibyśmy się precyzyjnie odnieść do Pana wypowiedzi:

Nie można niczego zamockować, bo cały request opiera się na jednej prywatnej metodzie, która w dodatku używa, a jakby inaczej, static. To samo z logowaniem. O Dependency Injection programiści w firmie nie słyszeli?
DI są przydatne, ale istnieją różne wzorce projektowe, a biblioteki są w zamyśle jak najbardziej niezależne od stosowanego wzorca projektowego. Dependency Injection ze względu na prostotę realizowanych przez klasy operacji i ich uniwersalność nie zostały użyte umyślnie.

Jakieś klasy niby są ale wszystko co wchodzi i wychodzi z metod to typy prymitywne.
Zgadza się. Są to typy prymitywne. Z biblioteki będą korzystali programiści systemów z różnymi architekturami. Klasa ma być przede wszystkim łatwa w dopasowaniu do dowolnego systemu.

SRP. W jednej klasie jest wszystko: request, walidacja, komunikaty błędów.
Znamy SRP, jednakże nie uważamy za dobry pomysł aby rozdzielać funkcjonalności biblioteki na klasy zgodnie z SRP zawsze, wszędzie i bez przemyślenia. Wprowadziliśmy podział na klasy obsługujące poszczególne metody płatności oraz klasy pomocnicze. Nie sztuka w stworzeniu 100 klas zawierających 1-2 metody. Obecny podział jest czytelny dla programistów, którzy będą korzystali z biblioteki dla potrzeb integracji. Gdyby zaistniała potrzeba dalszego rozwoju klas pod kątem realizowanych przez nie zadań jak najbardziej należałoby je rozdzielić na mniejsze. Takie potrzeby w zamyśle nie powinny się jednak pojawić.

Metody typu 'saleValidateAndPrepareParams'. Sama nazwa już powinna dać programiście do myslenia. O jedno 'and' za dużo.
Tu się zgadzamy. Można rozdzielić tą metodę na dwie osobne.

Magiczne liczby. Co to jest 40 albo 128?
40 jest stałą długością ciągu kodu autoryzacyjnego używanego w systemie niezmienną od zawsze (podobnie jak 128). Można wyciągnąć to do const oraz odpowiednio skomentować, tak aby nikt ich nie zmieniał.

Code duplication. Cała walidacja, włącznie z komunikatami błędów, jest powielana. Parsowanie parametrów i przygotowanie danych do request-u tak samo.
Oczywiście, że tak. Nikt bowiem nie zaimplementuje wszystkich tych rozwiązań jednocześnie. Należy wybrać jedno dowolne z tych rozwiązań, najlepsze dla danych potrzeb i je zaimplementować. Tworzenie do tego 10 repozytoriów jest przerostem formy nad treścią.

Takie rzeczy jak URL czy IP powinny być podawane w parametrze a nie hardcodowane i to w zmiennej.
W przypadku zmienności tych parametrów tak, ale one są niezmienne.

Jak już to stała jest bardziej odpowiednia do tego.
Dlaczego nie stała? Gdyby w wyjątkowo rzadkiej sytuacji trzeba było jednak zmienić te ścieżki, to przy tej skali implementacji i tej rzadkości zmian łatwiejsza jest modyfikacja konstruktora niż przerobienie całej klasy

static? Po raz kolejny. To się kompletnie nie nadaje do przetestowania
To zależy od sposobu testowania.

Po raz kolejny hardcodeing. Ścieżki, IP, URL.
Biblioteki mają przyspieszyć, a nie spowalniać programistę. J/w.

You made my day Tego komentować nie trzeba.
Tu zastanawialiśmy się, co poeta miał na myśli? To, że powinien być autoloading? Nie powinien.

Podstawy takie jak autoloading, DI.
Rozumiem że na co dzień nie zajmuje się Pan integracjami bibliotek do istniejących systemów o różnych strukturach? Nie jest możliwa realizacja autoloadingu z całkowitym wyeliminowaniem ryzyka konfliktu z projektem, do którego biblioteka jest dołączana (tak, znamy spl_autoload_register i słyszeliśmy o przestrzeniach nazw). Na wielu hostingach współdzielonych będzie z tym delikatnie mówiąc bardzo duży problem.

Oby to było cokolwiek innego niż XML...
Tak, to jest XML. W temacie wyrażeń regularnych w naszej opinii jest to dobra droga biorąc pod uwagę integrację z zewnętrznymi systemami. Wbudowane metody PHP służące do parsowania odpowiedzi w formacie XML nie zawsze są w stanie poprawnie przetworzyć odpowiedź XML (szczególnie biorąc pod uwagę różne wersje PHP, w których jest wykorzystywana biblioteka, różne systemy kodowania itd.). To rozwiązanie jest zwyczajnie najbardziej niezawodne do tego konkretnego zastosowania.

Niespójność code style. Raz tak, raz tak. Jak kompu popadło tak pisał.
Ten zarzut jest całkowicie bezpodstawny i niezgodny z rzeczywistością. Biblioteki są standaryzowane. Zastosowane coding standards bibliotek są podobne do Symfony2: http://symfony.com/doc/current/contributin.../standards.html . Jedynie w kodzie z niektórymi krótkimi przykładami zastosowania bibliotek mogą faktycznie być niespójności.

Wszystko upchane w kilku klasach, które robią wszystko i nic operając sie na static.
Ponownie static (IMG:style_emoticons/default/smile.gif) Funkcje statyczne znajdują się głównie w klasie Util oraz Validate, nie operują na zmiennych lub instancjach obiektów zewnętrznych! A to że nie jest to mile widziane przez testerów jest osobną kwestią. Obecny podział jest czytelny dla programistów, którzy będą korzystali z biblioteki dla potrzeb integracji.

Generalnie kompletny brak SOLID.
To jest temat do dyskusji dotyczący konkretnych klas i ich precyzyjnych zastosowań.

Testy - a raczej ich kompletny brak.
Tu się zgodzimy - nie ma testów. Mamy je w planach do przygotowania w przyszłości, jeśli będzie takie zapotrzebowanie ze strony użytkowników bibliotek.

Samej funkcjonalności nie oceniam, bo sam wgląd w bibliotekę dyskwalifikuje ją w przedbiegach
Komentowanie rzeczy odrywając je od ich zastosowania jest jak ocenianie wygody samochodu po jego kluczykach.