Integracja szybkich płatności z PayU w sklepie internetowym

Witajcie.
Robię sobie mały sklep i doszedłem do momentu zintegrowania go z jakimiś szybkimi płatnościami. Pierwsze co mi wpadło w oko, to payu. Nigdy z szybkimi płatnościami nie miałem do czynienia od strony programowania, więc chciałbym uzyskać trochę pomocy. Szybko przeleciałem przez dokumentację, ale jest dla mnie trochę niejasna. Chciałbym zapytać o łańcuch akcji jakie mój sklep powinien wykonać po dodaniu produktów do koszyka i uzupełnieniu swoich danych przez klienta. Z tego zo zrozumiałem z dokumentacji payu mam ułożyłem sobie taki plan:

1. Klient ma produkty w koszyku i wypełnia formularz ze swoimi danymi (kupuje bez rejestracji).
2. Ja te jego dane zapisuję do swojej bazy do tabeli 'klient'. I jego zamówienie zapisuję też w swojej bazie w tabeli 'zamówienie'.
3. Wywołuję requesta do payu, żeby się zautoryzować i dostać token.
4. Teraz z tym tokenem robię do payu kolejnego requesta do utworzenia zamówienia (przesyłam parametry customerIp, merchantPosId, description, currencyCode, totalAmount, continueUrl, extOrderId, notifyUrl).
   continueUrl to link do mojej strony, która otwiera się po przetworzeniu płatności przez payu, skąd ta strona wie czy przelew się powiódł czy nie? Musi to wiedzieć?
   extOrderId, to identyfikator zamówienia w mojej bazie, które właśnie klient złożył. Gdzie ten identyfikator potem do mnie wraca? Leci do continueUrl czy notifyUrl?
   notifyUrl, to strona która odbiera od payu zmiany statusu przelewu i po mojej stronie musi zadbać o zmiany zamówienia w mojej bazie i ewentualne powiadomienie klienta.
5. Klientowi pokazuje się strona payu z wyborem metody płatności, klient robi przelew.
6. Klient jest przekierowany na continueUrl. Teraz klient może już zamknąć przeglądarkę.
7. W tle payu strzela do notifyUrl z powiadomieniami o zmianach z płatności. Jeśli płatność się powiodła, to realizuję zamówienie. Jeśli nie powiodła się, to wysyłam klientowi wiadomość.

Coś tu jeszcze powinno być po drodze? A może polecacie jakiegoś innego operatora szybkich płatności?

Robisz mały sklep, dlaczego nie skorzystasz z gotowca?

@szczemp - odpowiadając na Twoje punkty

Ad.1 - to czy zalogowany czy nie to i tak nie ma znaczenia bo lista pól obligatoryjnych do PayU jest taka sama.
Ad.2 - dokładnie
Ad.3 - dokładnie, z tą tylko różnicą, że dostajesz również refresh_token do "odświeżenia" swojego tokenu i tym tokenem możesz "przedłużyć" życie obecnego tokena aby cały czas korzystać z tego samego przy późniejszych akcjach.
Ad.4 - wysyłasz request do utworzenia zamówienia (pola obowiązkowe wiadomo, muszą być a opcjonalne to już wedle Twojego uznania). Na tym kroku nie martwisz się czy przelew się powiódł czy też nie. W każdym razie, dostajesz w odpowiedzi tego requesta zwrotkę z API, gdzie masz pole orderId wygenerowane przez operatora płatności i to właśnie pole zapisujesz do swojej tabeli "zamowienia". Dostajesz także "redirectUri" i tam przekierowujesz użytkownika.
Ad.5 - tutaj użytkownik sobie płaci
Ad.6 - może zamknąć, możesz również dać (po przekierowaniu na continueUrl) jakiś skrypt, który sprawdza sobie status płatności (masz endpoint do pobierania zamówienia i tam jest jego status) albo dajesz stronę typu "czekamy na potwierdzenie płatności"
Ad.7 - dokładnie, tutaj jak PayU "odnotuje" płatność to wyśle potwierdzenie na ten adres i w tym potwierdzeniu będzie orderId, który wcześniej sobie zapisałeś (krok 4) i po nim będziesz identyfikował zamówienia.

Mjuzik napisał(a):

Robisz mały sklep, dlaczego nie skorzystasz z gotowca?

Nie obraź się, ale najprostsza odpowiedź brzmi 'bo mogę'. Jak ja lubię takie posty nie wnoszące nic do zadanego pytania.
Bardziej szczegółowa odpowiedź, to taka, że sklep nie jest standardowy. Przejrzałem gotowce i żaden darmowy nie oferuje tego co mi potrzeba. Niektóre wtyczki wprowadzają podobne funkcjonalności, ale nie do końca wszystko to co mi potrzeba.

leonpro778 napisał(a):

@szczemp - odpowiadając na Twoje punkty

Ad.1 - to czy zalogowany czy nie to i tak nie ma znaczenia bo lista pól obligatoryjnych do PayU jest taka sama.
Ad.2 - dokładnie
Ad.3 - dokładnie, z tą tylko różnicą, że dostajesz również refresh_token do "odświeżenia" swojego tokenu i tym tokenem możesz "przedłużyć" życie obecnego tokena aby cały czas korzystać z tego samego przy późniejszych akcjach.
Ad.4 - wysyłasz request do utworzenia zamówienia (pola obowiązkowe wiadomo, muszą być a opcjonalne to już wedle Twojego uznania). Na tym kroku nie martwisz się czy przelew się powiódł czy też nie. W każdym razie, dostajesz w odpowiedzi tego requesta zwrotkę z API, gdzie masz pole orderId wygenerowane przez operatora płatności i to właśnie pole zapisujesz do swojej tabeli "zamowienia". Dostajesz także "redirectUri" i tam przekierowujesz użytkownika.
Ad.5 - tutaj użytkownik sobie płaci
Ad.6 - może zamknąć, możesz również dać (po przekierowaniu na continueUrl) jakiś skrypt, który sprawdza sobie status płatności (masz endpoint do pobierania zamówienia i tam jest jego status) albo dajesz stronę typu "czekamy na potwierdzenie płatności"
Ad.7 - dokładnie, tutaj jak PayU "odnotuje" płatność to wyśle potwierdzenie na ten adres i w tym potwierdzeniu będzie orderId, który wcześniej sobie zapisałeś (krok 4) i po nim będziesz identyfikował zamówienia.

Dzięki za odpowiedź.
Wczoraj spróbowałem tego na sandboxie payu. I tam już po przekierowaniu klienta na stronę płatności redirectUri można zrobić symulację przelewu. Fajnie jest bo można wypróbować płatność z sukcesem lub bez sukcesu. Obie ścieżki i tak przekierowują do mojego continueUrl, z tym, że jeśli płatność będzie z błędem, to co continueUrl doklejany jest querystring error=(zapomniałem jaki numer). Wygląda na to, że już tu coś wiadomo na temat przelewu i mogę na stronie continueUrl dać odpowiedni komunikat i zaktualizować zamówienie w swojej bazie. A jak przekierowanie na continueUrl przyjdzie bez parametru error, to dać komunikat o czekaniu na płatność. Dobrze to wywnioskowałem, czy coś pomyliłem?

@szczemp - nie wiem czy ten parametr error w URL jest "miarodajny" (czy to nie jest parametr tylko i wyłącznie na potrzebny testów). Ja to bym chyba i tak się oparł na statusie jaki zwróci mi API

szczemp napisał(a):

Mjuzik napisał(a):

Robisz mały sklep, dlaczego nie skorzystasz z gotowca?

Nie obraź się, ale najprostsza odpowiedź brzmi 'bo mogę'. Jak ja lubię takie posty nie wnoszące nic do zadanego pytania.

OK, możesz - ale nie uważam, żeby odpowiedź @Mjuzik nic nie wnosiła. Wręcz przeciwnie - w wielu przypadkach taka porada by była bardzo stosowna i wartościowa. Być może Ty jesteś ogarnięty, wiesz czego chcesz i ogarniesz temat - tego nie wiemy, bo się zarejestrowałeś parę dni temu, a ten wątek to Twój pierwszy post. W związku z brakiem informacji dot. tego, dlaczego chcesz to robić, a także z brakiem możliwości zapoznania się z Twoją wiedzą/dokonaniami, zostałeś potraktowany jako osoba początkująca, która nie do końca wie, czego chce i czego jej potrzeba. Może w Twoim przypadku to była świadoma i przemyślana decyzja, ale uwierz mi - często jest tak, że się pojawia ktoś, kto ma średnie pojęcie o temacie i zaczyna snuć jakieś swoje dziwne wizje, na nowo wymyślać koło itp. I dla takiej osoby skierowanie jej na prawidłowe tory jest mega dobrą pomocą.

szczemp napisał(a):

Mjuzik napisał(a):

Robisz mały sklep, dlaczego nie skorzystasz z gotowca?

Nie obraź się, ale najprostsza odpowiedź brzmi 'bo mogę'. Jak ja lubię takie posty nie wnoszące nic do zadanego pytania.
Bardziej szczegółowa odpowiedź, to taka, że sklep nie jest standardowy. Przejrzałem gotowce i żaden darmowy nie oferuje tego co mi potrzeba. Niektóre wtyczki wprowadzają podobne funkcjonalności, ale nie do końca wszystko to co mi potrzeba.

W gotowcach nie chodzi o to, żeby brać z nich 100%. Mam na myśli gotowe opensource typu sylius, shopware, magento. Masz gotowe, darmowe moduły i po prostu przerabiasz i konfigurujesz pod siebie. Nie miałbyś wtedy problemów z continueURL, który został już rozwiązany dziesiątki razy za pomocą gotowych rozszerzeń. Pisanie sklepu od zera praktycznie nigdy się nie opłaca ani czasowo, ani finansowo.

Robisz integrację z payU, fajnie. Jeśli będziesz chciał zmienić na tPay, bo mają niższą marżę to będziesz znowu wszystko pisał od zera.
Procesowanie płatności, które sobie wymyśliłeś to najbardziej standardowy proces, który obsługuje każdy z z wyżej wymienionych systemów opensource. Jak lubisz marnować czas, albo po prostu sobie kodować sklep dla fun'u to ok.

Rozumiem "bo mogę" ale też tak sobie pomyślałem że po co od zera pisać. W e-commerce to robię od lat i szczerze powiedziawszy nie wiem na ile Twój projekt jest nietypowy ale jeszcze mi się nie zdarzyło aby jakaś funkcjonalność nie dała się ogarnąć w Prestashop czy Magento. Przecież do nich możesz sam pisać moduły i nadpisywać istniejące funkcjonalności a odpada Ci wiele roboty którą masz pisząc wszystko od zera. No choćby te płatności. Masz gotowe moduły a i je możesz przecież dostosować. Rozumiem jak uznasz moją odpowiedź jako nic nie wnoszącą do tematu ale nic mnie w Twoim wpisie nie przekonało że jakiś projekt trzeba stawiać od zera. Po prostu też jestem ciekaw co jest tak nietypowego co zmusiło Cię do tak drastycznego posunięcia. No chyba że robisz to hobbystycznie to inna sprawa.