BillingMeld: dlaczego serwer powinien potwierdzać zakupy, a nie aplikacja

Zakup w aplikacji mobilnej zazwyczaj wydaje się prosty wyłącznie dla użytkownika. Kliknięcie przycisku, potwierdzenie płatności, dostęp do funkcji lub subskrypcji — i użytkownik oczekuje, że wszystko będzie działać automatycznie.

Dla dewelopera za tym przyciskiem zaczyna się znacznie bardziej złożony proces. Należy potwierdzić samo zakupy, uwzględnić odnowienia, zakończenie subskrypcji, zwroty, recenzje operacji, zmianę urządzenia i różnice między sklepami Apple i Google.

Kluczowy problem pojawia się, gdy serwer zaczyna uważać, że klienta aplikacja jest jedynym źródłem prawdy.

Jeśli aplikacja poda: »Zakup zrealizowany«, serwer odblokowuje dostęp i nadal opiera się na stanie, które otrzymał raz. Jednak cykl życia zakupu się na tym nie kończy.

Subskrypcja może zostać odnowiona, automatyczne odnowienie wyłączone, płatność zwrócona, a sama operacja — cofnięta przez sklep.

Dlatego w BillingMeld zakupy potwierdza nie aplikacja, lecz serwer.

Klient informuje, ale nie decyduje

W architekturze BillingMeld aplikacja mobilna nie jest głównym źródłem informacji o zakupie.

Klient może przesłać dane o dokonanej operacji, ale to tylko podstawa do weryfikacji. Ostateczną decyzję podejmuje część serwerowa BillingMeld, sprawdzając informacje przez infrastrukturę Apple lub Google.

To jest zasadnicza różnica.

Urządzenie może pracować ze starym stanem, nie otrzymać w porę kolejnej zmiany lub przesłać dane, które już nie odzwierciedlają aktualnego stanu zakupu.

Dodatkowo, klient nie powinien mieć możliwości samodzielnego decydowania, czy użytkownik ma dostęp płatny.

BillingMeld sprawdza np.:

• Czy istnieje faktycznie taki zakup;

• Czy odnosi się do właściwej aplikacji i produktu;

• Czy obowiązuje aktualnie opłacony okres;

• Czy doszło do odnowienia;

• Czy wyłączono automatyczne odnowienie;

• Czy dokonano zwrotu;

• Czy operacja nie została cofnięta;

• Czy nie minął już opłacony okres.

W ten sposób wiadomość od klienta przestaje być dowodem zakupu, a staje się wskazówką do sprawdzenia jego rzeczywistego stanu.

Jedno źródło prawdy dla serwerów

Podłączonym usługom nie trzeba samodzielnie realizować pełnego zakresu integracji z Apple i Google jednocześnie.

Sięga się do BillingMeld i otrzymuje już znormalizowany stan zakupu.

Na przykład: dostęp jest aktywny, opłacony okres się skończył, odnowienie potwierdzone, auto-odnowienie wyłączone lub zakup cofnięty.

To pozwala jasno rozdzielić odpowiedzialność.

Apple i Google są źródłami stanu samej operacji w sklepie. BillingMeld weryfikuje te dane, sprowadza je do wspólnego modelu i zapisuje aktualny stan. Dla końcowego produktu decyzję o dostępie podejmuje już na podstawie statusu BillingMeld.

Dla serwerów produktów oznacza to jednolity kontrakt zamiast wielu niezależnych integracji.

Nie trzeba osobno wdrażać w każdej usłudze reguł App Store, Google Play, a potem starać się dopasować różne formaty, zdarzenia i statusy do wspólnej logiki.

Dlaczego nie można w pełni ufać klientowi

Aplikacja kliencka działa na urządzeniu użytkownika.

Można ją zamknąć, ponownie uruchomić, przywrócić z kopii zapasowej, później zaktualizować lub uruchomić na innym urządzeniu. Może działać przez jakiś czas ze starszym stanem lub w ogóle nie otrzymać zdarzenia, które nastąpiło po początkowym zakupie.

Nawet bez ingerencji użytkownika, klient jest złym źródłem końcowego stanu subskrypcji.

Na przykład, użytkownik wykupił subskrypcję i uzyskał dostęp. Później może dojść do zwrotu lub cofnięcia operacji przez sklep.

Jeśli serwer zna jedynie początkową wiadomość od klienta, będzie uważał zakup za nadal aktywny.

Inaczej, użytkownik może wyłączyć automatyczne odnowienie. Mimo to, opłacony okres musi jeszcze obowiązywać do daty zakończenia.

System oparty na prostym stanie „subskrypcja istnieje / nie istnieje” może zbyt wcześnie zamknąć dostęp lub go pozostawić, mimo że prawo do korzystania wcześniej wygasło.

BillingMeld opiera się na innej logice: klient nie potwierdza własnych praw. Informuje o zdarzeniu, a serwer ustala faktyczny stan zakupu.

Zakup — to nie jedno zdarzenie

Jednym z głównych błędów w architekturze rozliczeń jest traktowanie zakupu jako jednorazowego wydarzenia.

W rzeczywistości ma ono cykl życia.

Na początku pojawia się operacja. Potem jest potwierdzana przez sklep. Rozpoczyna się opłacony okres subskrypcji. Później może dojść do kolejnego odnowienia.

Użytkownik może wyłączyć automatyczne odnowienie, ale korzystać z subskrypcji do końca opłaconego okresu.

Płatność może nie przejść przy kolejnym odnowieniu.

Może nastąpić zwrot.

W niektórych przypadkach zakup może zostać cofnięty.

Dlatego samo stwierdzenie, że „w pewnym momencie istniał zakup”, to za mało.

Serwer musi wiedzieć, co się z nim dzieje teraz.

Cofnięcie zakupu nie umknie obserwacji

Zwłaszcza widoczne jest to przy zwrotach i cofnięciach operacji.

Pierwotny zakup mógł być zupełnie poprawny. Użytkownik faktycznie opłacił produkt i uzyskał dostęp.

Jednak później stan operacji się zmienił.

Jeśli BillingMeld otrzymuje informację o zmianie, aktualizuje własny stan zakupu i, w razie potrzeby, dodatkowo sprawdza dane przez sklep.

Po tym podłączona usługa pracuje już z nowym statusem.

W ten sposób aplikacja nie musi nieustannie wierzyć, że zakup z kilka tygodni czy miesięcy temu był poprawny.

Jeśli sklep już nie uznaje danego prawa za ważne, BillingMeld odzwierciedla to w swoim stanie.

Odwołanie subskrypcji i zakończenie dostępu — to nie to samo

Tu występuje istotna różnica.

Jeśli użytkownik wyłączy automatyczne odnowienie, nie oznacza to zazwyczaj, że dostęp ma zostać od razu zamknięty.

Aktualny opłacony okres może nadal obowiązywać.

W takim przypadku BillingMeld musi zachować informację, że dalsze odnowienia są wyłączone, ale jednocześnie znać datę końca już opłaconego okresu.

Aż do jego zakończenia dostęp nie będzie uważany za nieaktywny, jeśli nie nastąpi nowe potwierdzenie odnowienia.

To jest jeden z przykładów, dlaczego prosta flaga subscription = true dla właściwego rozliczania to za mało.

Stan subskrypcji zawsze musi uwzględniać czas i zdarzenia jej cyklu życia.

Odnowienie to także odrębna weryfikacja

Subskrypcja nie kończy się na pierwszej opłacie.

Serwer musi wiedzieć, czy nastąpiło kolejne odnowienie i czy faktycznie następny opłacony okres został potwierdzony przez sklep.

BillingMeld śledzi te zmiany i aktualizuje stan subskrypcji.

Jeśli odnowienie jest potwierdzone, prawo do dostępu obowiązuje dalej.

Jeśli kolejne pobranie nie nastąpiło lub sklep już nie potwierdza następnego okresu, system nie powinien automatycznie przedłużać dostępu na własną rękę.

Dla użytkownika wygląda to naturalnie: dostęp jest tak długo, jak długo obowiązuje opłacona subskrypcja.

Dla deweloperów oznacza to, że nie muszą wielokrotnie implementować tej samej logiki odnowień w każdej aplikacji.

Przykładowy scenariusz

Użytkownik subskrybuje w aplikacji mobilnej.

Klient otrzymuje dane o zakupie i przesyła je do BillingMeld. Jednak samo to zgłoszenie nie jest jeszcze podstawą do pełnego potwierdzenia zakupu.

BillingMeld sprawdza operację przez odpowiedni sklep.

Jeśli App Store lub Google Play potwierdzi zakup i jego stan jest zgodny z zasadami produktu, BillingMeld zapisuje aktywne prawo.

Podłączona usługa udostępnia użytkownikowi opłacone funkcje.

Stan ten funkcjonuje już niezależnie od początkowej wiadomości klienta.

W przypadku odnowienia, BillingMeld uwzględnia nowy opłacony okres.

Jeśli użytkownik wyłącza automatyczne odnowienie, obowiązuje jeszcze bieżący okres do końca.

W przypadku zwrotu lub cofnięcia operacji, stan ponownie się zmienia.

W tej architekturze aplikacja nie przechowuje własnej, oddzielnej „prawdy” o zakupie. Dysponuje stanem potwierdzonym i zapisanym przez BillingMeld.

Co się dzieje przy zmianie urządzenia

Model serwerowy szczególnie przydatny jest, gdy użytkownik zmienia telefon lub reinstaluje aplikację.

Prawo do zakupu nie powinno istnieć tylko dlatego, że konkretna kopia aplikacji kiedyś dokonała pomyślnej transakcji.

Przy tym reinstalacja nie powinna niszczyć potwierdzonego prawa użytkownika.

Jeśli stan zakupu znajduje się na serwerze i powiązany jest z zatwierdzoną operacją w sklepie, nowe urządzenie może uzyskać dostęp do aktualnego statusu z serwera.

To kolejny powód, by nie trzymać logiki dostępu wyłącznie po stronie klienta mobilnego.

Co to daje deweloperom

Dla zespołów wydających kilka mobilnych aplikacji lub działających na iOS i Android, rozliczenia szybko przekształcają się w odrębny, infrastrukturalny problem.

Należy uwzględnić:

• różne formaty danych Apple i Google,

• potwierdzenie początkowego zakupu,

• odnowienia subskrypcji,

• zakończenie opłaconego okresu,

• wyłączenie automatycznego odnowienia,

• zwroty,

• odwołanie operacji,

• ponowna instalacja aplikacji,

• zmiana urządzenia,

• odzyskiwanie zakupów,

• zmiany stanu, dokonane bez udziału klienta.

BillingMeld wyodrębnia tę logikę do osobnej warstwy specjalistycznej.

Serwery produktów współpracują z nim zgodnie z jednym kontraktem i nie muszą samodzielnie interpretować wszystkich szczegółów każdej platformy płatniczej.

Zmniejsza to ilość kodu powielanego i, co jeszcze ważniejsze, minimalizuje ryzyko, że różne aplikacje tej samej firmy będą inaczej rozumieć ten sam scenariusz płatności.

Najważniejszy jest stan prawny, a nie potwierdzenie

W tej architekturze najbardziej zainteresowała mnie zmiana od sprawdzania pojedynczego zakupu na kontrolę aktualnego stanu.

Historia płatności sama w sobie nie odpowiada na główne pytanie produktu:

czy użytkownik ma prawo do płatnej funkcji w tym momencie?

Operacja może mieć sukcesywny, początkowy zakup, ale końcowy okres może się już kończyć.

Subskrypcja może mieć wyłączone odnowienie automatyczne, ale wciąż być aktywny opłacony czas.

Może istnieć potwierdzone odnowienie.

Może wystąpić zwrot.

Sklep może cofnąć operację.

Dlatego najważniejszym obiektem staje się nie potwierdzenie i nie pierwotna odpowiedź klienta, lecz aktualne prawo użytkownika oparte na zatwierdzonym stanie zakupu.

To stan, który BillingMeld przekazuje innym usługom.

BillingMeld jako granica między sklepami a produktami

W efekcie powstaje dość wyraźna granica architektoniczna.

Z jednej strony znajdują się App Store i Google Play z własnymi formatami, zdarzeniami, zasadami i cyklami życia zakupów.

Z drugiej — aplikacje i wewnętrzne usługi, które najczęściej potrzebują znacznie prostszej odpowiedzi: jakie prawa ma użytkownik w tym momencie.

Między nimi znajduje się BillingMeld.

Przyjmuje dane z sklepów, weryfikuje je, sprowadza do własnego modelu i zwraca już znormalizowany wynik.

To pozwala produktom nie znać wszystkich wewnętrznych szczegółów każdej platformy płatniczej.

Dlaczego to ważne dla użytkownika

Technicznie, poprawna architektura rozliczeń powinna być dla użytkownika praktycznie niewidoczna.

Jeśli zakup jest potwierdzony i obowiązuje opłacony okres, dostęp powinien działać.

Jeśli użytkownik wyłączy automatyczne odnowienie, opłacony czas nie powinien zniknąć przed czasem.

Po udanym odnowieniu dostęp powinna być kontynuowana.

Jeśli sklep potwierdzi zwrot lub odmowę, system musi to poprawnie odzwierciedlić.

Przy zmianie urządzenia lub reinstalacji aplikacji, użytkownik nie powinien musieć ręcznie udowadniać każdej części infrastruktury, że zakup faktycznie istnieje.

W rezultacie, zasada jest dość prosta:

klient informuje o zakupie, sklep jest zewnętrznym źródłem jego stanu, BillingMeld to sprawdza i normalizuje, a reszta usług podejmuje decyzję opierając się na zatwierdzonych danych BillingMeld.

Dlatego BillingMeld to nie tylko kolejny moduł płatności.

To warstwa zaufania po stronie serwera pomiędzy aplikacją mobilną, sklepami Apple i Google oraz produktami, które potrzebują precyzyjnej wiedzy, jakie prawa płatne przysługują obecnie użytkownikowi.

Więcej o projekcie: billingmeld.de.