Płatność bez zakładania konta

Być może głupie pytanie - ale..

Czy istnieje sensowna opcja wdrożenia płatności do aplikacji frontendowej, tak, żeby użytkownik nie musiał robić żadnego konta, ani nawet nie nie musiał klikać "zaloguj z"?

Jeśli nie - możecie podrzucić jakąś najprostszą Waszym zdaniem metodę? (tak, żeby możliwie mało trzeba było backendowych rzeczy robić, użytkownik miał bardzo przyjemny i niezauważalny experience z wykupieniem. I tak, żeby nie płacić też jakiś słonych prowizji pośrednikowi płatności najlepiej - myślałem pobierać jakoś 1$ tylko miesięcznie za premium features od użytkowników)

To zależy — przede wszystkim od tego, za co użytkownik płaci. Jeśli to, co kupuje, jest w jakiś sposób immanentnie unikalne i istotne głównie dla niego — na przykład kupuje jakiś produkt z dostawą, albo zamawia spersonalizowany obrazek wg swoich wytycznych — to da się pokombinować i może do czegoś sensownego dojdziemy. Jeśli nie — na przykład kupuje konto premium dające dostęp do pewnych treści (wspólnych dla wszystkich osób z kontem premium), albo blokujące reklamy — to musisz jakoś skutecznie rozróżniać użytkowników.

Wtedy pozostaje kwesta tego, czy chcesz, żeby rozróżnienie było w pewnym sensie permanentne (tzn. restart przeglądarki czy komputera w niczym nie przeszkadzał) i czy chcesz, żeby było niezależne od użytego sprzętu (tzn. użytkownik mógł do tego wrócić na innej maszynie). Te wymagania — zwłaszcza to drugie — praktycznie wymuszają posiadanie jakichś kont.

dzięki za odpowiedź @Althorion .

to tak:

To zależy — przede wszystkim od tego, za co użytkownik płaci. Jeśli to, co kupuje, jest w jakiś sposób immanentnie unikalne i istotne głównie dla niego — na przykład kupuje jakiś produkt z dostawą, albo zamawia spersonalizowany obrazek wg swoich wytycznych — to da się pokombinować i może do czegoś sensownego dojdziemy. Jeśli nie — na przykład kupuje konto premium dające dostęp do pewnych treści (wspólnych dla wszystkich osób z kontem premium), albo blokujące reklamy — to musisz jakoś skutecznie rozróżniać użytkowników....

1. Kupuje konto premium które by dawało dostęp do większej ilości funkcji aplikacji - odblokowywało by pewne buttony / funkcje front-endowe można powiedzieć.

   Wtedy pozostaje kwesta tego, czy chcesz, żeby rozróżnienie było w pewnym sensie permanentne (tzn. restart przeglądarki czy komputera w niczym nie przeszkadzał) i czy chcesz, żeby było niezależne od użytego sprzętu (tzn. użytkownik mógł do tego wrócić na innej maszynie). Te wymagania — zwłaszcza to drugie — praktycznie wymuszają posiadanie jakichś kont.

2. Tutaj widzę dwie opcje:
   a) Użytkownik wykupuje dostęp na danym komputerze i dostęp musiałby działać po restarcie komputera i przeglądarki
   b) Użytkownik kupuje subskrypcje na miesiąc, lub na x miesięcy, odnawialną i wtedy powinna raczej działać też na innym komputerze

mógłbyś coś doradzić w tych dwóch opcjach?

b) rozumiem, na 100% wymaga prowadzenia jakiejś bazy z emailami i statusem użytkownika - czy zapłacił etc? można pominąć ustawianie hasła przez "zaloguj z", ale swój backend z bazą e-maili i statusem zapłaty trzeba prowadzić i tak?
jak wtedy wygląda na froncie odblokowanie tego, ustawiasz jakąś zmienną const hasPaid ktora zczytuje ajaxem z bazy danych czy użytkownik jest zalogowany a w kodzie po prostu każda funkcja która jest premium podpatruje tą zmienną (stałą:P) i na tej podstawie "puszcza" kod dalej? Tak to się robi zazwyczaj? (wystarczające security?)

Zatem masz funkcje uniwersalnie użyteczne — tzn. nie tylko kupujący dostaje coś spersonalizowanego, ale każdy dostaje to samo — oraz potrzebujesz dostępu z różnych miejsc. Skoro tak, to potrzebujesz możliwości identyfikacji użytkowników (żeby móc rozróżnić płacących od nie płacących), oraz ta identyfikacja musi być niezależna od aktualnej sesji w przeglądarce.

Zatem, tak, potrzebujesz jakiejś możliwości logowania, która jednocześnie pozwoli się użytkownikowi logować na swoje konto z różnych miejsc (czyli nie zależy od używanego sprzętu), oraz jednocześnie nie ułatwi specjalnie współdzielenia (czyli, na przykład, „tajemny” adres strony odpada).

Normalnie się to robi poprzez trzymanie na backendzie loginu, hasza hasła, i tymczasowego ID logowania; a zalogowanemu użytkownikowi wysyłasz odpowiednie ciasteczko z takim samym ID, jak w bazie. Poszukaj sobie w sieci gotowców — to jest łatwo popsuć (pierwsza zasada kryptografii — nie implementuj samemu kryptografii).

Althorion napisał(a):

Zatem masz funkcje uniwersalnie użyteczne — tzn. nie tylko kupujący dostaje coś spersonalizowanego, ale każdy dostaje to samo — oraz potrzebujesz dostępu z różnych miejsc. Skoro tak, to potrzebujesz możliwości identyfikacji użytkowników (żeby móc rozróżnić płacących od nie płacących), oraz ta identyfikacja musi być niezależna od aktualnej sesji w przeglądarce.

Zatem, tak, potrzebujesz jakiejś możliwości logowania, która jednocześnie pozwoli się użytkownikowi logować na swoje konto z różnych miejsc (czyli nie zależy od używanego sprzętu), oraz jednocześnie nie ułatwi specjalnie współdzielenia (czyli, na przykład, „tajemny” adres strony odpada).

a jeśli by zrobić model subskrypcji per urządzenie? czyli możesz logować się tylko z danego komputera / telefonu, i wykupujesz subskrypcje miesięczną. Rozumiem, ze coś takiego też wymaga utworzenia konta?

Konto to jest nic innego jak jakiś zbiór danych i funkcji dostępny po autoryzacji, najczęściej loginem i hasłem, lub logowaniem z zewnętrzną stroną.

@Althorion ma rację, że jeśli ktoś za coś płaci - to albo kupuje coś dla wszystkich (jak np patroni płacą za czyjś cel, i potem autor upublicznia wynik każdemu), albo w jakiś sposób trzeba rozróżnić osobę która za to płaci. Można to zrobić albo kontem, albo np samym mailem - tzn. po płatności możesz wysłać na maila delikwentowi odpowiedź: albo z tym co kupiłeś (np jakiś bilet, jakąś treść, etc.) albo z danymi dostępowymi do treści, np tymczasowe hasło lub access link.