Mikropłatności Google Play

Czy jest na forum osoba, która zaimplementowała mikropłatności w aplikacji rozprowadzanej przez Google Play?
Jeśli tak, to może zechciałaby się podzielić wiedzą na ten temat lub może podjęłaby się współpracy we wdrożeniu tego w mojej aplikacji?

A interesują Cię subskrypcje?

Jeszcze nie wiem.
Mam bank fotografii https://foto.3n.com.pl. Z Google Analitycs wynika, że więcej niż 50% ruchu jest z urządzeń mobilnych.
Strona jest na to przygotowana i wszystkie operacje można wykonać na komórce.
Ale to jednak jest uciążliwe (zakładanie konta, logowanie się, itd.).
W związku z tym od kilku tygodni pracuję nad aplikacją mobilną.
Aplikacja już jest. Można przeglądać zdjęcia zawarte w banku. Zdjęcie można ustawić jako tapetę lub pobrać do pamięci.
I teraz zastanawiam się co dalej. Czy dać właśnie abonament, za który byłby nieograniczony (lub ograniczony) dostęp do wszystkich zasobów, czy po prostu mikropłatność za pojedyncze pobranie (oczywiście z licencją do komercyjnego wykorzystania), czy może jeszcze inaczej (reklamy?).
Nie mam tu żadnych doświadczeń, zakładam jednak, że aplikacja może być lepszym rozwiązaniem niż strona internetowa, która jest, bo i zasięg większy i prostota zakupów, no i 50% ruchu z urządzeń mobilnych.
Chętnie więc posłuchałbym doświadczeń innych w tym temacie.

Jeśli chodzi o subskrypcje to możesz za pomocą tego zrobić takie abonamenty miesięczne, roczne, gdzie ludzie płacą i mają dostęp do zdjęć bez ograniczeń i zaplacili tylko raz. Wtedy tworzysz w google produkt określasz jego cenę i tyle.
Jeśli chodzi o dostęp do pojedyńczych zdjęć lub jakiś paczek. To nazywa się to in app purchases. Tworzysz jakąś opcję np 10 fotek w paczce i podpinasz pod tę paczkę opcję płatności IAP.

Google dostarcza mechanizm weryfikowania płatności czy user poprawnie zapłacił za produkt. Dostarcza również inforamcje o tym czy subskrypcja jest ważna czy nie. Jeśli chodzi o IAP to niestety jeśli zrobisz IAP dla paczki 10 zdjęć to będziesz potrzebować backend który będzie trzymał informacje o tym ile user już wziął zdjęć z banku.

W tej chwili mam tak, że klient kupuje tzw. kredyty, a jakie konkretnie pliki wybierze, to nie ma znaczenia, byle zmieścił się w kupionych kredytach.
To już jest zrobione i to działa (tzn. zlicza, pokazuje co pobrano, itd.)
Może taki kredyt (lub kilka kredytów) mogłoby być "produktem"?

A jak wygląda u nich proces uruchamiania oprogramowania. Jest jakaś "piaskownica" do testowania?

Tak, da sie to zamknąć w produkcie. To dokładnie tak samo jak kupowanie coinów w grze
https://medium.com/@vleonovs8/tutorial-google-play-billing-in-app-purchases-6143bda8d290

Co do testowania, to jest cały system:
https://developer.android.com/google/play/billing/billing_testing

Dzięki.
Zastanawiam się jakby z tymi paczkami było. Żeby wiedzieć ile wziął, to w tej chwili mam zakładanie konta, logowanie, itd.
A tego właśnie chciałbym uniknąć. Pewno z informacją o płatności przychodzi jakiś identyfikator usera i dałoby się na tej podstawie wszystko obsłużyć (żeby było bez zakładania konta w banku i logowania się do niego przed zakupami)?
Czyli tak - odpalam aplikację, wybieram zdjęcie, klikam "Pobierz" - mam komunikat "Nie masz kredytów, czy chcesz je zakupić?
Klient odpowiada TAK - mam nowy ekran z cenami kredytów (im więcej w paczce, tym taniej).
Klient wybiera jakiś pakiet. Z konta schodzi mu kasa, u mnie jest informacja że taki user kupił taki pakiet. Czy z tą informacją przychodzi jakiś AndroidID, albo UserID?
I co dalej. Kiedy wejdzie ponownie do aplikacji i będzie chciał pobrać zdjęcie, to aplikacja powinna przesłać do serwera ten ID i na tej podstawie wydać mu pozostałe zdjęcia.
Da się tak zrobić?

Google nie dopisuje żadnego user id. Jesli chcesz taki miec musisz o to usera poprosić, żeby np zalogował się googlem do Twojej apki. Ewentualnie robisz własny backend z własnymi userami i wtedy wiążesz płatność do usera.
Jak user ma kupiony produkt to jesteś w stanie pobrać wszystkie jego aktywne produkty/subskrypcje na koncie google i po tym sprawdzić czy ma nadal coś aktualne.

Mam zrobioną rejestrację i logowanie (na stronie), ale właśnie tego (zakładania konta i logowania) chciałbym uniknąć. Bo tu jest wąskie gardło. Ludziom nie chce się zakładać kont.
Dlatego liczę na jakieś rozwiązanie polegające na tym, że skoro ktoś zalogował się do sklepu i zapłacił i całe rozliczenie jest przez ten sklep, to żeby nie musiał już u mnie się logować.
Czy jak user wejdzie za jakiś czas do aplikacji, to da się bez logowania przypisać mu wcześniejsze zakupy?
Innymi słowy, czy API zapewnia to, że jego aktywność w mojej aplikacji jest możliwa do śledzenia?

Całe rozliczenie jest robione przez Google. Przy każdym otwarciu aplikacji jesteś w stanie pobrać informacje o tym jaki produkt i w jakim stanie użytkownik ma na swoim koncie googlowym. NIe ma tam jednak żadnych informacji na temat jego Id. Takie rzeczy musiałbyś trzymać na swoim backendzie. Google dostarcza mechanizm płatności wraz z weryfikacją czy aby przypadkiem nie wygasło, a jak wygasa to masz taką informację.

To jeszcze dodam (kiedyś podchodziłem do projektu związanego z mikropłatnościami, ale temat upadł, więc mam jedynie jakiś fragment wiedzy teoretycznej), że wiele osób radzi nie polegać jedynie na informacjach zwracanych przez Google. Podobno są jakieś programy/hacki, które fałszują komunikację z serwerem płatności Google i w ten sposób aplikacja dostaje info, że płatność została dokonana, ale realnie żadna kasa nie wpłynie. Wielu szczegółów nie pamiętam, ale tak na szybko znalazłem https://github.com/soomla/android-store/issues/47:

There is an android crack software named 'Freedom(http://system.in-appstore.com/freedom/)'. It can crack google in app billing in my game app, when the user ask for a purchase, it will simulate a success payment notify to my app, then my app will add gems for the user, but google backend doesn't receive any payment.

.

Same issue here, our users have simulated "$1.354" in payments in just two days. In my opinion, this means that it is "serious and widespread" and it should be prioritized

Dlatego dobrze jest albo weryfikować pojawienie się kasy na koncie, albo skorzystać z alternatywnej metody płatności - jakieś PayU czy czegoś w tym stylu.

A co do zakładania konta - nie musisz tego robić jawnie, ale i tak możesz trzymać informacje o użytkowniku. Nie wiem jak to się robi, ale jest taka możliwość (może np. po IMEI telefonu, albo jakieś unikalne ID systemu). Jest taka gra jak https://play.google.com/store/apps/details?id=com.playrix.fishdomdd.gplay&hl=pl - kiedyś sobie zainstalowałem, trochę pograłem i mi się znudziło. Ale że dzieciaki chciały sobie popykać, to chciałem wyczyścić moje osiągnięcia i dać im grę ze stanem początkowym, żeby mogli sobie zaczynać od totalnie zera. Niestety, gra jest (albo przynajmniej była, nie wiem jak to wygląda obecnie, opisywana sytuacja miała miejsce jakieś 2 lata temu) jakoś zabezpieczona - ani czyszczenie jej pamięci, ani odinstalowanie, ani nawet wywalenie z listy aplikacji z poziomu sklepu Google nic nie dawało, po reinstalacji byłem zawsze w tym miejscu, na którym skończyłem ostatnio.
Powtarzam - nie wiem, jak oni to zrobili, ale jest to dowód, że takie coś jest możliwe. Czyli możesz pilnować zakupów/kredytów danego usera nawet bez konieczności zakładania przez niego jawnie konta. Minusem jest to, że taki zakup będzie powiązany z danym urządzeniem (albo może z kontem Google).

cerrato napisał(a):

... wiele osób radzi nie polegać jedynie na informacjach zwracanych przez Google. Podobno są jakieś programy/hacki, które fałszują komunikację z serwerem płatności Google i w ten sposób aplikacja dostaje info, że płatność została dokonana, ale realnie żadna kasa nie wpłynie. Wielu szczegółów nie pamiętam, ale tak na szybko znalazłem https://github.com/soomla/android-store/issues/47:

Sam Google https://developer.android.com/google/play/billing/billing_library_overview#Verify mówi o dwóch sposobach weryfikacji. Jedno po stronie backendu, gdzie to Twój backend sprawdza poprawność płatności. Drugie po stronie urządzenia, ale tutaj znów trzeba trzymać klucz w apce.

Sam Google https://developer.android.com[...]lling_library_overview#Verify mówi o dwóch sposobach weryfikacji

No ale właśnie mi chodziło o to, żeby może nie opierać się na mechanizmach dostarczanych przez Google, tylko skorzystać z czegoś zewnętrznego, całkowicie od Google niezależnego. Wiele aplikacji tak robi - chociażby (z tego, czego sam używam) http://www.mobilet.pl/ - gdy chcę doładować kasę przeznaczoną na parkowanie, to wchodzę w aplikacji w zakładkę "saldo" (czy jakoś tak), potem wciskam "doładuj", apka mnie przenosi do jakiegoś portalu płatności online, tak w minutę doładowuję konto i już po powrocie do apki, saldo mam zwiększone. Nie jest to wcale dużo więcej zamieszania niż z płaceniem przez Google, a masz 99,48% pewności, że płatność naprawdę została dokonana.

Jest jeszcze jeden plus braku integracji z płatnościami Google.
A mianowicie Google skubie 30% każdej transakcji :D żdzierstwo :D
Jak już ustaliliśmy @Stefan_3N nie jest korporacją więc negocjacje nie wchodzą w grę :P

Stefan_3N napisał(a):

Ale to jednak jest uciążliwe (zakładanie konta, logowanie się, itd.).

Na telefonie to nie jest uciążliwe bo każdy jest zalogowany do konta google i nie trzeba wpisywać loginów i haseł wystarczy potwierdzenie (można też logować przez fejsbuka i inne instagramy). Przy kolejnych uruchomieniach aplikacji user jest już zalogowany.
To przykład gotowego backendu https://firebase.google.com/docs/auth/android/firebaseui

Mógłbym rozwinąć to co już mam. Mam system rejestracji, wystawiania faktur, itd.
Mam też przygotowany sprzęg z PayPalem.
Ale nie jestem zadowolony z tego rozwiązania.
Żebym mógł wystawić fakturę muszę mieć więcej danych niż tylko login i hasło.
Czyli klient musi przejść przez cały formularz, zaakceptować zgody, itd.
Zanim to zrobi, to się rozmyśli.
Dlatego kombinuję żeby to uprościć.
Klient już podał swoje dane rejestrując się w sklepie. Więc oddałbym im te 30% za to, żeby całe rozliczenie między sklepem, a klientem było już poza mną. Żebym ja nie musiał wystawiać faktury na każdy pojedynczy plik, a klient otrzymywałby ode mnie tylko licencję w formie elektronicznej (dowodem zakupu dla klienta byłyby dokumenty z Google Play).
Google w jakiś sposób identyfikuje urządzenia. Gdyby ten identyfikator spływał razem z potwierdzeniem zapłaty, to problem miałbym rozwiązany (tak mi się przynajmniej wydaje).

Dziękuję wszystkim za poświęcony czas.

Żebym mógł wystawić fakturę muszę mieć więcej danych niż tylko login i hasło.

Ale nie musisz przecież wystawiać faktury za każdym razem.
Już o tym pisałem, ale powtórzę - wzorem może być mobilet. Zainstaluj to sobie na komórce, a potem doładuj swoje konto. Może trzeba podać parę danych podczas instalacji (używam tego już pewien czas, więc nie pamiętam), ale potem samo doładowanie idzie totalnie bezstresowo. Poświęć 5PLN i zobacz, jak to działa ;)

To nie chodzi o mnie i o to że ja chcę wystawiać fakturę.
Specyfika branży jest taka, że jak ktoś kupuje zdjęcie, to po to żeby mieć je w pełni na tzw. "legalu" (inaczej wziąłby coś z banku darmowego).
Jak chcesz np. wydrukować zdjęcie w dużym nakładzie i jesteś firmą, która robi usługowo składy i masz zlecenie, to klient (zlecający) odbierając pracę może poprosić Ciebie (wykonawcę) o dowód, że zdjęcie jest legalne (bo boi się ewentualnych późniejszych konsekwencji).
Jest wiele darmowych banków foto, ale zapisy licencyjne są tam często nie jasne. W większości z nich jest zapis "nie do wykorzystania komercyjnego", albo są ograniczenia co do nakładu, itp. Trzeba się dobrze wczytać, żeby nie wpaść na minę.
I teraz - jak drukujesz coś w dużym nakładzie, to nie mając "podkładek" na wszystkie użyte materiały po prostu ryzykujesz.
Dlatego niektórzy wolą banki komercyjne, bo dostajesz licencję i fakturę, która jest dla Ciebie ochroną.
Więc chciałbym to zrobić tak, żeby z jednej strony uniknąć formalności związanych z rejestracją, ale z drugiej, żeby kupujący miał jednak konkretny dowód zakupu (najlepiej związany z konkretnym plikiem), który mógłby wpiąć gdzieś do swojej dokumentacji, który dawałby mu pewność, że kupił zdjęcie w pełni legalnie.

No OK, ale tak z drugiej strony - przecież takie faktury u Ciebie się generują automatycznie, prawda? Bo nie uwierzę, że koleś wypełnia pola w formularzu, a potem Ty sobie ręcznie odpalasz Optimę (czy inną Symfonię) i ręcznie fakturę klepiesz ;) A skoro to leci z automatu, to nadal nie rozumiem, w czym jest problem.

Problemów jest kilka.
To, że masz już wystawioną tę fakturę, to połowa sukcesu. Teraz musisz ją zaksięgować.
Czyli system księgowy. A jak faktura jest od zagranicznego kontrahenta, to zaczyna się jazda. Przewalutowania, sprawdzania skąd to jest, jaka jest sytuacja podatkowa, itd. A wszystko dla rozliczenia 1$.
Oczywiście - można zaprogramować cały system księgowy :-), no ale po to są właśnie te gotowe rozwiązania, żeby każdy od zera tego nie robił.

No i to o czym wspomniałem na początku. Żeby wystawić mu fakturę, to potrzebuję danych. Czyli klient musi wypełnić szczegółowy formularz (z adresem, itd.). Do tego regulamin zakupów (najlepiej w jego języku i z uwzględnieniem niuansów prawnych w danym kraju).

Zdecydowanie łatwiej byłoby to rozliczyć przez pośrednika.
Ja rozliczam się jedną fakturą w miesiącu z pośrednikiem, a pośrednik, na życzenie klienta wystawia mu dokument w jego języku z wyszczególnioną informacją za co to jest.
I za to rozliczenie oddałbym te 30%, tylko żeby to działało.