Witam,
Piszę e-commercial projekt, który będzie zintegrowany z PayPal oraz Stripe. Cały basket zapisuję w sesji. Następnie chcę go zapisać do bazy danych oraz usunąć sesję. Gdzie dokładnie go zapisać? W momencie jak user klika zapłać i zostaje przekierowany do odpowiedniego serwisu? Czy po odpowiedzi o pozytywnej transakcji? I jak to połączyć, żeby user nie zapłacił dwa razy za ten sam order?
Kiedy writing e-komercjal project najlepiej saving basket gdy order jest zapisywany.
Tak, nabijam się ze sposobu w jaki dobierasz słownictwo.
Gdzie dokładnie go zapisać?
Najlepiej w bazie danych.
W momencie jak user klika zapłać i zostaje przekierowany do odpowiedniego serwisu?
To jest najlepsza opcja - wtedy nie będziesz miał problemu w momencie, gdy transakcja się w rzeczywistości powiedzie, a serwis zwróci i tak błąd. Nic nie jest idealne - robiłem kiedyś w tym i naprawdę warto zapisywać wszystko co się dzieje na stronie.
I jak to połączyć, żeby user nie zapłacił dwa razy za ten sam order?
?
Kiedy miałby płacić drugi raz?
Noo dobra, a jak user dojdzie do etapu, gdzie musi zapłacić (order zapisany w db), ale rozmyślił się i wraca do koszyka i usuwa np jeden produkt. Przechodzi cały etap od nowa i co teraz? Mam zaktualizować zamówienie w db, prawda (zamówienie id przechowuję w sesji)? A jak już ostatecznie zapłaci za zamówienie to usuwam koszyk i id zamówienia z sesji i zmieniam status zamówienia w db? Coś jeszcze czy mniej więcej tak to ma działać?
Jeśli masz na myśli że jeszcze nie nacisnął przycisku Zapłać - do momentu jego naciśnięcia zamówienie siedzi w sesji (a najlepiej i tak zrobić sobie jakiś persistent shopping cart, ale to swoją drogą), i dopiero po jego naciśnięciu jest zapisywane do bazy oraz otwiera się okno z transakcją.
PS naprawdę nie wplataj tych angielskich słów, wygląda to niepoważnie.
Przecież jak użytkownik kliknął za zapłać to już zapisuję zamówienie w db o w tym samym momencie przekierowuje go np na stronę paypala. I właśnie teraz kiedy przyszło płacić, Klient rozmyśla się i wraca usunąć (ew. dodać) produkt do koszyka. I co teraz? Na czym polega persistent shopping cart? Właśnie po to otworzyłem ten wątek :)
Czy persistent shopping cart polega tylko i wyłącznie na umieszczeniu koszyka oraz przycisku checkout na każdej podstronie?
Ach, no to widzisz - teraz zrozumiałem o co chodzi ;)
W takim wypadku jakimś wyjściem będzie na pierwszym miejscu nie usuwać niczego z sesji i faktycznie czekać do samego końca (potwierdzenia transakcji) z zapisaniem czegokolwiek. Ale moim zdaniem to dosyć dziwny myk - ja po prostu anulowałbym zamówienie z komentarzem transakcja anulowana (tak aby klient wyraźnie to widział) i dał najwyżej przycisk zamów ponownie, który kopiowałby produkty do nowego zamówienia.
Zasadniczo jeśli użytkownik już otwiera kartę płatności to nie powinien się rozmyślać.
Czy persistent shopping cart polega tylko i wyłącznie na umieszczeniu koszyka oraz przycisku checkout na każdej podstronie?
Co? Gdzie coś takiego wyczytałeś?
W persistent shopping cart chodzi o to, że zamiast do sesji, dane o zamówieniu (produktach) w formie koszyka zapisujesz u siebie w bazie danych, a do usera wysyłasz permanentne ciasteczko z jakimś losowym id wskazującym na ten koszyk. Dzięki temu po ponownym uruchomieniu przeglądarki potencjalnie nie straci zamówienia, tylko będzie mógł dalej kontynuować. Taki system jest np. w Magento.
Właśnie o to chodzi, że nie powinien, ale co jak się rozmyśli. Na początku też myślałem, na cwaniaka, że zapiszę sobie zamówienie jak dostanę wpłatnę, ew zautoryzuję kartę (Stipre), ale w paypal już tak ładnie nie ma :/ bo tutaj musisz czekać na odpowieć przez IPN co trwa trochę dłużej.
Na razie napiszę tak jak opisaliśmy to wyżej. Zamówienie ląduję w bazie danych z odpowiednim statusem i dopiero na stronie potwierdzającej zapłatę zapiszę status na zapłacone. Nie chcę mi się bawić.
Zamówienie ląduję w bazie danych z odpowiednim statusem i dopiero na stronie potwierdzającej zapłatę zapiszę status na zapłacone.
I to jest jedyne sensowne (moim zdaniem) rozwiązanie - w razie reklamacji także prościej :P
Zobacz jeszcze tylko moją edycję odnośnie persistent shopping cart.
To już coś mamy, ale z tym powrotem do koszyka i anulowaniem zamówienia to coś mi tutaj nie pasuję. Tak samo mi nie pasuje aktualizowanie zamówienia w bazie danych o to najbaridzej mi się rozchodzi. A co jak Klient wróci do koszyka?
Przedstaw jakoś szerzej ten scenariusz, nie rozumiem dokładnie o co w tej chwili Ci chodzi.
Chodzi mi o ten sam problem na początku. Użytkownik tworzy koszyk, przechodzi do płatności i rozmyśla się z jednej rzeczy. Usuwa jeden produkt, wraca do płatności i co teraz? Bo przecież stworzyliśmy już zamówienie w bazie danej, ponieważ klient był już na stronie z formularzem płatniczym, ale zrezygnował. I co tworzyć nowe zamówienie czy aktualizować obecne? Na pewno nie usunę zamówienia z bazy danych, to zupełnie mi nie odpowiada.
Cały czas to jest to samo, jedno zamówienie - po prostu zaktualizuj je w takim wypadku w bazie danych.
Noo i to z grubsza ma sens. Aktualizuję zamówienie i usuwam wszytko z sesji dopiero po zamłaceniu. Mi pasuje.