Zmiany w Google Play i ugoda z Epic: Architektura Third-Party Mobile Billing

Każdy twórca gier mobilnych patrzył na swój miesięczny dashboard przychodów i wzdrygał się na widok 30% opłaty platformowej, która błyskawicznie wyparowywała jego marże. Przez lata deweloperzy Androida byli zamknięci w sztywnym ekosystemie: jeśli chciałeś, aby Twoja gra znalazła się w największym sklepie mobilnym na świecie, musiałeś korzystać z ich własnego systemu billingowego, oddawać ogromną część z mikrotransakcji i budować całą architekturę uprawnień (entitlements) wokół ich specyficznych API.

Ta era oficjalnie dobiega końca. Aby w pełni wykorzystać warunki wprowadzone przez google play changes epic settlement, deweloperzy muszą fundamentalnie przemyśleć swoją infrastrukturę backendową.

Niedawne zakończenie sagi prawnej Epic Games vs. Google zaowocowało nakazanymi przez sąd zmianami, które otwierają ekosystem Androida na oścież. Deweloperzy mogą teraz kierować graczy do zewnętrznych payment gateways, omijać obowiązkowy 30% podatek, a nawet dystrybuować gry za pośrednictwem alternatywnych sklepów z aplikacjami hostowanych bezpośrednio w Google Play.

Ale ta nowo odkryta wolność finansowa wiąże się z poważnymi kosztami technicznymi. Jeśli zrezygnujesz z Google Play Billing, stracisz automatyczną walidację paragonów (receipt validation), offline caching i scentralizowane śledzenie uprawnień, które on zapewniał. Jesteś teraz całkowicie odpowiedzialny za bezpieczne zarządzanie zakupami graczy w wielu bramkach płatniczych.

Oto szczegółowa analiza technicznego wpływu tych zmian oraz tego, jak zaprojektować bezpieczny, niezależny od sklepu backend billingowy, który zapobiega oszustwom i utrzymuje stany świata w synchronizacji.

Techniczny wpływ ugody Epic vs. Google

Zanim zagłębimy się w kod, musimy zrozumieć, co dokładnie zmienia dla architektury Twojej gry nakaz sądowy (obowiązujący od listopada 2024 do listopada 2027).

1. Zewnętrzne routowanie płatności jest teraz legalne

Google nie może już zablokować Twojej gry za umieszczanie linków kierujących graczy do przeglądarki internetowej w celu sfinalizowania zakupu. Oznacza to, że możesz zintegrować dostawców płatności, takich jak Stripe, Xsolla czy PayPal, którzy zazwyczaj pobierają około 2,9% do 5% plus niewielką stałą opłatę za transakcję. W przypadku gry indie typu mid-core generującej 50 000 USD miesięcznie z mikrotransakcji, rezygnacja z 30% opłaty platformowej pozwala zaoszczędzić około 12 500 USD każdego miesiąca.

2. Sideloading i sklepy firm trzecich

Alternatywne sklepy z aplikacjami mogą być teraz dystrybuowane bezpośrednio przez Google Play Store, a Google ma zakaz płacenia producentom urządzeń za wyłączną preinstalację Google Play. Twoi gracze mogą pobrać grę z Epic Games Store, Amazon Appstore lub niestandardowego launchera wydawcy, grając na tym samym urządzeniu z Androidem.

3. Śmierć uprawnień z jednego źródła (Single-Source Entitlements)

Historycznie klient gry mógł po prostu zapytać Google Play Billing Library: „Czy ten użytkownik posiada przepustkę bojową premium?”. Jeśli odpowiedź brzmiała „tak”, odblokowywałeś zawartość.

Teraz gracz może kupić przepustkę bojową przez link Stripe na swoim komputerze, zalogować się do gry pobranej z alternatywnego sklepu Android i oczekiwać, że jego zawartość tam będzie. Walidacja po stronie klienta (client-side validation) oficjalnie umarła. Musisz przejść na architekturę server-authoritative, w której Twój backend jest jedynym źródłem prawdy dla wszystkich ekwipunków graczy.

Architektura niezależnego od sklepu backendu uprawnień

Aby obsługiwać wiele bramek płatniczych, Twój backend potrzebuje solidnego schematu bazy danych, który oddziela transakcję finansową od uprawnienia w grze.

Nigdy nie łącz ekwipunku gracza bezpośrednio z ID paragonu konkretnego sklepu. Zamiast tego użyj pośredniczącej tabeli transakcji.

Zalecany schemat bazy danych

Aby zbudować to ręcznie, będziesz potrzebować trzech głównych tabel w swojej relacyjnej bazie danych (np. PostgreSQL):

• Users: Główny profil gracza.
• Transactions: Rejestruje zdarzenie finansowe. Zawiera GatewayProvider (np. „Stripe”, „Google”, „Xsolla”), GatewayTransactionId, Amount, Currency oraz Status (Pending, Completed, Refunded).
• Entitlements: Rzeczywiste przedmioty w grze, które posiada użytkownik. Zawiera UserId, ItemId, AcquiredViaTransactionId oraz RevokedAt.

Gdy następuje zakup, bramka płatnicza uderza w Twój serwer za pomocą webhooka. Serwer weryfikuje webhook, tworzy rekord Completed w tabeli Transactions, a następnie wstawia odpowiednie przedmioty do tabeli Entitlements.

Implementacja bezpiecznej walidacji webhooków po stronie serwera

Najważniejszą częścią tej nowej architektury jest handler webhooków. Jeśli kierujesz graczy do strony płatności innej firmy, ten zewnętrzny dostawca wyśle żądanie HTTP POST do Twojego backendu po pomyślnym dokonaniu płatności.

Oszuści aktywnie skanują w poszukiwaniu niezabezpieczonych endpointów webhooków. Jeśli Twój endpoint ślepo akceptuje payloady JSON bez weryfikacji podpisów kryptograficznych, napastnicy sfałszują komunikaty o „sukcesie płatności” i przyznają sobie nieskończoną ilość waluty premium.

Oto gotowy do użycia w produkcji przykład w TypeScript z wykorzystaniem Express.js. Ten fragment pokazuje, jak bezpiecznie walidować podpis webhooka Stripe, zapewnić idempotencję (aby gracze nie zostali obciążeni dwukrotnie, jeśli webhook zostanie wywołany dwa razy) i zaktualizować bazę danych gracza.

import express from 'express';
import crypto from 'crypto';
import { PrismaClient } from '@prisma/client';

const app = express();
const prisma = new PrismaClient();
const WEBHOOK_SECRET = process.env.PAYMENT_WEBHOOK_SECRET || '';

// We need the raw body to verify the cryptographic signature
app.post('/api/webhooks/billing', express.raw({ type: 'application/json' }), async (req, res) => {
    const signature = req.headers['x-payment-signature'] as string;
    const rawBody = req.body;

    // 1. Cryptographic Signature Verification
    const expectedSignature = crypto
        .createHmac('sha256', WEBHOOK_SECRET)
        .update(rawBody)
        .digest('hex');

    if (signature !== expectedSignature) {
        console.error("Security Alert: Invalid webhook signature detected.");
        return res.status(401).send('Invalid signature');
    }

    const event = JSON.parse(rawBody.toString());

    // 2. Process only successful payments
    if (event.type === 'payment.success') {
        const { transactionId, playerId, itemId } = event.data;

        try {
            // 3. Database Transaction with Idempotency Check
            await prisma.$transaction(async (tx) => {
                // Check if we already processed this transaction (Idempotency)
                const existingTx = await tx.transaction.findUnique({
                    where: { gatewayTransactionId: transactionId }
                });

                if (existingTx) {
                    console.log(`Transaction ${transactionId} already processed. Skipping.`);
                    return;
                }

                // Log the financial transaction
                const newTx = await tx.transaction.create({
                    data: {
                        gatewayTransactionId: transactionId,
                        provider: 'CustomStripeGateway',
                        status: 'COMPLETED',
                        playerId: playerId
                    }
                });

                // Grant the in-game entitlement
                await tx.entitlement.create({
                    data: {
                        playerId: playerId,
                        itemId: itemId,
                        acquiredViaTransactionId: newTx.id
                    }
                });
                
                console.log(`Successfully granted item ${itemId} to player ${playerId}`);
            });

            return res.status(200).send('Webhook processed');

        } catch (error) {
            console.error("Database error during webhook processing:", error);
            return res.status(500).send('Internal Server Error');
        }
    }

    // Acknowledge other event types without crashing
    return res.status(200).send('Event ignored');
});

Znaczenie utwardzania payloadu (Payload Hardening)

Zauważ, że powyższy kod używa express.raw(), aby przechwycić dokładny strumień bajtów żądania przed sparsowaniem go do JSON. Nawet jedna niewłaściwie umieszczona spacja w payloadzie JSON spowoduje niezgodność skrótu HMAC.

Zabezpieczenie tych endpointów nie jest opcjonalne. Jak widzieliśmy w przypadku poważnych incydentów w branży, brak utwardzenia backendu przeciwko sfałszowanym żądaniom HTTP to gwarantowany sposób na zrujnowanie ekonomii gry. Aby dowiedzieć się więcej o tym, jak wystawione API prowadzą do katastrofalnych exploitów, przeczytaj naszą analizę The Star Citizen Data Breach Explained Architecting Game Backends To Survive Compromises.

Rozwiązanie problemu synchronizacji w czasie rzeczywistym

Rozwiązaliśmy logikę uprawnień na backendzie, ale teraz stajemy przed problemem UX.

Wyobraź sobie ścieżkę gracza:

1. Gracz klika „Kup 1000 monet” w Twojej grze na Androida.
2. Gra otwiera przeglądarkę internetową urządzenia z Twoją niestandardową stroną płatności.
3. Gracz dokonuje zakupu kartą kredytową.
4. Bramka płatnicza wysyła webhook do Twojego serwera.
5. Gracz wraca do aplikacji gry.

Skąd klient gry ma wiedzieć, że zakup się powiódł? Jeśli polegasz na HTTP pollingu (klient pyta serwer „Czy już kupiłem?” co 3 sekundy), wyczerpiesz baterię urządzenia i zasypiesz backend niepotrzebnymi żądaniami.

Zamiast tego Twój backend musi wypchnąć (push) zaktualizowany stan ekwipunku do klienta w dokładnie tej samej milisekundzie, w której zatwierdzana jest transakcja w bazie danych. Wymaga to trwałego połączenia dwukierunkowego. Jeśli budujesz tę infrastrukturę od zera, będziesz musiał zaimplementować warstwę WebSocket, która nasłuchuje zdarzeń w bazie danych i rozsyła je do aktywnej sesji klienta.

Jeśli masz trudności z architekturą tego rozwiązania, możesz dowiedzieć się, jak zaimplementować powiadomienia push w czasie rzeczywistym w naszym przewodniku: Ditch Http Polling An Unreal Engine Websockets Tutorial For Real Time Backends.

5 dobrych praktyk dla Third-Party Mobile Billing

Jeśli migrujesz swoją grę ze standardowej biblioteki Google Play Billing, aby skorzystać z nowych zmian w ekosystemie, przestrzegaj tych pięciu architektonicznych dobrych praktyk:

1. Wymuś ścisłą idempotencję: Na urządzeniach mobilnych stale dochodzi do przekroczenia limitu czasu sieci (network timeouts). Bramka płatnicza może wysłać ten sam webhook „sukcesu” trzy razy, jeśli serwer zbyt długo odpowiada. Zawsze sprawdzaj bazę danych pod kątem TransactionId przed przyznaniem przedmiotów, aby upewnić się, że gracze nie otrzymają przypadkowo wielu kopii przedmiotu.
2. Automatyzuj cofanie uprawnień przy chargebackach: Korzystanie z billingów firm trzecich oznacza, że jesteś odpowiedzialny za obsługę chargebacków i zwrotów. Twój handler webhooków musi nasłuchiwać zdarzeń payment.refunded i automatycznie oznaczać odpowiedni wiersz w tabeli Entitlements jako Revoked. Jeśli to pominiesz, gracze zorientują się, że mogą wycofać płatność z karty kredytowej i zachować walutę premium.
3. Oddziel klienta od bramki płatniczej: Klient gry nigdy nie powinien komunikować się bezpośrednio z API bramki płatniczej. Klient powinien poprosić Twój backend o token sesji płatności, otworzyć widok webowy z tym tokenem i pozwolić backendowi zająć się faktyczną walidacją transakcji.
4. Zaimplementuj Graceful Degradation: Jeśli Twoja baza danych padnie, gra powinna być nadal grywalna. Buforuj uprawnienia lokalnie na urządzeniu za pomocą zaszyfrowanego pliku zapisu, ale zawsze waliduj je względem prawdy po stronie serwera, gdy gracz próbuje wydać walutę premium lub dołączyć do meczu multiplayer.
5. Ujednolic proces wirtualnej waluty: Nie twórz w bazie danych oddzielnych „Google Coins” i „Stripe Coins”. Mapuj wszystkie przychodzące transakcje walutowe na jeden, ujednolicony identyfikator wirtualnej waluty na backendzie, aby uniknąć ogromnych problemów w logice UI gry.

Infrastruktura: Build vs. Buy – rzeczywistość

Ugoda Epic vs. Google to ogromne zwycięstwo dla przychodów deweloperów, ale przenosi ciężar infrastruktury bezpośrednio na Twoje barki.

Budowa wysokodostępnego, niezależnego od sklepu backendu billingowego wymaga skonfigurowania baz danych PostgreSQL, konfiguracji Redis do buforowania idempotencji, zarządzania certyfikatami SSL dla bezpiecznych webhooków i utrzymywania serwerów WebSocket dla aktualizacji klienta w czasie rzeczywistym. Dla małego zespołu indie to łatwo 4 do 6 tygodni dedykowanej pracy nad backendem — czasu, który powinien zostać poświęcony na to, by gra była po prostu fajna.

To jest dokładnie to tarcie architektoniczne, które eliminujemy. Dzięki horizOn te złożone usługi backendowe są wstępnie skonfigurowane. Nasza platforma zapewnia gotowy do użycia, niezależny od sklepu system uprawnień, który bezpiecznie obsługuje walidację webhooków server-to-server, zapobiega duplikowaniu transakcji i automatycznie synchronizuje ekwipunki graczy w czasie rzeczywistym. Zyskujesz korzyści finansowe z billingu firm trzecich bez konieczności stawania się inżynierem DevOps.

Patrząc w przyszłość

Ekosystem gier mobilnych przechodzi najbardziej znaczącą zmianę strukturalną od ponad dekady. „Zamknięte ogrody” w końcu upadają, a deweloperzy, którzy dostosują swoje architektury backendowe tak, aby były niezależne od platformy, odniosą ogromne korzyści finansowe, unikając tradycyjnego 30% podatku platformowego.

Jednak ta wolność wymaga odpowiedzialności technicznej. Autorytet po stronie klienta nie jest już możliwy do utrzymania. Jeśli chcesz przetrwać w świecie wielu sklepów i wielu bramek płatniczych, musisz traktować swój backend jako absolutne źródło prawdy.

Gotowy na skalowanie swojego backendu multiplayer i wdrożenie bezpiecznych, międzyplatformowych uprawnień bez pisania tysięcy linii powtarzalnego kodu infrastruktury? Wypróbuj horizOn za darmo i pozwól nam zająć się architekturą serwerową, abyś mógł skupić się na wydaniu swojej gry.

---

Źródło: Major Google Play Changes as Epic v Google Ends