GoldenLine
Zaloguj się

konto usunięte

Temat: Płatności do Symfony2

Dzisiaj walczyłem z podpięciem PayU za pomocą gotowego Bundle do Symfony2. Niestety straszna kicha w tym temacie. Zdążyłem potestować dwa Bundle i w obu wysypało mi błędami. Po eliminacji kilku z nich odeszła mi ochota na dalszą walkę z czymś co wykoleja się na wszystkim co możliwe.

Czy ktoś zna jakiś działający Bundle do Symfony 2.8? Szkoda mi już czasu na walkę z wiatrakami. A jednak lepiej byłoby mieć możliwość aktualizacji przez composer niż ręcznego grzebania we własnym kodzie.
Ewentualnie jakaś podpowiedź czego użyliście do stworzenia własnego rozwiązania też będzie pomocna.
Link do wypowiedziLink

konto usunięte

Temat: Płatności do Symfony2

Jeżeli ktoś nie utrzymuje należycie paczki to tak jest. Albo zwyczajnie coś źle robisz. Nie prościej skorzystać z ich oficjalnego SDK?

https://github.com/PayU/openpayu_php

Zrobić z tego bundla to dziecinada. Wystawiasz serwis i sobie potrzebne do działania parametry wrzucasz w semantyczną konfigurację:

http://symfony.com/doc/2.8/components/config/definitio...

Ewentualnie zrób fork tamtej paczki. Może ktoś zwyczajnie nie podbił wersji sdk od dawna.
Link do wypowiedziLink

konto usunięte

Temat: Płatności do Symfony2

To chyba jedyne sensowne rozwiązanie. Zdziwiło mnie że tak krytyczna i popularna funkcjonalność nie ma działającego Bundle.
Link do wypowiedziLink

konto usunięte

Temat: Płatności do Symfony2

Nie to jest tylko opcjonalne. Zresztą zobacz to:
http://developers.payu.com/pl/restapi.html#references_...

Jestem właśnie w trakcie realizacji modułu do PayU, tylko nie pod Symfony i nie potrzebuję wcale tego SDK tylko wystarczą mi standardowe helpery Request, w celu wysyłania POST-em requestów do tego API jak również standardowy Cache do zapisywania Access Token który jest ustawiony z tego co widzę na 12 godzin o ile się nie mylę. Zresztą łatwo przeanalizować te kody z githuba.
Link do wypowiedziLink

konto usunięte

Temat: Płatności do Symfony2

Dariusz R.:
Nie to jest tylko opcjonalne. Zresztą zobacz to:
http://developers.payu.com/pl/restapi.html#references_...

Jestem właśnie w trakcie realizacji modułu do PayU, tylko nie pod Symfony i nie potrzebuję wcale tego SDK tylko wystarczą mi standardowe helpery Request, w celu wysyłania POST-em requestów do tego API jak również standardowy Cache do zapisywania Access Token który jest ustawiony z tego co widzę na 12 godzin o ile się nie mylę. Zresztą łatwo przeanalizować te kody z githuba.

Tylko po co? Piszesz coś co już jest obsłużone przez SDK. Zmienią API i on sobie zaciągnie nowszą wersję SDK a Ty w tym czasie będziesz siedział i dłubał w swoim rozwiązaniu żeby je dostosować. Jeżeli ktoś dostarcza oficjalny lib, na ogół lepiej z takowego korzystać.
Link do wypowiedziLink

konto usunięte

Temat: Płatności do Symfony2

Właśnie dlatego grzebałem tyle czasu w tych Bundle. Skorzystanie z openpayu/openpayu też nie jest idealne. Jak coś zmienią to trzeba będzie grzebać przy integracji. A nie zawsze jest możliwość wykonywać coś w terminie na wczoraj.
Link do wypowiedziLink

konto usunięte

Temat: Płatności do Symfony2

Z płatnościami musi być na wczoraj. Potrafiłem przez weekend zarobić tyle co normalnie przez miesiąc tylko dlatego że komuś trzeba było sklep naprawić w środku nocy. A ludzie mają fioła na punkcie płatności. Jak Cie payu wraca na białą stronę to klientowi który nie jest kumaty 1000 myśli przechodzi przez głowę od oszustwa zaczynając. Żaden sklep tego nie chce.

Dlatego upewnij się że masz wszelkie testy i nie kombinuj bezpośrednio z API itp jeżeli nie musisz. Chyba że SDK mają fatalnie napisane.
Link do wypowiedziLink

konto usunięte

Temat: Płatności do Symfony2

Dariusz P.:
Jeżeli ktoś dostarcza oficjalny lib, na ogół lepiej z takowego korzystać.

A masz gwarancje że ten nowy lib pojawi się akurat na czas, albo nie będzie problemów z frameworkiem? Zresztą testowałem to już np. na Laravelu. Była jakaś wersja rozszerzająca standardowe logowanie (generowane zresztą Artisanem) o sprawdzanie ról i uprawnień, tylko że było to zdaje się na github pod L 5.1, testowałem to na L 5.3, niestety po takiej instalacji composerem nie działało, ze względu na jakieś tam niezgodności w klasach. Podejrzewam że tutaj chodzi o podobne problemy.

Np. zmieniają funkcjonalności w serwisie płatności tak że wywala się jakiś 500 Internal Server Error, w takim przypadku to ja bym dostał na mój mail powiadomienie o wystąpieniu takiego przypadku i to nawet z fragmentami kodów, gdzie to dokładnie występuje (tak sobie zrobiłem, że na mail otrzymuję standardowy widok debugera). Jestem w stanie zareagować dość szybko.

Pytanie czy jesteś w stanie (w przypadku gdy taki nowy lib się na czas nie pojawi) tak samo szybko zareagować, bo często w tych pakietach jest dość sporo plików i klas i jest dość trudne w analizie co się tam dokładnie dzieje.Ten post został edytowany przez Autora dnia 10.12.16 o godzinie 19:05
Link do wypowiedziLink

konto usunięte

Temat: Płatności do Symfony2

Dariusz R.:
Dariusz P.:
Jeżeli ktoś dostarcza oficjalny lib, na ogół lepiej z takowego korzystać.

A masz gwarancje że ten nowy lib pojawi się akurat na czas, albo nie będzie problemów z frameworkiem? Zresztą testowałem to

Lib jest utrzymywany przez PayU. Spodziewam się że będzie na czas. Na 100% szybciej niż krojone na miarę rozwiązanie. Przetestowane.
Link do wypowiedziLink

konto usunięte

Temat: Płatności do Symfony2

Myślę że Dariusz Półtorak ma rację. Skoro PayU dostarcza własnego liba to warto z niego skorzystać. Chociaż nie ma pewności czy sobie w którejś wersji czegoś nie zmienią i aplikacje zaliczą crash z powodu np złej nazwy. A przecież o to chodzi, żeby płatności miały SLA 100%.
Link do wypowiedziLink

konto usunięte

Temat: Płatności do Symfony2

Tam jest dwa sposoby na rejestrację płatności.

1. Przez specjalnie przygotowany formularz, dane wysyłane POST-em
2. Przez ich JSON API

ad 1) Pobierając tą ich bibliotekę można znaleźć przykłady w oparciu o ten formularz, nie ma problemu żeby wrzucić i zintegrować ze swoją aplikacją
ad 2) W dwóch krokach. Najpierw autoryzacja i pobranie tokenu, zapis do cache o pewnym terminie ważności. Później rejestracja w dość specyficzny sposób, z autoryzacją Bearer z tym tokenem i wysłanie danych ale to też w dość specyficzny sposób.

Testowałem p2 z użyciem tych standardowych helperów frameworka, całość tej logiki można zmieścić w nawet jednej klasie, kodu jest i tak niewiele. Oczywiście można wykorzystać i tą bibliotekę.
Link do wypowiedziLink

konto usunięte

Temat: Płatności do Symfony2

Dawid Z.:
Myślę że Dariusz Półtorak ma rację. Skoro PayU dostarcza własnego liba to warto z niego skorzystać. Chociaż nie ma pewności czy sobie w którejś wersji czegoś nie zmienią i aplikacje zaliczą crash z powodu np złej nazwy. A przecież o to chodzi, żeby płatności miały SLA 100%.

Lib ma semantyczne wersjonowanie. Więc problemu na tym polu być nie powinno. Mają testy automatyczne. W takich wypadkach należy się głównie martwić o porzucenie wsparcia. To już trzeba monitorować samemu. Tzn w momencie jak pojawi się nowa główna wersja (3.x) to należy zrobić jak najszybciej migracje. Nikt Ci raczej z dnia na dzień nie zrobi liba 3.x i nie wywali wsparcia dla 2.x. Przy systemach płatności taki ruch to samobójstwo.
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Systemy płatności




Wyślij zaproszenie do
Anuluj