Game dev

Cum adaugi corect cumparaturile in aplicatie (Apple, Google, RevenueCat): lectii dintr-un portofel autoritativ pe server

Publicat 20 aprilie 2026 · 8 min citire

Cand am inceput sa adaugam economia de jetoane in jocurile noastre din Neon Arcade (games.hashcoreai.com), prima decizie a fost si cea mai importanta: clientul nu are voie sa-si modifice niciodata propriul sold. Pare evident scris asa, dar majoritatea tutorialelor despre cumparaturi in aplicatie te incurajeaza exact spre opusul: cumperi un pachet, primesti un callback in app, scrii numarul de monede in stocarea locala. Functioneaza la demo si pica la prima persoana care deschide consola de developer.

Acest articol este un devlog onest despre cum am construit corect partea de monetizare: cumparaturi prin Apple, Google si RevenueCat, plus reclame recompensate care acorda jetoane virtuale. Totul se invarte in jurul jetoanelor din joc, o moneda pur virtuala folosita pentru a debloca clase de personaje, nave si upgrade-uri. Nu este vorba de bani reali, de minat sau de investitii.

Regula zero: portofelul traieste pe server, nu in client

Modelul nostru este simplu de descris: exista un singur document per utilizator in Firestore, iar acolo se afla soldul de jetoane si lista de deblocari. Regulile de securitate Firestore arata exact asa:

allow read: if request.auth != null && request.auth.uid == uid;
allow write: if false;

Clientul poate citi propriul portofel, dar nu poate scrie absolut nimic. Singura cale prin care soldul se schimba este o functie Cloud (Admin SDK), declansata fie de o cumparatura validata, fie de un milestone in joc, fie de o reclama verificata. Cand vrei sa cheltui jetoane, apelezi o functie spendTokens care, intr-o tranzactie, verifica soldul, refuza daca nu ajunge si scade costul corect din tabelul de preturi de pe server. Clientul trimite doar un id de obiect, niciodata o suma.

De ce conteaza: daca soldul sta in client, orice utilizator poate modifica un numar in memorie sau in localStorage si poate debloca tot continutul gratuit. Cu portofelul pe server, cel mai rau lucru pe care il poate face un client compromis este sa minta despre ce vede pe ecran, nu despre ce detine cu adevarat.

Cumparaturile pe web: RevenueCat Web Billing + Stripe

Pe web nu poti folosi billing-ul nativ Apple sau Google, asa ca pe hub-ul nostru cumparaturile trec prin RevenueCat Web Billing, care prezinta un checkout Stripe gazduit. Codul din browser este deliberat subtire: configureaza RevenueCat pentru uid-ul Firebase al utilizatorului, listeaza pachetele dintr-un offering numit store si prezinta checkout-ul. Atat. Nu atinge niciun sold.

Un detaliu pe care l-am invatat pe drum: app_user_id trebuie sa fie uid-ul Firebase. Clientul apeleaza Purchases.logIn(uid) inainte de cumparatura, altfel RevenueCat genereaza un id anonim de tipul $RCAnonymousID:... si webhook-ul ar credita un portofel pe care aplicatia, care cauta dupa auth.uid, nu il poate citi niciodata. Cheile publice SDK sunt sigure de pus in cod, fiindca o cheie publica nu poate face decat ce poate face un client autentificat oricum, iar portofelul ramane autoritativ pe server.

Webhook-ul: regulile care fac diferenta intre corect si dezastru

Toata greutatea cade pe webhook-ul care primeste evenimentele de la RevenueCat si crediteaza portofelul. Aici sunt patru reguli pe care le respectam strict, fiecare nascuta dintr-un mod concret de a esua.

1. Idempotenta pe identitatea tranzactiei, nu pe id-ul evenimentului

Retrasmiterile sunt normale: daca webhook-ul tau raspunde lent sau cu o eroare, RevenueCat (ca orice sistem serios) reincearca. Daca dedublezi pe id-ul evenimentului, te poti pacali singur, fiindca aceeasi cumparatura poate genera mai multe evenimente. Noi construim cheia de dedublare din identitatea imuabila a tranzactiei plus tipul evenimentului: transaction_id:type. Inainte de a scrie ceva, tranzactia verifica daca exista deja un marcaj cu aceasta cheie si, daca da, nu face nimic.

Esecul prevenit: creditarea dubla. Fara aceasta cheie, o singura retransmisie inseamna ca utilizatorul primeste pachetul de doua ori. Inmultit cu cateva mii de tranzactii, economia jocului devine fictiune.

2. Esueaza inchis pe environment: doar PRODUCTION misca sold real

RevenueCat trimite evenimente atat din PRODUCTION, cat si din SANDBOX (cumparaturi de test, gratuite, repetabile la infinit). Noi creditam portofelul real doar daca environment este exact PRODUCTION. In afara emulatorului, daca environment lipseste sau e altceva, tratam evenimentul ca non-productie si raspundem cu un ack care nu misca nimic.

Exista un singur opt-in temporar, RC_ALLOW_SANDBOX, pe care il folosim in faza de testare cu carduri Stripe de test, si care trebuie sa fie oprit inainte de lansare publica. Daca uiti acel comutator pornit, oricine poate face cumparaturi sandbox gratuite si isi umple portofelul real.

Esecul prevenit: jetoane gratuite la scara. Un sandbox deschis catre productie inseamna ca economia ta plateste pentru carduri care nu au costat nimic.

3. Trateaza refund-urile: debit clamp la zero

Un refund nu vine ca un eveniment separat curat, ci ca o anulare (CANCELLATION) care poarta acelasi product_id ca achizitia. Asta inseamna ca nu poti decide credit vs. revocare dupa produs, ci dupa tipul evenimentului. Cand vine un refund pentru un pachet de jetoane, debitam ce am acordat, dar il limitam la soldul curent, astfel incat un sold deja cheltuit sa nu poata deveni negativ.

Diferenta neacoperita (utilizatorul a cheltuit jetoanele inainte de a cere refund) o inregistram ca owed pentru revizuire de frauda. Este un compromis acceptat si delimitat, nu un clawback dur care ar lasa portofelul cu numere negative bizare.

Esecul prevenit: solduri negative si exploit-uri de tipul cumpara-cheltuie-cere-refund care ar putea sparge logica de cheltuiala in jos.

4. Respinge id-urile care nu sunt uid Firebase

Daca app_user_id incepe cu $RCAnonymousID, contine slash sau e gol, ignoram evenimentul. Un portofel-fantoma creditat pe un id pe care aplicatia nu il poate citi niciodata este pur si simplu bani aruncati si suport client garantat.

Regula	Cum o implementam	Esecul evitat
Idempotenta	Cheie `transaction_id:type`, verificata in tranzactie	Creditare dubla la retransmisie
Fail closed pe environment	Doar PRODUCTION crediteaza; sandbox e opt-in temporar	Jetoane gratuite din sandbox
Refund-uri	Debit clamp la zero, restul ca `owed`	Solduri negative / exploit refund
Identitate utilizator	Respinge id-uri non-Firebase	Portofele-fantoma necitibile

Pe deasupra, scriem un ledger determinist: cate un rand per tranzactie si tip, cu sursa, suma si tip, ca sa putem reconcilia oricand. Tot ce misca portofelul lasa o urma.

Reclamele recompensate: niciodata nu crede clientul

Pe partea nativa, oferim jetoane pentru vizionarea unei reclame recompensate. Tentatia evidenta este: cand SDK-ul AdMob spune in client ca reclama s-a terminat, crediteaza jetoanele. Nu facem asta niciodata. In schimb folosim Server-Side Verification (SSV) de la AdMob: cand utilizatorul termina reclama, Google (nu clientul) trimite un callback GET semnat catre o functie Cloud a noastra.

Acel callback este semnat cu ECDSA P-256 peste SHA-256. Verificam semnatura impotriva cheilor publice ale Google (cache-uite cu TTL si reincarcate la o cheie necunoscuta) inainte de a misca un singur jeton. Daca semnatura nu e valida, raspundem 403 si nu se intampla nimic.

Trei detalii care inchid restul gaurilor:

Suma este o constanta de server. Ignoram complet reward_amount din callback si creditam o valoare fixa definita la noi. Un client nu poate cere sa fie recompensat cu mai mult.
Cooldown. Intre doua recompense creditate impunem un interval minim (la noi cinci minute), aplicat si in UI, dar verificat si pe server.
Plafon zilnic. Un numar maxim de recompense creditate per zi UTC, ca plafon anti-abuz. Nu se asteapta sa fie atins de un jucator normal, dar opreste un script care ar incerca sa stranga la nesfarsit.

Si aici, dedublam pe transaction_id: un replay al aceleiasi recompense deja procesate nu adauga nimic. Inregistram fiecare eveniment, fie ca a fost creditat, fie ca a fost limitat de cooldown sau plafon, pentru audit.

Esecul prevenit: un client modificat care striga ca a vazut o reclama si minteaza jetoane gratuit. Cu SSV, singura sursa care poate misca portofelul este un callback semnat de Google pentru o vizionare reala.

Checklist scurt inainte de lansare

Soldul si deblocarile traiesc pe server; regulile clientului sunt write: false.
Clientul trimite id-uri de produs/obiect, niciodata sume; sumele se cauta in tabele pe server.
Webhook-ul dedubleaza pe identitatea tranzactiei plus tip, intr-o tranzactie de baza de date.
Doar evenimentele PRODUCTION misca sold real; orice comutator de sandbox este oprit.
Refund-urile debiteaza cu clamp la zero si inregistreaza diferenta pentru revizuire.
Reclamele recompensate trec prin SSV semnat, cu suma de server, cooldown si plafon zilnic.
Fiecare miscare lasa un rand in ledger, reconciliabil.
Stergerea contului curata datele de pe server (cerinta Apple si Google Play).

Niciuna dintre aceste reguli nu este complicata individual. Greutatea sta in a le respecta pe toate in acelasi timp, fiindca fiecare gaura inchide un mod diferit de a pierde bani sau de a strica economia jocului. Acesta este, de fapt, intregul mesaj: monetizarea corecta nu inseamna cod sofisticat, inseamna sa nu ai incredere in client niciodata, nicaieri.

Daca construiesti monetizare pentru o aplicatie iOS, Android, Flutter sau web si vrei sa o faci corect din prima, povesteste-ne despre proiect la contact@hashcoreai.com, sau arunca o privire la cum arata in practica in jocurile noastre de pe games.hashcoreai.com.

When we started adding the token economy to our Neon Arcade games (games.hashcoreai.com), the first decision was also the most important one: the client is never allowed to change its own balance. It sounds obvious written down, but most in-app-purchase tutorials nudge you toward exactly the opposite — buy a pack, receive a callback in the app, write the coin count to local storage. It works in the demo and breaks the first time someone opens the developer console.

This article is an honest devlog about building the monetization layer the right way: purchases through Apple, Google and RevenueCat, plus rewarded ads that grant virtual in-game tokens. Everything here is about in-game tokens — a purely virtual currency used to unlock character classes, ships and upgrades. It is not about real money, mining, or investing.

Rule zero: the wallet lives on the server, not in the client

Our model is easy to describe: one document per user in Firestore holds the token balance and the list of unlocks. The Firestore security rules look exactly like this:

allow read: if request.auth != null && request.auth.uid == uid;
allow write: if false;

The client can read its own wallet, but it cannot write anything at all. The only way the balance changes is through a Cloud Function (Admin SDK), triggered by a validated purchase, an in-game milestone, or a verified ad. To spend tokens, the client calls a spendTokens function that, inside a transaction, checks the balance, refuses if it is too low, and subtracts the correct cost from a price table that lives on the server. The client only ever sends an item id, never an amount.

Why it matters: if the balance lives in the client, any user can flip a number in memory or localStorage and unlock all the content for free. With the wallet on the server, the worst a compromised client can do is lie about what it shows on screen, not about what it actually owns.

Web purchases: RevenueCat Web Billing + Stripe

On the web you cannot use native Apple or Google billing, so on our hub purchases run through RevenueCat Web Billing, which presents a hosted Stripe checkout. The browser code is deliberately thin: it configures RevenueCat for the user's Firebase uid, lists the packages from an offering called store, and presents the checkout. That is all. It never touches a balance.

One detail we learned the hard way: app_user_id must be the Firebase uid. The client calls Purchases.logIn(uid) before buying, otherwise RevenueCat generates an anonymous id like $RCAnonymousID:..., and the webhook would credit a wallet the app — which keys on auth.uid — can never read. Public SDK keys are safe to embed, because a public key can only do what an authenticated client could do anyway, and the wallet stays server-authoritative.

The webhook: the rules that separate correct from disaster

The full weight falls on the webhook that receives RevenueCat events and credits the wallet. There are four rules we follow strictly, each born from a concrete way to fail.

1. Idempotency on the transaction identity, not the event id

Retries are normal: if your webhook is slow or errors out, RevenueCat (like any serious system) retries. If you dedup on the event id, you can fool yourself, because the same purchase can produce several events. We build the dedup key from the immutable transaction identity plus the event type: transaction_id:type. Before writing anything, the transaction checks whether a marker with that key already exists and, if so, does nothing.

Failure prevented: double crediting. Without this key, a single retry means the user gets the pack twice. Multiply that across a few thousand transactions and the game economy becomes fiction.

2. Fail closed on environment: only PRODUCTION moves real balance

RevenueCat sends events from both PRODUCTION and SANDBOX (free test purchases that are infinitely repeatable). We credit the real wallet only if environment is exactly PRODUCTION. Outside the emulator, if environment is missing or anything else, we treat the event as non-production and reply with an ack that moves nothing.

There is a single temporary opt-in, RC_ALLOW_SANDBOX, that we use during the testing phase with Stripe test cards, and that must be turned off before public launch. If you leave that switch on, anyone can make free sandbox purchases and top up their real wallet.

Failure prevented: free tokens at scale. A sandbox left open to production means your economy is paying out for cards that cost nothing.

3. Handle refunds: debit, clamped at zero

A refund does not arrive as a clean separate event — it comes as a cancellation (CANCELLATION) carrying the same product_id as the purchase. That means you cannot decide credit vs. revoke by product; you decide by event type. When a refund of a token pack arrives, we debit what we granted, but we clamp it to the current balance, so an already-spent balance can never go negative.

The unrecovered shortfall (the user spent the tokens before refunding) is recorded as owed for fraud review. It is a bounded, accepted tradeoff, not a hard clawback that would leave the wallet with weird negative numbers.

Failure prevented: negative balances and buy-spend-refund exploits that could break the spend logic downward.

4. Reject ids that are not a Firebase uid

If app_user_id starts with $RCAnonymousID, contains a slash, or is empty, we ignore the event. A ghost wallet credited on an id the app can never read is just thrown-away money and guaranteed support tickets.

Rule	How we implement it	Failure avoided
Idempotency	`transaction_id:type` key, checked inside the transaction	Double crediting on retry
Fail closed on environment	Only PRODUCTION credits; sandbox is a temporary opt-in	Free tokens from sandbox
Refunds	Debit clamped at zero, remainder logged as `owed`	Negative balances / refund exploit
User identity	Reject non-Firebase ids	Unreadable ghost wallets

On top of that, we write a deterministic ledger: one row per transaction and type, with source, amount and type, so we can reconcile any time. Everything that moves the wallet leaves a trace.

Rewarded ads: never trust the client

On the native side, we grant tokens for watching a rewarded ad. The obvious temptation is: when the AdMob SDK says in the client that the ad finished, credit the tokens. We never do that. Instead we use AdMob's Server-Side Verification (SSV): when the user finishes the ad, Google (not the client) sends a signed GET callback to one of our Cloud Functions.

That callback is signed with ECDSA P-256 over SHA-256. We verify the signature against Google's published verifier keys (cached with a TTL and refetched on an unknown key) before we move a single token. If the signature is invalid, we reply 403 and nothing happens.

Three details that close the remaining holes:

The amount is a server constant. We completely ignore the callback's reward_amount and credit a fixed value defined on our side. A client cannot ask to be rewarded more.
Cooldown. Between two credited rewards we enforce a minimum gap (five minutes for us), applied in the UI but also verified on the server.
Daily cap. A maximum number of credited rewards per UTC day, as an anti-abuse ceiling. It is not expected to be hit by a normal player, but it stops a script from grinding endlessly.

Here too, we dedup on transaction_id: a replay of an already-handled reward adds nothing. We record every event — whether it was credited or throttled by cooldown or cap — for auditing.

Failure prevented: a modified client that shouts that it watched an ad and mints free tokens. With SSV, the only source that can move the wallet is a Google-signed callback for a real view.

A short pre-launch checklist

Balance and unlocks live on the server; client rules are write: false.
The client sends product/item ids, never amounts; amounts are looked up in server-side tables.
The webhook dedups on transaction identity plus type, inside a database transaction.
Only PRODUCTION events move real balance; any sandbox switch is off.
Refunds debit with a clamp at zero and log the shortfall for review.
Rewarded ads go through signed SSV, with a server amount, a cooldown, and a daily cap.
Every movement leaves a reconcilable ledger row.
Account deletion wipes server-side data (an Apple and Google Play requirement).

None of these rules is complicated on its own. The weight is in respecting all of them at once, because each hole closes a different way to lose money or break the game economy. That is, in fact, the whole message: getting monetization right is not about sophisticated code, it is about never trusting the client, anywhere.

If you are building monetization for an iOS, Android, Flutter or web app and want to get it right the first time, tell us about the project at contact@hashcoreai.com, or take a look at how it works in practice in our games at games.hashcoreai.com.