Słownik lokalizacji SubSovereign

Przewodnik dla tłumaczy (ludzi lub Merlyna). Każdy termin produktu należy tłumaczyć TEN SAMO sposób za każdym razem, we wszystkich dokumentach/stronach/UI — spójność sprawia, że 26 języków brzmi profesjonalnie, a nie maszynowo. Niektóre terminy są standardami branżowymi i pozostają w języku angielskim.

Pozostawić w języku angielskim (NIE tłumaczyć — nazwy własne / uniwersalne terminy techniczne)

• SubSovereign (nazwa produktu)
• API, SDK, webhook, JSON, JWT, Redis, PostgreSQL, GDPR
• Nazwy sklepów i dostawców: Apple, Google, Amazon, Roku, Stripe
• Nazwy metod/pól w SDK i wszelki kod (np. checkEntitlement(), appId)

Tłumaczyć — i tłumaczyć KONSYSTENTNIE (definicje, aby wybrać odpowiedni termin)

• entitlement — dostęp, który użytkownik otrzymał w wyniku aktywnego zakupu/subskrypcji (np. „odblokowane funkcje premium”). Podstawowa koncepcja. Wybrać jeden naturalny termin w języku polskim i używać go wszędzie.
• receipt validation — weryfikacja zakupu ze sklepu po stronie serwera, bezpośrednio z danym sklepem, aby klient nie mógł zostać sfałszowany. Preferować sformułowania „weryfikacja po stronie serwera” lub „weryfikacja na serwerze”.
• app — aplikacja dewelopera zarejestrowana w SubSovereign (tenant). Nie SDK, nie nasz produkt.
• API key — poświadczenie, którego SDK/aplikacja używa do wywoływania API SubSovereign.
• subscription — płatny plan odnawiany cyklicznie.
• access level / tier — poziom dostępu, jaki produkt przyznaje (np. darmowy / premium / pro).
• self-hosted — deweloper uruchamia system na własnej infrastrukturze (w przeciwieństwie do zewnętrznego SaaS).
• sovereign / sovereignty — posiadasz i kontrolujesz swój stos technologiczny oraz dane (w UK/UE, bez zewnętrznej chmury przechowującej dane użytkowników). Kluczowy punkt sprzedaży — tłumaczyć znaczeniowo, zachowując wagę przekazu.
• revenue share — procent przychodów dewelopera pobierany jako opłata. SubSovereign nie pobiera żadnej części — to wyróżnik względem Adapty/RevenueCat. Tłumaczyć jasno (np. „brak udziału w Twoich przychodach”).
• multi-tenant — jedno wdrożenie obsługujące wiele izolowanych aplikacji/organizacji.
• dashboard — internetowe zaplecze, w którym deweloper zarządza aplikacjami, kluczami i analizami.
• paywall — ekran, na którym aplikacja prosi użytkownika o subskrypcję (deweloper buduje go samodzielnie; nasz SDK przekazuje informacje o przysługującym użytkownikowi dostępie).

Ton

Kierowany do deweloperów aplikacji, ale napisany tak, aby mógł go zrozumieć czytelnik nietechniczny — zwięzły, ciepły, pewny. Preferować krótkie zdania. Wyjaśniać dlaczego, a nie tylko jak.

Jak działa SubSovereign

Jeśli sprzedajesz subskrypcje w aplikacji, musisz ciągle odpowiadać na jedno trudne pytanie: co ten użytkownik właściwie opłacił, w tej chwili? SubSovereign udziela odpowiedzi — niezawodnie, na własnej infrastrukturze, bez pobierania udziału w Twoich przychodach. Ta strona wyjaśnia ideę, zanim zaczniesz pisać kod.

Problem, który rozwiązuje

Każdy sklep aplikacji (Apple, Google, Amazon, Roku) obsługuje płatności po swojemu — z własnymi paragonami, regułami odnawiania i przypadkami brzegowymi: darmowe okresy próbne, zwroty, aktualizacje, ponowne próby płatności, udostępnianie rodzinne. Prawidłowe określenie „czy ten użytkownik ma dostęp premium?” we wszystkich sklepach, na każdym urządzeniu, to naprawdę trudne zadanie. I nigdy nie możesz ufać samej aplikacji — każdy może ją zmodyfikować i udawać płacącego klienta.

SubSovereign działa jako pośrednik, który robi to dobrze, dzięki czemu Ty nie musisz budować i utrzymywać tego samodzielnie.

Model mentalny

Jest jedna zasada, od której wszystko zależy:

Aplikacja pyta. Serwer decyduje.

Twoja aplikacja nigdy nie decyduje, czy użytkownik ma dostęp — pyta SubSovereign, a SubSovereign odpowiada na podstawie zweryfikowanych paragonów. Urządzenie użytkownika nigdy nie jest źródłem prawdy.

Elementy systemu

• Dashboard — internetowe zaplecze dla deweloperów. Tutaj rejestrujesz każdą aplikację, tworzysz swoje poziomy dostępu (tiery, które sprzedajesz, np. pro, premium), łączysz je z produktami kupowanymi przez użytkowników w poszczególnych sklepach i projektujesz swój paywall. Tutaj również pobierasz swój klucz API.
• SDK — niewielka biblioteka, którą dodajesz do swojej aplikacji (Android, iOS/tvOS, Roku lub Web/React Native). To „słuchawka” aplikacji łącząca ją z SubSovereign: sprawdzanie dostępu, weryfikacja zakupu, pobieranie paywall, zapisywanie zgody.
• Serwer — samodzielnie hostowany backend SubSovereign. Weryfikuje paragony z każdym sklepem, przechowuje uprawnień, buforuje je dla szybkiego odczytu i odpowiada na pytania aplikacji.
• Sklepy — Apple StoreKit 2, Google Play Billing, Amazon IAP (Fire TV), Roku Pay oraz Stripe (dla sieci). SubSovereign komunikuje się ze wszystkimi, dzięki czemu Twoja aplikacja musi rozmawiać tylko z jednym punktem.

Co się dzieje, gdy użytkownik subskrybuje

1. Użytkownik klika Zasubskrybuj na Twoim paywallu. Twoja aplikacja przeprowadza standardowy proces zakupu przez system płatności sklepu (Google Play, StoreKit itp.) — SubSovereign go nie zastępuje.
2. Sklep przekazuje Twojej aplikacji paragon (token zakupu). Aplikacja przesyła go do SubSovereign przez SDK.
3. SubSovereign przeprowadza weryfikację paragonu — sprawdza autentyczność paragonu pośrednio ze sklepem, serwer do serwera. Sfałszowany lub powtórzony paragon zostaje odrzucony.
4. Jeśli paragon jest autentyczny, SubSovereign zapisuje uprawnień użytkownika — poziom dostępu, który odblokował, kiedy wygasa i czy zostanie odnowiony.
5. Twoja aplikacja pyta: „co ma ten użytkownik?”, SubSovereign odpowiada na podstawie zweryfikowanych danych (buforowanych dla szybkości), a Twoja aplikacja odblokowuje odpowiednie funkcje.

Od tego momentu przy każdym uruchomieniu aplikacji powtarza się krok 5: zapytaj i odblokuj to, co powie odpowiedź. Odnowienia, anulowania i wygaśnięcia są automatycznie odzwierciedlane, ponieważ serwer je śledzi.

Dlaczego samodzielne hostowanie i suwerenność mają znaczenie

SubSovereign działa na Twojej infrastrukturze (hosting w UK/UE, Twoja baza danych), a nie w chmurze strony trzeciej. Oznacza to:

• Posiadasz dane swoich użytkowników. Historia zakupów, uprawnienia i zapisy zgód znajdują się w Twojej bazie danych, pod Twoją kontrolą — co sprawia, że zgodność z RODO to coś, czym dysponujesz, a nie coś, na co liczycie, że zrobi za Ciebie dostawca.
• Brak udziału w przychodach. W przeciwieństwie do hostowanych usług, które pobierają procent od przychodów z subskrypcji, SubSovereign niczego nie pobiera — Ty zatrzymujesz 100% tego, co płacą Twoi użytkownicy.
• Brak uzależnienia od dostawcy. To Twoje wdrożenie; możesz je przeglądać, rozszerzać i przenosić.

Czego to NIE JEST

• Nie jest procesorem płatności. Użytkownicy wciąż płacą przez sklepy aplikacji (lub Stripe w sieci); SubSovereign jedynie weryfikuje i śledzi te zakupy.
• Nie narzuca gotowego paywallu. SubSovereign zdalnie dostarcza treści paywallu (ceny, funkcje, długość okresu próbnego), dzięki czemu możesz je zmieniać bez aktualizacji aplikacji — ale Ty budujesz sam ekran, dokładnie tak, jak chcesz.

Gotowy, aby zacząć?

Przejdź do Pierwsze kroki, aby uruchomić serwer i zarejestrować swoją pierwszą aplikację, a następnie wybierz przewodnik dla swojej platformy: Android, iOS, Web / React Native, Roku, React, React Native, Flutter lub Web Component.