Purchase Verification and Acknowledgement
This page describes how Nivaya is intended to handle Google Play subscription purchases for Android builds distributed through Google Play. It is written as a reviewer-facing and operations-facing statement for the billing path implemented in the app and backend.
1. High-Level Policy Position
Digital subscription purchases in the Android app should be processed through Google Play Billing. Entitlement granting should be tied to verified Google Play purchase state, not only to client-side success callbacks.
Razorpay or other payment processors may exist for non-Play or non-digital contexts, but they are not intended to be used for Play-distributed Android digital subscription purchases in this flow.
2. Client-to-Server Verification Flow
- The Android app starts the Google Play Billing purchase flow for the matching Play product ID.
- After purchase, the app receives a purchase token and related purchase metadata from Google Play.
- The app sends the purchase token, product ID, user identifier, and installation/audit metadata to Nivaya's secure backend.
- The backend checks that the purchase token has not already been used as an entitlement primary key.
- The backend calls the Google Play Developer API to verify the purchase with Google.
- The backend grants entitlement only after a successful verification result.
- The backend records audit fields such as user, token, product, verification timestamp, purchase state, and acknowledgement status.
3. Google Play Endpoints Intended for Verification
- Subscriptions:
purchases.subscriptionsv2.get - One-time products when applicable:
purchases.products.get - Subscription acknowledgement:
purchases.subscriptions.acknowledge - Product acknowledgement when applicable:
purchases.products.acknowledge
4. Acknowledgement Rules
- Initial subscription purchases should be acknowledged after successful backend verification and entitlement grant.
- Subscription upgrades, downgrades, and re-signups that create a new purchase token should also be acknowledged.
- Renewals generally do not require fresh acknowledgement unless Google Play creates a new token in a relevant lifecycle event.
- The backend should check acknowledgement state before attempting acknowledgement again.
5. Token Lifecycle and Fraud Controls
- Purchase tokens should be stored server-side and treated as globally unique values.
- The backend should reject replay of a purchase token that has already been bound to another entitlement record.
- When Google returns a
linkedPurchaseToken, the backend should revoke or invalidate the replaced token so two users cannot keep the same entitlement. - Audit logs should include verification attempts, entitlement decisions, acknowledgement attempts, and revocation events.
6. Required Production-Grade Backend Behavior
- Use a service account with Android Publisher API access.
- Verify purchase tokens on the backend, not only in the client app.
- Grant entitlement only after verification passes.
- Acknowledge the purchase from the backend when required.
- Handle cancellation, expiry, refund, chargeback, and token replacement events.
- Prefer webhook / Real-time Developer Notification handling in addition to app-open refresh.
7. Current App-State Note
The current Nivaya Android flow includes Google Play Billing, local billing history support, and a deployed backend verification path. Production operation still depends on correct Play Console subscription product configuration, service-account access, and reviewer/test setup.
8. Play Console / Hosting Checklist
- Create subscription products in Play Console that match the app product IDs.
- Host this page and the privacy policy page on a stable HTTPS URL.
- Add the privacy policy URL to the Play Console listing.
- Complete Data safety declarations to match the live app behavior.
- Prepare app access / review notes if reviewer sign-in or test subscriptions are needed.